Download game_des

Assault on the Exploding Barrel Factory
Design and Planning Document
February 21, 2008
Version 1.0
1. Document Revision History
Rev. 1.0 – February 21, 2008 – Initial Version
2. System Architecture
The goal of the design for this system is to abstract the physics, graphics, audio, and
artificial intelligence so that the core game world does not have to worry about their
implementation. This is accomplished via bridges which will allow for a standardized and
simplified interface to these functions.
2.1 Packages
2.1.1 Entities Package
The entities package will have many responsibilities essential the functionality of the
game world. It will contain a list of all entities currently present in the game world, as
well coordinate the interactions between them. In this capacity, it will work with the A.I.
package (to handle enemy behavior) and the physics engine (to resolve collisions). It will
also be responsible to sending data to the graphics and audio packages for rendering.
2.1.2 Resources Package
The resources package will be responsible for managing the game entities being held in
memory, and for providing pointers to information relevant to individual entities,
including model and texture data, among other information. This will allow for more
efficient use of memory, as for each type of game entity the pertinent data will only be
held in memory in one location, avoiding unnecessary copies. The resource package will
also be responsible for the garbage collection of this data, and any data no longer being
used by an active game entity will be unloaded.
2.1.3 A.I. Package
The A.I. package will abstract the inner workings of enemy behavior in the game, hiding
it from the entity package. This will allow the entity package to send a call requesting the
next action for an enemy entity, and not have to worry about the way in which the
behavior is determined. The behavior of an entity will be determined by a finite state
machine, and if different types of enemies are added later, the A.I. package will
determine the proper machine to use to determine behavior.
2.1.4 Menu Package
The menu package will handle the user’s interaction with the game’s menu system and all
of the functions associated with it. This includes the loading and saving of game data, and
the modification of the file containing keymaps. It will also be responsible for generating
the menu interface.
2.1.5 Graphics Package
The graphics package will abstract the graphics rendering process from the game world.
It will feature a bridge class with standardized functionality to be used by the game
world, and will utilize OpenGL behind the scenes to render the game world.
2.1.6 Audio Package
Similarly to the graphics package, the audio package will abstract the graphics rendering
process from the game world. It will feature a bridge class with standardized functionality
to be used by the game world, and will utilize OpenAL behind the scenes to play the
sounds of the game world.
2.1.7 Physics Package
The physics package will simulate the game world and monitor for any collisions that
occur. It will implant the OPAL open source physics engine, and will send data on
collisions back to the entity package to be handled in an appropriate manner.
2.2 Typical Program Flow
1.
2.
3.
4.
5.
Capture player input from buffer and update player entity accordingly.
Simulate A.I. behavior and update relevant entities.
Step physics engine forward 1/30th second.
Update entities based on collisions.
Render game world (graphics and audio).
3. Class Design
3.1 Entity Package
3.2 Resources Package
3.3 A.I. Package
3.4 Menu Package
3.5 Graphics Package
3.6 Audio Package
3.7 Physics Package
4. Detailed Design
4.1 The Finite State Machine
4.1.1 Description
The AI for the game will be using a Finite State Machine, which will be hidden behind a
bridge. This will allow us to update to more advanced AI routines in the future, time
allowing. If all conditions are true, the machine fires a shot at the player. If one of the
conditionals returns false, corrective action is taken on the part of the entity (i.e. rotate to
face the player) and on the next cycle the tests are run again.
4.1.2 Behavior Flow
4.2 Singleton Pattern Implementation
Many of our classes will use the Singleton pattern, including the ResourceManager and
ResourceFactory, the EntityManager and EntityFactory, the Finite State Machine and the
various states, and the GameWorld.
4.3 Bridge Implementation
We are using the bridge pattern to hide the implementation of the graphics, audio, A.I.,
and physics, which will allow us to change or add different implementations without
major modifications to the overall code.
5. Testing Plan
Our project will have a testing framework that will include unit testing, integration
testing, load testing, system testing and regression testing.
5.1 Unit Testing
Wherever possible, we will include unit tests. Although much of our content is graphical,
we will test for data integrity. All tests will be logged to allow access to previous results
since the software will continually be modified.
5.2 Integration Testing
We plan to use a bottom up approach at the initial stages of the project to make sure that
different important subsystems are compatible with each other. Later we will also use a
top down testing approach to more accurately reflect user interaction with the system.
5.3 Load Testing
Since games require a lot of resources, we will include tests to ensure that the program
does not use an excessive amount of memory.
5.4 System Testing
Most of our testing will investigate whether particular features work well with the whole
system. We will isolate certain features, such as walking through a door or firing a gun,
and check if the game runs smoothly and performs to a satisfactory level. This will have
to be done manually, and our customer base has agreed to assist in this process. This will
also help us refine the feel of the game and give the customers a chance to offer feedback
on desired features.
5.5 Regression Testing
We plan to build an automated system that will run all of our unit tests. We plan to have
the test run automatically with each nightly build, and on demand if we desire to test
whether a change will have undesired effects.
6. Plan
6.1 Development
6.1.1 Build Goals
The initial goal will be to construct a system capable of rendering the game world and
featuring player interactivity. This will involve the integration of the game world, the
physics engine, and the graphics engine. Once this is achieved, enemy A.I. will be
integrated next, and finally audio. These elements together will represent the basics
necessary for the game to function. From here, additional features will be implemented as
time permits, potentially including increased game content (in terms of levels), additional
enemies (and their A.I.’s), and new weapons for the player.
6.1.2 Coding
The coding of the game will be divided amongst the programmers based on individual
strengths in certain areas. The game world itself, consisting of the entity, resource, and
A.I. packages will ultimately be a collaborative effort will different programmers
working on different classes within each package. This will allow everyone on the team
to become familiar with the intricacies of the system, and will facilitate innovation,
particularly once the desired base level of functionality has been achieved. The audio,
graphics, and physics packages will each be handled by an individual programmer, as it is
more useful in the case of these to have one programmer specialize in each and abstract
the complexity away from the other programmers. David will be responsible for the
graphics package, Jack for the audio, and Ben for the physics.
6.2 Testing
We plan to use a series of automated scripts to implement unit, integration, and load tests.
These scripts will be written by the programmer who wrote the particular section of code
and reviewed by another member of the team. They will be run automatically at the
completion of every build to facilitate regression testing. System level testing will be
conducted manually to make sure the system works as expected and to allow feedback on
its performance. These will be carried out by the team and by the customers listed in the
Requirements Document.
7. Checklist
7.1 Content













Is the design complete, well-organized, and clear? Are the components and
interfaces specified in enough detail that the design could be turned over to an
independent group for implementation and still be understood?
Is the design specified hierarchically?
Are diagrams used effectively?
Are design patterns used effectively?
•Is the level of abstraction appropriate and consistent?
Is information hiding used effectively to isolate complexity?
Is information hiding used effectively to isolate parts of the program that might
change?
Is the design minimal?
Is coupling between components in the design minimal?
Is the strategy for the user interface design covered?
If needed, is the database design specified?
Does the design include a coherent error-handling strategy?
Are all the requirements in the requirements document covered by the design in a
sensible way, by neither too many nor too few building blocks?
7.2 Testing








Does the design avoid nondeterministic behavior?
Does the design include self-checks?
Is the design stateless wherever possible?
Does the design include a test interface?
Are all the testing stages (unit, integration, validation) covered?
Is the regression test strategy covered?
Are non-functional validation tests necessary and covered (stress, performance,
security, etc.)?
Does the testing plan include walkthroughs or inspections?
7.3 Planning




Does the plan include multiple iterations, each adding functionality
incrementally?
Does the plan take dependencies among different components into account?
As much as possible, does the plan avoid situations in which the entire team
would have to wait if one task is not finished on time?
Is the timeline realistic?