HN Theater @HNTheaterMonth

This is an interesting video about how hard it is to effectively animate just one small aspect of human motion: walking through a door: https://youtu.be/AYEWsLdLmcc

Interactions can be really hard to get right, see doors [1]

1. https://www.youtube.com/watch?v=AYEWsLdLmcc

⬐ pugworthy

I quite like door interactions in VR - specifically Half-Life: Alyx

⬐ wcarss

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)

⬐ MarkMc

Fascinating that players in VR would not attempt to turn the handle of a latched door, and instead would simply assume the door was locked. And the solution was incredible: simply play the hand-rotation animation when the player grabs the handle - and the player will think they had rotated their hand!

⬐ gardaani

Doors in Alyx were so difficult for me. It took few minutes before I got the first door open. I tried to grab the handle and then walk forward, but somehow it didn't work. I think the correct move is to grab the handle and swing it open with an hand motion. Anyway, I didn't understand why it was made so much more difficult than in real life.

⬐ TOMDM

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

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.

⬐ grumbel

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.

⬐ Stevvo

Chaos Theory has got to be one of my favorite games of all time; the movement is sublime, to this day unmatched by other entries in the series.

⬐ dharmab

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...

⬐ faanghacker

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

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

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

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

Except network issues were not mentioned in the video. Moving the goalposts.

⬐ short_sells_poo

It was just an example of conceptually simple things that are hard in games. Are you disagreeing with what I wrote?

⬐ faanghacker

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

> 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

> 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.

⬐ midnightclubbed

Many games do simulate/animate/synchronize doors with their own custom systems because doors are way more complex and problematic than 99% of other in-game objects.

⬐ Animats

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.

⬐ 5faulker

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.

⬐ faanghacker

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.

⬐ fredophile

So your first solution means that NPCs can't interact with doors. What if your game needs NPCs to be able to move around freely and not be trapped in the rooms they spawn in.

Your blocked door solution also has some issues. How do I represent the state of a partially open door? Can a partially open door block bullets? Can I move through a partially open door? Can NPCs? What happens if the car moves towards the door while it is partly open? What if the car moves away? What happens if I try to interact with a partially open blocked door? What happens if I try to interact with a partially open unblocked door?

⬐ gus_massa

> 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

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

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

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.

⬐ gus_massa

I only found buildings crushing interceptors https://www.starcraftai.com/wiki/Tricks,_Glitches_and_Exploi...

⬐ duskwuff

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.

⬐ Hikikomori

Doors are complicated? Just don't have doors, problem solved. Game is complicated? Just don't create game. Such easy solutions.

⬐ short_sells_poo

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.

⬐ burnished

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

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

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

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

for someone without regrets your comments sound awfully bitter

⬐ faanghacker

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

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.

⬐ Legogris

> 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.

⬐ don-code

Ah, the Crooked Cartridge trick! I haven't heard this mentioned since the 2000s. Zelda: OoT was (and still is) one of my favorite games of all time, and I was devastated to have bricked my cartridge this way - along with my nearly-fully-finished game (IIRC it was just the Golden Skulltula sidequest remaining).

To be fair, it was _saving_ after having performed the glitch that persisted glitched data to the save RAM, but I only figured that out seven years later.

⬐ mucle6

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.

⬐ mensetmanusman

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.

⬐ robbrown451

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.

⬐ michaelt

> still a bit weird to call that one out as an impressive example

Well, the clips from Last of us seemed to be the only ones where the character put their hand on the doorhandle, and kept it there for the duration of the door opening. And the door didn't visibly clip through anything on the other side.

The clips from Fortnite and Hitman, in contrast, didn't show the player character using the door handle at all.

⬐ Trasmatta

> 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.

⬐ robbrown451

True, and I doubt I would even notice a problem if playing the game. It's just when you are specifically looking at the doors, stuff like that jumps out at you. If I made the video, I probably would have edited it a bit differently so it doesn't call attention to flaws at a time when he's making the opposite point.

⬐ LanceH

The reason doors open both ways is so a player doesn't have to back up when opening a door inward. While it's something we do in person easily enough, it requires fine movements of a character or it requires taking over the character. Both feel awful for the player. So, the sacrifice of having the door open unrealistically both directions.

Can you imagine running away from the zombies, you reach for the door, move to back up and realize you didn't quite grab the handle? Or the other version where you do grab the handle and realize you need to let go of it to start shooting, but are stuck in an animation.

Personally, I'm cool with worlds with no doors and outsized doorways. Ideally the scenery between my character and the camera fades out, so the camera only has to move to follow, not to get a better angle. I do admire the effort that goes into it making the doors look good.

⬐ sparker72678

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

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

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

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?)

⬐ ehnto

I was mostly using a state machine as a way to frame the complexity of the domain, most checkouts don't use state macines but the possible state permutations exist even if only calculated once.

⬐ matsemann

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.

⬐ sluggosaurus

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.

⬐ Anon_troll

> 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"

⬐ williamdclt

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

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.

⬐ adnzzzzZ

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

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?

⬐ yissp

A first-person perspective avoids some of the issues discussed in the video, like camera placement. I imagine it's also easier to animate if you only need to worry about the player's hand and lower arm.

⬐ beenBoutIT

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.

⬐ lazugod

> 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.

⬐ nyanpasu64

> that would affect anyone who uses doors as entrances to underwater houses

Given the current Java waterlogging mechanisms, even if doors acted like slabs and trapdoors, they would still hold out water source blocks present on one face. It would still break scuba diving though.

⬐ sluggosaurus

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.

⬐ djmips

nice goalpost move.

⬐ mastazi

The more I delve into game development the more I'm convinced that we in fact do not live in a simulation.

Why would someone spend day after day carefully modelling things that no one seems to notice anyway?

For example the way in which dead leaves accumulate in a specific corner of my balcony.

If those beings that created the simulation are so advanced that they created this amazing word, why were they at the same time so stupid that they didn't do any optimisation and instead decided to model and refine things that almost no one notices anyway?

If those intelligent beings decided to spend less time on that aspect, and leaves accumulated on my balcony in a less complicated pattern, I wouldn't notice anything weird anyway, because I would be accustomed to that other less complicated pattern. So there would be no reason to make an effort on that.

⬐ throw_m239339

> The more I delve into game development the more I'm convinced that we in fact do not live in a simulation.

We'd have to define what a "simulation" is at first place. There is an order to the universe, it's just not a man made concept, since physics have rules, whether we can understand them, or not, rules that mankind did not make, just observe.

These rules are objective since we can make predictions with these rules. Quantum physics is valid otherwise we wouldn't be here exchanging comments through computers. So there is something akin to a program, that's undeniable.

> Why would someone spend day after day carefully modelling things that no one seems to notice anyway?

Because these things have a purpose that defy human understanding. You're assuming the alleged simulation is made for us or for our purpose, whatever it is, but we can't even tell what the purpose of mankind at first place.

I believe, from the point of view of a sentient "god", the all powerful programmer, who lives outside the universe, we live in something akin to a simulation and there is a world outside the program.

Maybe that "god programmer" is rolling dices with some variable adjustments and see how everything unfolds, we live in that running simulation.

a lot of scientists already think that our universe is akin to a hologram. So that's a valid idea. We'll never know anyway.

⬐ ruined

i mean, if you're looking at it, it's obviously important enough to simulate.

and what, specifically, do you think you would notice if it was in some way simplified? how can you be certain about the leaves on your balcony? you have no objective frame of reference to compare "full detail" simulation.

⬐ mastazi

> if you're looking at it, it's obviously important enough to simulate.

basically the argument I was trying to make is: if it wasn't simulated I wouldn't be looking at it, and I wouldn't find it strange at all because I would be living in a world where that thing doesn't exist

> and what, specifically, do you think you would notice if it was in some way simplified?

exactly, I wouldn't notice anything.

My argument is: if those beings are so smart that they created this awesome simulation, how could they be so dumb that they wasted time simulating unneeded details?

⬐ Talanes

Maybe someone on the team really likes leaves. Fallout 3 only has so many beards because one artist got a whim and cranked them all out.

⬐ throw_m239339

> My argument is: if those beings are so smart that they created this awesome simulation, how could they be so dumb that they wasted time simulating unneeded details?

How do you know if things exist if you're not looking at them? I'm jesting of course, but isn't it a question that quantum physicists ask themselves?

⬐ ruined

if it's within your perception it's needed detail

⬐ ruined

>if it wasn't simulated I wouldn't be looking at it, and I wouldn't find it strange at all because I would be living in a world where that thing doesn't exist

why do you think this isn’t constantly happening?

>how could they be so dumb that they wasted time simulating unneeded details?

if it’s within your perception, it’s needed detail.

⬐ sdenton4

Go read Permutation City... There's two threads of simulation, one which is hacky video games style, and the other is built up entirely from simple physics.

⬐ burnished

Well, you're sort of assuming that our physics are the full range of physics, and everything is being modeled faithfully. What if our simulation is just a subset? That is to say, everything is already a less complicated pattern (from a certain perspective) and you don't notice because you don't know any better.

⬐ exporectomy

If they're superhuman, all those details might be as easy for them as scenery in a model railway.

More convincingly though, if leaves didn't behave that way, the entire rest of the world would have to be designed in a consistent way. Fluid dynamics would have to work differently - and consistently with everything else or we'd notice.

⬐ perryizgr8

> decided to model and refine things that almost no one notices anyway

You certainly noticed.

⬐ TheRealNGenius

This is kind of off topic, you're really stretching it by bringing in talk of living in a simulation when we're just talking about doors. This is neither evidence for or against that argument

⬐ burnished

OK so what if we're in a.. video game simulation and one of the really difficult issues is getting the emergent populations to not notice that they are being simulated, much like our difficulty with doors. There. Back on topic.

⬐ TheRealNGenius

Then roko's basilisk ;p

⬐ burnished

oh this is the first I've heard of that, how interesting, thank you!

⬐ wtetzner

Maybe they just wrote a simulator for physics, and what you’re noticing is just emergent behavior.

⬐ mastazi

Yes that's a good point. What I'm seeing might be an unintentional by-product.

⬐ bennyelv

Maybe the point of the simulation was the leaves and you're the unintentional by-product...

⬐ dleslie

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.

⬐ simion314

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.

⬐ djmips

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

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

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

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. ;)

⬐ Animats

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.)

⬐ db48x

https://www.youtube.com/watch?v=YE8MVNMzpbo

Here’s a game developer talking about the problem and how they solved it in The Witness, but note well the limitations he describes. It’s not directly useful if the player can jump, for instance.

⬐ tinus_hn

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

As someone outside of this field, could you elaborate on how quake "did it right" and how it requires you to limit yourself?

⬐ None

None

⬐ tinus_hn

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.

⬐ fxtentacle

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

https://wiki.beyondunreal.com/Legacy:BSP_Hole

⬐ fxtentacle

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

> 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?

⬐ fxtentacle

Yes and no.

The Unreal approach makes it easy to create levels with a waterproof outer hull which allows you to use certain optimizations (such as portals in the BSP tree) to reduce what you need to draw.

But even without that, CSG usually produces only geometry that has a thickness, and that's what helps with the sliding through floors in the first place.

But since the Unreal approach makes it very easy to query if a point is inside the valid space of the level, or not, that's also used as a shortcut for determining if things did fall through somewhere.

So yes, the "blank filled with mass" approach further reduces the problem but no, it's not strictly necessary.

⬐ Kinrany

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

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.

⬐ bladedtoys

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

Isn’t Star Citizen expending a great amount of effort in coding reverse kinematics for their entire game?

⬐ account42

As far as door controls go, I really like Frictional Game's approach to controlling doors via an analog mouse motion as seen in the Penumbra and Amnesia series. Not only does this feel a bit more natural than having an animation play after clicking, you are also fully in control of how far the door is open at any time.

⬐ olivierestsage

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

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".

⬐ scambier

Relevant Twitter threads:

https://twitter.com/ZenOfDesign/status/1369336758211608583

https://twitter.com/kurtmargenau/status/1369342602177220609

⬐ fspacef

Skyrim did it best

⬐ djmips

And ladders. ;-)

⬐ daenz

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.

⬐ omegalulw

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.

⬐ MichaelEstes

I'd imagine most first person games use their occlusion culling as their base for network visibility, but I could be wrong.

⬐ Nition

One method is:

- Divide the world into a grid.

- Put everything into the world into its grid square (based on position).

- Have the local player ask the server for everything in their own grid square plus the eight around them. Or more if you want the player to see more than one grid square ahead.

- Have the local player also dump anything that goes out of grid range.

Note that this only applies to networked objects, so it doesn't mean the player has to see a blank void beyond their grid range. You can still show them a low LOD view of the world without networked objects. You might also network some things with greater range than others.

In your case, I'm not familiar with the game you're talking about, but do you mean "how does it know to network something to me if I'm shooting it from far away?" You could have the server check who damaged the door and make sure it's networked to them once it takes damage.

⬐ zeta0134

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

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.

⬐ tus89

> 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.

⬐ Hikikomori

Depends on how important such events are in the game. Lazy, or just being smart with your limited resources as culling like this isn't cheap.

⬐ Waterluvian

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

> IFF they can see the door at all

That is typically one of the conditions encompassed by "network relevancy".

⬐ notafraudster

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?

⬐ anthony_r

That moment when you realize that a multiplayer game is actually also a distributed database :)

⬐ midnightclubbed

Not so much race conditions but the distances doors synchronize across the network has to be really carefully synchronized with the weapon ranges, character rendering ranges and building mesh level-of-detail.

If doors synchronize closer than a player's sniper rifle range then a player can either stand just behind a door (that is open for them) and shoot people at range (who see the door as closed). Or the door defaults to open and a closed door that seems like cover allows you to get sniped.

While the ideal is to synchronize everything at the same distance, if you have 100+ players on a single map and a sniper rifle with 500m range you can be synchronizing the stage of hundreds of doors per player and eating bandwidth that would (usually) be better used synchronizing player position state. In practice you end up doing some amount of 'automatic' synchronization and some based on context... and a server that has the definitive world state that can 'undo' shots through closed doors etc.

Building rendering distances can also be an issue with doors, generally you switch to simpler building models as they get further from the player's camera. But you can't include doors in the lower level of detail models until you are at a distance that enemy players are also not visible. So while a building can be a 200 triangle shell at 400m it still has to have doorways and network synchronized doors, even if the doorway is 4 on-screen pixels it should still be possible to see a player move behind that open doorway (or not see them if the door is closed).

⬐ vvanders

Oh totally.

Half of games networking is finding out what you can "get away with" from an impact/user perception. Ex: play hit effects, sounds in a de-synched way locally but have major game events be authoritatively acked by the server, the local events also do a good job of masking the latency. The other half is really cool tricks like dead-reckoning or lock-step[1] which uses a completely deterministic game state to sync hundreds of entities over latent connections.

It's a really fun design space that's leverages heavily both the game design(designs where players "predict" are easier to keep in sync/fun), a level of deception to hide latency and cool technical approaches to hard problems in a non-deterministic environment.

[1] https://en.wikipedia.org/wiki/Lockstep_protocol

⬐ swagasaurus-rex

Most networked games are built on UDP that resend the game state many times to ensure a high probability of timely delivery.

Desync is common and is caused by packet loss in UDP games. It's not usually worth while to compare your state with the authoritative state, because that requires a round-trip from client->server. Instead, the server can rank each piece of the state as important (has been altered recently is a good measure of importance), and just spam out a bunch of redundant game state packets hoping some of them arrive.

You can build a guaranteed delivery packet system on top of UDP, but a guarantee has to come from the client meaning you're waiting on round-trips to confirm that the states are fully in-sync. Most games (especially fast paced shooters) don't need this level of assurance, and heavy packet loss over a long period of time should just result in a disconnect for that player.

⬐ midnightclubbed

Every networked game I've seen uses a reliable transmission layer built on top of UDP. Generally there are packets that work as you describe and are fired out to the server (and/or other players) with 'full' state (typically player position, orientation, speed and maybe a few state bytes... with orientation sent more regularly than position and speed). The remainder of packets are sent reliably.

Each game packet is typically packed (and compressed) with other game packets to maximize bandwidth and acknowledgment data for the reliable packets is also compressed into the data stream. Reliable packets take very little additional bandwidth (assuming your UDP connection is not going to lose many packets in normal use). Players will pull ethernet cables for a second to force packet loss if the unreliable packets give them an advantage (ie to allow them to interpolate through a wall or to not register shot hits).

⬐ ajkjk

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

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...

⬐ Sohcahtoa82

I was writing a real-time multiplayer game a while ago and used that article as the basis of how to keep players in sync.

One thing it doesn't mention, but that I thought of and implemented a protection against, is a malicious client sitting there and listening to game states, then send a bunch of inputs with timestamps in the past that would put the player into an advantageous position. I eliminated this by coding the server to reject any inputs that are older than 500 ms, and since the server was authoritative, the client had to just deal with it and put the player where it was up to 500 ms ago. The server would even tell the client "You are lagging and I ignored your input" when this happened, so legit clients could deal with it.

While yes, this could create a negative player experience as a player who is dealing with a lot of latency or packet loss would frequently get teleported back, that player would already be having a negative experience due to everyone else jumping around. Even with interpolation between predicted states and authoritative states, at 500 ms latency, you're going to have a bad time in a real-time multiplayer game when latency matters.