Game Software Engineering

PSU CS410/510GAMES Lecture 3
June 27, 2000

• The Software Engineering ``Lifecycle''
  • Requirements Collection and Analysis: What are we doing?
  • Architecture and Detailed Design: How are we doing it?
  • Coding: Doing it
  • Verification and Validation: Did we do it?
  • Maintenance: Making it stay done
• The Game SE Lifecycle
  • Requirements: Rules, Performance, System
  • Architecture: Common among most games
    • State representation (size vs. complexity vs. performance)
    • Search methodology (usually recursive DFS: iterations?)
    • UI (interactions with other components?)
  • Detailed Design: The missing piece
  • Coding
    • On the importance of constant/poly factors
    • Clean code
    • Instrumentation
  • Verification and Validation
    • Unit Test: very important
    • System Test: library of test cases
    • Inspection: individual and group
  • Maintenance
    • Most commercial and academic game software not reproducible!
    • Good maintenance: RCS/CVS, root cause analysis, refactoring
    • Verifying maintenance changes: regression testing
    • Nondeterminism and PRNGs
• Example: Aces Up
  • What are we doing, really?
    • Upper-bounding the win rate
    • Nailing down the rules
  • How will we do it?
    • Architectural design
    • Detailed design: shuffle, search
  • Do it: coding Aces Up
  • Did we do it?: testing
    • Testing the shuffle
    • Testing the search: small cases
    • Validating against requirements