Technical Discussion February 10 2009

SFU Burnaby 12:30pm - 2:20pm

Warm Up Topic

What would you put in a technical design document? Not to be confused with a game design document, this document should focus on information that is important to know for implementing the design.

General comments

  • If you are reusing code for a sequel to an existing game a technical design document is not as important unless significant new features are added.
  • Game design documents are usually not written with implementation in mind so a technical director writing a technical design document must determine which game elements can be implemented the same way. This is a process of simplification and classification.
  • Should be separate from game design document but may be a good idea to reference it.
  • System specs (target system/platform)
  • Tools (version control, compilers, debuggers)
  • Custom tools that will be built as part of the project
  • Engine and middleware libraries
  • File formats
  • Build process
    • Things like continuous integration, automated testing (unit testing included)
  • Code standards
    • Some members suggested this could be a separate document as it does not describe the project specifically.
  • Pipeline
    • How game assets will be fed into the game. Sometimes assets must be generated such as lightmaps
  • Class diagram
  • Level organization
  • How to implement key features
    • The most important part of the document
    • Should specify constraints and suggest possible implementations.
    • Any assumptions that are made about the design.
    • Why a certain algorithm or data structure was chosen and what limitations there are.
    • Where to find information to similar problems in well researched fields. (ie. fluid dynamics to model crowd movement)

Topic 1: Looking at "How to implement key features" in a TDD in more detail

Example: Pong + Gravity (Idea taken from Plasma Pong)

Design Document says:
The playing field is a water tank that contains water (or possibly air or plasma) and the ball and paddles follow or affect the current. The paddles can suck water in or shoot water out by pressing two different buttons.

Technical Document says:
Playing field design
Solution 1: Create a lattice using a 2D array. First start by creating a lattice. The resolution of the lattice should be parameterized for game balancing. Actions include updating the lattice, move an object inside it, shoot forces into it or pull forces from it.
References: Fluid dynamics

Members Present

  • Eric Raue
  • Ali Kim
  • Karol Krizka
  • Colin Hume
Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License