Assault on the Exploding Barrel Factory
Requirements and Specification Document
February 12, 2008
Version 1.0
1. Project Abstract
Assault on the Exploding Barrel Factory could be made available as a free download and
provide many people with an entertaining experience. This community of potential
players represents the customers for the product. The game itself will be a first person
shooter that features the player fighting their way through the factory, overcoming
obstacles and enemies in the form of automated defense systems that would draw on the
exploding barrel motif whenever possible. The aim would be to use this theme in a
humorous way while also providing fun gameplay, poking fun at many video game
stereotypes along the way. In this manner, the game could be made entertaining for the
player and represents a viable product.
2. Document Revision History
Rev. 1.0 – February 12, 2008 – Initial Version
3. Customers
3.1 Gaming Community
This game will be freely distributed and will run on a Linux platform. There are not many
games which run on this platform, so many gamers who prefer this method should like
this game. This community of Linux gamers represents the potential users for this
product.
3.2 Specific Users
Several people have expressed interest in being actively involved with providing
feedback for the game during the development process. They are as follows:







Adam Horne
Ben Everson
Dinesh Penugonda
Myra Rivera
Edwin Rodriguez
Xavier Vega
Albert Choi
4. Competitive Landscape
4.1 We do not have a brand name
Consumers are more likely to buy a product from an established company than an
obscure one. When one thinks of Electronic Arts, gamers know they have a history of
producing decent games. Lack of brand name recognition will make it more difficult for
us to advertise.
4.2 Large, Small Companies vs. US
Large software companies have in house and advanced API’s. We do not. Due to our
time constraints, we will be required to obtain open source items to handle certain aspects
of the game engine. In addition, larger companies have a diverse talent pool. Many
programmers can specialize in specific parts of the game (i.e. graphics, physics engine,
artificial intelligence). These same programmer teams suffer from difficulties in
communication due to their sheer scale and number of people involved. Being in a group
size of 3, our communication cost is much smaller and coordination will be much easier.
Everybody will have better familiarity with different parts of the game, allowing for a
much more flexible development process.
4.3 System Environment
We will be developing this game to run in a Linux environment. Most games are
developed for the Windows Operating System. This carries with it both pro’s and con’s.
On the negative end we restricted ourselves in the API’s available to us. On the positive
side, we will be developing for a small niche and will have less competition when our
game is complete.
4.4 Time/Experience
We only have 8 weeks to develop this product. For large software companies, it can be
upwards of a year. Furthermore, we also lack experience in producing games. Many
companies have employees who spent years developing games. This is our first time.
Because of this, this game will not be able to go toe-to-toe with major development
studios in areas such as physics and AI. Therefore, in order to make our game a viable
product, we will have to make the game fun to play in general and entertaining in other
ways to minimize this weakness.
4.5 Competition
Not only do we have to compete with other computer games, we also must compete with
Playstation, Wii, Microsoft X-box, etc. There are a lot of options in the market.
4.6 Money
Since we have limited financial resources, we are limited in the amount of money we can
spend on off the shelf technology. Therefore, we either develop it ourselves, borrow
from open source projects, or we don't do it at all. Since we don't have a brand name, it
will be difficult for us to raise funds.
5. Requirements
5.1 Installation
Pre-conditions: (Subject to change based on results of development process)
512 MB Ram
128 MB video card
~2 GHz processor
Hard Drive space? (Guess 200 MB (should include sounds, textures, configuration files,
executable, etc).
Internet Connection (to download the game installer)
Linux OS
Post Conditions:
Game is installed.
Basic Flow:
1.
2.
3.
4.
User is prompted to choose an installation directory.
Installation process runs based on user input.
Installation completes.
User can choose to start game immediately upon exiting installation.
5.2 Game Start/Menu
Pre-conditions:
Game has been installed.
Post-conditions:
Main game menu is loaded and displayed.
Basic Flow:
1. User executes the game program.
2. The main game menu is loaded and displayed.
3. The user can then choose from the following options:
a. The user can start a new game.
b. The user can resume a saved game.
c. The user can modify the controls of the game.
d. The user can modify the difficulty of the game.
e. The user can quit the game.
5.2.1 New Game
Pre-conditions:
User selects new game.
Post-conditions:
Introduction screen(s), movies, etc. are shown.
Game world is loaded and player is placed at start location.
Basic Flow:
1. See 5.3.1 “Game Initialized.”
5.2.2 Load Game
Pre-conditions:
User selects load game.
Post-conditions:
Game world is loaded and player is placed in stored location.
Basic Flow:
1. See 5.3.1 “Game Initialized.”
5.2.3 Modify Controls
Pre-conditions:
User selects modify controls.
Post-conditions:
New menu shown containing controls and the keys they are mapped to.
Basic Flow:
1. Player clicks on a particular functions button.
2. Next input (i.e. keyboard key, mouse button) is mapped to that function.
3. Player exits menu, returning to main menu.
5.2.4 Modify Difficulty
Pre-conditions:
User selects modify difficulty.
Post-conditions:
New menu shown containing current and possible difficulty levels.
Basic Flow:
1. Player clicks on one of two arrow buttons to increment/decrement difficulty.
2. Brief description of difficulty is displayed in menu.
3. Player exits menu, returning to main menu.
5.2.5 Game Exit
Pre-conditions:
User selects quit option.
Post-conditions:
Game program is terminated.
Basic Flow:
1. See 5.3.5 “Quitting the Game.”
5.3 Gameplay
5.3.1 Game Initialized
Pre-conditions:
User begins new game.
-orUser loads previous game.
Post-conditions:
3D game environment loaded, player place it proper location with correct values (Health,
Ammo, etc.)
Basic Flow:
1. Depending on whether the game in new or loaded, a file containing relevant
information (i.e. Location, Orientation, Health, Ammo, etc.) is read and parsed.
2. The game environment is built and rendered using this information.
3. The game engine is engaged, and the player begins to play.
5.3.2 Game Interaction
Pre-conditions:
Mouse and Keyboard are installed and working.
3D game environment loaded.
Post-conditions:
Gameplay continues smoothly.
Barrels are exploded. Fun is had.
Basic Flow:
1.
2.
3.
4.
5.
6.
7.
8.
Uses mouse to look.
Uses left mouse button to shoot.
Uses 'wasd' keys to move (up, left, down, right respectively)
Uses number keys to change weapons.
Uses ‘esc’ key to return to menu. (Gameplay should be immediately resumable.)
Uses ‘p’ key to pause game.
Player health, ammo, etc. are shown in HUD.
Player must reach door to next level/room, while avoiding/destroying exploding
barrels.
5.3.3 General Gameplay Flow
Pre-conditions:
None
Post-conditions:
New level is loaded.
Basic Flow:
1. Player works way through room of factory, avoiding obstacles and destroying
automated defenses. Rooms are themes to be different parts of the assembly
process.
2. If player dies/fails, player is restarted at beginning of room.
3. Player reaches door at the far end of the room.
4. Player enters hallway/airlock.
5. Door is locked behind player.
6. Previous level data is flushed, new level data loaded.
7. An autosave is made, for use as the spawn point if the player dies.
5.3.4 Saving the Game
Pre-conditions:
Game is in play. (Specifically, this option is not available in the menu until after the game
has been initialized.)
Sufficient hard drive space.
Post-conditions:
File containing relevant game information is generated and stored.
Basic Flow:
1. Player opens game menu.
2. Player selects ‘save game’.
3. Player is prompted to name the save file. If one of the same name already exists,
the player is prompted to overwrite. All saves are stored in a directory in the
game’s installation path.
5.3.5 Quitting the Game
Pre-conditions:
None
Post-conditions:
Game process terminated.
Basic Flow:
1.
2.
3.
4.
Player opens game menu.
Player selects ‘exit game’.
Resources are freed.
Returns to OS.
5.3.6 Game is Completed
Pre-conditions:
Game finished. All barrels destroyed.
Post-conditions:
Credits are shown
Returns to main menu
Basic Flow:
1.
2.
3.
4.
The player reaches the end of the game.
End screen(s), movies, etc. are shown.
Credits are displayed.
Player is returned to the main menu.
5.4 Non-Functional System Requirements
Timing:
Platform:
User Interface:
Scalability:
Responsiveness:
Legal Issues:
Should run at 30 frames per second.
Linux.
GUI Menu and "First Person" 3D Environment.
Should be able to run with system requirements from 5.1.
Game should respond to user input immediately.
Should have legal disclaimer for sharing, copying, modifying.
6. Checklist















Have all the viewpoints of all the stakeholders been taken into account?
Do the requirements completely specify what the function of the program should
be?
Are all non-functional requirements (e.g. speed, memory, capacity) specified?
If there are requirements imposed by the environment in which the program will
be used, are those requirements specified?
Do the requirements avoid specifying a solution or a design?
Are separate requirements listed separately and not lumped together?
Are the requirements clear and precise, not ambiguous?
Are the requirements consistent, no contradictions?
Are the requirements accompanied by a rationale or justification?
Are the requirements given in a consistent format?
Are the requirements properly prioritized?
How is the notation in the document? Are graphical and mathematical notation
used appropriately? Is the technical jargon kept to a minimum?
Does the requirements document make good use of scenarios and use cases?
Are the requirements realistic?
Are the requirements verifiable?