In all the post-mortems and production methodologies for game development, none really address the difficult problems of building a simulation-heavy game in a non-insane way.

With my experience working on Scarface, LMNO, game AI in general, and a side project I’m starting that delves heavily into crowd simulation, I wanted to formalize my thoughts on production processes for simulation driven games.

I mean to answer the question of how best to tackle creative and production challenges, in a way that will most quickly get you to a point where the game is compelling to play (and therefore also viable to pitch and market before being complete).

 X is for Overused

The most predominantly official production process for games is the Cerny method. It’s called all manner of things in practice, first playable, vertical slice, but it primarily invoved building 2-3 minutes of polished experience including gameplay, art, sound, etc. before the rest of bulk of the game’s content. That reduces the amount of content that has to be completely remade as other assumptions change. While you never completely escape that, this method certainly helps.

At EA it was broken down even further – after an initial concept phase, there was the X-Slice (same as above), followed by the X-Level. The X-Level represented 10-15 minutes of gameplay, but additionally required all tools and other pipelines to be fully working. This extra time to focus on tools helped to make sure that content could be added to the game as quickly and as easily as possible during full production.

Content Is Killer

You’ll note the repeated use of the word content or synonyms for it in the above description. This methodology best (perhaps only) applies to games built on a small set of very repeatable mechanics and systems – the fabled “30 seconds of fun”. The game then staggers levels, characters, other art, with minor changes in systems for pacing across the entirety of the game.

After the initial vertical slice is complete, you generally feel confident in judging the gameplay, understanding what needs to be added, and how long it will take to create assets for the game. You are completely unable to do this if your game is a simulation, though.

You Know It When You See It

So what defines a game as simulation-driven? It’s not always a strict avoidance of a level/content based progression in the game. The Thief series is level-based, but its gameplay comes from a series of connected systems. The space in which the gameplay takes place is one of those systems.

Some examples are easy to spot – The Sims’ gameplay is driven purely through the interactions of the various systems, the Sims, their goals, the objects they can use, and building houses full of those objects for your Sims to interact with.

Skulls of the Shogun, as a strategy game, features quite a few systems. But it’s not simulation driven, although many strategy games may sit on that fence. The distinction is that gameplay in a simulation stems from second or higher order interactions between systems. In Skulls, the various systems interact to give you lots of strategic possibilities, but we tried to make the consequences as clear as possible to make the strategy more accessible. (The higher order consequences are more for advanced players to explore and not part of the base gameplay).

Second or higher consequences occur when a player’s action in a system has an impact in another system. That may impact another system, and so on. The gameplay stems from dealing with those the second order consequences – either reacting to (in the case of a stealth game like Thief), managing (in the Sims), or a mix of both (in an open city game like GTA).

Lots of game feature simulations – the physics behind a racing game or Angry Birds, but those higher order consequences have to be a key part of the gameplay experience. That’s when the simulation & all its systems not just affect, but completely define the player’s experience with the game.

A Field Full of Broken Dreams

Building a simulation driven game, you can’t judge the player’s experience with 2-3 minutes of gameplay. Those 2-3 minutes might only involve 20% of the game’s systems. And while adding art and sound assets is still time consuming, the experience is driven by complex, layered, system interactions.

You could start adding shipping content to those systems, but without the remaining systems roughed out, the systems you do have will surely change. Those assets need to support the system feedback the player needs, so if the combination of systems are not proven, pushing a high fidelity art asset into the game is useless. As soon as one of those systems, even if it’s a different one, changes, that asset might not even be needed.

In my 13+ years making games professionally, I’ve seen or heard of the Cerny method applied to simulation driven games many, many times. In no case has it ever gone even passably alright, causing heavy delays and more often than not, tanking the project completely.

M-M-M-MAXIMUM…

In that sense any work done before the simulation is refined is wasted effort, just like building extra levels was wasted effort before the Cerny method. But what you need in this case is maximum connectivity between systems.

What that means is that each system may not have all of its mechanics implemented (ideally has as few as possible), as long as all of the rules that connect to other systems are implemented. That includes any lower-level mechanics that are necesaary to build those connections.

Coming Soon…

The rest of the series will delve into specific milestones and how they are necessary for development to reasonably progress. In my next part, I’ll look at what’s uniquely required out of the concept phase for a simulation based game.

This was cross-posted from my blog.