Research Group for Applied Software Engineering
Forschungsgruppe für Angewandte Softwaretechnik

 

Bumpers Requirements Analysis Document (RAD)

 

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 Scope of the system

1.3 Objectives and success criteria

The objectives of the Bumpers project are to:

  • provide a simple and fast car game called Bumpers, which works on different operating systems.
  • provide the Bumpers game, which needs no extra administrational knowledge. The player should be able to do all administrative work (e.g. installing).

The project Bumpers is accepted if at least the following success criteria are satisfied:

  • The Bumpers executable is available on September 25, 2003 and satisfies the functional requirements specified in section 3.2.
  • The Bumpers executable runs on Windows, Mac OS X and Linux.
  • The ÒShort loading timeÓ and ÒSmooth car drivingÓ nonfunctional requirements from section 3.3 are satisfied.

 

1.4 Definitions, acronyms, and abbreviations

Bumpers
The name of the computer game to develop.

1.5 References

2 Current system

The Bumpers project is a greenfield engineering project. There is no current system to replace and the tasks of Bumpers are not accomplished by now.

 

3. Proposed System

3.1. Overview

The focus of this project is the development of a game called Bumpers. Bumpers can be played by one person, called player. Bumpers is a window based application. Its main window consists of a playing field, a menu, a control button bar and a player information pane. An arbitrary number of bumpers controlled cars and one player driven car are visible on the playing field. There are two types bumpers controlled cars, which have a different image, representing their chassis. One type is a fast car; the other is a slow car. During the game, all cars are driving on the playing field. The borders of the playing field limit their positions. The player can change the velocity and the direction of the driven car. Bumpers can change the velocity of the other cars. Within the plying field, the direction of the slow car may change. The goal of the player is to crash all other cars. This can be reached by driving the driven car on the top of each other car. This will crunch the car and it will not be able to drive any more. The player wins the game if all other cars are crunched. If a car drives on the top of the driven car, the driven car is crunched and the player lost the game.

 

3.2. Functional Requirements

The game Bumpers supports one type of user: the player. The Bumpers player tasks include downloading, installing, playing and configuring the game. The player tasks and the behavior of the system leads to the following functional requirements:

 

3.2.1. Downloading Bumpers from the web

The player can choose a Bumpers compressed executable file related to its operation system on the Bumpers download web page. By choosing a Bumpers executable, the selected file will be saved on the local file system of the player. The Bumpers download page offers executable Bumpers files for Windows, Mac OS X and Unix based operating systems.

 

3.2.2. Installing the Bumpers

By decompressing the downloaded Bumpers file, the user installs the Bumpers application.

 

3.2.3. Starting the Bumpers application

Based on the type of the operating system, the player can start the Bumpers application in different ways. On Windows and Mac OS X systems, the player has to double click on the Bumpers executable file. On Unix based systems, the player has to open a shell, navigate into the Bumpers directory and call the Bumpers start script file. The Bumpers window opens. A playing field with an arbitrary number of cars, a tool bar with control buttons and player information pane is visible within the window. One car, which is placed in the upper left corner of the playing field, has a different chassis than all other cars. The same chassis is visible in the player information pane with the label Òyour carÓ. This is the driven car of the player. All other cars are distributed over the playing field. Two types of cars with different chassis are visible. These are slow and fast cars. The game is ready to play

 

3.2.4. Stopping the Bumpers application

The player may stop the Bumpers application in two different ways. He can press either window close icon of the Bumpers main window or select the ÒExitÓ menu item of the Bumpers menu.

 

3.2.5. Starting the game

The player starts a Bumpers game, by pressing the start button on the Bumpers control button bar. This can only be done, if the game is not running.

 

3.2.6. Drivability of Bumpers cars

After starting and during a bumpers game, all participating cars are driving on the playing field. The shape of playing field is a rectangle with a border on every side. Each car has a direction and a velocity. Each car moves with its velocity into its direction. If a car reaches a border of the playing field, it changes its direction with the rule: the angle of incidence is the angle of reflection. The initial position of the driven car is the upper left corner of the playing field. Its initial direction is to the right and it has an initial velocity that is not zero.

 

3.2.7. Stopping the game

The player stops the Bumpers game, by pressing the stop button on the Bumpers control button bar. All cars of the playing field stop their driving. This can only be done, if the game is running.

 

3.2.8. Changing the direction of the driven car

During a Bumpers game, the player can change the direction of its driven car, by clicking with the mouse into the playing field. The driven car changes its direction and drives to the clicked position.

 

3.2.9. Changing the velocity of the driven car

During a Bumpers game, the player can change the velocity of its driven car by using the velocity control buttons from the player information pane. Two buttons are offered. One will increase and the other will decrease the velocity of the driven car.

 

3.2.10. Crashing a foreign car

During a game, the player can crash a foreign car by driving its driven car on the top of the foreign car. After the crash, the foreign car stops driving. It rests on its location and takes not part on the game any more.

 

3.2.11. Winning a Bumpers game

The player can win the game, if he crashes all cars with its driven car. An information dialog window will notify the player that he has won.

 

3.2.12. Loosing a Bumpers game

The player of Bumpers can loose the game, if a car drives on the top of the players driven car. An information dialog window will notify the player that he has lost.

 

3.2.13. Setting the number of fast cars

The player can set the number of fast cars that will take part on a Bumpers game. This is done in the preferences dialog window. This window appears after pressing ÒPreferencesÓ menu item of the Bumpers menu. After confirming the change by pressing the ÒOKÓ button, the playing field is repainted and contains the new number of fast cars. This can only be done, if the game is not running.

 

3.2.14. Setting the number of slow cars

The player can set the number of show cars in the same manner as the setting of the number of fast cars.

 

3.2.15. Setting the number of frames per second

The player can set the frames per second for a Bumpers game. The number specifies the number of repaints of the playing field per second. This is done in the preferences dialog window. This window appears after pressing ÒPreferencesÓ menu item of the Bumpers menu. After confirming the change by pressing the ÒOKÓ button, the changed value is set to the game. This can only be done, if the game is not running.

 

3.2.16. Setting the image for the fast car chassis

The player can set the image that is used for painting a fast car. This is done in the preferences dialog window. This window appears after pressing ÒPreferencesÓ menu item of the Bumpers menu. It contains actual image of the fats cars and offers a button to select a new image. If the player presses the select button, an open dialog appears that offers access to the file system of the playerÕs computer. The player can select an image and confirm the selection. Than, the selected image appears in the preferences dialog. After confirming the change by pressing the ÒOKÓ button, the playing field is repainted and the fast cars are represented with the selected image. This can only be done, if the game is not running.

 

3.2.17. Setting the image for the slow car chassis

The player can select the image of the slow cars in the same manner as for the fast cars.

 

3.2.18. Setting the image for the driven car chassis

The player can select the image for its driven car in the same manner as for the fast cars.

 

3.3. Nonfunctional Requirements

3.3.1. Usability

  • Simple to play. The game rules of Bumpers must be intuitive. A player should learn how to play Bumpers, during playing Bumpers.
  • Smooth car driving. Bumpers should support a smooth car driving. Otherwise the players would not like the game.
  • Driven car awareness. To support the player as much as possible during the Bumpers game, all relevant information of the driven car must be visible to the player. This includes at least the velocity and the position of the car.

 

3.3.2. Reliability

  • Crash safe. The Bumpers application should be crash safe in 90% of its runtime.

3.3.3. Performance

  • Short response time. The loading time of the Bumpers application must be smaller than 10 seconds. All other response times must be below 2 seconds.

 

3.3.4. Supportability

  • Car velocity. As the velocity of a car may change during a game, it must be in the range of a minimum and a maximum velocity.
  • Different car types. The Game Bumpers must support two different kinds of bumpers-controlled cars. One kind must be a fast car that does not change its direction until it reaches the bounds of the playing field. The other is a slow car, which may change its direction during driving on the field. Both kinds of cars should be able to change their velocity. They have a different minimum and maximum velocity range.
  • Market customization. As Bumpers will be built for the markets in North America and Europe, it must be customized for the differences of these two markets. This includes different velocity units for the markets. Europe has kilometer per hour and America has miles per hour.

 

3.3.5. Implementation

  • Programming language. Bumpers must be implemented in Java.

 

3.3.6. Interface

  • Simple user interface. The user interface of Bumpers should be understandable to the player on the first view. The user interface is based on a main window, which includes a playing field, a button bar and a player information pane. The cars of Bumpers are driving in the playing field. The button bar offers control buttons for starting and stopping a game. The player information pane offers status information and control opportunities about the driven car of the player.

 

3.3.7. Packaging

The executable Bumpers game must be available over the web within one download. All needed files must be compressed in standard compressing file type. This is WinZip for Windows, disk image for Mac OS X and a tarball file for Unix based operating systems.

 

3.3.8. Legal

  • Cheap Game. The development of Bumpers must be done with a budget <= 1000Þ. As the game should reach as many players as possible and it should be financed over advertisement, it cannot be expensive.

 

3.4. System models

3.4.1. Scenarios

3.4.1.1. Installing Bumpers

Alice wants to play the game Bumpers, but it is not installed on her computer. She opens the Bumpers home page and navigates to the Bumpers download page. The page offers Bumpers versions for Windows, Mac OS X and Unix. As Alice works on the new Apple Power Book, she selects the Mac OS X version and the download of Bumpers starts. After the download completed, Alice unpack the compressed Bumpers file and copies the unpacked file into her application directory. The Bumpers application is installed a ready to be started.

 

3.4.1.2. Starting Bumpers

Alice starts the Bumpers application by double clicking on the installed Bumpers file. The Bumpers window opens. A playing field with an arbitrary number of cars, a tool bar with control buttons and player information pane is visible within the window. One car, which is placed in the upper left corner of the playing field, has a different chassis than all other cars. The same chassis is visible in the player information pane with the label Òyour carÓ. This is the playing car of Alice. All other cars are distributed over the playing field. Two types of cars with different chassis are visible. These are slow and fast cars. The game is ready to play.

 

3.4.1.3. Playing a Bumpers game

After starting the Bumpers application, Alice presses the ÒstartÓ button on the tool bar. All cars start to drive in different directions with different velocities. The playing car of Alice, located at the upper left corner drives to right. The velocity, velocity control buttons and the position of the driven car are visible in the player information pane. Alice clicks with the mouse into the playing field and her driven car changes its direction to the clicked position. The driven car reaches a border of the playing field and changes its direction. The angle of incidence is the angle of reflection. All other cars that reach a border change their direction in the same manner. By using the velocity control buttons, Alice changes the velocity of her driven car. All player information located in the player information pane is updated on every change of the driven car.

 

3.4.1.4. Winning a Bumpers game

During the playing of a Bumpers game, Alice drives her car on the top of a foreign car. A crash occurs and the foreign car gets crunched. It does not drive any more. Alice repeats this with all other cars. After crunching the last car, the moving of her driven car stops and a dialog window with the text ÒCongratulation, you win!Ó appears. Alice wins the game. She closes the window by pressing the ÒOKÓ button. The playing field is repainted. The driven car of Alice is reallocated in the upper left corner and all other cars are distributed over the playing field.

 

3.4.1.5. Loosing a Bumpers game

During the playing of a Bumpers game, a car drives on the top of AliceÕs driven car. A crash occurs and the driving of all cars stop. A ÒYou lost!Ó dialog window appears. Alice lost the game. She closes the window by pressing the ÒOKÓ button. The playing field is repainted. The driven car of Alice is reallocated in the upper left corner and all other cars are distributed over the playing field.

 

3.4.1.6. Configuring Bumpers

Alice presses the menu item ÒPreferencesÓ from the Bumpers menu. A window with the bumpers settings appears. It contains a number of fast cars, a number of slow cars, a number frame per second and three images with the labels Òslow carÓ, Òfast carÓ and Òdriven carÓ. A ÒselectÓ button is located next to each image. Alice changes the number of slow and fast cars. By pressing a ÒselectÓ button, an open dialog appears and Alice selects an image from her file system that she wants to use as chassis for the cars. After changing the settings, she presses the ÒOKÓ button and the preferences window disappears. The playing field of Bumpers is repainted and consists of the number of cars, Alice set in the preferences window. They appear with the selected images as chassis.

 

3.4.2. Use case model

The following diagram gives an overview of the identified use cases.


altFigure 1: Overview of Bumpers use cases (UML use case diagram).


 

3.4.2.1 Actors

We identify the following actors:

Player
As already introduced, the Player represents the player of the game Bumpers. He is able to play games and to control its driven car.

To define the controlling of all other cars than the PlayerÕs driven car and to offer an instance that controls the car driving and watches for car crashes, we identify two system actors.

Robot
The Robot is the enemy of the Player. He controls all other cars than the driven car of the Player. If the Player wins, the Robot lost.

 

Referee
The Referee is the watcher of the Bumpers game. He is responsible for moving the cars over the playing field, detecting crashes and declare the winner of the game.

 

3.4.2.2 PlayGame

Use case Name PlayGame
Initiating actor Player
Preconditions The Bumpers application started and no game is played.
Flow of events Actor Steps System Steps
  1. The Player presses the 'start' button of the Bumpers button bar  
    2. The system starts a new Bumpers game.
3. To move and control the cars, the acting of the Robot and Referee starts.
  4. By using the use case ControlCar, the Player can change the direction and velocity of its driven car.
5.1 If the Player presses the ÒstopÓ button from the button bar.
 
    5.1.1 The system stops the game and requests a stop game confirmation by using a confirmation dialog window.
  5.2.1 If the Player acknowledge the stopping,  
    5.2.1.1 the system closes the dialog and sets the playing field to the initial state.
  5.2.2 If the Player cancel the stopping  
    5.2.2.1 the system closes the dialog and the game moves on.

 

 

3.4.2.3 ControlCar

Use case Name ControlCar
Initiating actor Player, Robot
Preconditions The Bumpers application started and a game is played.
Flow of events Actor Steps System Steps
  1.1 If the Player presses the velocity up or down button from the Player information pane,  
    1.1.1 By incrementing or decrementing the actual car velocity, the system computes a new velocity of the driven car.
1.1.2 If the new velocity is in the minimum and maximum car velocity range, it is set to the car.
  1.2 If the Robot increments or decrements the velocity of a car,  
    1.2.1 If the new velocity is in the minimum and maximum car velocity range, it is set to the car.
  1.3 If the Player clicks with the mouse into the playing field,  
    1.3.1 the system computes the direction from the current position of the driven car and the mouse click.
1.3.2 the system sets the computed direction to the driven car of the Player.
  1.4 If the Robot changes the direction of a slow car,  
    1.4.1 the system validates the direction and set only valid directions to the car.

 

3.4.2.4 MoveCar

Use case Name MoveCar
Initiating actor Referee
Preconditions The Bumpers game started and the PlayGame use case is executing.
Flow of events Actor Steps System Steps
  1. Based on the direction and velocity, the Referee computes a new position for all cars that are not crunched.  
    2. The system validates if the new position is within the playing field.
3. If the position of a car reaches a bound of the playing field, a new direction with the rule: the angle of incidence is the angle of reflection is set to the car.
  4. If the Referee checks the crunched state of the cars by using the use case CheckForCrashes.
4.4.1 If the driven car is crunched, the Referee declare the Player as looser and stops the game.
4.4.2 If the driven car is not crunched and all other cars are crunched, the Referee declare the Player as winner and stops the game.
 
    4.4.3 The system informs the Player with a dialog window if he wined or lost the game.
4.4.4 The system sets the playing field to its initial state.
Quality requirements The Referee moves the cars during a whole Bumpers game. He does this in a frequently time period that is defined through a Bumpers frames per second property.

 

 

3.4.2.5 CheckForCrashes

Use case Name CheckForCrashes
Initiating actor Referee
Preconditions The Bumpers game started and the MoveCars use case is executing.
Flow of events Actor Steps System Steps
  1. The Referee asks for all car positions and all car sizes.  
    2. The system returns all car positions and car sizes.
  3. If the Referee detects an intersection based on the position and size of the driven car and another car, he declares a crash.  
    3.1 If the driven car position is below the other car, the system sets the driven car to crunch.
3.2 If the driven car position is above the other car, the system sets the driven car to crunch.

 

 

3.4.2.6 ConfigureBumpers

Use case Name ConfigureBumpers
Initiating actor Player
Preconditions The Bumpers applications started and no game is played.
Flow of events Actor Steps System Steps
  1. The Player presses the ÒPreferencesÓ menu item from the Bumpers menu.  
    2. Bumpers displays the preferences dialog window. It contains a number of fast cars, a number of slow cars, a number frame per second and three images with the labels Òslow carÓ, Òfast carÓ and Òdriven carÓ. A ÒselectÓ button is located next to each image. Two buttons with ÒOKÓ and ÒCancelÓ are displayed at the bottom of the dialog.
  3.1.1. If the Player presses the ÒCancelÓ button,  
    3.1.2. the preferences dialog window disappears and no changes are done in the Bumpers configuration.
  3.2.1. If the Player enters a new value in the Ònumber of fast carsÓ, Ònumber of slow carsÓ or Òframes per secondÓ text field,  
    3.2.2 the system validates the entered value. If the value was entered in the Ònumber of fast carsÓ or Ònumber of slow carsÓ text fields, the value is validated for being a number and being greater or equals than zero. If the value was entered in the Òframes per seconds text field, the value is validated for being a number and having a value between one and twenty. If the new value is correct, it is displayed. Otherwise the old value is displayed again.
  3.3.1 If the Player presses a ÒselectÓ button next to one of the car chassis images,  
    3.3.2. the system displays a default Òopen fileÓ dialog.
  3.3.3.1.1 If the Player selects an image from the file system and presses the ÒokÓ button,  
    3.3.3.1.2 the system closes the Òopen fileÓ dialog and the selected image is displayed as chassis for the selected car.
  3.3.3.2.1 If the Player presses the ÒCancelÓ button from the Òopen fileÓ dialog,  
    3.3.3.2.2 the system closes the Òopen fileÓ dialog.
  3.3.4.1. If the Player presses the ÒOKÓ button from the preferences dialog,  
    3.3.4.2. the system closes the Bumpers preferences dialog and all changes are set to the system.
3.3.4.3. The playing field is repainted and set to its initial state.
Exit conditions All cars including the driven car are painted on the playing field and Bumpers is ready for a new game.

 

3.4.3. Object model

In this section we describe the Bumpers object model. First we focus related classes and give UML class diagrams to illustrate their relations. At the end we provide an UML class diagram containing all introduced classes.


altFigure 2: Overview of Bumpers car classes and the playing field (UML class diagram).


 

3.4.3.1. PlayingField

The PlayingField represents the playing field of Bumpers. It is a two dimensional rectangle. Its size is defined by the two attributes width and height. The lowest left point of the field has the coordinate 0,0. The highest right point of the field has the coordinate width, height. Through this, the bounds of the field are defined. The numFastCars attribute defines the number of fast cars the PlayingField contains. The numSlowCars attribute defines the number of slow cars the PlayingField contains. The player can change these attributes. They must be greater or equals than zero. The slow and fast cars are realized with the RobotCar class. So, the playing field contains many RobotCars that can be access through the getRobotCars method. Beside the slow and fast cars, the PlayingField has always a DrivenCar that is controlled by the player. The paint method of the PlayingField paints itself and all containing cars at their position. The initiate method sets the playing field in its initial state. First it removes all cars from the playing field. Than it puts the driven car with the configurable image as chassis in the upper left corner of the playing field. The driving direction of the driven car is set to the right direction. The velocity of the driven car is set to an initial value. A set of robot cars, defined through the number of fast and slow cars, are set at random positions within the playing field. Their Boolean value is set to indicate if they are fast or slow. The velocity of all cars, except the driven car, is set to a random value within their minimum and maximum limited velocity range. The direction of all cars, except the driven car, is set to a random value. The method getDrivenCar returns the driven car.

 

3.4.3.2. Car

Instances of the Car class represent cars that take part on the game Bumpers. They drive on the playing field with its velocity into their direction. The velocity must be in the range of the minVelocity and maxVelocity attributes. The attribute isCrunched indicates if the car is crunched or not. If it is crunched, it cannot drive any more. The chassis attribute defines the image that is used for painting the car. The size of a car is defined by the width and height attributes. The position_x and position_y attributes define the actual position on the playing flied. They define the lowest left point of the car and must be greater or equals than zero. To be sure that the car is painted within the playing field, the width and height of the playing field must be grater than the position_x + width and the position_y+height of the car. The paint method paints the car with its chassis. The computePosition method computes the new position of a car based on its direction and velocity. If the new position reaches a bound of the playing field, the direction of the car is changed with the rule: the angle of incidence is the angle of reflection. The velocity can be changed by the incrementVelocity and decrementVelocity methods and access with the getVelocity method. The direction can be accessed with the getDirection method. It can be set with the setDirection method.

 

3.4.3.3. RobotCar

The RobotCar class extends the class car. It represents the cars on the playing field, controlled by the Robot. An instance of the RobotCar class is either a fast or a slow car. This is defined by the attribute isFastCar. Bases on the attribute, two different minimum and maximum velocity ranges are used. Furthermore, the Robot does not change the direction, if the is a fast car.

 

3.4.3.4. Robot

The Robot controls the robot cars during a game. He may change the velocity of the robot cars. If a robot car is a slow car, he may also change the direction. The robot can be started and stopped and robot cars can be added to him. The methods start, stop and addCar are used for that.

 

 

3.4.3.5. DrivenCar

The DrivenCar is the car that is controlled by the player of the game Bumpers. It extends the class car. To interact with the player of Bumpers, an observer pattern is used. The DrivenCar has the role of the subject. Cockpit components can subscribe and unsubscribe to the driven car. They are notified if the state of the driven car changes.

 

3.4.3.6. MouseSteering

The MouseSteering class enables the player of Bumpers to change the direction of the driven car. It listens to the mouse and reacts if the mouse is pressed within the playing field. In the case of a mouse click, the setCarDirection is called. It computes the new direction of the driven car, based on the actual position of the car and the position of the mouse click. The new position is set to the driven car.

 

3.4.3.7. CockpitComponent:

CockpitComponents are used to control and display the state of the driven car to the player of Bumpers. They can be subscribed and unsubscribed to the driven car. They are visible in the graphical user interface of Bumpers. Therefore, the cockpit component has a paint method. The driven car calls the update method, if its state changes.

Next, we have a view of the identified cockpit components that are responsible for visualizing the state of the driven car. The following class diagram gives an overview of the components.


altFigure 3: Overview of the driven car cockpit components (UML class diagram).


 

3.4.3.8. RoundsPerSecond

Displays the velocity of the driven car in rounds per second to the player.

 

3.4.3.9. Accelerator

The Accelerator provides two buttons for increasing and to decreasing the velocity of the driven car. Based on the actual velocity of the car, the buttons are enabled or disabled.

 

3.4.3.10. SpeedometerEurope

Displays the velocity of the driven car in kilometer per hour to the player.

 

3.4.3.11. SpeedometerAmerica

Displays the velocity of the driven car in miles per hour to the player.

 

3.4.3.12. GPS

The GPS component displays the current position of the driven car to the player.

 

3.4.3.13. ChassisView

The ChassisView displays the chassis image of the driven car to the player.

In the following we focus on the graphical components and the referee of Bumpers.


altFigure 4: Overview of Bumpers graphical user interface classes (UML class diagram).


 

3.4.3.14. Referee

The class Referee controls the game Bumpers. It is responsible for starting and stopping the game with the method startGame, stopGame. During a game, it moves the cars of the playing field within the moveCars method in a periodic time interval, defined with the attribute framesPerSecond. The moving computes and sets the new positions of all cars. The playing field and the cars are repainted afterwards. Than, the Referee uses the checkForCrashes method to detect crashes between the driven car and any robot car. When needed, he declares after a crash the player as winner or looser and stops the game.

 

 

3.4.3.15. BumpersWindow

The BumpersWindow represents the main graphical window of Bumpers. All other graphical components are placed within the window.

 

3.4.3.16. ToolBar

The ToolBar is a graphical component that supports the required buttons for starting and stopping the Bumpers game. It is part of the main window.

 

3.4.3.17. PreferenceDialog

The preferences of Bumpers can be set by an instance of the PreferenceDialog class. The dialog is reachable from the Bumpers main window menu.

 

3.4.3.18. PlayerInformationPane

The PlayerInformationPane is a graphical container in that all cockpit components of the driven car are placed. The information pane builds the graphical visualization of the driven car state to the player.

The following diagram gives an overview of all introduced classes and their relations.


altFigure 5: Overview of Bumpers object model (UML class diagram).


 

3.4.4. Dynamic model

The following figure gives an overview of the main states of Bumpers.


altFigure 6: Overview of Bumpers main states (UML state diagram).


After starting Bumpers, the application is in the Ônot playingÕ state. In this state the player can set the preferences of the game by pressing the ÒPreferenceÓ menu item of Bumpers. This will open a new window, in which all Bumpers settings can be done. After closing the preference window, Bumpers is again in the Ònot playingÓ state. By pressing the start button of Bumpers tool bar, the game begins and Bumpers is in the playing state. This state is exited, if the player presses the stop button of the tool bar, the driven car of the player gets crunched or all robot cars get crunched. The whole Bumpers application can be terminated from either the Ònot playingÓ state or the ÒplayingÓ state. Closing the Bumpers window or invoking the ÒexitÓ menu item of Bumpers menu does this.

In the next state diagram, we focus on the driving of the cars during the game. Here we look at the ÒplayingÓ state in more detail. The state transition is controlled by the referee.


altFigure 6: Overview of Bumpers states during a game (UML state diagram).


A Bumpers game runs through a loop of states. The loop starts with the computation of the new positions of all cars on the playing field. The playing field and all cars are repainted in at their new positions. Than, it is checked, if a crash between the driven car and any other robot car occurred. If the driven car is crunched or all robot cars are crunched, the game stops and the player wined or lost the game. The Bumpers game defines the frames per second, which specify the frequently interval of moving and repainting the cars. The referee waits until this time expires and tests, if the player has stopped the game manually, by pressing the stop button. If so, the loop will be exited and the game stops. Otherwise, the loop starts again.