Bumpers System Design Document
1. Introduction
1.1. Purpose of the system
The purpose of the project Bumpers is to develop a car game called Bumpers. The game should be simple, fast and cheap. Instead of producing a high-end photo realistic 3D game, which need high hardware performance, have a high learning curve and request a couple of time from the player, Bumpers should be a small game that can be played in a couple of minutes and provide a high fun-factor by simple rules. There are multiple examples like Tetris, Moorhuhn or Minesweeper that prove the acceptance and the success of simple games.
To make Bumpers reachable for as many players as possible, it must be available for downloading over the web. The player will not be charged. The project is than financed with advertising.
1.2. Design goals
The design goals represent the desired qualities of Bumpers and provide a consistent set of criteria that must be considered when making design decisions. The following design goals are identified.
- Using Java. As Bumpers must run on multiple operating systems and support at least Windows, Mac OS X and Linux, Java is chosen for implementing Bumpers. By using Java, the same code of Bumpers can run on multiple platforms that support the Java Virtual Machine.
- No dependencies to commercial software components. As Bumpers should be distributed free from any charge or license, it must not rely on any commercial product.
- Usability. The usage of Bumpers must be intuitive. The graphical user interface must be designed that the player understands the game by using it. There must be not need for a player help document.
- Robustness. As Bumpers has just a small set of interactions between the game and the player, all interaction must be designed that the player is not able to enter invalid data.
- Response time. The fun factor of a game depends on short response times. Otherwise the game would not be accepted from the players. The response time of starting the Bumpers application must be below 10 seconds. Once the Bumpers application started, all responses of Bumpers to an interaction of the player must be below 2 seconds.
- Customization. As Bumpers is build for the European and North American market, the player of Bumpers must be able to switch between two versions of Bumpers that are related to the local settings of the two markets. For example, the speed unit of the driven car must be displayed in kilometer per hour or in miles per hour, depending of the version.
1.3. Definitions, acronyms and abbreviations
- Bumpers
- The name of the computer game to develop.
1.4. References
2. Current software architecture
As the Bumpers project is a Greenfield engineering project we have no current software to replace.
3. Proposed software architecture
3.1. Subsystem decomposition
During the subsystem decomposition of Bumpers we divide the system into smaller subsystems with a strong coherence. The different subsystems should have a loose coupling.
The following UML class diagram gives an overview of the identified subsystems and their relations.
Figure 1: Subsystem decomposition of Bumpers (UML class diagram). For better readability, we do not show the attributes and operations of the classes. The object model of the RAD provide the classes in more detail.
- UI. The UI subsystem consists of classes that are responsible for the graphical user interface to the player. This includes the main window of Bumpers, the tool bar that supports the start and stop buttons, a preference dialog in which the player can control the settings of Bumpers and the player information pane.
- Control. The Control subsystem contains classes for the controlling of the game. This includes the Referee class that is the main game controller and the Robot.
- Cars. The Cars subsystem contains all classes that are needed to model the cars of Bumpers. This also includes the playing field.
3.2. Hardware/software mapping
Bumpers is build as a stand alone application and does not communicate to any other computer. So, Bumpers is an independent component that runs on one computer node that supports Java.
The following UML deployment diagram illustrates the hardware/software mapping for Bumpers.
Figure 2: Hardware/software mapping for Bumpers (UML deployment diagram).
3.3. Persistent data management
Bumpers supports no persistent storage.
3.4. Access control and security
As the players are anonym to Bumpers, Bumpers supports no access control or security.
3.5. Global software control
Bumpers is a local stand alone application and has just to react on the interaction of the player. The player interacts with the classes of the UI subsystem. After interacting with these classes, events are created and dispatched to the related objects. The Referee object controls the moving of all cars during the game.
3.6. Boundary conditions
The starting, stopping and installing of the Bumpers application defines the boundary conditions. Here we must take care of the different operating systems Bumpers is build for.
- Installing. For all operating systems, Bumpers need no explicit installation execution. Copying the executable Bumpers application into the local file system does the installation.
- Starting. The starting of Bumpers depends on the operating system. If Windows or Mac OS X is used, the player starts Bumpers by an double click on a ?Bumpers.bat? or a Mac OS X executable application file. For other Unix operating systems, we provide a Unix script for starting Bumpers.
- Stopping. Pressing the ?Exit? menu item or closing the Bumpers window stops the application.
4. Subsystem services
At the moment, we provide no services in terms of operations for the subsystems.