This is the third part of a series on production practices for building simulation driven games.
The most important aspect of the concept phase is your isolated systems prototypes. Their sole purpose is for you to decide if you want each system in your game because they reinforce your aesthetic goals.
They are isolated prototypes in that each one is focused on a single system and its causes and effects within itself. We’ll look at examples of these single-system prototypes, and more pitfalls to avoid while building them.
- Part 1 – An overview of the problems applying common production processes to these types of games.
- Part 2 – Description of the concept phase & deliverables
Guideposts
Prototypes are most likely to be successful when they have one focused question they are trying to answer, a well-defined experiment. Unfortunately our isolated prototypes sole question is “Do we want this in our game?” which is pretty muddled.
In reality, it is more specific – “Does this prototype achieve some aspect of the aesthetic goals we set out for our simulation?” Still, these prototypes should be framed as creative exploration and not science experiments. They are launching pads for coming up with ideas that realistically can be implemented, and making creative decisions, and less about proving one thing over another. If they can be that specific, all the better, but don’t expect that to be the case.
As soon as you feel the prototype gives the experience you want, move on to the next. If it doesn’t, your options are to flesh out more mechanics in that prototype, or ditch it and move on. These systems do NOT have to:
- Work 100%
- Include all the mechanics in their design
- Have reusable code
- Be fun
The Prerequisite Example
In my crowd simulation project, there’s a need for a system to search for information in a crowd. This is partly for story purposes, but also to meet my simulation’s secondary goal, reinforcing the sensation of being a large group of people.
The first prototype was a fog of war, line of sight based system, similar in high concept to Monaco’s line of sight system. While it included some information loss that happens in that situation, the player could only solve problems with it using pretty rote behavior.
Ultimately all the player needed to do was move around, and the crowd changing didn’t interact much with the system. Since the fog of war was location-based, if people moved around in the crowd you would have knowledge of new people in the existing location. Having that immediate knowledge of new circumstances didn’t seem like it met the desired goal.
A gridded line of sight based “fog of war” prototype with placeholder art.
The next prototype relied on the assumption that there was specific information that took time to read from an individual person. This could be story related – finding a specific individual in a crowd – or show the player this character’s attitude that would affect other mechanics in the system and the player’s choices.
So I tried making this a targeted action, having the player target another person in the crowd. After a short amount of time, this information is revealed to the player. Being closer to the target takes less time, and is blocked by people and other collision. So the player needs to move around to reach multiple targets.
At that point it became apparent that the information could be stored for both player convienence and to simulate some permanence of the player’s “memory”. And as examined people move around, the information could decay. The player would have to reexamine targets that moved far from their original position, or after enough time has passed.
Prototype for a search/examine mechanic in a crowd w/abstract programmer art.
As the player moves around the crowd, other characters will move in reaction to them and each other. This has the desirable second-order effect that the better at moving around the crowd the player is without disturbing it, the faster they can find information. As other events alter characters position and behavior, the player loses some control and has less information.
This captures the goal for this system of creating the atmosphere of chaos, and order (in that all the people in the simulation can act with a small set of reliable rules to create this behavior). It also has lots of possibilities to connect to other systems. Those are both important points to reach when deciding what’s “good enough” for a prototype to move forward. The prototype doesn’t need all those possibilities implemented, that means it’s ready to be combined with other prototypes in the next stage.
Warning Signs
Sometimes this prototyping can veer towards implementing any random idea that might achieve the aesthetic goals, but you have to be careful if there are any clear cut signs that this system won’t play nice with others, or has no justification in the story world, etc.
In the worst case, you will have created several prototypes for a system, none of which fully meet your creative goals. One warning for this is when you actually cycle back around and repeat a prototype. That is, you build a very similar version of that mechanic/system, perhaps with a minor change.
That’s a big warning sign – you should have learned whatever you needed from the original. If the additional changes don’t specifically address those problems, you’re just spinning your wheels. We ran into this in a couple instances on LMNO, and probably spent too long dwelling on a solution. Working on Skulls of the Shogun, we adamantly never backtracked, we always tried to take that as a sign to cut the feature or simplify it.
At this point your options are to rethink the design and remove the system, or pick the least offensive choice. If there’s a prototype that meets some of your creative goals but not to the degree you would like, just run with it. Taking into account that both high fidelity presentation and connected systems are missing from the prototype, these are *almost* always what take an ok system to 100% in terms of the final experience.
If you’ve fully explored the design space and still haven’t found anything that meets your goals, that’s when it’s time to scrap the system and go in an entirely different direction. Otherwise you can attempt to take the best candidate to higher fidelity to gauge a real player’s experience, but this is typically a sign of creative indecision and not truly necessary for the production process (after all, if you’re a game designer one would hope imagination would solve that last step).
Extra Big Warning Signs
Do not “prove” any technology you feel is a risk for your game in this stage that is unrelated to these goals. For instance in an open city game, maybe you want vehicles have some new, super detailed modeling that enables even more realistic damage, handling, etc. It’s not proving anything however, as the early phases of the city simulation may imply vehicles are much less important than your first assumption. Further story & look development may also impact environment types, affecting this decision.
There’s always a necessity to utilize team members who are onboard early but don’t have the skill sets for this prototyping, so exceptions are always made. But think hard if there really is a possibility to incorporate them into this effort.
Do not focus on any aspect of simulation performance for both this and the next stage of development… As long as your prototypes are running, that will be sufficient for some time. Tuning performance of simulation algorithms is largely unlike optimizing graphics for a particular hardware set.
Most performance problems in simulation algorithms stem from data management and processing – you will not know the real data you need, or how often and where you need to access it. So the two tools you have in simulation optimization – changing the data, or changing how you access it – have no real information to be used correctly, yet.
Look Ma I’m Multitasking!
While system design goes on, obviously look development and story development are going on in parallel. The challenge with the latter especially is that story choices will inform system choices in a game that combines both, an open city game like GTA or a level-based systemic game like Thief.
The story often informs how detailed the simulation should be, and the constraints on locations that are needed for story purposes. Ideally it also informs what themes the simulation needs to reinforce.
While this stage is still some time away from being able to fully integrate the two, in those kind of genres story development must start as early as possible. Once we get to a certain point, not having a solid story outline/treatment can cause a lot more wasted effort. Or worse, a simulation whose experience is totally out of sync with the game’s story elements.
Since these prototypes are not very useful for pitching, if you do need to sell internal or external decision makers on the gameplay, they are usually only good for talking over to explain any new gameplay concepts. You’ll have to rely on look development going on in parallel (especially via sizzle reels, mocked up gameplay footage at production quality art levels, etc.) to pitch the concept at this point if necessary.
Always Be Closing
While the focus on iteration in game development processes over the last decade has certainly been a good thing, it does have a down side – you can over-focus on prototyping, causing production in general to slow down. As soon as you reach the point you feel comfortable making the decision to include/exclude a given system, put down the prototype and move on.
The simpler and more confident you are about the role of the system, the less you need to prototype it. If you have enough information to make a decision, don’t stall on it. Decisions can be thrown away just like prototype code, too, if something goes wrong later.
Now you have some concrete systems that work for your high level design. Ideally you also have some ideas as to how those systems connect, but that’s the fundamental question to answer in the next phase – building a fully connected simulation.