Shoot from the hip or do a pre-viz

Working as a game designer is super fun, difficult, demanding and unlike anything else. In a recent article in Gamasutra, Matt Allmer writes:

Game design is like sailing a ship while still building the hull! Jump out of a plane while still sewing your parachute and you’ll get a good sense of pace in this business. The horse is never put before the cart. We race them side-by-side to see which one wins!

I think the above pretty much nails what this job is about. The article lays out a set of basic principles of game design (13 of them) and is well worth reading. I am, like Allmer, of the view that the game design process, albeit chaotic by nature, can and should be tamed by carefully applying process and principles. I won’t argue for or against the particular principles mentioned by Allmer, but instead talk a bit about what I have seen (or not seen) of intentional game design process within the industry and look at a very powerful tool.

I think that all projects I’ve been on has been initially approached from a design view in pretty much the same way. There’s been a period of brainstorming around features, environments, AI issues and whatnot (in the cases of “Riddick” and “Darkness”, a lot of thought went into finding suitable features to the existing IPs). Brainstorming is all great fun and valuable, but also s bit scary since the material and ideas produced will form the foundation for your work the upcoming couple of years. You don’t wanna go all wrong and you want to keep some leeway for future changes so you tend to not be too specific and detailed at this stage. Formulating the design vision and laying out the foundation for the project is more important. (But I do believe that there are methods and tools to do preliminary evaluation of your designs even at this stage. I’d really like to try one or two things some time) However, as the project moves along the team starts working on realizing the vision and trying out the design ideas. This process is often unnecessarily slow and cumbersome. Usually, it goes something like this:

  1. Based on a pretty high level design or general vision, you create a more detailed paper design which is reviewed together with team members. Issues are raised and the design is perhaps revised a couple of times.
  2. Required planning is done.
  3. (Placeholder) content and assets are produced and code is started to be created.
  4. As soon as something that runs on a console or PC can be seen, the design can be properly reviewed.
  5. If you’re okay, iterate content, design and code until satisfied.

In the worst case, it is not until after point 4 that you know whether you have something that works as imagined, if your new feature introduces previously unknown risks into the project or if you have to go back to the drawing board altogether. Fortunately, if you have a team with skilled and experienced people, or if you are seasoned enough yourself, you will hopefully be able to decide whether to move on from point 1 to 2 by applying some preliminary analysis. My experience is that ever too often, that new feature that looked so simple and straightforward on paper will explode and quickly transform into a complex beast before you know it.

So, along the way towards a reasonably full implementation you will most probably run into hard-to-foresee problems and you will have to either adapt your design or revise the production plans (which usually means cutting something else). For instance, you might find that switching between 1st and 3rd person causes awkward-looking arms and weapons in 1st person because of the field of view and suddenly you need to implement two separate animation sets for the hero, one for each camera mode (in this particular example, you will face other problems too).

As you gather experience, the amount of surprise problems like these decrease somewhat, but we work in an industry that moves very fast. Each new project demands innovation in some or several areas — and let’s not even begin talking about technology. So you will face new types of problems on a regular basis and it’s extremely hard to anticipate how everything will unfold as you start realizing your game vision.


At the latest project I worked on, we were fortunate enough to be able to do a lot of pre-visualizations (and some simple prototyping) before doing the first implementation tests. This is something we could almost only dream about in earlier projects. Now and then we actually did pre-viz something, but not very often. We did, for example, a really cool first person hand-to-hand combat test very early in the production of “Riddick”, but that test was more a high level vision than a real preparation for implementation based on a particular design. It did give us some answers to how fighting should feel like (which was very valuable), but it didn’t attempt to answer how it should work mechanically.

Most often, pre-viz tests has either been neglected as a worthwhile thing to do, or it has been impossible due to massive workloads and time constraints. But having worked with much more extensive pre-viz production than ever before, I must say that it is a time-saver and a super-valuable tool for a number of reasons. In my latest project, we had a large number of mechanics that we didn’t know how to create. Many were advanced character control mechanics and those were, thankfully, pretty straightforward to pre-viz. In the typical case, an animator put together a clip with the hero character doing whatever interaction we wanted to test. A camera track was also carefully set up. We usually had to do one or two iterations over the pre-viz to get everything right. We tried to emulate as much as possible of what we wanted in the final game in terms of cameras, timing, looks on animations, environmental constraints etc, but even so, producing a pre-viz was very fast. And for that modest time investment, we got a lot back:

  • Problems were immediately exposed. We had a maneuver where the hero could jump and grab a specific game object and then continue moving along that object. Our pre-viz tests (we did several) immediately showed us severe camera movement issues that would be very hard to solve. Our solution became to ignore the problem and have the camera do a hard cut to the “grabbing” position. We continued to test this solution in pre-viz videos to get the right angles and flow for maximum clarity and drama. In the end, the feature came out really great.
  • The goal becomes clear to anyone. A design on paper risk becoming something different in the head of each team member that reads it. It’s better if you tag along sketches or diagrams, but it’s still a problem. In the case of character movement mechanics, a video surpasses everything else in clarity. As we become better at creating pre-vizes, our coders said again and again that they was really helped by the videos we produced since they could really see what we meant.
  • A pre-viz is a fantastic communication tool. The strength of the pre-viz for communicating clearly (as per previous point) means that a pre-viz can very easily be sent out for quick review and feedback, either internally or to the publisher. Pre-vizes tend to speak for themselves much more than written pieces of information so you can quickly get feedback from people that knows very little of the project.

As our project moved along, the pre-viz mentality slowly settled and we tried to apply it whenever we felt we had unanswered questions that we might be able to answer by simpler means than by implementation:

  1. We did the usual mockup screens and diagrams of GUI and HUD elements. We laid out typical missions will each piece of information we needed to hand the player identified and tied them to the GUI – in effect running missions on paper (prototyping on paper could be very useful).
  2. Some important HUD functions were tested in video to anticipate what he needed to do to improve player guidance. These tests exposed problems with the rendering being too unclear on CRT televisions and the design was reiterated before implementation began.
  3. We had a simple 2d flash tool where we could lay out and prototype missions, place objectives on the map and play them as they would unfold in the game. We could also have the tool measure traveling distances. We didn’t get to use this prototyping tool very extensively, but I’m certain that it would eventually have been useful when pacing missions.
  4. We invented a dynamic music system that we believed would create just the dynamic response we aimed for. We manage to test the basics of the system by capturing footage from sections of Just Cause 2 which we tagged with information on the game’s music state and also mixed in placeholder music, stingers and washes to match. We had some initial concerns if our system would work but fortunately this test showed that it would work, given that we managed to take care of a couple of problems that the test exposed.

These were just a couple of examples of where pre-visualization material helped the design process and production immensely. In many cases, realizing how to create a pre-viz was straightforward (animated hero + camera, for instance) while in other cases, we had to be somewhat inventive to find a way to test what we needed to test (like the music system example above).

Looking at previous projects in hindsight I can easily identify a bunch of problems we did run into that would probably have been exposed much earlier and with less cost by doing proper pre-visualizations. But of course it’s easy to be afterwise. And even if you manage to work with pre-vizes in the most optimal way imaginable, game design is still about building the hull while sailing the ship. The difference is that day by day you will evolve much more accurate blueprints — and hopefully you can shoot less from the hip.

Leave a Reply