In my first post I described why the vertical slice approach covered by the Cerny Method fails to produce the same results in simulation-driven games. Now I’ll detail more of the goals for the equivalent milestone in a production process geared towards these kinds of games.
Previous entries in the series:
- Part 1 – An overview of the problems applying common production processes to these types of games.
- Part 2 – Description of the concept phase & deliverables
- Part 3 – Guidelines and pitfalls for building isolated prototypes in the concept phase.
Horizontal Slice?
Because gameplay and its pacing are derived from how systems interact, building 2-3 minutes of polished gameplay is largely impossible until the game is in post-production and every system has near-final art.
In order to judge gameplay, we need to have every system in the game, but working at the lowest possible fidelity. Only then can we gauge those system interactions and see if they add to the vision of the final game. (And yes, if it’s “fun”).
To call it a horizontal slice isn’t entirely accurate either. It is focused predominantly on systems, and you may have to make temporary art for it. The goal is partly similar – to deliver a playable build that people can evaluate the experience of the game, and for you to gauge the practicality of finishing each aspect of the game. It is not meant to prove the final quality/fidelity level of everything in the playable.
(If you work at large company that is fond of turning all its milestones into acronyms, I handily have you covered. Good luck with your CSP!)
Maximum Connectivity, Minimum Functionality
If your simulation includes combat, the only thing your combat system truly needs is a way to damage enemies, and possibly heal. You don’t need a range of weapons or abilities in as much as the reduction of health is what connects combat to other systems.
Now, if your game involves unlocking or upgrading combat abilities, you will want a handful so you can implement the unlocking mechanism (such as earning money to buy new weapons), as that is a key connection point to other systems. Again, though, you want the bare minimum of options here that proves the player has a reason to use that system.
This lets players use the individual systems, but keeps you from focusing on needless details during this stage. You need to figure out the pacing between systems, which systems can be used to solve what problems, and how they affect each other.
Oh THAT’s What You Meant
On Scarface it took us perhaps over a year or so to get to a stage where all the relevant systems were functioning together. In part this was because the genre at the time was still very new (with only GTA 3 as an example).
Discussions across the team on the high level gameplay tended to focus on trying to understand how to compartmentalize all the systems. What percentage of shooting was there? What percentage of driving? While there is a design purpose to those questions, they can lose relevance as simulation-driven gameplay empowers the player to choose their own solutions to problems.
So we had combat/shooting gameplay fairly fleshed out, vehicles including both driving and a system for shooting while driving (replete with proper character targeting animations while driving). I innocently finally combined all these into one sandbox to test my procedural traffic and people spawning, adding enemies as well as civilians.
Even without a concrete goal, you could play and enjoy the feedback and interactions between systems – shooting from your car, getting damaged, chasing people on foot, getting into another car, avoiding pedestrians, and navigating the streets. Again, these are better understood compulsion loops 9-10 years later, but at that point it became a lot easier I think to convey the gameplay goals to non-designers on the team.
The conversation was not focused on the detail of the percentage of what gameplay happens when, but more about the structure and flow of the game, what gets the player to where, to empower them to do what. When you’re focused on the lowest level “30 seconds of fun”, it can be hard to switch to a state where “fun” comes from interactions that are paced out over minutes. The connected systems playable allows that kind of perspective.
The Soup
The first real creative stumbling block in this milestone will come once your previously isolated systems are finally hooked together. The initial experience of these interconnected systems will be, largely, a mess. Gameplay critical events will either happen too much, or too little.
On LMNO, by the “end” of the project, we had a “vertical slice” of “2-3” minutes of representative gameplay. which you could play for 45 minutes. It could be confusing, it would break, but in that experience you would see at least one of a few things you’d not seen before in a game, like an AI character poking fun at you for misusing an object in the world (dynamically, such that it felt more convincing than as a scripted event).
In my crowd sim game, I added two behaviors (people get out of your way when running towards them, and if bumped multiple times will start to get aggressive), and one run through a crowd set the entire population into a riotous frenzy. That may be a desirable behavior, but not triggered so easily.
This is where we delve into finer detail systems design. You’ll need to add positive and negative feedback loops in the form of game mechanics. These should slow the rate of events that happen too frequently, or speed up their likelihood.
Unfortunately there few good resources on applying control theory (meant to help structure systems to create desired outputs) to game simulations in detail. Your options are basically super detailed electrical engineering textbooks, or reverting to MDA-style formalism that only touches on system dynamics.
If you know of any decent resources that apply control theory to something like game simulation design in an approachable way (whatever discipline they may come from), please post below. You should check out Paul Tozour’s series on Decision Modeling – not directly focused on this, but it can be applicable.
The Magic Rule of 7 Plus or Minus 2. Usually Minus.
I don’t know if it is related to the limitations of short term memory (my guess is not directly), but across my entire career the instances when I’ve seen successful emergent gameplay come from systems design share one thing in common.
It stems from having several small systems that are highly interconnected, as opposed to fewer systems that are deeper and have more detail. Each system only has a handful of mechanics, but those mechanics impact other systems and give the player reason to use all of them together.
If you’re having difficulty making your systems work together, you may want to ask yourself the following questions:
- How many high levels systems in the game are there? Is it significantly greater than 5-7? You may want to consider paring it down. Is it lower and the systems more complex? Try thinking about how to break up those systems to make a design that encourages emergent behavior be more manageable.
- Is there a system that at a high level is described by more than a handful of mechanics? Here there’s some leeway in what granularity you define “mechanic” (one rules or a small set of very interrelated rules). Any system much larger than this size needs paring down to the essentials. You may be able to go back and add complexity later, but do it based on playtests and what can be supported – the extra complexity in a single system may not be necessary because the player will be balancing gameplay between all the systems.
- How does each system impact other systems? At the bare minimum, a given system must have some output that affects another system, and some input from another system that affects it as well.
These limitations are primarily on rules the player is interacting with. the underlying systems may use lots more technologies which obviously necessitates more “rules”, but the focus in this scaling is on game mechanics.
Art Directing Your Prototype
The goal of this stage is a playable experience, one that you can put in front of players. But you can’t focus on implementing high fidelity assets in the connected systems playable.
You still need to have art though, and something that at least suggests whatever it is simulating. Most importantly, it has to convey the information needed to the player. Is a character’s animation clearly conveying state the player needs? Does the environment art highlight the systemic affordances the player has?
The solution is to decide some consistant limitations to the art in the playable, and stick with them. On LMNO we called this (if I remember correctly) low-fi HD. Instead of grey blocks, a table would look like a table. Representative models would be used to get a valid sense of scale & space. Only default textures would typically be used, no normal mapping or more advanced shaders. Lighting can remain flat, unless it’s specifically needed for the level design.
Wherever possible, use in progress work – models may be of a representative level of detail, but simply not have advanced texture/material work done on them yet. Try to use assets at a consistent level of completion across the board, however.
Chris Hecker used the same approach in building Spy Party, using placeholder art that was still consistent in its minimal art direction. Messaging to players it’s not final art is easier to convey when the overall aesthetic is simplified.
By remaining consistent, you prevent players from spending a large portion of their time distracted by individual assets, wondering if they should comment on this one asset looking incomplete because others are highly polished. A consistent look for your connected systems playable let’s them focus and evaluate the gameplay.
First Playable!
While I dislike the term “first playable”, since it should be a driving goal to also have your game playable in some form, this milestone now gets you to a point we can evaluate the simulation-driven gameplay, as well as production costs and technical risks.
Systems that rely heavily on lot of procedural work (for instance if they require automatically processing the environment to create data used by another system) should be evaluated for their potential stability in the final product (or lack thereof). If any system poses a real production risk, you should be able to easily replace it in this stage and test the entire simulation with a stripped down version, to gauge its real necessity.
Having completed this stage with a playable experience you can use to build interest in the game, we’re still not fully into production. The next milestone will focus on the tools and pipelines needed to enter real production.