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
  • Book Extract - Creating Games: Mechanics, Content, and Technology

    - Morgan McGuire and Odest Chadwicke Jenkins

  • 5.10 User Interface Storyboards

    For a computer game, the user interface is the installer, the title screen, menus, dialogs, in-game heads-up display and information displays, options screens, and any other controls or text. Each of these must be storyboarded for both content and graphic style, although content is the primary purpose of this section. Storyboards can be simple sketches that show the GUI elements, with callout boxes and labels indicating the function of each element. Flow charts (state machines) are needed for each major GUI interaction showing the modes that the interface can be in and how the player's actions change modes.

    User interface storyboards are simpler for a board game. In this case, they are essentially concept art for the layout of the play area, board, and pieces. The difference between the UI section and the concept art section is that UI focuses on functionality and concept art focuses on style.

    5.11 Tags and Dialogue

    This section is exclusive to video games. The tags and dialogue section is a database that maps descriptive labels (tags) used by the programmers and designers to actual text that the user will see and hear in game. For example, a button labeled "Launch Attack!" in the game might have the tag ATTACK. Later in the development cycle, the designers can decide that the button should instead say "Commence Firing." To make this change, the tag stays the same, but the value stored for that tag in the tag database changes. This way, the programmers don't have to update their source code for cosmetic changes, and the technology and design teams can work without interfering with one another. Tags are also used for dialogue lines. The tag HELLO INKEEPER1 could map to "Salutations, weary traveler. Come in and rest yourself for a while."

    Tags are critical for internationalization. Translators can work through the database without significant concern for where text appears in the game. Likewise for adjusting potentially offensive language to satisfy content ratings.

    In games with spoken dialog, tags map not only to text but to audio files, although these are more difficult to change. However, like translators, voice actors can work through the database of script lines. Voice actors should be given some context and experience with the game so that their tone and inflection are appropriate.

    5.12 Technology Plan

    The technology plan is primarily for video games, but it can be adapted to board games in a useful way. A video game requires several major pieces of software. Some are part of the game itself, like the core engine (rendering, physics, and networking) and the gameplay code (user interface, artificial intelligence, and game logic). Other pieces are tools: the software used for maintaining the design document (e.g., Microsoft Word, wiki), the artist tools (e.g., 3DS Max, Photoshop), the programmer tools (e.g., Visual Studio, VTune), the management tools (e.g., Project, Excel, Trac), asset management (e.g., AlienBrain, Subversion), level editors, art exporters, and so on. Hardware technology is also required for console development, development consoles, all development workstations and servers, and often special-purpose technology like motion capture and 3D scanners for artwork.

    The technology plan enumerates all of the technology needed for producing the game and maintaining the company. It designates whether it will be bought or built in-house. For technology that can be bought, the specific solution selected should be explained and defended. For technology that must be built, the rationale for building in-house should be explained and the rough specifications for the project outlined. The buy/build decision is often easy except for core engine technology, where the company must decide if it can adapt an existing game engine or must build its own. For further discussion of core engine technology and this difficult decision, see Chapter 6.

    Board games require some tools for production (usually 2D art programs and word processors) but not nearly as much as video games. However, board games have another technology requirement in terms of playing pieces and their manufacture. The technology plan for a board game should discuss how those pieces will be obtained and the costs associated with that plan. Generic pawns and dice can be purchased inexpensively, but custom pieces require a more significant investment. Playing boards and cards can be surprisingly expensive to produce, although there is great room for savings by altering the printing method or switching to lower-quality (sharp corner, monochrome, thinner) paper and cardboard components.

    For students working on a class project, the technology plan is highly constrained by the materials available for the course. For a board game, reusing existing game pieces and boards is a fast and cost-effective alternative to producing custom pieces. For a video game, using open-source software or writing a mod for a game engine is a great alternative to buying or building. Students are often tempted to build most of their technology, but reusing existing technology allows you to focus more on design and innovation and less on reinventing the wheel!

    5.13 Software Architecture

    Video games require complex software design. The architecture documents describe the features of each programming module. This includes the major application interfaces (APIs), the algorithms that are used to implement them, and the design patterns behind them. In addition to text and tables of numbers, architecture typically contains many diagrams. These include inheritance diagrams, memory depictions of key data structures, and data file format diagrams. The two types of diagrams that always appear are the system module diagram and the data flow graph. The module diagram depicts the high-level control structure, and the data flow shows how information moves.

    The system module diagram looks like a brick wall, where each brick is a software component. Components at the bottom are low-level libraries, such as DirectX and Havok. If we personify the components as people in a company, these are the laborers who will do the actual "heavy lifting." The components that rest on top of them direct the action of these lower libraries. Those themselves are managed by higher-level routines. In programmer terminology, higher boxes call into the boxes below them, creating a dependency. Components at the top of the module diagram are generally the most specific to the particular game, while those at the bottom are so generic that they may be provided by the platform manufacturer for use in all games.

    The boxes in the data flow diagram are major software components (some of which are licensed), and the arrows show the kind of data that flow between them. The direction of arrows shows data dependence. Data generally flows in from pre-created art assets and real-time user input and out to the display. An example of the data flow diagram for a typical game appears in Figure 6.3.

    5.14 Controls

    Video games depend on their control schemes. An otherwise great game can fail because the input mechanic is too awkward or is targeted at the wrong audience. The controls section details both the mapping of buttons to in-game functions and the algorithms mapping analog inputs to actions.

    Figure 5.6: Controls for Roadkill on the PlayStation 2 by Red Octane. (Image courtesy of Red Octane/Activision)

    This section contains images such as Figure 5.6 that show the explicit control layout for traditional input devices, as well as action diagrams for more recent innovations such as accelerometers (e.g., the NintendoWiimote), video cameras, and audio and gesture recognition. Chapter 17 explains the technology behind user input and theories of how to design effective input schemes.

    5.15 Level Design

    Most games are divided into levels that represent a discrete change in difficulty, such as different waves of aliens in Space Invaders. It can also be a scenario or map, such as the warehouse "Assault" map in Counter-Strike or the Joan of Arc battle in Age of Empires. In a classic emergent game like chess, levels become vague (although one could consider the opening, middle, and end games to be separate levels).

    In a game that has a strong and primarily linear progression, levels are generally areas of a larger world (although the same location may be revisited as a separate level). The progression through this is indicated by the plot graph.

    For games with location-based levels, create maps that show the layout and the connectivity of the level. Indicate major encounters, key item locations, and goals. The topology of the level is more important than the true proportions for this section, but you should make notes tying areas to the art direction section.

    Provide analysis of the level space, diagramming the flow of characters through the area and identifying choke points and focus nodes. A choke point is a small area that controls the flow between major parts of the map -- for example, a narrow mountain pass and a bridge over a river. Characters will be funneled through these areas, and control and influence over such areas will become key to the player's strategy. A focus node is the location of a shared resource. Examples include a gold mine in an RTS game, a key power-up in an FPS, a healing shrine in a fantasy game, the flags in a rally race, and a watering hole in an animal simulation. These areas increase player interaction by bringing them together. Unlike choke points, they are not necessarily sources of contention because players may collaborate to use the resource and may share it if it is not limited.

    Some games have randomly generated levels, like Settlers of Catan and the random maps in StarCraft. For these, discuss the kinds of features that will appear in the level and how the level-generation process ensures that they arise in the proper distribution.


comments powered by Disqus