[HN Gopher] Why video game doors are so hard to get right [video]
___________________________________________________________________
Why video game doors are so hard to get right [video]
Author : throw0101a
Score : 162 points
Date : 2021-09-04 14:04 UTC (2 days ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| daenz wrote:
| They don't cover the network relevancy in this video, but that's
| another issue. In a network game, if player 1 opens a door, you
| want player 2 to see the door opening IFF they are within the
| "network relevancy" radius of the door. If they aren't within
| that radius, the door state shouldn't be replicated. However, if
| later they do come within the radius, that network state of an
| opened door should propagate to player 2, minus the "opening"
| animation.
|
| In UE4, this is handled with 2 different network synchronization
| mechanisms: 1) multicast events (for animations) and 2)
| replicated state (for authoritative state). When player 1 opens
| the door, the server fires a multicast event to all clients
| within the network relevancy radius that says "play door
| animation." Multicast events only play once, and only to clients
| who were listening at the time of it firing. At the end of the
| door animation, the server sets the authoritative state to
| "opened." This authoritative state propagates to all clients,
| current and future clients. This allows player 2, who was outside
| the radius when the door was opened, to see the door as opened as
| they get closer, without seeing the animation playing.
| tus89 wrote:
| > In a network game, if player 1 opens a door, you want player
| 2 to see the door opening IFF they are within the "network
| relevancy" radius of the door.
|
| This is all kind of wrong. You _want_ players to see the door
| opening IFF they can see the door at all. If incompetent
| developers can 't achieve that and come up with some other
| solution and a lame excuse to go with it, that does not change
| the desire from a player perspective.
| Waterluvian wrote:
| What about hearing the door? What about any effects the door
| interaction might have?
|
| I think narrowing it to "seeing" the door might produce a
| limited result that closes a lot of doors on proper
| multiplayer handling of other game mechanics.
| crescentfresh wrote:
| > IFF they can see the door at all
|
| That is typically one of the conditions encompassed by
| "network relevancy".
| omegalulw wrote:
| How is network relevancy calculated? For example, if I'm AWPing
| the A-site door on Cache from mid, presumably, figuring out
| that the animation is relevant for me id non trivial.
| zeta0134 wrote:
| In many games I would expect this to be the same as the
| clientside render distance for the door object, which isn't
| especially expensive to compute. The server has at least a
| rough approximation of this distance at all times, affected
| by lag.
| Out_of_Characte wrote:
| For CS:GO, they do exactly this with player characters, to
| prevent simple wall hacks. Though near corners the models
| are always visible as the player could peek faster than the
| network can respond.
| MichaelEstes wrote:
| I'd imagine most first person games use their occlusion
| culling as their base for network visibility, but I could be
| wrong.
| [deleted]
| notafraudster wrote:
| Is there a concern about a race condition in this sort of
| model? Granted a time quanta is probably quite low. Like, I go
| from just outside the listening boundary to just inside after
| my client has ignored the animation cue and before my client
| gets the state cue. Absent clever visual occlusion checks it
| seems like this could be a concern. How is this kind of thing
| resolved? It's true that skipping an animation and having a
| door pop open is better than having the door stay closed and a
| desync, but it seems like there's gotta be more corner cases
| here?
| ajkjk wrote:
| Fortunately video games don't require non-raciness to the
| degree that regular applications do. I imagine that in most
| cases it's just imperfect.
| daenz wrote:
| My understanding is that the network relevancy radius is
| usually pretty large, so you're unlikely to notice a lot of
| edge cases. Also, by using events for relatively unimportant
| things (animation playing, effects, sounds, etc) and
| replicated state for the important stuff, then everything
| mostly works out correctly, since the server makes a strong
| effort to ensure _eventual_ consistency of replicated state.
|
| Where network replication matters a lot more though is on
| things like movement and shooting in competitive games. There
| is a great short series of blog posts by Gabriel Gambetta
| that covers different problems and solutions, but everything
| is a tradeoff https://www.gabrielgambetta.com/client-server-
| game-architect...
| anthony_r wrote:
| That moment when you realize that a multiplayer game is
| actually also a distributed database :)
| grumbel wrote:
| I always liked the doors in Splinter Cell Chaos Theory
| (https://youtu.be/ajlONBnhLkE?t=81), as they give you numerous
| ways to open them, including a sneaky way where you get full
| control to slowly open it in an analog fashion.
| dleslie wrote:
| The comments about the challenges, specifically walking into door
| frames and general access accuracy challenges, speaks less to the
| door than to the mode of movement. The same concerns can be
| applied to picking up small objects and navigating narrow and
| treacherous paths; both concepts which are a consistent challenge
| for game developers as well.
|
| These concerns are less pronounced on PC because fine adjustments
| are simplified by the input method. With gamepads, precise
| movements are possible but more challenging than with a mouse,
| and any player momentum amplifies the challenge.
| olivierestsage wrote:
| I always thought the first Quake had it right: doors slide open
| automatically upon the approach of the player character, and are
| always fully open by the time you reach them, so the player is
| never blocked (as long as they have the key). But obviously that
| would not work for a game set in a realistic setting.
| Gravityloss wrote:
| You don't usually realize this when playing but the scale in
| Quake is weird. Everything is big and bulky. There's just no
| budget for a lot of triangles. That makes navigating it a lot
| easier. It's closer to a driving game in some sense.
|
| Stylistically it works when in a fantasy setting, or in some
| science fiction "tech base". But it wouldn't, if you had
| ordinary everyday objects like doors, beds or kitchens around.
|
| If you've made Quake maps, you also notice that to make it
| playable, you should avoid things like protruding door frames,
| or the player easily and annoyingly gets stuck on the wrong
| side of it. The mapper must place clip brushes so the player
| smoothly flows over these obstacles. The player never notices
| these "nudges".
| dharmab wrote:
| A related article: A survey of gamedevs answering "What is a
| thing in video games that seems simple but is actually extremely
| hard for game developers to make?"
|
| https://www.ign.com/articles/turns-out-hardest-part-making-g...
| Legogris wrote:
| > For instance, I worked on a game where if you reloaded
| immediately after defeating a particular boss, you would get
| locked into the boss room, because the door leading out of it
| was not keeping its open state correctly.
|
| Reminds me of Zelda: OoT. At the final boss fight, Ganon knocks
| the sword out of your hand, the only point in the game where
| you're without a sword equipped as an adult. In early versions
| of the game, if you saved and reloaded at that point, you would
| end up with the sword unequipped, resulting in some glitchy
| behavior. For example you could now use any equipped item on
| horseback. The hookshot could be abused to allow you to move
| Link pretty much freely in 3D space.
|
| Even in later versions, you can get to this behavior by never
| picking up the first sword and lifting the left side of the
| cartridge ever so slightly when Mido blocks the way to the
| first dungeon until you have a sword, allowing you to pass
| through him. The no-sword OoT challenge is just challenging
| enough to be fun.
| mucle6 wrote:
| IIRC the glitch speedruns relied on the fact that you didn't
| have to get the master sword since you could pick it up if
| you were able to "warp" to that cutscene.
|
| https://youtu.be/OKSWkpC_SC4?t=946 Link starts at where the
| master sword gets knocked off but the premise of the speedrun
| is interesting on its own.
| faanghacker wrote:
| So basically, everything is difficult, including doors.
|
| That makes the OP article sound like clickbait, making doors
| out to be the most difficult thing about game design.
|
| Also, I wonder how much of it is due to the disconnect between
| design and software implementation. From a software
| perspective, it doesn't seem that difficult to define doors as
| a separate class or type of game object behavior, and hard code
| that behavior into sequences.
|
| It seems like the difficulty is mostly on the design/animation
| side. Controversial opinion: Maybe the problem is that
| designers and animators are just not as good at solving these
| logic problems as the software engineers.
| egypturnash wrote:
| Watch the video, it goes into detail about why doors are
| hard, especially as you start moving from "press space when
| near the door to make it slide into the wall" to "the door is
| a physics-simulated object that interacts with all the other
| physics-simulated objects in the game, and which players and
| NPCs will open in a realistic fashion that involves blending
| pre-fab animation with the location of the handle/knob
| relative to the character instead of vaguely waving a canned
| animation in the direction of the door as it magically
| opens".
|
| Never mind a door simulated at the level of "I am opening it
| _just_ wide enough for me to get outside with some food and
| water for the semi-feral cats who live under my house, with
| minimum opportunity for them to run inside before they 're
| distracted with that food, also I have to kick it to get it
| open now because this is New Orleans and the house just
| settled a little more after Ida and now the frame's a little
| less square". Which is an interaction I have with a door
| _every morning_ without ever thinking about the door.
|
| There's also a quote from a lead developer at an AAA team
| saying that doors are _the_ hardest thing to get right.
| Everything in a video game is a thin veneer of illusion, and
| doors are surprisingly complex in how they have to interact
| with _every_ level of that illusion.
| faanghacker wrote:
| I suppose if you're going for that level of realism, then
| you have more complexity like the person reaching for the
| doorknob and opening it. That's certainly more complex.
|
| Maybe the problem is trying to simulate it as a generic
| physics engine object, as opposed to a specific object type
| that has its own hard-coded rules of motion. Again, there's
| complexity involved, and I can see how it makes the job
| more difficult when you have to integrate with the rest of
| the game engine.
|
| Still, I would think that by now game devs should know that
| doors are difficult, and thus take them into account from
| the beginning when designing a game engine (maybe that's
| what they do) rather than trying to integrate them into the
| engine that's already been designed.
| short_sells_poo wrote:
| There are some things that generalize in game
| development, mamy don't. How you implement a door can
| very much depend on the sort of game you are building.
| And it can absolutely get complicated simply by the fact
| that you'll likely need to hand roll your solutions.
|
| I haven't worked in game dev in decades, but I remember
| that just network synchronization could be tricky because
| the degree to which a door is open could lead to very
| different outcomes in a game. Eg take a shooter game:
|
| Does the door block/deflect bullets?
|
| Yes? Well now you need to make sure to synchronize
| clients really cleverly because each player will see a
| different state of the door depending on their latency.
| Whether they can shoot through the opening is relative to
| each clients' reference frame.
|
| Oh, just make the server decide you say? Well, now all
| your inputs have a perceptible delay because your client
| has to wait for confirmation from the server, or you'll
| often see jarring prediction error correction when the
| thing you predicted is wrong.
|
| A huge amount of research and work has gone into this and
| yet there's still no silver bullet.
|
| That you think this is all solved just says that you know
| very little of the problem area - which is ok - but then
| you should not be making broad and confident statements
| about it. A touch of humility doesn't hurt.
| faanghacker wrote:
| Except network issues were not mentioned in the video.
| Moving the goalposts.
| short_sells_poo wrote:
| It was just an example of conceptually simple things that
| are hard in games. Are you disagreeing with what I wrote?
| faanghacker wrote:
| Not at all. Network issues make everything in games more
| complicated, not just bullets going through doors.
|
| Everything in games can be complicated: physics, doors,
| AI, network. Even the first line of that video
| description.
|
| I think that just proves my original point: it's
| clickbait to single out doors as being exceptionally hard
| versus everything else in game design.
| short_sells_poo wrote:
| > I think that just proves my original point: it's
| clickbait to single out doors as being exceptionally hard
| versus everything else in game design.
|
| That's a fair point, but I think the charitable reading
| of the title is that amongst all the complicated things,
| a conceptually simple object like a door can still be
| very deceptively complex.
|
| I sometimes get an urge to work on the myriad of game
| ideas I've written down over the years. And every time I
| remind myself that what I really like is the "idea" of
| making a game, not the actual process. Because the actual
| process is a draining, thankless and often rage inducing
| process. The actual building of a game is 95% of the time
| spent on stupid little details like making a door work
| properly.
|
| And it is for that reason that I really admire game
| developers, particularly indie ones. It takes an insane
| amount of willpower, mental fortitude and wits to take a
| game from idea to playable product. And you then have to
| contend with one of the most toxic and volatile consumer
| groups in existence.
| faanghacker wrote:
| > I sometimes get an urge to work on the myriad of game
| ideas I've written down over the years. And every time I
| remind myself that what I really like is the "idea" of
| making a game, not the actual process. Because the actual
| process is a draining, thankless and often rage inducing
| process. The actual building of a game is 95% of the time
| spent on stupid little details like making a door work
| properly.
|
| Yeah, I agree. I actually started out learning
| programming as a pre-teen by making my own games. It can
| be a lot of fun at times, but a lot of frustration too,
| and I can see how the latter eclipses the former as as
| you scale into a more complex game and with a bigger
| team.
|
| It's not an easy job that's for sure.
| faanghacker wrote:
| I watched the video again. Still don't see what the big deal
| is. For example...
|
| NPCs blocking doors? Don't put NPCs there, and tell AI to
| avoid door zones rather than trying to make them know how to
| move out of the way when doors open.
|
| Car on the other side of the door? Don't let the door open
| all the way.
|
| In the elevator example in the IGN article: Implement an
| elevator door like in modern elevators, or if it's more
| primitive, don't let players or NPCs walk under the elevator,
| or worst case, kill the character -- can't call the AI dumb
| if they avoid being under the elevator that can kill them.
|
| This isn't an unsolved problem. Halo did this with
| telefragging someone who is blocking a teleporter, and
| StarCraft did this by destroying the siege tank under a
| landed building.
| short_sells_poo wrote:
| Everything you describe is an ugly hack that ruins
| immersion and suspense of disbelief. Are you proposing the
| AI shouldn't be able to use doors? What if an NPC wants to
| open a door at the same time as a player? Are you
| suggesting that gamedevs should add an entire myriad of
| these exceptions to all the interactive aspects of the
| game? That's wholly infeasible. Players can and will break
| sort of game design in wild abandon.
|
| You are trying to build a believable world, or at least one
| with as few uncanny valleys as possible.
|
| Doors are hard, as is everything interactive. That doesn't
| mean people shouldn't try to make these things better. And
| at the same time, we need to acknowledge that doing this is
| bloody hard.
| gus_massa wrote:
| > _StarCraft did this by destroying the siege tank under a
| landed building_
|
| If this in StarCraft I? In StarCraft II even a burrowed
| zergling can prevent the landing of a Command Center. (That
| makes no sense from a realistic point of view.)
| faanghacker wrote:
| Yes, StarCraft I. The issue wasn't physical realism. The
| problem was that a player could move a tank under a
| building during mid-landing, siege it up, and the
| boundaries of the building protected the siege tank from
| melee attacks.
|
| Killing the tank was the "creative" solution, instead of
| a "brute force" solution to change the game dynamics to
| prevent the tank from sieging up under the building in
| the first place.
|
| In SC2 the tanks will be forced to move out from under
| the building when it lands, but SC2 also has a much
| improved unit movement system over SC1 that allows this
| to be done more easily.
| sgarman wrote:
| I've never seen this in any of the BW games I watched. I
| wonder if they fixed it. You just can't land a building
| where a unit is. There was a crazy bug where you could
| load units into a flying CC and use it as a mobile
| fortress but that too is patched.
| faanghacker wrote:
| That was the whole point -- it was fixed early on by
| killing the tank, rendering the exploit useless, which is
| why you never see it in games anymore.
|
| Search on YT for the tank glitch.
| duskwuff wrote:
| Yes. And it only became relevant if you exploited a race
| condition by ordering the building to land, then ordering
| a siege tank to move under that landing point while the
| landing animation was in progress. You couldn't order a
| building to land on top of a unit, and a queued order to
| land would fail if any units were in the way, but once
| the building _started_ to land, it wouldn 't stop, and
| any units under it would be trapped. The bug fix added a
| second check which would kill any units under the
| building when it finished landing.
|
| In principle, you could do this with any unit, but it was
| mostly useful for siege tanks, since those were the only
| Terran ground unit which really benefited from sitting in
| place.
| burnished wrote:
| Sounds like you'd benefit from giving it a try. I'm going to
| go out on a limb here; you're at that stage of your life
| where everything you haven't tried sounds simple and you
| don't understand why other people struggle so much. I'm
| guessing this because on hearing that something is difficult
| your first suggestion is to.. simply design a class, and then
| suggest that the problem resides in the kinds of people
| approaching the problem.
|
| Its a sort of arrogance that I think will be familiar to many
| people. But it sort of assumes that other people are too
| stupid or incompetent to try <insert obvious easy solution>.
| You might do better by trying to figure out what went wrong
| with the 'obvious' solution, or what you are missing in your
| own understanding that makes the problem appear so much
| simpler. If you figure out novel solutions, great! That's
| real genius. I think mostly you'll find out how tough most
| problems are.
| faanghacker wrote:
| I didn't say it was simple, I'm sure it's a complex
| problem. But maybe not disproportionately difficult to
| model if you can handle the complexity. That's why I gave
| the benefit of the doubt to the software engineers.
|
| IME Most people can't handle complexity in their own fields
| of work, whether it comes to tax accountants making
| mistakes on my tax return that I caught later; or real
| estate agents telling me my queen-sized bed won't fit in
| the apartment, when I already knew from analyzing the
| floorplan that it would, and I was correct when we measured
| the room; or international flight attendants overcharging
| me because they can't do currency conversions properly.
| I've worked in the software industry including FAANG and
| dealt with a wide range of people, some of whom I've had to
| explain basic problem solving concepts or do things for
| them that they should have done themselves.
|
| Believe me, I'm at the stage of my life where I've tried a
| lot of things, succeeded at some, and failed at others.
| I've lived in different cities in different countries. More
| importantly, having been exposed to a wide range of people,
| I am less inclined to overestimate most people's ability to
| do things.
|
| Is that arrogant? Maybe. But I started out assuming that
| everyone has some latent untapped
| talent/creativity/curiosity/potential and over the years
| I'm less inclined to give people so much benefit of the
| doubt.
| scrollaway wrote:
| Ah, you're one of those people.
|
| Sounds to me like the person you're replying to had you
| perfectly figured out. If you're lucky one day you'll get
| to look back on this comment in regret. If not, you'll
| keep living in ignorance.
| faanghacker wrote:
| Good thing I had the foresight not to "follow my
| passions" and work in big tech instead of game dev or
| academia, which is why I'm retired and don't need to
| worry about either regret or ignorance.
| jcelerier wrote:
| for someone without regrets your comments sound awfully
| bitter
| faanghacker wrote:
| It's called becoming a curmudgeon once you have dealt
| with enough bullshit in your life. I think much of the HN
| community can relate to that.
| dharmab wrote:
| Thank you for writing up a clear headed response. I had
| started to write a response to the comment, but decided I
| didn't know a way to phrase it in a way that would be
| constructive and decided not to submit.
| 5faulker wrote:
| Doors are one of those things that seem simple but actually
| is not, due to it being an interaction point between players
| and the game.
| Animats wrote:
| Move, shoot, and drive are easy, or at least well worked out,
| and everything else is hard. Doors are just a common case of
| "everything else" Sitting down realistically is hard.
| Standing up realistically is hard. Picking up stuff
| realistically is hard. Interacting with any object via
| contact is hard. Interacting with moving avatars is really
| hard.
|
| The hard problems come up when you actually have to do motion
| planning, in the robotic sense. Few games do that. In most
| games, you're just moving the avatar while running canned
| animations. UE5 has a new dynamic animation system which is
| supposed to help with this. In the UE5 demo video, you see
| the character walk through an open doorway, and she reaches
| out and touches the doorframe. That's some kind of IK-driven
| animation triggered by proximity. Not clear if the mechanism
| behind that is general enough to handle door opening. Anyone
| know?
|
| In virtual worlds, where you don't have pre-planned gameplay,
| it's a big problem. Second Life has hundreds of thousands of
| doors, and at least three vendors of door control software.
| Usually, doors have to be clicked on to open them, although
| stores often have automatic sliding doors.
| djmips wrote:
| And ladders. ;-)
| Kinrany wrote:
| An essay about game development professions that uses doors as
| the main example: https://lizengland.com/blog/2014/04/the-door-
| problem/
|
| Edit: mentioned in the end of the video, of course :)
| faanghacker wrote:
| I noticed that most if not all of these questions are
| applicable to doors in even simple 2D games.
|
| Whereas the physics engine and real-world realism aspects are
| what the video talks about.
|
| If the problem is that doors are inherently difficult to
| design, the counterpoint is that these questions have already
| been answered in multiple ways over the past 30+ years of video
| game history. It's easier today than ever to answer these
| questions by drawing on previous games.
| sluggosaurus wrote:
| While I'm duly impressed by the achievement of hyper-realistic
| door physicals, the effort:payoff ratio seems completely wack. I
| think these game developers are overthinking it. Minecraft does
| doors right in comparably simple way, and I think few if any
| players have a problem with it; it's a more popular game than any
| game with fancy doors. The most realistic doors in the world
| won't make a bad game any better, while simplistic doors won't
| make a good game any worse.
| lazugod wrote:
| > Minecraft does doors right in comparably simple way, and I
| think few if any players have a problem with it
|
| Ha. This is an amusing claim given that redstone, the whole
| complicated circuitry used in advanced Minecraft machines, was
| arguably added for the purpose of powering doors. Years of work
| have gone into all of the community-made piston doors of
| various sizes and features. And all interactive components like
| buttons and pressure plates have to have their signal duration
| balanced against how long it takes to walk through a door.
|
| Even ignoring redstone, though, doors are complicated to design
| in the exact same ways. Which way do they swing open? Depends
| how you're facing when you place them... unless the game
| detects double doors, and reverses the second one to match. And
| each door has to have a corresponding vertical trap door, which
| can either be flush with a floor or with a ceiling. Which way
| do trap doors open? Well, whichever way works best with the
| ladder below them. Oh, which means trap doors must also act
| like ladders. In fact, you can climb a wall of nothing but trap
| doors in the game.
|
| What about water? Trap doors can be waterlogged, and that's a
| common way to hide irrigation. But normal doors intentionally
| aren't. Why? Because doors are the most common early-game tool
| for scuba diving - a placed door becomes a free pocket of air.
| Does it seem realistic? No, and maybe they could fix it, but
| then that would affect anyone who uses doors as entrances to
| underwater houses, as well as make scuba diving more difficult.
|
| Players argue about the use of doors for diving; they argue
| about whether they should be able to shoot arrows through the
| windows in doors; they argue about whether every new tree
| should bring a new type of wood, and thus a new type of door.
|
| Doors are hard, no matter how simple the game.
| sluggosaurus wrote:
| I'm utterly unconvinced. Point by point:
|
| Redstone: The surprising complexity of a redstone torch does
| not confer complexity to a minecraft door, even though you
| could use that torch to open or close a door. A minecraft
| door has one binary state relating to redstone, powered or
| unpowered. That's it. The redstone functionality a minecraft
| door has is very simple by the standards of many other
| redstone-capable blocks in the game.
|
| Piston doors: Can be arbitrarily complex, but these do not
| confer complexity to regular minecraft doors.
|
| Placement: Minecraft doors are not the simplest block in this
| regard, but they are far from the most complex. Just compare
| them to stairs. Stairs have four attributes:
| facing[east,west,north,south], half[bottom,top], shape[inner_
| left,inner_right,outer_left,outer_right,straight]. There are
| 80 ways any stair block can be configured. There are only 64
| configurations of a door block in minecraft (as far as the
| player need be concerned, it's only half of that since half a
| door implies the other half, similar to an extended piston.)
| Incidentally, there are 9 materials a door can be made out
| of, but _48_ materials stairs can be made out of. And 8 of
| those 48 stairs have the special behavior of turning into
| other material, while only one of the 9 door materials has
| special behavior.
|
| Waterlogging: Regular minecraft doors have never waterlogged.
| Waterlogging is complexity added to other blocks in the
| aquatic update, but doors were not changed. There was no
| complexity added here. And doors are not the only blocks
| which weren't updated for waterlogging; there are dozens of
| other blocks like this.
|
| Trapdoors: Are more complex than regular minecraft doors.
| Trapdoors being complex does not mean that regular minecraft
| doors complex.
|
| Players wishing doors had more complexity: Is not doors being
| complex.
|
| > _Doors are hard, no matter how simple the game._
|
| Doors are extremely complex in some games, and significantly
| less complex in others. Complexity is not a binary trait. I
| claimed that minecraft doors are _comparably_ simple,
| particularly when compared to the doors in TLOU2. I stand by
| that.
| williamdclt wrote:
| Minecraft-style door animations (ie, no animation) would
| absolutely break immersion in a game with a realistic style.
| You can make a game that does not look realistic, but that's a
| completely different art direction, we can't just wave away
| complexity
| sluggosaurus wrote:
| Okay, comparisons within a particular artistic style then:
| Splinter Cell vs Metal Gear Solid V. MGSV has somewhat
| realistic doors, but much simpler than the door system SC:CT
| has. I've heard quite a few player complaints about MGSV, but
| never that the doors are less complex than the doors in a
| stylistically similar game ten years older. Splinter Cell
| gets some praise for doors, but Metal Gear doesn't get
| criticized for for falling short of that high bar.
|
| Another example from _beenBoutIT_ : The Last of Us and its
| sequel have the same sort of style. The sequel has superior
| doors but is generally considered an inferior game. The
| quality of the doors really doesn't seem to be a major factor
| in how these games were received.
|
| Minecraft itself: minecraft doors having no animation was not
| a foregone conclusion derived from the broader style of the
| game. Minecraft pistons _do_ have animations when extending
| or retracting. I 've never heard a player complain that
| minecraft doors are lack what minecraft pistons have.
|
| I think that most video game players are accepting of doors
| behaving in unrealistic ways. Simple doors don't actually
| bother most players, and complex doors _usually_ go
| unappreciated by most players. Contrary to what the video
| claims, doors _can_ 'just magically fly open', and players
| don't care.
| beenBoutIT wrote:
| Managers need to be able to spot OCD spirals and keep things on
| track. Having perfectly realistic doors isn't that important -
| the end user only notices them when they break. TLOU2 is
| remembered most for being less great than TLOU and not for its
| superior door mechanics.
| Anon_troll wrote:
| > Minecraft does doors right in comparably simple way, and I
| think few if any players have a problem with it
|
| See https://bugs.mojang.com/browse/MC-149060 "Villagers "spam"
| doors by opening and closing them really fast"
|
| Or
| https://bugs.mojang.com/browse/MC-69281?jql=text%20~%20%22do...
| to see the 6000+ bug reports related to doors.
|
| Or watch https://www.youtube.com/watch?v=aiEq0bJcAz0 "Villager
| door spam"
| adnzzzzZ wrote:
| There's value in getting things right no matter how long they
| take and no matter if people will notice it or not. I
| personally don't hold this view too strongly but I can
| understand other gamedevs who do.
| sluggosaurus wrote:
| I understand how artists would think that way. Obviously they
| have passions and care about details few except other artists
| would notice. But on a commercial project, shouldn't managers
| reign in on this sort of thing and redirect the efforts of
| artists in a more productive direction?
| robbrown451 wrote:
| It's funny how, right at the beginning (20 seconds in), he is
| saying he is impressed with the doors in Last of Us Part II,
| while showing a door that closes in one direction, then opens in
| the other. This would be especially impossible given the closer
| mechanism at the top of the door, but then you notice that both
| parts of the mechanism are attached to the door itself (rather
| than one being attached to the door frame) and just swings with
| it, so it is worthless as a closer mechanism.
|
| I can't blame the devs for taking shortcuts like that, but still
| a bit weird to call that one out as an impressive example.
| Trasmatta wrote:
| > but still a bit weird to call that one out as an impressive
| example
|
| Everything else about the doors in TLOU2 _is_ impressive,
| though. I don 't think there's any game that exists that has
| doors that are as well engineered as TLOU2 that also properly
| swing in only one direction.
| sparker72678 wrote:
| This is a great video.
|
| Next I'd love to see, "Why online checkout forms are so hard to
| get right."
|
| Software is hard.
| ehnto wrote:
| Part of the reason is that the state can be extremely complex.
| It looks like some simple forms, but if you were to write out
| all the state combinations for tax, location, shipping, product
| combinations, configurations, logged in/out, guest/account,
| pricing rules, payments, inventory, warehousing,
| internationalization, so on and so fourth, you get a pretty
| complex state machine.
| fsckboy wrote:
| yes, the state machine can be complex, but there's no excuse
| for throwing away the state that represents everything the
| user has gone to the trouble to enter in, that is not complex
| and should be preserved.
| falcor84 wrote:
| I'm not quite following you there, other than possibly the
| authentication piece, all of the other variables seem to me
| to be recalculable from scratch every time - where else would
| you need state transitions? (i.e. where is there Path
| Dependency?)
| matsemann wrote:
| Validation. A field is incorrect, but only because it
| hasn't been touched yet so don't show an error. Or it's
| incorrect because the value isn't allowed based on another
| change you made in the form.
| bladedtoys wrote:
| For the curious, one extremely useful tool used for things like
| this is "inverse kinematics"[0] In this case you need the wrist,
| elbow, shoulder, hip, etc joints to bend such that the hand
| exactly reaches the door knob and stays on the knob as the door
| swings open possibly stepping the legs forward or backwards.
| Coding inverse kinematics from scratch is definitely non-trivial,
| luckily that is rarely necessary.
|
| https://en.wikipedia.org/wiki/Inverse_kinematics#Inverse_kin...
| wincy wrote:
| Isn't Star Citizen expending a great amount of effort in coding
| reverse kinematics for their entire game?
| simion314 wrote:
| I am wondering why floors also are hard, the falling though the
| world is a bug I see too often, especially on the indie games I
| tried.
| fxtentacle wrote:
| For keeping things from falling through, you need to project
| the movement vector onto the plane. That means sqrt of
| magnitude and dot product. If you keep doing that every frame,
| a lot of tiny and otherwise insignificant floating point errors
| are going to sum up.
|
| The correct approach is to not model the floor as thin sheet
| geometry but instead to model it as solid objects, e.g. the CSG
| approach used in Quake, Half-Life 1 and Unreal 1 & 2. I believe
| those games didn't have any falling through bugs.
| foxfluff wrote:
| https://wiki.beyondunreal.com/Legacy:BSP_Hole
| fxtentacle wrote:
| Also there, I believe the underlying issue is lack of
| floating point precision. That's why the fix is to nudge
| the brush a bit and/or move it back onto the integer grid.
| thaumasiotes wrote:
| > The correct approach is to not model the floor as thin
| sheet geometry but instead to model it as solid objects, e.g.
| the CSG approach used in Quake, Half-Life 1 and Unreal 1 & 2.
|
| While I never actually did any level editing, I did read a
| guide to the Unreal Tournament level editor, which said that
| UT was unusual in that a blank level was filled with mass and
| the level creation process involved subtracting that away to
| create empty space, rather than adding objects to an empty
| void.
|
| Related?
| Animats wrote:
| This is why people buy physics engines or use game engines with
| physics engines built in. It's a solved problem, but the heavy
| machinery is non-trivial.
|
| (I used to work on ragdoll physics.)
| tinus_hn wrote:
| It's not hard, Quake did it right many years ago. It just
| requires you to limit yourself in ways that aren't acceptable
| these days.
| bruce343434 wrote:
| As someone outside of this field, could you elaborate on how
| quake "did it right" and how it requires you to limit
| yourself?
| tinus_hn wrote:
| Quake, for optimization reasons, did a lot of preprocessing
| on the geometry that makes up the world. This made it
| possible to render it on slow hardware. The process for one
| required the designer to make sure there were no cracks
| anywhere to fall through, because if you had one the
| preprocessing would fail.
|
| The preprocessor divides the entire inside of the level
| into convex areas and builds a graph that expresses where
| they touch. So for movement, if you just make sure that you
| can only go from one area into another that according to
| the graph touches it, there simply is no way to move out of
| bounds because the out of bounds area is not in the graph
| at all.
|
| This does mean though that you have a world that is mostly
| static, that consists only of indoor spaces and has a
| limited amount of complexity because otherwise the
| preprocessing results in an unmanageable amount of data.
| There is just no way you can preprocess the whole world
| like that in a modern open world game.
| [deleted]
| djmips wrote:
| I think it's because floors are often modelled infinitely thin,
| a plane with no thickness. It's all to easy to get on the wrong
| side of that plane for any number of reasons.
| simion314 wrote:
| But why not model it with 1m thinness and put some trigger
| code if you touch the other side to reset you, same for
| objects.
|
| I am not a game dev, so at first look a level editor that is
| mostly drag and drop should solve this for the level
| designers, but for some reason you can still fall through
| floors.
| umvi wrote:
| Scenario:
|
| - you have a 1m thick floor in your video game.
|
| - your video game has physics in it (like gravity,
| collisions, etc).
|
| - your game runs at 60 fps
|
| Given these assumptions, if any in-game object ever exceeds
| a velocity 60 m/s then on one frame it will be above the
| floor and on the next frame it will be below the floor
| without ever triggering a collision. Oops.
|
| Let me guess: "Just make the floor infinitely thick". Sure
| that would work but it sort of limits the kinds of maps and
| terrain you can make if the floor is always infinitely
| thick.
|
| One way to solve it without infinitely thick floors is to
| draw an imaginary line between your current position and
| previous position every frame and check if the line would
| have collided with anything . If it does - do something
| (make the player die, move them back above the floor,
| etc.). It gets more complex when it's not just the floor
| you have to worry about clipping through but the wall and
| the ceiling and all other objects.
| adanto6840 wrote:
| Oh we definitely try "simple" approaches like that,
| whenever we can. And if the entire 'level' is, well, level
| & there are no elevation changes (or elevation changes are
| restricted to '1 elevation per floor of a structure, for
| instance) then sure, that type of solution works.
|
| Otherwise though, the 'trigger' code you suggest ends up
| generally being some kind of math (ie physics, regardless
| of whether it's via a physics engine layer or a game/state
| layer); you essentially have to figure out "where" on the
| plane the object is, convert that to the proper coordinate
| system for your overall level, and then 'sample' the
| underlying terrain/mesh/ground covering to figure out if
| you're in a legal position.
|
| Typically this ends up being implemented as a "clamp" of
| sorts; you will pretty rapidly end up with oddities,
| floating point precision quirks, and the like.
|
| The "best solution" will vary, often drastically, from game
| to game.
|
| FWIW, I've been doing game-dev for almost 10 years now &
| have almost exclusively done "AI/NPC" agents. We've faced
| what I would classify as pretty much the same issue with AI
| agents, especially when you want them to follow nice,
| smooth paths while also realistically 'bumping into' each-
| other -- yet ensuring that they will _never, ever, ever_ go
| through a wall. It sounds so stupidly-simple but, I can
| assure you, it is not! If you had unlimited resources
| (read: CPU), then it 's not so bad, you can calculate for
| "optimal" every frame -- in reality, you never have
| unlimited resources, and seemingly-simple calculations like
| this have to run extremely fast and they cannot be allowed
| to fail (there's nothing more frustrating & game-breaking
| than NPCs that get 'stuck' behind a wall or in an area that
| they cannot vacate, etc). You can write code for agents to
| "detect stuck + get un-stuck" but, similarly, doing that
| fast is non-trivial; and ideally you don't want them stuck
| to begin with!!
|
| It's a massive can of worms. ;)
| wcarss wrote:
| Related, here[1] is an excellent ~hour long talk by Kerry Davis
| of Valve about how much thought they had to put into doors for VR
| while working on Half Life: Alyx.
|
| 1 - https://www.youtube.com/watch?v=9kzu2Y33yKM
|
| (edit: it looks like digipen also posted that talk themselves,
| and theirs doesn't have the ~10-15 minute gap the VNN one has,
| but theirs seems to not have the slides. Take your pick!
| https://www.youtube.com/watch?v=8OWjxGL8PDM0)
| TOMDM wrote:
| The doors in Alyx feel so good.
|
| Poking a gun through, or quickly tossing a grenade and then
| closing the door again felt so natural.
| usrusr wrote:
| Proud second place on the list of best doors in video games,
| after the XCom door that is only ever correctly opened by
| carefully arranging six soldiers in descending order of
| disposability before touching that right mouse button.
| mensetmanusman wrote:
| I still occasionally laugh at recalling how doors worked in Quake
| 2; if you made your own doors in the map editor it was possible
| to design some that would open up like normal doors but they
| would turn you to gibs if you were unfortunate to stand in their
| turning path.
|
| Great way to play tricks on friends.
| [deleted]
___________________________________________________________________
(page generated 2021-09-06 23:00 UTC)