====== 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&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 ----