Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Excerpt: A Systematic View Of Game Design

    - Lewis Pulsipher

  • The Processes

    Each of the seven processes shown on the main diagram can be divided into another diagram (not considered in this book) with sub-processes, until there is no point in drilling down further. For learners, the top level is sufficient.

    Remember that the seven processes (activities) may be going on at the same time, not in a particular order. These are:

    Conceive and refine ideas. The game begins in the mind. I've discussed above how important it is to have lots of ideas and how you can generate ideas.

    This is also where you'll research whatever situation you are trying to model -- if any. For example, if you're designing a game about farming, you need to know how farming works, which is likely to require some research. If you're designing a game about the Battle of Kursk in World War II, you'll need to research the battle and the capabilities and intentions of the Soviets and Germans. If your game is intended to be a simulation, closely reflecting some reality, then this research will be very important to the accuracy of the simulation. Nonetheless, do just enough research to get you going, and then work on the game; some people get stuck indefinitely in "research."

    ArmA II is just one of many simulation games that rely heavily on research.

    Play game in "mind's eye" thought experiments. Gradually you'll have some notions about how the game will work. You should play the game or parts of the game in your mind and ask yourself "what is the player going to do and how is this going to be shown in the game." You can play in your mind=s eye any time. You can be riding in a car, you can be waiting in a queue, you can be reading your notes made so far. Experienced designers do this a lot and sort a lot of the game out in their heads before they ever have a prototype to play. Video game designers must rely very heavily on this process because it's relatively difficult and time-consuming to produce a playable prototype of a video game.

    Conceive game, structure, framework. At some point you'll have enough information that you'll lay out on paper how the game is actually going to work. Once you do this then you'll want to make a prototype so you can try to play.

    Create and refine prototype. Creating the prototype is relatively quick for tabletop games but takes far longer for video games. Some video game designers, if it's practical, will make a paper prototype first to test the concepts that are the essence of the game.

    Write notes-rules-software. At some point for video games someone will have to write the software. For tabletop games you can get away with relying on what's in the designer's mind for early playing, but sooner or later rules have to be written. So it's notes at early stages, rules at later stages.

    Solo playtest. The designer plays the game himself so that he can work out the worst problems before he inflicts it on anyone else. If a team produces the (video) game, they likely all play the solo version to discover problems.

    Playtest with others. Most of the play testing ought to be done by people other than the designer(s) and production team. This will include testing for tabletop games where the designer is present and probably teaches the players how to play, and blind testing where the designer is not present or at least has no part in what happens and the players learn the game as though they had just bought it.

    In Figure 3 these two testing processes are adjacent to each other but separate in order to emphasize how important it is for the designer to play the game himself before other people play. (Technically speaking, there probably ought to be one process, Playtesting.)

    It's also important for the designer to play the game himself before other people play. (Technically speaking, there probably ought to be one process, Playtesting.) The designer can find a fix for many problems simply by playing himself. Then the outside playtesters, assuming they're not being paid to playtest, will be happier with the playtesting and more likely to continue to play the game. If the game has big faults when they first play, they're much less likely to play again. You need to work out the really big faults before anyone else plays. (Yes, there are likely to be really big faults.)

    In tabletop gaming, the process of refining the prototype is often called "development," and someone other than the game designer may be in charge. Two heads are better than one, and the developer acts something like a book editor, suggesting or making changes to improve the game. In video games (and many tabletop designs) the designer(s) are also the developers in this sense.


comments powered by Disqus