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

At Frogtoss, we are looking at a lot of different design directions and making decisions about what we are working on next.

We tend to avoid market calculations when choosing directions, preferring to look towards qualitative guidelines instead. Specifically, we aim to answer “Can this be really great?” rather than “What does it look like if we can capture 1% of the iOS market at \$1.99?”. The former question pushes us to make a game that is worthy of customers, thereby shaping our plan. We feel that the second one simply counts the money before we’ve earned it and does not allow for meaningful course correction.

The axiom “good is the enemy of great” comes into play here; it is easy enough to come up with a fun idea that is cool and plays well. It is also easy to weed out the truly bad ideas.

What is a much tougher challenge is separating the good ideas from the great ones. In our process, it is inextricably linked to gauging a game’s potential to be enjoyed by a large number of customers.

Whenever an idea is ready for evaluation, I run it against a set of questions. These questions are steeped in a personal philosophy of what makes a game have the potential to be great.

The Questions

Is there one person anywhere who would consider this game to be their favorite? If so, why?

If there is one person in the world who considers your game to be their favorite it means that it has bubbled to the top of their consciousness and that they cherish it. If even one person can say this about your work, your game is truly special and should hold at least a strong niche appeal.

Is there an obviously new experience for players that is core to the game?

This question implies a philosophy: new experiences resonate the most. Without anything new, you are forced to do what someone else has done, but better. Make this concession consciously because if you do neither, your game probably does not have a lot of potential.

Picture the ideal player. What is being done to give this player a sense that they would be crazy to pass up the game because there is so much value in it for them.

My partner has spent over 300 hours in Left 4 Dead. She bought the game for \$50. When it goes on sale for \$10, she is completely amazed at how much gaming goodness opens up to you for such a small amount of money.

You need to be able to convince yourself that your ideal players need to find your game an extremely easy value proposition to agree with. This is important because everyone else is a step down from that.

Why does the game have the potential to create news stories after its launch window that prompt people to look into playing it?

They say that marketing is a tax you pay for being unremarkable. While not even close to the whole picture, having your game nurture conversation about itself is a huge contributor to the success of many games.

Are other developers going to be influenced by the advances you have made in the product?

Advancing the state of the art of game development — whether through design or technology — is a sign that your game is made of a unique fabric. This holds promise that you final product stands out and provides a unique experience.

In five years, is the game going to be remembered as a variant of a theme (Eradicator) or a gold standard in its genre (Duke Nukem 3D)?

Doing an honest gut check on whether your game is memorable helps you speculate what mindshare you can expect to have.

This question is saved for last because it is the macro question that summarizes your take on the product.

The Exercise

As an exercise, try running through the questions with your favorite classic game from the vantage point of the year that the game was released. You may find, as I did, how easy it is to positively answer the questions with truly great games.

Now pull up a good game on your Steam list that you tried out and put an hour into… perhaps a game that did alright but was not exactly a cultural shockwave. Notice how this good game does not make the grade.

With this contrast in mind, take the idea you’re working on and answer away. How does it stack up?

Good is the enemy of great and it helps to have tools to identify the enemy as early as possible!