Game Engineering Process Patterns
Patterns Used To Improve Game Engineering
Zachary Booth Simpson, Origin Research Fellow
Steve Beeman, Origin Director of Technology
14 May 1999
- A collection of patterns used to improve game engineering
- Documenting the obvious = Wisdom
- Disclaimers: not complete, no magic bullets, we may not be as agnostic as we fancy ourselves.
- Put developers in a room and lock the door.
- Second set of eyes helps documentation, bug finding, personal development
- Promotes programmer redundancy
- gotcha) Programmer becomes defensive -- may view as review instead of chance to improve.
Technical Design Review
- Experienced outsider reviews project
- Create a reality check for team and mgmt.
- Can happen at a variety of times during project: start, midway, troubled, etc.
- gotcha) confrontation over results.
- gotcha) kill the messenger.
- Clarify priorities early, develop risk budget.
- Identify mismatched risk / fun features.
- gotcha) Don’t throw away valuable game asset: ability to change problem.
- gotcha) Becoming married to details
- gotcha) Designers may play more value on feature than marketplace.
- Bugs from previous milestone are addressed for next milestone.
- Bugs have hidden costs, kill them early.
- Promotes stability. Less likely to change something that isn’t broken.
- gotcha) not faster, more predictable.
- gotcha) pressure to say:"things are on track"
Daily Build Cycle
- Daily build and archive of every asset.
- Assets don’t get lost or become stale.
- Identifies bad code quickly; promotes a strong self-test attitude.
- gotcha) annoyance.
- gotcha) version control must work well.
“How” Docs & Example Code
- Documents which describe how a system works as opposed to why it is the way it is.
- Most useful when presented as examples.
- gotcha) overly specified doc just restates the code in English
- gotcha) docs become out of date quickly, examples go stale.
- Doc which describes why a system is the way it is. What mistakes were made? What alternate solutions were abandoned?
- Helps prevent repeating the same mistakes.
- gotcha) Can degenerate into how docs, or become way too long.
- gotcha) Inclination to hide bad decisions reduces usefulness.
Code & Tool Reuse
- L1: Libraries, L2: Frameworks
L3: Example Code, L4: Knowledge
- Reduce reinvention of wheel.
- “Black boxes” deter redesign.
- gotcha) Learn by doing is reduced.
- gotcha) Ignored because code is different
- gotcha) Hard to debug what you don’t know
- Standards for naming, bracketing, commenting, documenting.
- Reduces “it’s different” arguments.
- gotcha) politically explosive
- gotcha) More namespace collisions
- Create a disposable simulation.
- Five kinds: UI, Algorithmic, Structural, Architectural, Demos
- Help make decisions early.
- gotcha) not incremental development!