Joe Chung
Monmouth U. Homepage

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Overview of Software Development Methodologies ======

----

===== Reading =====

  * **Game Design:**
    * http://www.gamedev.net/reference/articles/article1940.asp - Game Unified Process
    * http://www.gamedev.net/reference/articles/article1843.asp - Incremental Development

  * **Gamasutra**
    * http://www.gamasutra.com/features/20051026/gabler_01.shtml - How to Prototype a Game in Under 7 Days: Tips and Tricks from 4 Grad Students Who Made Over 50 Games in 1 Semester

  * **Game Design Document**
    * [[https://piazza.com/class_profile/get_resource/iebohcxbd4a1v0/iepzmw2wzur2m|a game design document (Flauncy Space Cows)]]

----

===== In General... =====

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

Why do many game projects fail (besides bugs galore and overworked developers)?
  * Difference in goals and methodologies among team members or groups
  * Unreasonable goals and "too many ideas"
  * Dedication (lack of...)
  * Skill and knowledge (lack of ...)
  * Poor project management

----

===== 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 the design specifications
    * Identify all the actions, errors, tokens, states, labels in the game (might draw a state diagram on how the user moves around the game)
      * state diagram [[http://rockhopper.monmouth.edu/~jchung/cs498gd/fa11/lect/flauncyStateDiag1.png|example1]], [[http://rockhopper.monmouth.edu/~jchung/cs498gd/fa11/lect/flauncyStateDiag2.png|example2]])
    * 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 certain 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
  * Quality assurance (testing) is most likely to get short-changed when time runs short
  * {{http://rockhopper.monmouth.edu/~jchung/images/rightarrow.gif?25|}} [[http://www.youtube.com/watch?v=NP9AIUT9nos|A provocative video]] {{http://rockhopper.monmouth.edu/~jchung/images/leftarrow.gif?25|}}

----

===== Many Variations of the Software Life Cycle Model =====

  * Rapid prototyping phase before specification (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
    * [[http://en.wikipedia.org/wiki/Unit_testing#Extreme_Programming|Unit testing]]
    * Success depends on ALL members of the team on the same page
    * Very fast (average 6 month for project)
    * Programmers are king; tends to alienate non-programmers on team

===== The Importance of Prototyping =====

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

----

===== Game Design According to Sid Meier =====

His games [[https://en.wikipedia.org/wiki/Sid_Meier|resume]]:
  * The Civilization Series
  * Pirates
  * Railroad Tycoon
  * Gettysberg, Antietam
  * Alpha Centauri
  * SimGolf
  * others

"Players should have the fun, not the programmer or designer."

"Begin the game with great opening minutes."

"Great gameplay is a stream of interesting decisions 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.
    * "He designs and creates his games by playing them, over and over, until they are fun." (Wikipedia)
  * Now get other people to look at the game.
  * Meticulously observe the players of the game.
  * Constantly reward the player in the game.
  * Throw in new game testers.
  * Make the game harder until the players beg for mercy.
  * [[http://interviews.slashdot.org/article.pl?sid=05/10/21/0550213&amp;tid=11"|Interview on Slashdot]]

----

===== Elements of a Game Design Document =====

  * Not all design documents will have all of the following elements.
    * Game Title
    * Overview
    * Gameplay modes
    * Core features in the game
    * Secondary features in the game
    * State diagrams (schematics)
    * Game internal economy
    * Game balance
    * Victory conditions
    * Interface design (high-tech or low-tech)

==== The Importance of a Game Design Document ====

  * Project history (i.e., Have a plan?  Write it down!)
  * Project internal communication
  * Identify system limitations
  * Develop project plan and budget

----