Guidelines for the Software Plan
Created by: Lead Software Engineer
Target audience: Software
Team (primary)
Art Team (secondary)
Sound Team (secondary)
Approval: Game Producer/Project Manager
Development Manager
While the
functional specification explains what is going into the product, the
software plan explains how. The plan is a working blueprint for the game
The primary
author is the lead programmer, though it is often more timely and useful if the
programmers responsible for implementing the various program areas be
responsible for documenting them. In its compiled form, it should present a
plan that any programmer can understand and work from.
As the main target audience is programming team, the document will generally be written from the system perspective as opposed to the user perspective. The process of writing it will flag any of the uncertainties on the programming side and any problems in the functional spec.
Any changes or additions to the template Software Plan need
to be agreed in advance with Project Manager or Development Manager. An
overlooked detail can lead to undesirable results in the product, project and
team dynamic.
The Plan is detailed as follows
Project
Overview
5
AI
The platform indicates what development technologies will be
used. Detail the target hardware platform – include here as much detail as
possible including the CPU, memory, storage, display, etc. Clarify what are the
minimum and ideal system requirements – include specific hardware and
peripherals here like 3D cards, memory card, joysticks, etc. The platform
details should be forwarded to the QA team as early as possible.
Operating System: Detail the targeting operating
system on the gaming platform. If more than one, list each OS. Indicate the
most common development environments used on the OS. Highlight any known
risks/problems with the target OS.
Based on the
information supplied about the target platform and OS, explain and detail what
programming language & development environment (including version no and
cost) will be used. List the advantages of using the chosen language for the
project. List any other development packages that will be needed – including
source control, resource tools, installers, etc
External Game Code: Describe the source and purpose
of any game code that will be used but not developed by the project team. This
includes code libraries like DirectX, any acquired video or sound API, or any
other off-the-shelf solution.
Directory structure: A description of the development
structure should be defined – this will include where builds, resources,
scripts, etc are stored and named. Access privileges should also be included.
Programmer’s guide: Based on the language used, a
guide should be devised to ensure consistent programming standards. This will
cover naming conventions, class/data structure design, portability issues, code
reviews etc
This is certainly the bulk of the document. The perspective
must be from the system out as opposed to the designers’ or users’ perspective.
Core game objects: Based on the Functional Spec,
create and display the game class tree, using UML (or a similar modelling
language). All relationships/dependencies are to be shown.
Detail each individual class; describing its purpose,
methods, interfaces and data types. If using Design Patterns, specific why the
specific design is being used.
Detail how code will be organised e.g. system library, core
game library, graphics library, etc
Control loop: Be specific about how control is
transferred from the start-up code to the shell and down into the main game
code. Explain the use of multi-threading, drivers, DLLs and memory management.
Of course further details on the likes of multi-threading and memory management
will be covered in the areas that they will be used most, like the rendering or
sprite engine, sound code and AI.
Level Specific Code: Based on the level design seeds
in the functional specification, describe how code specific to those levels
will be implemented and how it will accomplish the desired effect.
Data driven: Put all the factors that control
behaviour into data files read at run-time, so the designers can change and
balance
game details as required. Detail any internal tools that are required to
support this.
4. Resources
Explain how resources/data is stored, loaded, transferred,
processed, saved and restored. While references should be made to data entry or
processing tools, separate functional and technical specifications should be
made for any complex or user intensive tools.
Devise a strategy to accomplish the behaviours and
decision-making described in the functional specification. Detail any AI
algorithms that may be used. Include the methods of manipulating the AI as
dictated by the functional spec, i.e. whether it’s data driven or embedded into
compiled code, and whether it’s a scripted language or a fixed set of variables
or a combination of both. AI should include path finding, target selection,
tests and events to attach reactionary behaviours to, and other decisions made
by characters, units or intelligent game elements involving game situations and
unit statistics. Break down the statistics used to control the behaviour.
6. Multiplayer (if applicable)
The game code architecture must be reviewed from a
multiplayer perspective. Questions to be addressed include;
What connection methods and
protocols are supported?
Is it client-server or peer-to-peer?
What are the packet sizes and how
often are they sent?
What is the structure of the
packet?
How are missed packets and latency
issues handled?
What messages are broadcast and
what are sent to specific hosts?
How many different messages are
there and when are they used?
Look and feel is one area of the design that undergoes the
most changes during development. Therefore, its necessary that the programming
for the GUI be as flexible as possible, separating game purpose from GUI
function, so that changes that occur to the user interaction methods will not
affect other areas of the game or require significant reprogramming. Create a
variety of GUI objects (controls) using inheritance to maintain a consistent
code interface to the events and the values. Assume that any of the GUI objects
can be exchanged at any point in the project. To this end, your documentation
should be flexible and generic. While it should break down the GUI into the
screens, windows and menus, it should not go any further into the specific interaction.
Instead, document how the various GUI objects will work, wherever they are
used.
Game Shell: List all the screens that make up
the game shell - all the screens and windows other than the main play
screens. These are derived from the flowchart in the functional specification
(include installation and set-up screens). Each item listed should be its own
subsection with a description of its purpose, its scope (i.e. before or after
level specific data is loaded), the pertinent values it will be accessing and
setting, and what functions it will call.
This section needs to explain how the art and video will be
stored, loaded, processed and displayed in the game. This includes the
animation system, whether it’s 2D or 3D, and the video decompression and
streaming system (including off the shelf solutions).
Graphics Engine: Whether you are using sprites,
voxels or 3D-polygon rendering or a combination, break down their classes in
very specific detail and the interfaces to the core game code. Describe areas
like view ports, clipping, special effects, and the connection to the collision
and movement functions described in the game mechanics.
Artist Instructions: Break out the details important to
the artists, like resolutions, bit depth, palettes, file formats, compression,
configuration file definitions and any other data the artists need to define to
fold in the art. Consider what tools can be created to streamline the art
pipeline, and indicate their specifications here or create separate
specifications for the more complex or user intensive tools.
Describe how sound will be loaded and played. Be specific
about the use of mixing, DMA, multiple channels, 3D sound, and methods of
determining priority. If using third party drivers, describe their interface
and purpose. Be sure to address all of the requirements specified in the
functional spec.
Sound Engineering Instructions: Break out
the details important to the sound engineers and composers, like sample rates,
the use of multiple channels, 3D sound definitions, sample length etc. If using
MIDI, indicate the version to use and the number and type of instruments that
can be used and possibly stored. Indicate the data path and file requirements
including any specific configuration files that need to be created. Consider
what tools can be created to streamline the sound pipeline, and indicate their
specifications here or create separate specifications for the more complex or
user intensive tools.