There are two ways to really beat something up in a physical game: first, throw the object against the wall and, second, toss a heavy boulder on top of the object. The former can be thought of as impact damage. The velocity of the two objects colliding determines the magnitude of the impact.

The second is more challenging to get right. This iscrush damage. It takes some processing to determine when something is crushed and how badly it is crushed.

In some games, you have a crushing ceiling that descends slowly and squeezes players into the ground. Let’s take this simple example as a starting point and work from there: the crushing ceiling descends on the player. As the crushing ceiling pushes the player further into the floor, the player starts losing health and dying.

That’s great, but what happens in a more complicated simulation with rigid bodies that can roll out of the way? Perhaps a heavy block falls on an object, but the object squeezes out to the left. Sure, the big block penetrated your ball for a single frame, but this was quickly resolved by the physics solver by applying an impulse at to the proper point on the ball. You can’t simply tag the ball as crushed and respond with death in your game code.

The rest of this tutorial looks at addressing this problem with Box2D. Box2D is remarkably stable when dealing with significant mass ratio differences.

One way of solving this is to look at how long two fixtures (components of rigid bodies) stay interpenetrated and to apply damage when a time threshold has been reached. The assumption is that the solver does a great job of applying impulses to separate the two bodies, so when they fail, it’s a sign that there is not enough space for them to coexist. This is encroachment, and if it endures for a period of time, one of the encroaching objects is crushing the other one.

Let’s recap what we want out of production quality crush detection, and then we’ll get into an implementation you can build from.

• Detect impact damage separately from crush damage. Crush damage is the continuous pressure from forces from one object to another, causing encroachment. Impact damage happens in a single frame. These fire different gameplay events.
• Determine which object is crushing and which one is doing the crushing. A heavy object crushing another because of gravity is one thing, but an object with propulsion can push another object against the wall, causing it to be crushed. Horizontal pressures causing encroachment are still potentially a crush scenario!
• Compute crush magnitude independent of framerate. Keep in mind that force-based solvers tunnel in most situations. Box2D is no exception — if you have a long frame, you’ll tunnel further. We need to pass predictable and stable crush values to the game code regardless of framerate variability.
• Handle light objects bumping without crushing. If a paperclip lands on your head, you don’t want to die. Most players would object and promptly post an embarrassing yet funny video to Youtube.
• Scale the simulation to a large number of objects. Spot all of the opportunities to exit early in your crush detection routines and take advantage of them!

So, that’s what we want. In the second part, we’ll get our hands dirty with some source code.

Scripting languages have really fallen out of favor in modern game development. It’s easy to rile a working programmer up to a lather about poor debuggers, lack of threading or slow compile times related to a scripting language they were saddled with on a given project.

That said, the pendulum has swung too far in the anti-scripting direction.

The beginning of a console cycle is epitomized by a need for compatibility: “how can we ship on multiple prototype hardware platforms?” and tool efficiency: “how can we reduce the spiralling cost of development inherent in expanding horizons?” These questions led developers to make scripting plays in their engines.

In contrast, we are near the traditional end of a console cycle. We understand how to get a lot out of the hardware so the focus is free to move towards code execution efficiency in order to exceed the experiences players have had on the fixed hardware to date.

Looking past the consoles, memory latency is forcing us towards cache-friendly approaches to implementation which avoids indirection inherent in runtime bytecode interpretation and vtable lookups. Even if we push the CPU Ghz up, we aren’t going back to peppering our runtimes with vtables anytime soon thanks to memory latency overhead.

In this environment, it’s fully understandable that we would deign to avoid developing in languages like UnrealScript where only the rote engine-level loops are not bytecode interpreted. None of this means that scripting languages should be cut out of game development.

I see two places where scripting still beats out compiled code by providing new experiences for players:

First, scripting can be for one-off level scripting events. Scripts will always have a place as glue code. If you are nesting your loops in a level script, you have probably gone too far. Because you are not attempting to implement large parts of the game world in script and beacuse they do not run on tick, the performance impact is minimal.

A few lines of script is a natural alternative to abstract event firing systems. Visual scripting languages, ironically, are rarely informative at a glance. It’s much easier to see all of the code in one place than to click around a 3D blueprint looking for wires between entities and still need to guess at execution order.

The second use for scripts is more interesting. Right now, a big trend in games is towards online.

If you send state updates to your clients, the only way to add new behavior to your game is to patch your client. If you send script code for interpretation, you are only limited by the assets in the local cache and the hardcoded simulation to what your players experience.

The first version of Capture the Flag for Quake was written by Zoid before QuakeWorld. He took advantage of the fact that, before QuakeWorld, the Quake client was mostly a dumb terminal sending a subset of QuakeC over the pipe. Players could connect to his unique server without any mods and play CTF. This low barrier helped make Threewave Capture the Flag the first really popular Internet teamplay game.

If you are sending script over the pipe in 2011, please remember to fuzz your interpreter… and don’t drop in an off-the-shelf language that wasn’t designed with unsafe code in mind. Thanks.

Some wisdom on procedural content generation.

• Don’t build a procedural content gameplay generator until you have built two fully realized gameplay segments yourself. If you don’t know what “it” is, don’t waste resources by investing in automation of “it”.
• Building a PCG because you have insufficient level design time to populate a universe is not the same as building a PCG because you want users to have access to unlimited content. The former justifies an offline PCG and the latter argues for an online one. The offline one can take bigger technical risks, incorporate more processing time and output the level for a level designer to further tweak. Know why you need a PCG before coding one up.
• 3D PCG is largely unexplored outside of terrain heightmaps. When I wrote a random indoor level generator for Doom 3 years ago (unreleased), filling the room space with prefabs took an hour of CPU time even though my implementation was in good, clean, common sense C++ running on a reasonable processor from the middle of the decade.

| These videos are some of my favorite “outer space” PCG generators. I really like the zoom out on the third video down. (Fast forward to about halfway through.) | http://www.infinity-universe.com/Infinity/index.php?option=com_content&task=blogcategory&id=17&Itemid=93