Physics & Game Design

There’s an interesting and thought-provoking article on Escapist about Havok and game physics in general which reminded me of some of the thoughts I’ve had since I started playing with the Unity game development tool.

Unity’s fundamental premise is to wrap pretty much all of the state-of-the-art game technology out there in a graphical, high-level development tool, kind of a 3D equivalent of HyperCard (the HyperCard analogy is more apt than, say, Visual Basic, since the runtime and development environments are essentially the same thing; which is what made HyperCard such an amazing thing).

One of the great features of Unity is its excellent support for physics. Because you can implement physics with scarcely any code, it’s highly recommended that you do so. Recently, I was trying to implement a sailing ship, and I wanted the player’s steering control to move the ship’s rudder. For reasons that aren’t important, I was having problems, and someone helpfully suggested that I use physics… Aaargh!

Now, a lot of discussion of physics tends to assume you know what physics is. I don’t mean formulae or theory, but what physics, as a component of a game, is. In essence, physics is all the behavior you expect from objects as a consequence of their size, shape, and mass. Perhaps the most common example of game physics, present in every game since Pong, is collision detection. In the “real world” two objects cannot occupy the same place at the same time, and to simulate this behavior in the game world you need to do collision detection (as a first step) and then do something about collisions when they are detected (e.g. make the ball bounce rather than go through a wall or paddle). In pong when the ball collides with a paddle or wall, it bounces more-or-less the way you would expect perfectly elastic bodies to bounce.

Interestingly, however, what makes pong at all interesting as a game is the fact that the ball does not bounce the way your Physics textbook says it should. Where your ball hits your paddle modifies the ball’s trajectory, allowing you to steer your shot in interesting ways. And herein lies the rub for all the idiots who think adding physics to games will somehow make the world a better place: what makes games good is good gameplay. To some extent physics can make explosions (say) prettier or more impressive, but a nicer deck of cards doesn’t make Euchre more fun than Bridge.

In other words, physics can embellish the stuff that makes no difference to the game’s outcome, but fine control of object behavior is exactly what makes gameplay good. Indeed many of the things that are being credited to “physics”, such as “gravity guns” or “portals” or whatever, are actually hand-crafted, finely tuned violations of physics which mainly use the physics engine to add a bit of convincing jiggle and bounce.

Here’s another way to look at it: you design a game that involves going through a door in the side of a wall. If physics lets you blow a hole through the wall, then opening the door ceases to be a plot point in the game. If you can collapse the wall, blocking the door, then you can create an unwinnable condition that may not be discovered during testing. Either way, putting physics into something that actually matters in the game isn’t helping.