Here's an example: remember those huge rotating gears in one of the early shareware levels of Duke Nukem 3D? Imagine if a general physics engine animation loop. Suddenly the gears become more than just eye candy as one comes off its axle and rolls down the hall after you, Indiana-Jones style. Or imagine shooting a gear with a missile, causing it to roll down the hall and crush your friend who was about to frag you from behind!

...

However, most physics engines in todays' games are pretty weak, doing just enough to keep that car from falling out of the world, but not enough to take the game to the next level of interaction — where a wrecked car's debris might explode onto the track, careening into the wall and other cars, tires rolling into oncoming traffic. Other often ignored physical possibilities include everything from simple rotational effects induced by being hit off center, to having the creatures in the game be self-balancing and motivating — rather than based on static animations — so they can react to new physical stimuli.

It's this series, published from 1996, that code powering Havok and PhysX was based on. Twenty years later, I haven't seen the amount of creativity and innovation that we all imagined real-time physics engines would give us. The impressive physics capabilities of Half-Life 2 were relegated to a few, boring, and, dare I say it, scripted puzzles in the final game.

PLACEHOLDER: Better footage for see-saw puzzle in Route Kanal (https://youtu.be/iwjl4xMF92w?t=333). Maybe some others?

Well, we've seen self-balancing and self-motivating characters in Spore, and I only call it out because Chris Hecker himself was one of the people to develop them.

Part of this is that simply adding real-life physics won't instantly make things exciting. There's a whole reason that pulling off those kinds of stunts require teams of people and weeks of planning to make sure the gear and axel is built to break in that specific way, and the charges go off with microsecond timing so it rolls just right down the aisle... because otherwise...

PLACEHOLDER: Demo roll of bad and boring physics. Large Indiana Jones rocks slowly sliding down an aisle. Sonic 2006. Ubisoft video games.

Global Physics in Video Games is a Choice

I think lots of people don't realize that physics in video games, at least the common technologies we have right now, are wrong. In the same way that level designers don't plant every tree and build every crate from scratch, they simply drag and drop it, our common "video game physics" systems are simplified systems with primitives like "a tree" or "a crate". We don't build our world by putting down molecules and atoms and running simulations of complex chemical interactions of them. And we still don't racing games by building and emulating combustion engines.

And, although obvious, this isn't just because of lack of power — I doubt a player would want to have a pit stop at the gas station to add more fuel after every match in Rocket League. Games should be fun experiences on their own merits.

That isn't to say that video game physics, when well-integrated, can't lead to amazing experiences. Even in the real-world, pool billiards is a simple game that plays on the intuitions of physics and elastic collision, and Angry Birds can be seen as a video game version of it.

Portal is similar. Although fans might argue on the specifics of how well it maps to "real-world" physics, and whether moving portals might violate conservation of momentum, the code behind the game doesn't actually care. The game has a close-enough-to-real-life, albeit, wrong, physics engine which it uses to build puzzles around teleporting and flying through space.

And PopCap's Peggle, inspired by Japanese pachinko machines and Atari's Breakout, intentionally uses an exaggerated cartoony physics engine, custom-built for the game. And inline with the rest of the game's humor, the physics engine even sometimes even feels like a character, sarcasticly sending your mistimed balls directly into the gutter, and mocking you by elongating a bounce gone wrong.

Dark Souls, one of my favorite video games of all time, uses the Havok Engine, but mostly only for things that don't matter, like the gibs of broken pots, and ragdolls left behind by fallen enemies. The rocks rolling downhill in Sen's Fortress, for instance, are entirely animated with traditional techniques. Admit it — a physics engine, even properly tuned, wouldn't be able to recreate that kind of a sensation. Physics simulations were probably used to help the animators figure out how the rocks would roll, but it's not computed at real-time. In fact, in Dark Souls 2, I can think of one example of physics in gameplay, and it's one that's gone wrong (well, besides the removed ragdolls).

PLACEHOLDER: old giant king or whatever, the head rolling off the platform. supercut of ten different attempts and it not killing enemies half the time? the memory of jeigh sucks and so does the from software B team.

Why have physics engines failed us? Why do we need to go back to hardcoded animations for things to work properly? Why can't the giant stone head rolling downhill have weight, depth, and balance?

choices are good and you should make more of them in your vidoe game

In all of these cases, it's not like physics was simply added into the game because it was a feature of the engine; a "required thing" for a video game to feel complete. I worry that with the uprise of engines like Unity and Unreal, with their relatively easy ability to add physics-based gameplay, a physics engine is just seen as "something a game needs" like a rendering engine and a sound engine. But just as a state-of-the-art rendering engine doesn't magically decide an art style for you, and how a 3D positional audio engine doesn't automatically compose a soundtrack for you, a physics engine doesn't and shouldn't decide the gameplay decisions a game has.

Rendering engines have over time added shader-based effects, physically based rendering, and the ability and want to use alternative cell-shaded cartoon-y art styles. Music engines have added a wide variety of looping styles, interactivity to sync up with gameplay, and runtime filters to make it sound like e.g. you are in a tunnel. But the "physics" engines, unfortunately, haven't adapted to the times. We still simulate a global world, with global effects like gravity, in which rigid bodies with mass move around with forces and constraints. Realistic, to an extend, perhaps, but unforutnately limited for the kinds of effects that we might want to create.

the part where i talk about simplified rigid body models

When we started crafting "physics engines" long ago, we knew we couldn't emulate the behavior of atoms themselves, especially when we don't quite understand them ourselves. We chose large-ish objects, which can't bend or break, and we defined they move through space, collide with each other, and bounce off of walls and floors.

These objects, since they can't bend or break, are known as "rigid bodies", and the laws governing the motion of these objects are known as "rigid body dynamics". Plenty has been written about rigid body dynamics, and everything you need to know practically about how these bodies move can be found in a traditional high school physics class. Objects in motion stay in motion, travelling in the same speed and direction, until acted upon by an external force. External forces affect an object's acceleration, which affects an object's velocity, which affects an object's position.

I'll assume that we all know how to build a simple see-saw — we take a long two-by-four, shove a long metal rod in it, and suspend it above the ground.

PLACEHOLDER: IKEA cross-section of a see-saw

Enough imagining, actually. Click on it — it's interactive. Drag the see-saw around.

I built this using the Unity engine, and published it as WebGL. As an iframe. I used Unity's physics system to build a cube, and then put a "revolve joint" on it, adjusted the axis you can use, limited it in a specific range, put a spring and a damper on it. The rest of everything — the rod in the middle, the thing suspending it above the ground — that's simply ornamental. The only "dynamic" part of my system is the rigid body that can tilt, and also the box that I dropped on it.

When modelling systems like this in video games, puzzle designers and world builders work with primitives, like these, which define the interactions that two rigid bodies might have with each other.

Modelling systems like this has a downside. These primitives can often be brittle and easily get out of control. And when building large puzzles that have multiple moving parts. Additionally, without special behavior, these primitives can require a lot of tweaking of all the different parameters to get a desired effect. Adjusting a single parameter in here might completely change the dynamic of a puzzle.

nintendo isn't shit because they have better primitives which aren't "box that moves and also collides"

Nintendo's video games are based on a central, in-house engine, "J", that we can see marks of all over their games, built up over 20 years. 2D UI layout and animation tools, a cutscene planner, 3D positional audio and music sequencing, even GPU text rendering and particles that integrate with their deferred renderer. The one piece of shared code I have never seen? Physics. They have a common math library and collision helpers, but they program each game to their own tastes.

They've modeled effects and behavior after physics for years, but never directly use a "physics engine" to do so. Every wobbly platform, every seesaw, every boomerang that returns back to you, all hand-coded for the best effect.

I think this is a fairly unusual "secret sauce" among Nintendo. Rather than endlessly tweak the "spring" parameter on a revolve joint, they craft exactly what they want to, using physics as a base for their own models and their own behavior.

Nintendo chooses their primitives and their physical model to be coarser and higher level. Rather than choose the rigid body and the revolve joint, they opt to model the seesaw or the wobbly platform directly.