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
  • [In this excerpt from Game Design: How to Create Video and Tabletop Games, Start to Finish, game designer Lewis Pulsipher offers a detailed breakdown of the processes involved in traditional game design. Our previous excerpt from Pulsipher's book can be found here.]

    Creating a game is a project, and follows the same kind of planning cycle as any project. This is the Plan-Execute-Monitor-Control-Replan cycle, as illustrated in Figure 2:

    Figure 2: Project Management and Game Development Cycles

    If you don't plan at all, you'll be constantly fixing things, often taking action to fix something that would not have needed fixing if you'd done things right. If you plan but don't check to see if reality (Execution) matches the plan (Monitor), then sooner or later reality won't match the plan. Further, even if you know the plan and reality doesn't match, if you do nothing to fix the situation (Control), then you deviate into failure. Assuming you Control the deviations, you then need to redo the plan. In other words:

    - If you don't know what's supposed to happen, how do you know what to do?

    - If you don't know what is actually happening, how can you make the right thing happen?

    - If you can't make the right thing happen, how can you get where you need to go?

    - If your plan doesn't adjust to reality, how do you know where to go, now?

    Further, looking at the second part of Figure 2, we see that the major process in creating a good game is similar to the management process. When you've reached the point of a playable prototype, you play the game, analyze the results, modify the prototype, and play again, around and around until you're "finished", or you give up, or you're forced to stop.

    Figure 3: Process of Game Design expresses the process a different way, in Data Flow Diagram terms borrowing from Systems Analysis.

    A "system" is an assemblage or combination of things or parts forming a complex or unitary whole. Typically, in systems analysis someone figures out how a system works, or ought to work, with the possibility that some of it might be automated. Here we're interested in how it ought to work so that we can use that knowledge in design.

    A data flow diagram shows the processes that occur in a system as well as places where data is stored, flows of data/information or objects from one place to another, and external entities that interact with the system:

    - circles are the processes, where things happen

    - the oddly shaped rounded rectangles are the data stores,

    - the arrows are the flows of data/information or objects,

    - and the rectangles are the external entities, outside the designer himself

    The purpose here is not to show time sequences but to show all the things that might occur. Hence during the operation of the system at any given time several of the processes might be occurring. It's not unusual during the design process to be generating ideas, playing the game in your mind's eye, and even conceiving the game structure and framework all at the same time. Often you could be creating and refining the prototype writing notes, rules, or software, and playtesting all at the same time.

    The system we're diagraming is game design. The publisher and playtesters are outside the system, as they are not actually designing the game (we hope).

    "Complete" is in quotes because publishers usually require changes to a game, sometimes for good, sometimes for ill, sometimes accidentally, sometimes deliberately. Researching and solving mass production issues is outside the system, insofar as the manufacturer does this.

    The diagram is meant to show the process for any game, non-video or video. It is a diagram that assumes a single designer, which is not the case for AAA video games, which are effectively designed by groups of people. A AAA video game creation diagram, which we'll see in Chapter 8, Section A (not included in this excerpt), is dominated by communication and cooperation because so many people are involved. Designers of big video games must cope with both sets of demands represented in two diagrams.

    Design collaborators are shown outside the system, as well, but in some cases two collaborators will work so closely that they will collectively be within the process just as a single designer is within the process.


comments powered by Disqus