How do you call a game system that handles the game physics? That's exactly what the "Telling clever lies!" rectangle reffers to: It's the other half of the system that comprises the game physics (the other being the raw/basic/unadjusted movement+collision systems which are later replaced by Havok, this is also explained in a previous slide).
"Acceleration" is not an attribute of Rigidbodies in any existing physics engine, it's not a property you set that defines how the object behaves, it's a magnitude resulting of the appliance of forces that is constantly changing if those forces don't remain constant. Acceleration and friction were already being used back in Asteroids (released in 1979, a bit before PS2/PSP), maybe even before that.
He explained it in the videos: when making videogames, they aren't made to be super realistic, using real physics, devs "lie" with many things to make games more fun.
As an example, in a platformer you make the character jump way higher than it would realistically do. This isn't realistic, is a 'lie' but in terms of game design fits better a game because gives you more options to reach higher platforms, have more reaction time when jumping to avoid or hit an enemy when landing etc.
In a shooter, being realistic means you'd die after receiving one or two shots, enemies would better coordinate, hide and search you and would be more accurate when shoting at you, and you wouldn't have continues, health kits or health autoregeneration. You'd hear an enemy shot after it landed, and you wouldn't have visual indications showing from where the shots are coming etc. As videogame this would be too hard and frustrating, do devs fake/lie with all these things to make it more approachable, less frustrating and more fun with "clever lies".
As an example, in an action game if an enemy throws a rock at you, devs put a long enough animation of the enemy starting to throw the animation at you, and later they tweak or cap the speed/acceleration/force/gravity/many other things involved giving you enough time to be able to avoid it, block it, parry it, etc. plus on top may show a visual effect to make you easier to understand the time window you have to parry it, or to let you identify faster if it's a type of attack that you have to block, parry or evade.
These things involve many design choices and programming split into many different areas. As I and him said, the areas related to movement and collisions systems when grouped together are normally refered as physics system/engine. As in this case, nowadays many devs choose to get a middleware -like Havok- to handle rigid body physics. The engine does internally all the calculations needed and only needs to have some objects defined with certain properties (which later can also be modified manually if desired) by the devs.
These objects may also activate certain events, as could be when colliding with certain type of object or when reaching certain speeds. Then as I and he said, outside the physics engine they can program something game specific for an event (as could be for a tree "if colliding with fire and aren't burning, enter the burning state".
You still haven't explained how, if all this is something that Havok handles on its' own, the standard for games is to have broken physics, while the polished behaviour of BotW and TotK is the exception.
It isn't any exception, as he mentioned in the video they did choose Havok because it's a very robust system proven in hundreds (or thousands?) of games in many different platforms since decades ago.
But as I (or he) mentioned the physics engine only handles movements and collisions. There can be bugs outside it which are the ones that activate the "broken physics".
The more time and work they put in trying to find a fix the bugs, and also tweak the game in general, the more polished a game is.
Typically there are two related to "broken physics" that are related to the game specific code, not so much to the code inside the :
- Sometimes the environment or the character has a wrongly placed collision box, in a way that when the character is in a certain spot and moves in a certain way or switches to other animation, modifying its collision box, clips inside the envirionment, getting stuck, or entering it or view throught it when very close. This is normally fixed by changing the collision boxes and/or modifying the checks and adjustments made when switching to that animation. Or sometimes, by applying a small force in the opposite direction.
- To calculate rigid body physics there's a limitation in the precision (amount of decimals) of the numbers used for stuff like forces, speed, coordinates, rotation, etc. and how frequently the physics simulations are calculated. This also causes that in some cases when there are two objects next to each other, as could be something on the floor or a ramp, there's a microcolision between them (similar to the one mentioned before) so a small force is generated to separate them, making it microcollide in other way generating another force in another way. This should only hapen once or twice in a small scale without being visible by the player, but in rare cases this starts scalating and the object is seen vibrating/jittering/shaking and sometimes ends flying away, sometimes flying away too long for a relatively small explosion. It often gets related to objects with too low mass, surfaces with too low friction, too high inertia or too relaxed value for forcing a dormant stace, center of mass not well positioned, and other causes.
It is more complex and there are way more things, but this happened in Zelda and mostly any other games, isn't any exception. The more variety/quantity and completity of collision boxes they have, the more difficult will be to test and solve this. And obviously, the more time and people devs are given to test/fix/tweak, the more polished will be. Nintendo as usual may have given them more than enough time, while instead people of games like Mindseye rushed the release without having given their devs enough time to fix and tweak stuff both related to physics and also related to many other things.
deepwiki.com
