Game Engineering Process Patterns

Introduction

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

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.

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.

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.

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"

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.

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

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

Coding Standards

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

Prototyping

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