Requirements Document

Scorched Earth 2000

Requirements Document

Kaos Software

10/03/99

SECTION / PAGE
Introduction / 3
Glossary of terms / 3

System model

/ 4
Screen shots / 7
Functional requirements definition / 10
Non-functional requirements definition / 14
System evolution / 15
Credits / 16

INTRODUCTION

Scorched Earth is an artillery based combat game developed by Wendell Hicken in 1990. Nicknamed “the mother of all games” and perhaps one of the first true multiplayer games ever designed it is a classic that has been through a number of version upgrades and modifications by various individuals. Unfortunately all known versions are designed only for single computer play. Our goal is to create the first network ready version of scorched earth.

We intend to rewrite the code from scratch using java. The game will be playable on any web browser with java 1.1 support (e.g. Netscape 4.x, Internet Explorer 4.x etc.) on any platform. Clients will be required to login to a game server to load the game and meet other players.

Given speedy progress of our primary objectives we also plan to incorporate some new features that are not found in the original. Details on all these issues are presented in the following sections.

GLOSSARY OF TERMS

Learning Curve : Time period required by the user to get comfortable with game controls and gameplay.

Minimum Distance : A specific distance that must be maintained when two tanks are being randomly placed on a terrain map.

Race Conditions : Unwanted errors caused when two or more processes are reading or writing some shared data are called race conditions. The final result of such situations depends on the timing of which program runs when.

Round : The game is split into a number of rounds. A round may be thought of as an individual battle, which starts with all players competing and end when only 1 surviving player is left.

Scorcher : Experienced Scorched Earth player

Splash Damage : Damage incurred to objects that are not hit directly by a weapon but are close to its point of explosion.

User Profile List : A list of user ID’s and passwords that is stored on the game server. The user profile list will contain certain player statistics as well.

System Model

The following diagrams describe the system model. As mentioned previously the game will utilize a client-server model. Users or clients will be required to logon to the game server with their browsers.

This diagram gives a close-up view of the functioning of the game server.

This diagram gives a close-up view of the functioning of the client.

Screen shots

FIGURE 1

FIGURE 2

FIGURE 3

FUNCTIONAL REQUIREMENTS DEFINITION

The objective of this section is to elucidate the services to be provided by Scorched Earth 2000. The following requirements have been numbered to facilitate easy reference at future points in the document. As a convention all dialog boxes, menu options and buttons that will be available to the user in the GUI have been highlighted. Words that can be looked up in the glossary of terms are italicized.

On connecting to the game server the user will be required to login to be able to participate in the game. The Login Dialog will facilitate this process.

1.1 Login Dialog (see Figure 1, Page 7)

Users will be presented with this login dialog box featuring the following choices:

1.1.1 Login : Enter using an ID already declared in the user profile list

1.1.2 New Player : Add a new user profile to the list (See 1.2)

1.1.3 Guest : Login as a guest i.e. without a specific ID

1.1.4 Leave : Exit the game

1.2 New User Registration Dialog

Clicking New Player will lead to this dialog. The user will be required to fill out the following information:

1.2.1 Username : Enter a desired Username

1.2.2 Password : Enter a password

1.2.3 Password Confirmation : Check to make sure the password is correct

Master Client

The first user to enter the game is designated the “master client”, referred to hereon as “the MC”.The MC is responsible for selecting certain game options upon logging in. This process takes place with the help of the following 2 dialog boxes:

2.1 Player Setup Dialog

2.1.1 Number of rounds: Number of rounds to be played before the game ends.

2.1.2 Maximum players : Specifies the maximum number of players to be allowed in the current game. Valid values are from 1 to7. (Note:-We may decide to cut done the maximum number of network players if we run into game performance issues.)

2.1.3 AI Opponents : The MC has the option of choosing computer players to enter the game. The following 3 AI players will be provided (in decreasing order of skill):

Killer

Cyborg

Shooter

2.2: Game Options (see Figure 2, Page 8):

2.2.1 Value of g: The MC is responsible for selecting the acceleration due to gravity or g. He can leave it to 9.8 m/s2 to simulate earth like conditions or change it to any value he sees fit.

2.2.2 Tank type: There will be a variety of tanks provided for the player to choose from. While the difference between the tanks will be mostly cosmetic, we may decide to come up with a separate class of mobile and immobile tanks. Figure 2 does not contain all of the different tank types that will be present in the finished product as they have yet to be designed.

2.2.3 Wind: The MC will be able to select between the following 3 wind conditions:

Changing wind

Constant wind

No wind

2.2.4 Initial Cash: How much money each player starts out with.

2.2.5 Nature Hazards : Special terrain conditions such as meteors and lightening.

2.2.6 Start button: Once the MC is satisfied with the number of users that have entered the game, he can commence the game by clicking the start button. After this point no new users can join until the end of the game in progress.

2.3 The initial tank positions within the battlefield are randomly decided. The only constraint provided is to make sure that no two tanks are within a certain minimum distance of each other.

Joining Clients

All clients joining the game server after the MC are referred to as joining clients, referred to hereon as “JC’s”.

3.1 JC’s are given the following options after logging in:

3.1.1 Tank Type: Option to select the desired tank type.

3.1.2 Join button : The JC can use this button to indicate he is ready to join the game. As specified in 2.3, users must have joined before the MC starts the game. Players cannot join once the game has begun.

Game Rules

The following are the basic rules of the game. We may decide to vary or change some of these rules as the game takes shape in order to enhance gameplay and overall enjoyment. See Figure 3, Page 8 for a better idea of a game in progress.

4.1Turn based gameplay: Every player will get a turn to launch a weapon. Upon launching the weapon the next player in line will have his turn. Turns will move in a cyclical order. The initial order of the turns will be randomly determined by the game server. Users will know it is their turn when the Fire button pops up in their GUI.

4.2 Firing Weapons: On his/her turn, the player will choose a weapon from his inventory and specify an angle and power(velocity) for it to be fired with. See bottom right of Figure 3, Page 8.

4.3 Violence Reward: The player will receive money for every enemy tank he destroys. He will be able to view his total earning on his GUI.

4.4 Round End: The round finishes when there is only 1 surviving tank left. The players are then taken to the Shop(see 5).

4.5 The Game finishes at the end of the number of rounds specified by the MC (see 2.1.1). The player who makes the most kills wins.

4.6 A statistics table will be displayed at the end of the game displaying how many kills each player had, what each players accuracy was etc.

Shop

At the end of each round, players are moved to a shop for purchasing weapons and special items. The weapons and items available in the shop will go through a period of tweaking by the QA’s to arrive at the optimum parameter values for maximum game enjoyment. Players will be able to make purchases from the following 2 sections in the shop:

5.1Weapons Section

5.1.1Each weapon will have a certain hit strength.

5.1.2Some weapons may have splash damage.

5.1.3The basic missile that a player starts out with is unlimited while more advanced weapons are available in limited quantities.

5.1.4Other weapons will be added as the game takes shape. Some of the early ideas we have so far are missiles, napalm, laser etc. The exact effect, graphics and hit strength of each weapon will be decided upon after experimentation with various values.

5.2 Items Section:

5.2.1Shields will be available to protect the tank from being destroyed when hit by a weapon. A heavy (expensive) and light (cheap) shield will be available, capable of resisting weapons of larger and smaller hit strength respectively.

5.2.2Parachutes will be on sale to protect a tank from falling too fast in case the hill it is on is destroyed by weapon fire.

5.2.3If we implement tank movement (see 2.2.2 and 3.1.1), fuel will be on sale at the shop to power the tank.

5.2.4A very expensive Guidance System will be available which will be capable of calculating the exact angle and force required for the user to destroy any enemy tank. The Guidance System will only be allowed to be used a limited number of times (probably twice per game).

5.3 All players will have to indicate they are done with new purchases by clicking a Finish button on the bottom of the GUI. The game will restart automatically after two minutes regardless of whether all the Finish buttons have been pressed. This measure has been put in place that other players do not have to wait for a player that for some reason did not push the Finish button.

6. Chat

Given sufficient time we plan to implement a chat mechanism for users to be able to further interact with each other. A user will be able to chat with someone else, most probably by double clicking on the desired players name on the GUI. An option for a broadcast message(to all players) will also be provided.

7. Team Battle Modes

Our current game is a free for all battle. We are also seriously considering adding a Team Battle mode where players can compete as teams rather than as individuals.

8. Sound Effects

We may also decide to add sound effects to further enhance user enjoyment and immersion if we are able to achieve all other requirements in a reasonable amount of time.

NON-FUNCTIONAL REQUIREMENTS DEFINITION

This section describes the non-functional requirements definitions as well as some of the constraints on the system and the development process:

The Learning curve for new players is under 15 minutes. We expect experienced scorchers to feel right at home as soon as they login to the game.

The network gameplay will be stable and accurate. Every client will have synchronized screens displaying the same game action. Race conditions will be avoided.

Each player will have a time limit of 1 minute within which he must fire his missile. Failure to fire within 1 minute will lead to his turn getting skipped. This feature has been incorporated so that other players are not forced to wait for unreasonable periods of time.

Real World Physics : Velocity, wind, and g will be taken into account when calculating weapon trajectories. Calculations will be based on real physical formulae.

The GUI is very user friendly and intuitive (See Figures 1,2,3 Pages 7,8,9).

The browser will not throw up any pop-up screens as they are annoying and distracting to the user. All dialogs, options and games will take place in the same browser window.

SYSTEM EVOLUTION

This section describes how we envision the development process. It lists some of our fundamental assumptions as well as anticipated changes.

There are 2 broad design phases that have been carved out. The first phase will concentrate on the achievement of basic gameplay and stable, accurate network gaming. The requirements that will be concentrated on in this phase are as follows:

All non-functional requirements

Functional requirementseries 1 (login screen)

Functional requirements2.1, 2.2.1, 2.2.6, 2.3(basic master client options)

Functional requirement3.1.2 (basic joining client options)

Functional requirementseries 4 (basic game rules)

On achievement of the said objectives we will look to achieve as many secondary objectives as possible, depending on time constraints. The secondary improvements we anticipate in order of priority are as follows:

Functional requirement series 5(shop: weapons and items)

Remaining functional requirementsin series2(advanced master client options)

Remaining functional requirementsin series3(advancedjoining client options)

Functional requirement 6 (chat module)

Richer graphics and more detailed terrain

Functional requirement 7 (team battle mode)

Functional requirement 8 (sound effects)

CREDITS

This requirements document has been written and designed by

Kapil Mehra

Valuable contributions and suggestions were made by the following people in the preparation of this document:

Hei C. Ng

Alex Rasin

Mikhael Kruk

Nathan Roslavaker

John Langton

Ramya Ramesh

Requirements Document

Requirements Document

Kaos Software

Table of Contents

System model

INTRODUCTION

System Model

5.2.1Shields will be available to protect the tank from being destroyed when hit by a weapon. A heavy (expensive) and light (cheap) shield will be available, capable of resisting weapons of larger and smaller hit strength respectively.

NON-FUNCTIONAL REQUIREMENTS DEFINITION

This section describes the non-functional requirements definitions as well as some of the constraints on the system and the development process:

This section describes how we envision the development process. It lists some of our fundamental assumptions as well as anticipated changes.