Important Note

Tufts ended funding for its Open Courseware initiative in 2014. We are now planning to retire this site on June 30, 2018. Content will be available for Tufts contributors after that date. If you have any questions about this please write to

Tufts OpenCourseware
Author: Ming Y Chow

Tufts OpenCourseWare
Introduction to Game Development
M. Chow
Spring 2012


Game Development Methodologies

In General...

  • ~80% of the development is design
  • ~20% of the development is the actual coding
  • Planning and some documentation are important

Why Do Some Many Game Projects Fail?

  • Unachievable ship date
  • Bugs galore
  • Overworked developers
  • Cost-overruns
  • High licensing costs
  • Difference in goals and methodologies among team members or groups
  • Unreasonable goals; "too many ideas"; "feature creep"
  • Dedication
  • Skill and knowledge
  • Poor project management
  • Studio culture

Case Study: Duke Nukem Forever

  • Announced on April 28, 1997
  • 3D Realms, the game's developer, closed its doors on May 6, 2009
  • "Normally, videogames take two to four years to build; five years is considered worryingly long. But the Duke Nukem Forever team worked for 12 years straight. As one patient fan pointed out, when development on Duke Nukem Forever started, most computers were still using Windows 95, Pixar had made only movie one Story Toy and Xbox did not yet exist. On May 6, 2009, everything ended. Drained of funds after so many years of work, the game's developer, 3D Realms, told its employees to collect their stuff and put it in boxes. The next week, the company was sued for millions by its publisher for failing to finish the sequel." Source:,
  • Bittersweet ending: playable game at PAX East in March 2011, finally released in June 2011
  • What went terribly wrong:
    • Overweening perfectionism; good enough wasn't acceptable
    • Staggering wealth, thanks to Duke Nukem 3D
    • Obsession with upgrades - Quake II engine, Unreal engine
    • No formal deadline, delivery date
    • Arrogant co-owner and project lead
    • Burnt-out programmers: "I left because I was burned out after working on the same project for five years without any end in sight"
    • Near the end, 3D Realms went on a hiring spree and also borrowed money from Take-Two (the same publisher of the Grand Theft Auto series) to complete the game
  • The Duke Nukem Forever List -events that occurred since its announcement on April 28, 1997:
  • Zero Punctuation: Duke Nukem Forever

A Growing Crisis

  • The game industry now rakes in more cash than Hollywood ($50 billion)
  • Needs maturity
  • A high proportion of developers are leaving the industry
  • That was then: game development didn't require artists or designers; it started with one electrical engineer; then a programmer; 0 to 5 people-years to develop a game.
  • This is now: an armada of developers, artists, testers, and managers for a AAA game; 120+ people-years to create a AAA game as of 2005
  • Safe bets, easier money: ride on the success of previous titles or popular movies
  • Alas, less risk => less innovation => less value => boom of used games market
  • Higher production cost
  • Developers can work 12 hrs / day 7 days a week for months during crunch

Early Methodology 1: The Arcade Gold Rush

  • A single $3000 arcade could collect more than $1000 in quarters per weekend
  • A considerable investment for one arcade game (1000 boxes * $3000 = $3 million required)
  • Field test a game idea by placing a mocked-up production machine in an arcade alongside other games
  • This is the hit-or-miss model: decide to mass-produce, tweak, or cancel arcade based on number of quarters in the field tested arcade

Early Methodology 2: The Classical Waterfall Model (or Game Waterfall Process)

  • Requirements Phase
    • Kickoff meeting(s) with the business analysts, product managers, and senior development personnel
    • Provide an overview of your game
    • Establish project goals
    • Set a tentative development budget
    • Set a tentative development timeline
  • Specification Phase
    • Define what the game should do to meet needs
    • Detail high-level functionality (e.g., the important features)
    • Detail secondary-level features (e.g., nice to have, but not critical)
    • Identify gameplay modes
    • Identify settings, mechanics, interaction models, etc.
    • Outline how the game is "won"
  • Design Phase
    • Get to the specifics of the game based on specification
    • Identify all the actions, errors, tokens, states, labels in the game (ideal to draw a state diagram on how the user moves around the game)
    • Draw mockup screenshots of environment
    • Draw mockup screenshots of user interface
    • Write a low-level (technical) design on all the functions of the game (e.g., menu items)
  • Implementation Phase
    • The actual programming (or coding) of the game based on the design specification
  • Integration Phase
    • Put everything together into a finished game
    • Several rounds of testing
    • Fix lingering bugs
    • Release beta test of product for people to try it out
  • Operation Mode
    • The game has "gone gold"
    • Game is rolled-out to production (actual use)
    • Maintenance - keep the product working and useful to players
    • Fix lingering bugs
    • Add enhancements to game
    • Release patches
  • Retirement
    • NOT rare in computer / video gaming (unlike business software)
    • Remove the product from service (thus, product is no longer supported)
    • Guard legacy source code

MAJOR Problems with Waterfall Model

  • Too popular (and beaten into the heads of countless software engineers)
  • You cannot move on to the next phase without completing the current phase...
  • ...and you cannot go backwards!
  • Very time-consuming and exhaustive
  • Document centric
  • Cascading-effects to next phase
  • Alas, QA is a "low-hanging fruit"

Many Variations of the Software Life Cycle Model

  • Rapid prototyping phase before specification (very popular)
  • Build game in increments (repeated loop; baby steps) - merge design, implementation, and integration phases into a repeated block
    • There is always something tangible
    • Checkpoints and testing are important
    • Reduces errors
  • "Creative writing seminar" - best written components and modules wins
  • Extreme Programming (XP)
    • Team-based and very collaborative
    • Hardly any documentation
    • Unit tests
    • Success depends on ALL members of the team on the same page
    • Very fast (average 6 month for project)
    • Programmers are king, alas, alienating others


  • Iterative process
  • You can develop knowledge over time. What does this mean?
    • "Find the fun"
    • You don't want to repeat the same mistakes
  • Process (repeat)
    • Concept
    • Design
    • Coding
    • Asset creation
    • Debugging
    • Optimizing
    • Tuning and polishing
  • Progressive goal
  • Potential problem: culture of studio and publisher

The Importance of Prototyping

  • All about the interaction
  • Ensure the core mechanics work
  • Test the fundamental rules of the game
  • Visuals are secondary

Game Design and Development According to Sid Meier

  • His résumé of games:
    • Civilization {I, II, III, and IV}
    • Pirates!
    • Railroad Tycoon
    • Gettysberg! and Antietam!
    • Alpha Centauri
    • SimGolf
  • Players should have the fun, not the programmer or designer
  • Begin the game with great opening minutes
  • Great gameplay is a stream of interesting decision that the player must resolve
  • Put the player in a position where he/she is the hero
  • His development process:
    • Prototype
    • Play the game for a while and get the basics right
    • Now get other people to look at the game
    • Meticulously observe the player
    • Constantly reward the player in the game
    • Throw in new testers
    • Make the game harder until the players beg for mercy
  • Read his interview on Slashdot: