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