1. Game Engineering Processes A collection of patterns used to improve game-engineering by Steve B. and Zack S. Documenting the obvious = Wisdom Disclaimers: not complete, no magic bullets, we may not be as agnostic as we fancy ourselves.

2. Peer Review 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.

3. 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.

4. Requirement Docs 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.

5. Zero-defect Milestones 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"

6. 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.

7. “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.

8. “Why” Docs 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.

9. 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

10. Coding Standards Standards for naming, bracketing, commenting, documenting. Reduces “it’s different” arguments. gotcha) politically explosive gotcha) More namespace collisions

11. Prototyping Create a disposable simulation. Five kinds: UI, Algorithmic, Structural, Architectural, Demos Help make decisions early. gothca) not incremental development!