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.16 Mechanics Analysis

    The heart of the gameplay design in the document is the mechanics analysis section. It is equally important for video games, board games, major AAA titles, indie games, and class projects. Pen-and-paper RPG manuals, such as the AD&D Player's Handbook, give a good idea of what the mechanic descriptions in this section should look like. Economics textbooks give good examples of how to analyze, model, and balance mechanics.

    Mechanics, also known as game mechanics, are small groups of rules that outline a strategic conflict, inspire a particular emotion in the player, or move the game forward. They are perhaps best understood through some examples.

    Racing is a classic mechanic. Get to the finish line before your opponents. Racing puts time pressure on the player, creating stress and motivation. It is inherently both fair and balanced; the achievement scale is defined by the ratio of fastest to slowest racer. The racing mechanic need not be as explicit as cars on a track. For example, in a capture-the-flag game, a race mechanic begins as soon as a flag is taken and both sides are trying to reach the goal (or intercept the carrier) as fast as possible.

    Shooting is a popular mechanic. It involves reflex actions, strategy in setting up a shot before the enemy appears, and leading the target when projectiles are slow. Shooting doesn't have to involve guns. Various games have used shooting mechanics to fire oneself out of a cannon, take pictures of wildlife, or successfully throw and catch a ball in sports.

    Describe the mechanics in your game. Mechanics are typically shared between large numbers of games and are the primary definition of genre. Indicate what other games use similar mechanics and describe the differences. Motivate the gameplay reason for each mechanic. Does it prevent an undesirable strategy, simulate some aspect of the game's setting, or exist to deepen strategy in an otherwise too simple game? Explain alternative mechanics that could have been employed to address that need and why this one is better. What is the strategy that arises from the mechanic?

    Give guidelines for making the mechanic balanced and useful for gameplay. Support these arguments in text, graphs and diagrams, and probability and mathematics.

    Other common mathematical tools for evaluating and balancing mechanics are outcome matrices and unit databases. Outcome matrices are for evaluating competitive situations where one kind of unit is up against another kind. The matrix lists the first unit type along the rows and the second unit type along the columns. Each entry in the center describes the outcome for the combination of unit types (think of a multiplication table from school or a road map that shows the distance between cities). Unit databases are tables with the unit types listed down a column and adjacent columns describing their statistical properties, like hit points and movement speed.

    For each measurable property of the game (e.g., points, gold, health), give a target graph of how it should ideally vary over time. See Chapters 7, 8, and 10 for further discussions of the mechanics analysis section.

    5.17 Schedule and Related Elements

    5.17.1 Schedule

    The master development schedule describes the plan for producing the game on time. It is broken down into prototype releases and milestones, and those are divided into individual tasks assigned to developers. Milestones describe the features and user experience that will be available at distinct points in time. They should be monthly or bimonthly for a game that is in development for years, but for a month-long indie project, they may be weekly or every other day.

    Tasks can be chained based on dependency in a Gantt chart to graphically indicate when a task has been inappropriately scheduled before another task it must build on. Figure 3.7 shows a project schedule maintained in Microsoft Project with both a Gantt view and a breakdown per milestone.

    5.17.2 Staffing Plan

    For a commercial game, the staffing plan describes how developers will be hired over time to meet the demands of the schedule. It can be expressed as hiring milestones or as a graph running along the bottom of the timeline. When designing it, remember that recruiting, interviewing, and training talent takes time from both the new hire and the existing team members. An indie team or a class project team generally has no hiring and needs no staffing plan.

    5.17.3 Key Developers

    Briefly describe the qualifications of team leads, producers, and managers. These are the people who should have proven track records and who will be held responsible for delivering a quality game product on time. Qualifications include education, previous job experience (especially games shipped), exceptional skills, and awards received.

    In industry, this section is primarily to convince a publisher (or investor) that your team has the ability to deliver the game that it is promising to create. In academia, this is to convince your teacher that your team has the necessary skills.

    5.17.4 Issue Tracking

    Issue tracking is a more sophisticated version of maintaining a "to-do" list. Issues are known bugs (also: errors or drawbacks) of the game design or implementation, customer support requests, and features that have been requested but not approved or scheduled. Issues are what you aim to eventually change into lines on the change log.

    Issues are commonly owned by one developer, but they are stored in a format that is visible to management and the rest of the company. A video game has so many issues that they are usually stored in a database and not in the design document itself. For a board game or extremely simple (e.g., puzzle game) computer game, a bulleted list with some details at the bottom of the status section may suffice.

    Figure 5.7: Sample bug list and a specific open ticket from the SourceForge issue tracking system for the G3D game engine.

    Figure 5.7 shows a screenshot from an issue-tracking system. The top of the screen is a table listing a small number of issues stored in the database. The table lists the developer who is assigned to resolve the issue, a summary, the date, and so on. The bottom is a detailed view of a single issue that has been selected.

    5.17.5 Status

    How is the project going? Augment the schedule with one or two paragraphs that summarize the current status in text. These should point out milestones that are at risk of slipping and major successes. Keep this up to date at all times.

    5.18 Budget

    The budget section describes the total cost of development. Line items include the cost of purchased technology, salary (according to the staffing plan), recruiting costs, art assets, and contractors. Marketing is not usually the developer's responsibility, but if you are producing a shareware/independent title, then that is a factor. See Appendix D for sample budget worksheets.

    5.19 Change Log

    Because it is a working document, the design document that you begin with might not might not look anything like the one you end with. Many changes are trivial and need no explanation. If you expand information that is already present or fix a minor error, everyone understands the change. When a major change is made, however, it is important to record that information. For example, if one mechanic is completely removed after a playtest, it should be noted on the design document, and everyone who will be reading it should be alerted. For such a change, add a line to the change log section briefly summarizing what happened -- for example, "Removed time limit on water war stage because playtesters reported excessive tension on that level."

    Developers frequently release rule changes (for board games) and patches (for video games) even after the game itself has been released. These are accompanied by change logs to let the players know what changed. Those change logs are edited versions of the ones that are in the design document.

    Some designers call the change log the revision history and maintain it right after the title page. The back of the design document is another popular location. It is often useful to not only maintain a bulleted list but to designate build or version numbers between strings of changes. This is helpful when reviewing old playtesting information to see what set of changes were enacted before and after the test.

    5.20 Exercises

    1. Give one player composite for the core constituency of each of the following games.

    (a) Pokémon

    (b) chess

    (c) Counter-Strike

    2. Draw a plot graph for your daily routine containing about 15 nodes. Use branches to indicate different ways your day plays out -- for example, according to the day of the week or based on what you find in your e-mail.

    3. Why are tags used in games instead of just putting the value of the tag directly into the game code?

    4. What is the difference between the plot graph and level design?

    5. List ten game mechanics -- for example, racing, shooting, and rockpaper- scissors relationship.

    6. What is the difference between the key developers section and the staffing plan?

    7. Why is a change log useful?

    8. Find the change log for a published game, and list a few of the major changes between versions.

    9. Create a "blank" design document for your project. This should contain all of the sections that are relevant but need not have any content beyond the section titles and the cover page. You can do this by starting with one of the templates on our webpage and deleting unnecessary sections or by following the instructions in this chapter.

    5.21 Resources

    It is hard to obtain sample design documents for major titles because game developers and publishers consider them confidential internal documents. However, a few have been published. The following reading contains examples of design document templates or completed design documents.


comments powered by Disqus