[ This week's post builds on last week's Reactive Design approach by defining behavior of game elements via interaction properties rather than explicit relationships, a technique which leads to more emergent and creative gameplay. ]
A Quick Recap
Last week I asserted that when designing games we should ask ourselves what *players *want to do and how we can *allow *them to do it, instead of what *we *want players to do and how we can *make *them do it. I also outlined a high-level approach to concept design with a focus on delivering the player's fantasies and building a playground that reacts in an engaging way to as many player choices as possible.
This week I want to dig deeper into one method for developing such a reactive playground.
Oh God, It's A Combinatorial Explosion!
In most cases throughout our industry's history, it seems that games have taken the approach of defining relationships between game elements in a very explicit way. This is a three-dimensional problem: two axes of game elements (for the elements that are interacting) and a third axis describing the interaction context (usually the verb that element A does to element B). Every point in space is an explicitly-defined relationship, meaning that as game elements (or worse, new verbs) are added, we rapidly approach a combinatorial explosion of functionality. This creates a chilling effect on the addition of new elements and mechanics due to high production cost, which in turn leads to static, lifeless game worlds *and games of *"guess the designer's intention".
For example, we might define three game elements: a concrete slab, a vial of oil, and a flamethrower. We desire an interaction whereby the player can break the oil vial on the concrete slab, then light the oil (and thus the slab) on fire with the flamethrower. Using this approach, we must define multiple explicit relationships:
- *Flamethrower -> Concrete Slab: *flames are blocked, slab is unaffected
- *Flamethrower -> Vial of Oil: *vial explodes
- Vial of Oil -> Concrete Slab: vial breaks, Concrete Slab becomes Oiled Concrete Slab
- Flamethrower -> Oiled Concrete Slab: slab catches on fire and burns for 30 seconds
That doesn't seem so bad, but now if we add just one more game element -- a sheet of plywood that we expect can be burned -- we have to add several more relationships:
- Flamethrower -> Plywood: plywood catches on fire and burns for 30 seconds
- *Vial of Oil -> Plywood: *vial breaks, plywood becomes Oiled Plywood
- Flamethrower -> Oiled Plywood: plywood catches on fire and burns for 60 seconds
And at this point, we probably want to redefine our Flamethrower -> Vial of Oil relationship to ensure that the fiery explosion can ignite nearby Plywood:
- Flamethrower -> Vial of Oil: vial explodes, all nearby Plywood catches on fire and burns for 30 seconds
This is fast becoming unwieldy, and we've barely got any game elements. Let's try a better way.
What Can We Get For (Almost) Free?
A different approach is not to define relationships between game elements at all, but instead to define relationships between properties, and then tag game elements (objects and verbs) with any desired combination of those properties. Once a reasonable foundation set of properties has been established, we'll rarely need to add more. But we can now add game elements almost for free, because their behaviors inherit entirely from the properties with which they're tagged.
Reprising our example above, we can define a few properties to encompass our desired behaviors:
- Flammable: This object can be caught on fire
- Fire: This object can ignite flammable things
- Breakable: This object can be broken by a collision with sufficient force
- Coating: When this object breaks against something, it coats that other object with its contents
We can implement these properties in a general way in our game engine, and then tag our previous game objects with them:
- Flamethrower: Fire
- Vial of Oil: Breakable, Coating (Oil)
- Oil: Flammable
- Concrete Slab: (none)
It should be obvious at this point how our previous interactions are preserved, without having implemented explicit element-to-element relationships. Instead, we implemented behaviors for properties, then re-used those behaviors for elements tagged with those properties. Now if we want to add our sheet of plywood, we simply do:
- Plywood: Flammable, Breakable
Aside from the fact that somebody still has to model and texture the asset, we now have a sheet of plywood that works within our existing game systems, without having implemented any new explicit relationships at all. Flammable and Breakable were already defined and used by existing game elements, and simply re-used here.
This is clearly a significant production savings, especially as the number and complexity of game elements increases. That the addition of a new game element is now much, much cheaper to do means designers can feel free to experiment and populate their worlds with interesting behaviors. We also gain the benefits of consistency *(e.g. all flammable things behave the same) and a *much simpler test matrix (if one flammable thing works as expected, all flammable things are now known to work as expected).
Embracing properties-driven design empowers designers to apply the full force of their creative will without overwhelming the rest of the team with technical requirements. And of course, empowered designers created the most inspired games. ;)Posted In: