002.

Technical Design Document

Table of Contents
002.Technical Design Document 0

2
002.Technical Design Document

002.Technical Design Document

Technical Design Document

Remember that you are first and foremost software system architects. Game software
designers are the cream of the crop of software engineers. Game designers design and
implement gameplay, could be a deck of cards, or paper and pencils. Game programmers
refers to writing the code that automates that deck of cards or paper and pencil game.
Beyond just writing code, Game Software System Architects design the systems that are
then farmed out to coders to build.

We use documentation to plan, design and communicate all aspects of a project, in our
case, a game. The game design documents describe the game, the project plan describes
the process of getting it built, and the technical design document describes the software
system that is the game.

It is important to realize that although we read these things linear start to stop, they are
rarely if ever created in the same manner. We often start with a technical core and work out.

If you have done your game design descriptions correctly, you have defined the player
activities and the games response. All characters and game objects, all battle systems and
scoring systems have been worked out on spreadsheets in the depth of detail that you can
play the game on paper by this time.

The time of defining gameplay mechanics has passed and now it is time to translate the
player activities into the software system requirements. We are going to use the Prototype
Software Requirements Specification as provided by IEEE 803-1998. It is an industry
standard framework for formatting software system requirements. According to the IEEE
guidance, a well done technical document will be accurate and complete, with system
features prioritized by importance, with no ambiguities or inconsistencies. The system
design and build must be verifiably matched from the gameplay rules, to the deployed
software system, with a documented audit trail that can be traced from beginning to end.
Lastly, the documentation and development processes must be flexible enough to be
modifiable to respond to unforeseen discoveries along the way. Most of these are self-
evident, and can be researched for further background, however lets take a look at some of
the highlights.

What does complete mean?

002.Technical Design Document 3

002.Technical Design Document

All attributes of functional and performance requirements and constraints are included for all
internal components and external interfaces. All data classes are defined, and all situations
of system responses to them are described, including what happens when invalid entries are
made. All terms, units of measure, are fully defined in the appendices, and all figures, tables,
and diagrams are fully annotated. If TBD is ever used (and it is strongly recommended at
this phase of development that you recognize that all TBDs are weaknesses and threats to
project success,) it should always be accompanied by the situation that is causing the TDB
and what can be done to eliminate it.

What is consistency all about?

This relates to establishing continuity throughout the project. If a lower level detailed
description does not match a high level description, then the build is broken by nature. This
is also important to establish an audit trail being able to establish traceability. According to
the guidelines, there are three types of inconsistencies.

1. The specified characteristics of something are in conflict. For example, the Mages
attributes are prioritized as Intelligence, Wile, and Conjuring power in one section, and
Intelligence, Wile, and Strength in another (given that Strength and Conjuring power are
two distinct objects.)
2. There is a logical or sequential disparity in the process flow.
i. One section says leveling up is a multiplicative event, level one multiplies the value
of the attribute by one, level two by 2, level three by 3, etc. And another section
says, or the system was built additive, so that level one adds 1, level two adds 2,
level three adds 3.
ii. Player must achieve A before B is unlocked. Yet in a subsequent section, or
actuality the player is able to achieve B without having accomplished A.
3. Linguistic continuity, where different sections describe and define the same thing using
different terms.

What are the degrees of necessity and stability?

Just like standardizing the descriptions and definitions of the system is essential, instilling an
understanding of the accepted nomenclature is also essential to clear and unambiguous
communications. The categories used are Essential, Conditional, and Optional.

1. Essential requirements are just that, the system is not functioning as required without,
like a collision boundary around an object meant to take damage. These are show
stoppers.
2. Conditional requirements enhance the system but are not essential to its operation.
Upgrading a weapons, shields, or drive system enhances gameplay, but the games
essential identifying characteristics remain regardless of this feature.
3. Options are not requirements, but are nonessentials that many or may not be

002.Technical Design Document 4

002.Technical Design Document

worthwhile. In one game project it was proposed that having a randomizer that caused a
pilot to sneeze, thus obscuring his view and concentration, causing a random challenge
to performance.

Why are Verifiability and Traceability important?

How else do we know we have built is what was originally described? In the industry this is a
huge one. When a system is contracted, money is a stake (even on salary basis.)
Sometimes large amounts of money. Contractual obligations for large amounts of money
attract lawyers. Having an ironclad testing and verification environment on your project is the
core of protection. Of more practical importance it ensures that what has been proposed,
contracted, designed, built, and paid for is delivered. To achieve this verifiability, we bind a
test case to every use case.

Traceability brings us to where the rubber meets the road. Essentially, the logical flow is to
start with your completed game document wherein every player activity and game response
is charted out in detail. Remember, if it is not in the game design document, it is not in the
game. The player activity list is written from the players point of view, The player launches
the game, the player logs in, and the player chooses an existing profile or creates a new
one The technical design document translates these activities into the point of view of the
software system, Upon launch, then system presents to log in screen. The screen contains
a form with fields for collecting username and password, as well as a link to register a new
account or reset password. In the ad supported version, there is a space provided at [exact
screen location]

Be mindful that these are examples to illustrate the activity of translation, and are not in the
standard format used. The format is a structured list. The reference number of each list item
is used to link traceability through the document trail from the player activity list in the game
design document, through the software system requirements document, to the unit testing,
integration testing, platform testing, and final user acceptance testing documents. Line item
traceability is the audit trail.

Rapid development and the use of a prototype or proof of concept to aid the design
process.

Prototypes (see ASTM E1340-96) are extremely useful in our post-waterfall liberation. First
off, is the game playable? It it fun? Is it interesting, compelling, and satisfying, craved by its
players? There are three main benefits of prototyping beyond these and project feasibility.
They provide quick feedback, they display unanticipated behaviors along with the anticipated
aspects raising questions that may not otherwise be anticipated until later in the process. It
is more difficult to respond to surprises the farther along in the development process, so
systems that start with healthy prototyping and design specifications take less time to
complete.

002.Technical Design Document 5

002.Technical Design Document

A prototype is also a way to extract software system requirements, experiencing the actual
process flow is far more accurate than thinking it up. This is especially true with large
complex systems and interfaces. It is sometimes simpler to cobble together an interface
screen based on quick sketches or a mental picture, and use a screen shot of it for design
documentation. It also allows experimentation to further mature a systems capabilities.

The Core

The documents formal name says it all Software System Functional Requirements
Specification. What are the specific functions that the software system is required to
provide?

This document translates the players activities point of view into a detailed description of,
what functions are to be performed on what data to produce what results at what location
and for whom.(IEEE 830-1998, Sec. 4.7, Paragraph 2)

The Requirements list is an external point of view of the system that describes the external
behavior of the system, not the internal processes, that is done during the next stage using
UML tools. Game object designs like character classes and game item classes, and their
attributes are modeled in the Game Document. From these will be eventually come the
system blueprints translated into UML data class entities. The structured requirements list
doesnt say how something gets done, just that it is required to occur.

Here is the prototype outline in un-annotated format, given in the IEEE 830-1998 Standard.
It is started by fleshing out information imported from same items in the game design
documents. Remember that this strictly limited to describing the software, not the market or
player type, competitive marketplace, or any of that type of meta information about the
game.

Table of Contents

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, acronyms, and abbreviations

1.4 References

1.5 Overview

2. Overall description

002.Technical Design Document 6

002.Technical Design Document

2.1 Product perspective

2.2 Product functions

2.3 User characteristics

2.4 Constraints

2.5 Assumptions and dependencies

3. Specific requirements (See 5.3.1 through 5.3.8 for explanations of possible

specific requirements. See also Annex A for several different ways of organizing

this section of the SRS.)

Appendixes

Index

Annotated version

Since the standard provides a prototype, it is expected to be modified for each particular
use. Form follows function. Sometimes not everything is needed. When that is the case
when these documents are drawn up as legally binding contracts, some unneeded parts are
documented as being agree to by all parties as not needed. Mention of these are made
within the document framework, and they are accounted for by entering the details of the
agreements of their release.

The following is how a game design documents player activities list is organized according
to guidance from IEEE 830-1998. It is used to directly derive the technical core of the system
requirements.

Table of Contents

1. Introduction The first two sections are similar to an executive summary and are high
level introductions of things that are filled in detail later in later document settings.
i. Purpose High Concept/Genre, highest level game play description, feature set.
ii. Scope What is part of this and what is not? Platforms, Constraints and limitations.
For example, is the project phased, so that this set of development includes
building the single player version of the game only, with preparation for the next
phases of LAN and MMOG implementations?
iii. Definitions, acronyms, abbreviations Self-evident, any terms that someone
outside of the team needs to understand.
iv. References

002.Technical Design Document 7

002.Technical Design Document

v. Overview of the requirements document. A 20k foot view of the document structure
for easy reference.

2. Overall Description This birds eye level view of the system, it is meant to describe the
technical settings (diagramed models are a good supplement.)

2.1 Product perspective Platform details, for example, if this game is part of a larger
gaming system, such as a casual online multiplayer game, hosted on a central server, with
peer to peer connections between player devices, including phones, tablets, PCs, consoles,
and dedicated game systems, how do the components being built in this project fit in and
interface with the rest of the components?

2.2 Product functions How do the components of this project interact with the components
outside of itself, if any.

2.3 User Characteristics What specialized interface devices required such as Kinnect, Wii,
touchpad, joystick, specialized controller, etc.

2.4 Constraints Example: if multi-platform, are some features limited on some?

2.5 Assumptions and dependencies

3. Specific requirements

3.1 External interface requirements If anything, what does this development unit send to
others and how. For example, if this projects output is a tablet client for a network hosted
game, and is being developed in parallel with the server software, how does it interoperate
with the server and other peers on different platforms such as phones and consoles?

3.1.1 User interfaces

3.1.1.1Logical characteristics (functions performed) of the each instance where the system
and user interact. Layout diagrams, screenshots, menu trees, input and feedback contents.

3.1.1.2Feedback specification for optimizing usability.(see usability criteria)

3.1.2 Hardware interfaces Devices and protocols supported and how

3.1.3 Software interfaces Purpose and contents of the data objects sent and received, and
how

3.2.4 Communications interfaces network protocols supported

3.2.5Platform constrains hardware architecture, memory, storage, security, protocols,

sensor availability, etc.

002.Technical Design Document 8

002.Technical Design Document

3.2 Functional requirements This is the core of what it is all about. Remember at the
beginning of this paper, I mentioned that although we read these things in a linear manner
start to stop, they are rarely if ever written the same way. This is the actual starting point and
where most of the focus takes place during the requirements gathering stage. This list is an
interpretation of the Player Activity List, into the external system view discussed earlier.
From this list are derived the break down, and modularization and communication schemes
of the production unit.

This is the most highly detailed section of the document. Each line item should contain only
one verifiable step. Where a user interface collects information, the information collected is
listed line by line. This section is best augmented with annotated diagrams that illustrate the
sequence and flow of the process.

Line item numbers are used to reference diagrams and process flow maps, and for
traceability through the audit trail. When we start drafting the blueprints for the system
modules, we derive use cases from this list, we reference the section numbers as practical.
Often the more detailed the description (Item Sec. 3.2.2.1.4.5), the less likely the numbers
will harmonize between documents. The higher level numbers (Sec. 3.2) are used as it
makes sense to trace from this list, to the use case, to the test case, to the optimization and
bug reports, to the final acceptance document.

The industry standard practice is to use statements listed as, the system shall In the
game design document, you used statements that started with, The player shall This is
the basis of the translation. If you did your game design properly, this part fills itself in once
you get the hang of it. It is also time to think through the minutiae.

Lastly, keep in mind this is written to define the fundamental actions that are required to take
place by the code in handling inputs, and processing them, and sending outputs. At the most
basic level, keep in mind the need to think about the following things as you work on the next
Section, 3.2.1.

3.3 Module funtionality

3.3.1Validity checks on the inputs does it need to verify non corrupt input and how.

3.3.2 Sequence of operations where is this module placed in the order of flow

3.3.3 Responses to abnormal situations, including

3.3.3.1 Overflow

3.3.3.2 Communication facilities

3.3.3.3 Error handling and recovery

3.3.4 Effect of parameters configuration, situation and environmental changes

002.Technical Design Document 9

002.Technical Design Document

3.3.5 Relationship of outputs to inputs, including

3.3.5.1 Input/output sequences

3.3.5.2 Formulas for input to output conversion

3.2.1 Subsystem A name

3.2.1.1 Requirements statement

3.2.1.2 Requirements statement

3.2.1 Subsystem B name

3.2.1.1 Requirements statement

3.2.1.2 Requirements statement

3.2.3 Physical implementation Details This happens during building the code on the well
commented code level. Code modules should be referenced back through the line of
traceability from code snippet to use case, to test case, to requirements list, to player activity
list.

3.4 Performance requirements - The expectations for acceptable performance

3.3.1 Standards, protocols and security

3.3.2 Hardware limitations

3.2.1 Availability

3.2.2 Security

3.2.3 Maintainability

3.5 Database Data classes and structures

3.5.1 ERD

3.5.2 Data types used by specific functions

3.5.3 Frequency

3.5.4 Accessed

3.5.5 Integrity verification

5.5.6 Retention standards

3.6 Testing Plan

3.6.1 Methodologies

002.Technical Design Document 10

002.Technical Design Document

3.6.2 Resources

3.6.3 Results

Blueprints for the System

Once the requirements list is complete and agreed to it is time for the next step of
interpretation. The following items derived from Section 3: Use Case diagrams, Use Case
scenarios, Class Diagrams, Activity diagrams, Sequence diagrams, TOR charts, CRC cards,
Test Cases, and Acceptance Criteria.

Example Translation

Note that at the highest level we are describing the Home Screen (Fig 1), Create an Account
(fig 2), Main Game Menu (Fig 2), Screen Game Setting (Fig 3), and Create Profile (Fig 4)
interfaces. Think of the subsections of each as expandable menus to stay organized. This is
presented to illustrate how to see the logical modules in the user activities. In this example a
group of activities are related to each other by functionality.

Interface Prototypes

Fig 1 (Ref 1.2, 1.5) Fig 2 (Ref 1.4.1) Fig 3 (Ref 2.3)

Fig 4 (Ref 3) Fig 5 (Ref 4)

The Player Activity list has sequences for the following scenario.

1. Home Screen
i. Player launches game
ii. Player sees Home Screen containing
i. Instructions on the nature of playing the game anonymously or as a registered
player
i. [Details]
ii. Instructions for creating an account
i. [Details]
iii. Button to start a game anonymously - [Reference to concept or art asset]
iv. Button to create an account - [Reference to concept or art asset]
v. Log in fields
i. Username
ii. Password
vi. Exit Game Button [Reference to concept art or art asset]
iii. Player Chooses anonymous

002.Technical Design Document 11

002.Technical Design Document

i. Player spawns in game world at default first waypoint.

iv. Player Chooses to create account
i. Player sees registration screen containing
i. Name
ii. Email
iii. Username
iv. Password
v. Submit button [Reference to concept art or art asset]
vi. Cancel Button [Reference to concept art or art asset]
ii. Player response
i. Enter information into fields
ii. Click Submit
i. User sees Home screen
iii. Click Cancel
i. User sees home screen
v. Player chooses to log in with existing account
i. At Home screen, player enters valid credentials
i. Username
ii. Password
iii. Clicks Cancel
i. User sees Home screen
iv. Clicks Submit
2. Main Game Menu Screen
i. Upon successful authentication player sees Main Game Menu
i. Start new game button [Reference to concept art or art asset]
ii. Load existing game button ] Reference to concept art or art asset [
iii. Existing character icons [Reference to concept art or art assets]
i. Edit button [Reference to concept art or art asset]
ii. Select button [Reference to concept art or art asset]
iv. Create new character button [Reference to concept art or art asset]
v. Game settings button
3. Game Settings Menu Screen
i. Sound
ii. Music
iii. Graphics
iv. Network
v. Main Menu
4. Create Character Menu Screen
i. Character Class
i. Thief

002.Technical Design Document 12

002.Technical Design Document

ii. Paladin
iii. Mercenary
iv. Mage
v.
ii. Appearance
i. Avatar editor [Reference to concept art or art assets, presentation dependent
on character class selected]
ii.
iii. Equipment
i. Player presented Initial equipment items depending on character class
ii.

Process Flow Diagram.

Fig 6

Now that weve set up the game design document criteria, it is time to see how this
translates into the Technical Software System Requirements as we have discussed.

Specific System Functional Requirements

1. Upon system startup and verification of running conditions the software system
shall present the Home Screen
2. Home Screen Options
i. Launch new game anonymously
ii. Create Account
iii. Log in
i. Username
ii. Password
iv. Exit Game
3. Upon launch new game anonymously software system shall move the player into
the game world with default and randomized attribute values
i. Load generic avatar
ii. Configure avatar attributes
iii. Provide avatar equipment
iv. Spawn avatar at default initial waypoint
4. Upon create new account software system shall present an interface to collect
specified information for immediate storage and retrieval for system use.
i. User inputs
i. Name
ii. Email
iii. User Name

002.Technical Design Document 13

002.Technical Design Document

iv. Password
v. Submit
vi. Cancel
ii. Upon submission the software system shall send the user profile() data to the
database
i. Perform verification of existing username
i. If the username already exists, the software system shall display
status message, [Username Already Exists]
ii. If the username does not exist, create database entry in correct fields
i. If database entry fails the software system shall report and record the
details of the incident.

The software system shall display Database failure message

An error report will be appended to event log

The message shall contain pertinent information about the failure

1. If the database entry succeeds The software system shall display

success conformation dialog message

If the user does not input acknowledgement after 10 seconds, the software system shall
display the Home Screen

Upon user input acknowledgement the software system shall display the Home Screen

1. If the user chooses to cancel the registration process, the software system
shall display the Home Screen

This is enough to see how the translation has revealed very detailed underlying processes.
We started off with the numbers but the additional steps have discontinuous traceability.
Extremely ambitious projects will index across documents, but that degree of fastidiousness
doesnt suit getting the game code written. So for the audit trail, well assign the use case ID
from the latest and most detailed revision of the requirements list.

A partial logical process flow looks very different from the game design maps. It illustrates
what the software does, and should look something like this:

Fig 7

002.Technical Design Document 14

002.Technical Design Document

Task Object Relationships

It is also time to be thinking about the software objects, their names, and where they are
placed on the above map. user profile() is not a misprint in 1.4.2, it is forward planning for
the name of a code object. There will be a need for createUserProfile(), verifyUserProfile(),
as well as others that will come to mind. This is where we start the Task Object Relationship.
We now have the task name, and the functions it needs to perform.

Fig 8.

TOR

Object Name Functions carried out

createUserProfile() collect user input from create new account

check database for identical existing entry
create properly named record in database
insert correct data in proper field
holds data until destroy signal from validateUserProfile()
sends signal to createUserpProfileSuccessDialoge()
validateUserProfile() select all record fields
compare all record fields to data help by createUserProfile()

report check status

If fail present error dialog containing relevant message
If fail append relevant message to event log with incident time
stamp
If succeed send destroy signal to createUserProfile()

If succeed send signal to createUserProfileSuccess()

The Task Object Relationships are the beginnings of the Use Cases, since they define the
activities one per line that the function performs. This basic list is

Game Entities to Data Entities

In the game entities are described in the game document. Character classes have been
created with sets of attributes and relationships. The battle systems and scoring systems are
developed and ready for conversion to code objects. Starting with the topmost classes,
Objects, Characters, Environmental items. All of these have the possibility of being
interactive or non-interactive, interactivity becomes an attribute of all classes. The Objects

002.Technical Design Document 15

002.Technical Design Document

class may contain battle gear, building gear, building materials, vehicles, power ups, all with
some mathematical effect on the game system. The Character class contains Paladin,
Mage, Thief, and Mercenary.

Fig 9

Character Classes and Their Attributes from the game design document

Self
Life Stamina Strength Intellect Wile Stealth
interest
Paladin -
7 6 8 5 3 5 4
Power
Mage -
4 5 4 8 6 5 7
Wisdom
Thief -
5 5 5 7 9 7 8
Dexterity
Mercenary 6 6 7 5 4 8 5

This is the beginning of a class diagram based on the table above, and show the
organization of the attributes and functions that make up the game objects.

Fig 10

Refer back to your software engineering coursework and experience to continue building
your Entity Relationship Diagrams as you iterate through the recommended development
cycle.

From Software System Requirements List use cases are batched by function. In the
example above, the function was interaction with the registration and login functions within
the player account management module. From the TOR list, we build out use cases and
take them through the following steps. Be sure to check DocSharing for more templates.

Fig 11

| 1. Analyze player activities and translate into system requirements | | | --- | --- |

002.Technical Design Document 16