Building Simulations, Part 2 - Concept Development

This is the second part of a series on production practices for building simulation-driven games.

Part 1 - an overview of the problems applying common processes to these types of games. I've updated it with a definition of what I mean by simulation-driven games.

The concept development phase of any game production is about exploring ideas and making decisions. These decisions are yet to be proven, but you need a way forward, otherwise you stall in blank-slate mode (a problem in any game production).

The Mission

A common element of this phase in any game is to define a mission statement about the overall experience. (I was always fond of the imagery of the one for EA's canceled Command and Conquer hybrid FPS/RTS, Tiberium - "You're the quarterback on the frontlines of the war of the future" or something along those lines if my memory serves).

While Skulls of the Shogun was not a simulation based game (having little concrete knowledge of the reality of the samurai afterlife), our goal of "arcade strategy" made it trivial to decide to add to new design elements. Did they speed up play, or did they slow it down in any way? If it was the latter, no matter how cool a feature it may have been, we quickly moved on.

At EA this was called, which will come as no surprise if you've read the first article, the X-Statement. Just as important though, you need to define the driving principles of your simulation.

Tony Montana's Miami

Working on Scarface, while the high level goal for the gameplay was always clear (inhabiting Tony Montana and his world), it took longer to define what made the world of Scarface unique. After GTA 3 and Vice City had liberally stolen from Scarface the movie, the team was left with the interesting problem of how to distinguish the world simulation from those games.

The driving factor was the realization that Tony Montana's world is a darker, more sinister place. Random people on the street are much more likely to be gangsters than innocent pedestrians.

Ultimately this was realized in the form of the Drug Wars-lite simulation creating ancillary missions in the world (as the player defends their safe houses from attack and transport drugs between locales), and attracting Heat from police. Heat was location based unlike earlier GTA games, and would be affected by the type of location the player was in. Shooting a gangster in an alley in a shady part of town would have much less impact than firing on a busy street in South Beach, reinforcing the notion that the parts of the world are darker and more violent.

This Is Worth Another Example

With my crowd simulation game, the overall experience is driven by themes exploring why people act the way the do in large scale protests, riots, etc., and exploring the gap between the individual and the group ("There but for the grace of god, go I").

What that means for my simulation, though, is a bit more complex. The simulation must deal with both groups of people and individuals that make them up. Some systems must create a group of individuals that act coordinatedly (through emergent behavior, much like people). However you can approach people as individuals to help reduce their instinctive reactions to group behavior. This is to realize the aesthetic goal of the getting the player to the realization of why people act as they do in those types of scenarios.

There must be some aspect(s) of the simulation that challenge the player to deal with the chaos, and order, of a large crowd. Trying to find people or information in a large group is challenging, and the game needs to capture that to help immerse the player in both the systems and the game's narrative.

Declaring Your Variables

Creatively, I find the next most valuable step is to decide the data that your simulation will be based on. In part that's because one of the first questions you are faced with is the granularity of the simulation. How detailed will it be? The simplest simulation that achieves your aesthetic goals will be the easiest to build and make entertaining, but it needs to be complex enough to drive those system interactions that make up gameplay.

For my crowd simulation, I wanted to anchor the simulation elements tied to my first aesthetic goal in the research of Steve Reicher and Cliff Stott. Turns out there's really not many researchers that study crowd behavior. Their book Mad Mobs and Englishmen? (looking at the 2011 soccer riots in England) details the two primary factors they found that influence people's behavior in riots - the amount a person identifies with the out-group, and their opinion of the legitimacy of the group in power/authority.

Now how can these factors be used to build relevant systems? That is a more concrete problem that helps quickly move past the blank slate and defines how to tackle systems design.

To the Prototypes, Batman!

The other goal coming out of the concept phase, besides having those creative razors to judge design elements, is a set of prototypes. These are individual, unconnected systems, one for each major unknown or new system to the game.

From those you should know what systems will be crucial to gameplay. You may have rejected some systems based on your prototypes, and you may still add more. But you should have a prototype for every core system you absolutely know will be necessary, and is largely new or heavily altered for your game.

If the game uses a well defined system like gunplay, probably in it's place in an established genre, there's very little use in prototyping it at this stage. It resolves no questions, and it is well-defined enough to to imagine how it might fit in with more unique systems. On LMNO we focused first how your relationship with the companion AI character would evolve outside of combat. But we also prototyped first person movement in a style similar to Mirror's Edge, because that pre-dated that game's release, so up to that point was fairly unique.

It would be some time before we would integrate combat with that, however. Perhaps even too long - the next part in the series will look at examples of building stand alone prototypes, and pitfalls to avoid during this concept stage.