SOFTWARE

REQUIREMENTS

SPECIFICATION

by car'eless

İrfan DURMAZ

Gürkan SOLMAZ

Erkan ACUN

2009

Table of Contents

1. Purpose of the Document....................................................................................................................3 2. Project Introduction............................................................................................................................ 3 2.1 Project Background.............................................................................................................................................3 2.2 Project Definition................................................................................................................................................4 2.3 Project Goals and Scope......................................................................................................................................4 3. The Process.......................................................................................................................................... 4 3.1 Process Model................................................................................................................................................... 43.2 Team Organization............................................................................................................................................ 6 3.3 Project Constraints............................................................................................................................................ 63.3.1 Project Schedule..............................................................................................................................................63.3.2 User Interactivity/Controls Constraint.............................................................................................................73.3.3 Realistic Game Play.........................................................................................................................................7 3.3.4 Realistic Scenes................................................................................................................................................7 3.3.5 Client Server.....................................................................................................................................................7 4. Research............................................................................................................................................... 8 4.1 Literature Survey and Technical Analysis ...........................................................................................................8 4.1.1 Graphics...........................................................................................................................................................84.1.2 Sound............................................................................................................................................................... 94.1.3 Network......................................................................................................................................................... 104.1.4 Other Tools.................................................................................................................................................... 114.2 Existing System Analysis................................................................................................................................. 114.2.1 Quake Live.................................................................................................................................................... 114.2.2 Unreal.............................................................................................................................................................125. Requirements Specification..............................................................................................................12 5.1 Functional Requirements..................................................................................................................................125.1.1 Menu Requirements.......................................................................................................................................125.2 Non-Functional Requirements......................................................................................................................... 155.2.1 Usability.........................................................................................................................................................155.2.2 Quality............................................................................................................................................................155.2.3 Documentation...............................................................................................................................................155.2.4 Platform Compatibility...................................................................................................................................155.2.5 Reliability and Robustness............................................................................................................................ 165.3 Hardware Requirements................................................................................................................................... 165.4 Software Requirements.................................................................................................................................... 166. System Analysis and Modeling..........................................................................................................176.1 Structured Analysis and Functional Modeling................................................................................................. 176.1.1 Level-0 of Data Flow Diagram..................................................................................................................... 176.1.2 Level-1 of Data Flow Diagram(Client Side)..................................................................................................18 6.1.3 Level-1 of Data Flow Diagram(Server Side)................................................................................................ 206.2 Use Case Diagrams...........................................................................................................................................226.2.1 Start Menu Use Case ................................................................................................ ....................................226.2.1 Pause Menu Use Case................................................................................................................................... 237. Project Scheduling.............................................................................................................................247.1 Project Schedule .............................................................................................................................................. 247.2 Gantt Chart ...................................................................................................................................................... 258. Risk Management..............................................................................................................................268.1 Project Risks ................................................................................................................................................... 269.References...............................................................................................................................................28

1. Purpose of the Document

Starting with introducing the project idea, presenting research on the idea and explaining the game

scenario, the document investigates functionality required in an implementation of the project, t

technical details to implement the project, flow of data and use cases. Estimated tasks and an expected

time-line for executing the tasks conclude the report.

2. Project Introduction

This chapter introduces the reader to the multiplayer online first-person shooter game for Linux

Project. A background to the project topic to put the idea into perspective is followed by project

definition. Then we explain why such an idea appeals us. Chapter is concluded by a discussion of what

is in scope

and what is not.

2.1 Project Background

Networking among computer systems provides many opportunities for computer application. Internet is

the most massive and brilliant example of what networking can bring in. The advent of Internet has

radically changed the human society. Internet has become a component of some of the most basic

things we do. Information priorly restricted to few has been available to all. Communication became

cheap, time-efficient and available in more ways. Very structures of societies have been reshaped,

people are befriending and communicating with other people they have never seen, or could never see

in the old ways. Entertainment is enhanced and became more social in its own way. Internet is a huge

social phenomenon. Nevertheless it is a thing of technology based on networking hardware and

computer power. Its functionality is directly related to features and capacity of the technology.

Pioneering systems of the Internet used text based communication. More bandwidth, improved network

hardware, more CPU/GPU power and practically more of everything in later years meant more

information could be passed on and processed. This, of course, meant yet newer and more appealing

applications could be produced. Applications where hundreds, thousands or millions of users interact

doing various things. Games are no exception to the Internet effect. Multiplayer games have always

been present throughout computing history, but everything became greater in scale and more

diverse in players. Multiplayer FPS games are one of the most popular ones.

2.2 Project Definition

First Person Shooter (FPS) is a video game genre which centers the gameplay around gun- and

projectile weapon-based combat through the first person perspective; i.e., the player experiences the

action through the eyes of a protagonist. Generally speaking, the first-person shooter shares common

traits with other shooter games, which in turn fall under the heading action game. From the genre's

inception, advanced 3D or pseudo-3D graphics elements have challenged hardware development, and

multiplayer gaming has been integral.

Most first-person shooter games have multiplayer mode, where a lot of users play against other human

players. This mode is very popular in the world, because people usually find playing with boats boring.

Although there are some games with good artificial intelligence, multiplayer games are more enjoyable

and realistic, because human brain is still better than artificial intelligence. The increasing multiplayer

game trend caused developing a lot of fps games based on multiplayer feature by different game

companies.

2.3 Project Goals and Scope

The fundamental goal of this project is to build a multiplayer online game that:

is enjoyable.

is ready for commercial release.

has potential for commercial viability.

can support hundreds of players in a single environment. *

supports large maps.

offers 3D graphics.

offers a 3D environment.

has sound effects.

approximates physics in some aspects.

has a low server load.

has a low bandwidth requirement.

uses peer to peer network model as much as possible.

uses dynamic server side load distribution.

is well documented.

The project goals do not include:

cross-platform compatibility.

building a well defined framework.

to implement AI routines from scratch.

The implementation goal is:

* open-source multiplayer fps for Linux

to implement network functionality from ground up using low level tools.

to implement 3D graphics environment using a game engine.

to implement sound effects using a game engine.

client to other client's communication, interaction and positioning.

3. The Process

3.1Process Model

As we will do the project in the content of Ceng491 course, requirements and the design parts

of the project will be improved sequentially and they will be completed by the end of first

term.

Therefore, we cannot use any incremental or evolutionary model. Also, requirements are well defined ‐

and reasonably stable so there will be limited number of new development efforts in the project. We

will try to make a realistic and safe requirements analysis so that we will have a robust design, which

will prevent us from returning back to design phase. Taking all of these into consideration, waterfall

process model is the most appropriate model for our project. However, there will be some

modifications in this model such that coding, testing debugging and integration will be performed‐

in one phase under the name ‘construction’, as seen in Figure 1.

Figure 1 Modified Waterfall Model‐

3.2. Team Organization

We decided our team structure to be independent by strict rules. Our team consists of only 3

students, and hence there is no team leader. Communications within the team are horizontal.

Decisions about projects are taken by all 3 members of the team so that each member contributes to

project equally. Also, in our model, each member is encouraged to contribute to the project and would

come up with innovative ideas.

3.3. Project Constraints

3.3.1. Project Schedule

Group car'eless consists of 3 senior computer engineering students of Middle East Technical

University’s Computer Engineering Department. This project is being produced for senior project

course of the said department. The situation presents some constraints. Developing a 3D simulation

environment with users communicating vocally over a network requires good knowledge of

computer graphics, network and game design. Learning these subjects, developing a game

concept, implementing and documenting the project are time consuming tasks. Within a 7 and a‐ ‐ ‐ ‐

half month time, we aim to come up with a final product with its testing and debugging completed.

3.3.2. User Interactivity/Controls Constraint

Our product is targeted to be used by people having no or very little knowledge of computers.

Therefore, there will be two modes of the simulation; one with limited interactions with the program

and one with very detailed interactions. In the first mode, user will perform his actions only

by microphone. On the second one, however, user will be making all his actions by directly interacting

with the program by keyboard.

3.3.3. Realistic Game Play

Since we are developing a simulation environment, we need our program to be as realistic as possible.

Users should face real emergency situations, and should come up with solutions using their

limited resources as in real life. Simulating this on computer is not an easy task; both

graphically and conceptually. Also to not end up with mis-training and faulty evaluation of user

performances, we have to design the game play very carefully.

3.3.4. Realistic Scenes

Quality of 3D graphics, models, textures, sound and animation will make our simulation look more

realistic, while costing a considerable amount of disk space and intensive processing.

3.3.5 Client-Server

data transfer between client and server will be optimized to fasten the communication.

secure client-server communication and system security.

4. Research

4.1 Literature Survey and Technical Analysis

To find the most suitable tools and environments for our application, we made an all round ‐

research related to different fields of our application.

4.1.1. Graphics

We made a wide research with respect to graphics part, as it is thought to be the most

challenging and time consuming part of the project. We decided to use a graphics rendering engine for

modularity and ease of writing code. The engines chosen to be examined are given in details

in the following subsections.

4.1.1.1 Crystal Space

This is a framework rather than a simple rendering engine. It has modules for 2D and 3D

graphics, sound, collision detection and physics. However, it is not appropriate for our project

in two reasons. Firstly, its documentation and developer support is not very satisfactory. Secondly, an

all in one engine including all kind of features is not appropriate for our project’s needs. We thought it‐ ‐

would restrict us in terms of functionality. Instead, we intend to use different API's/engines specialized

in its own area.

4.1.1.2 Java 3D

As we had not decide about the programming language, we examined both kind of engines

written in C++ and Java. Java3D is one of the few rendering engines written in Java. Java3D

Project, running under Java Community Process, does not seem to be developed very

professionally. Its documentation is poor and the demos do not attract much. We also searched for the

games written in Java3D such as Law and Order 2, Pernica, Roboforge and Flying Guns. From those,

only Law and Order 2 made a considerable profit out of market. As Java3D does not seem to satisfy our

needs, we had to give up on it.

4.1.1.3 Ogre

Within all the graphics engines we have searched, Ogre was the most impressive one. It is a

scene oriented, hardware accelerated 3D engine. Ogre would be useful for us in many respects.‐

Firstly, it has an active community contributing to the project, in case of any problem with the engine

such as a bug, or a confusing way, one can easily get an answer to his questions from its

developers in the forums. Also, Ogre has quite a rich documentation including the Project

Ogre Wiki where one can find code, tutorials, art tutorials and many examples. Also the book

“Pro Ogre 3D Programming by Gregory Junker” is dedicated to teach new users the fundamentals of

using Ogre. Secondly, Ogre’s being scene graph based makes it very appropriate to develop a 3D‐ ‐

application rich in objects. Scene graph data structure makes it easier to arrange the logical

representation of a graphical scene. It helps the programmer to define logical relations between the

objects (entities) which correspond to the nodes in the graph.

Although Ogre is not an all in one solution in terms of game development or simulation, it is ‐ ‐

compatible with many external add ons, tools and libraries. This gives freedom to us to use whatever ‐

input, audio and scripting libraries we want.

4.1.1.4 Ogre4J

Ogre4J is a project that enables the use of Ogre libraries in Java applications. As Java is

considered as the alternative programming language, Ogre4J seemed quite appropriate at first

sight. However, it is a new project and it is strongly possible that it includes bugs which would be very

difficult for us to deal with in the process of implementing the project. As we cannot take

such kind of risk, Ogre4J is not suitable for this project.

4.1.2. Sound

Our criteria for sound libraries are: platform independency, free license, 3D audio, recording and

documentation support. Suitable sound libraries for our project are listed and briefly described

in subsections between 4.1.2.1 and 4.1.2.3.

4.1.2.1 OpenAL

It works on both Windows and Linux and mainly free under LGPL. It supports 3D audio and

suitable for game applications. Functions for recording sound also exist. OpenAL consists of

low level functions. Furthermore, there is a high level utility library called ALUT similar to‐ ‐

OpenGL GLUT. ‐

Documentation of the library is sufficient and active forums exist. It is used by most of the well known ‐

game engines such as Unreal Engine, Torque Engine, Delta3D Engine and Doom3 Engine.

4.1.2.2. FMOD

It is available for both Windows and Linux. It is commercial, but free for non commercial‐

use. FMOD supports 3D sound, and many audio formats such as midi, mp3, ogg vorbis. In

addition, it supports recording, Internet streaming and sound effects. Documentation is sufficient.

Furthermore, FMOD is actively developed, with regular releases of new features. Some famous game

companies like Blizzard, Microsoft, Activision and NVidia are in the customer list of FMOD.

Moreover, it has a sound manipulation tool called FMOD Designer. However, it is only available for

Windows.

4.1.2.3 jVoiceBridge

The voice bridge is software written in the Java Programming Language that handles Voice over IP

(VoIP) audio communication. Also, it mixes tasks such as conference calls, voice chat, speech

detection, and audio for 3D virtual environments. In addition, it can be used as a component of other

applications, i.e. Project Wonderland. It is available for both platforms – Windows and Linux by‐

taking advantage of Java programming language. Negative aspect for this library is poor

documentation support.

4.1.3. Network

4.1.3.1 Raknet

It is suitable for Windows and Linux; free for non commercial use. It is Ogre compatible and ‐ ‐

preferred in a quite number of Ogre projects. It is a networking API that is for reliable UDP and higher

level functionality. It allows any application to communicate with other applications on the

same computer, over a LAN, or over the Internet. It was developed specifically for development

of online games and the addition of multiplayer to single player games. It provides detailed

reference and tutorials.

4.1.3.2. ZoidCom Automated Network System

This library is also platform independent and free for non commercial use. It is a high level, ‐ ‐

UDP based networking library providing features for automatic replication of game objects and ‐

synchronization of their states over a network connection. The project has extensive documentation and

lots of example programs.

4.1.3.3. Project Darkstar

It is a developing project which is supported by Sun Microsystems and its aim is to develop a reliable,

scalable, and fault tolerant system for low latency, high interactivity online content. Its primary target‐ ‐

is Massively Multiplayer Online Game content but it is also used in small group online games. The

project is written in Java Programming language so it is system independent. It is a new project and it

develops actively. For this reason, it may be risky to use. However, it is used in Project Wonderland.

4.1.4. Other Tools

We have examined JavaScript and Python to use in the scripting part of the project. We have not

decided to use which one yet. Crazy Eddie's GUI System is also decided to use for GUI library

which is compatible with Ogre. Also, CeGUILayoutEditor will be used to design GUIs.

For 3D model creation, we will use one or more modeling tools. We have examined 3D Studio Max,

Maya, Blender3D to get an idea about the modeling tools.

For texture and image creation, Adobe Photoshop, CorelDraw can be used.

For Integrated Development Environment, Eclipse and Netbeans will be used.

For text editor we will use Kate, Geany and Vim editor.

4.2 Existing Systems Analysis

This project encapsulates many different disciplines. It is similar to games as it involves features

such as 3D programming, multiplayer playing, and audio communication between users. It is similar to

simulators as it involves an education purpose and simulates a real environment and a realistic scenario.

Therefore, we searched for both multiplayer games and simulators. The games and the simulations

examined are given in following sections.

4.2.1. Quake Live

Quake Live (previously known as Quake Zero) is a FPS video game by id Software designed to run on

x86-based computers running MS Windows, Mac OS X or Linux that is downloaded and launched via

a web browser plugin. Quake Live runs an updated version of the id Tech 3 engine, focusing on

gameplay rather than major graphical upgrades. In addition to usability changes, Quake Live has a new,

more streamlined HUD. The game automatically downloads game content in the background as a part

of the registration process while the player interacts through a browser plug-in that can be embedded

into the website or experienced full-screen. Updates to the game are continually released and

automatically installed as the user logs in. There are some modes named as; Fuel, FFA, Team

Deathmatch, Capture the Flag and Clean the Area. Same modes can be thought for the project.

4.2.2. Unreal

Unreal is a first‐person shooter game which is considered to be technically superior to most of the

games in market. It has multiplayer support with strong network architecture. Due to its technical

capabilities and developer support, we examined it as a model for the project. Unreal is considered to

be the pioneer in many areas in game development. It has strong graphics capabilities and very efficient

network architecture. In the network architecture, generalized client server architecture is used rather

than monolithic server architecture used in other games such as Quake and Ultima Online. Unreal

implements a more efficient way for the network architecture with the help of game state concept. In

this concept, clients’ game engines also deal with the game logic instead of just sending the input to

network and getting the output from network. Also its network architecture has an intelligent side as it

makes predictions about the coordinates of the objects with the help of current coordinates and

trajectories.

5. Requirements Specification

5.1. Functional Requirements

5.1.1. Menu Requirements

5.1.1.1. Main Menu

Main menu will be displayed to the user at the beginning of the game. Details of the menu are listed

below.

Main Menu:

1. Language Selection

2. Select User

2.1. New User

2.2. Enter Username and Password

3. New Game

3.1. Create

3.1.1. Mode Selection

3.1.2. View Online Users

3.1.3. Start Game

3.1.4. Cancel

3.2. Join

3.2.1. Enter IP Address

3.2.2. Character Selection

3.2.3. Send Message (Chat with others)

3.2.4. View Online Users

3.2.5. Start

3.2.6. Cancel

4. Learn to Play

5. Options

5.1. Audio Settings

5.2. Microphone Settings

5.3. Graphics Settings

5.4. Controls Settings

6. Statistics

6.1. View Performance Of User

6.2. View Performance Of Team

7.Exit Game

5.1.1.2. Pause Menu

Pause menu will be displayed to user when the user strokes the pause keystone during the game .

Pause Menu:

1. Resume Game

2. Options

2.1. Audio Settings

2.2. Microphone Settings

2.3. Graphics Settings

2.4. Controls Settings

3. View Resource Details

4. Statistics

4.1. View Performance of User (Current game performance)

4.2. View Performance of Team

5.Exit Game

5.1.1.3 Other Functional Requirements

Here the functional requirements are presented :

• Players can change their profile

• Players can register and create accounts

• A menu with enough functionality providing the user character creation,selection

configuration change, login and logout features exists to carry out these purposes

• Players can choose their character

• Different parts of the terrain have different effects

• Terrain system allows realistic landscapes : Walls, pools, buildings

• Trees and different plant elements exist

• Various items exist

• Players can walk

• Players can run

• Players can attack with weapons

• Players can attack with free hands

• Players can die

• Players can be teleported to other zones

• A simple economical model exists to control the flow of currency in the game

• Players make different types of sound as a result of their actions.

• Players can be looted by other players when killed.

• Players' stats can be affected by the items carried

• Players' stats can be affected by the items equipped

• Players stores a limited number of objects

• Players can form party

• Players can chat with other players

• Players can attack other player

5.2. Non‐Functional Requirements

5.2.1. Usability

Being an education tool, our program will be used by the trainees including both experienced and

inexperienced computer users. Taking this into consideration, we try to design human‐program

interaction as clear as possible. The program is aimed to be easy to learn and satisfying to use. In this

respect, we follow a user‐centered design paradigm keeping the users’ needs in mind all the time.

5.2.2. Quality

Quality of the design and quality of conformance to this design is one of the major requirements of the

project’s development. The phases should be completed in certain time and the resulting software

should be free from the bugs as much as possible. Also it should be user‐fault‐tolerant to provide a

user‐friendly environment.

5.2.3. Documentation

We plan to provide a detailed end‐user documentation and technical documentation. End‐user

documentation will include user manual for installation and playing. Tutorial approach will be followed

in end‐user documentation. End‐user documentation will mainly aim to describe each feature of the

application, and assist the user in realizing these features.

Technical documentation is especially important for developers to be able to understand each

other’s code. Since explaining the code literally is a difficult process, tools that auto‐generate the code

documents may also be used for technical documentation.

5.2.4. Platform Compatibility

Broad compatibility with various systems is critical to have a large market for a product.

However, this is not the reason why we aim this product to be platform‐independent. We want it to be

platform‐independent since we disagree with the monopolism tried to be forced. We want to give

freedom to the user to choose any hardware platform or operating system as much as we can do. So we

will not contribute to monopolist approach currently existing in the market.

5.2.5. Reliability and Robustness

The resulting application is aimed to be both reliable and robust. In other terms, it should

perform and maintain its functions in routine circumstances, as well as unexpected circumstances. As

mentioned above, it may be used by inexperienced users too and it should continue to operate despite

possible abnormalities in user inputs. Also as it’s a training program, it should be consistent and

repeatable. If the user plays it in the same conditions with the same inputs, the program should behave

same as before. Reliability and robustness is one of the main issues for customer satisfaction and

reliance upon the project. Therefore, we aim to give importance to it within all process.

5.3 Hardware Requirements

Minimum System Requirements:

• P4 class or equivalent CPU

• 512 MB Memory

• 3D Graphics Card with 128 MB memory and graphics accelerator

• Modem/Ethernet Card

• Sound Card

• Hard Disk

• Microphone, Speaker, Keyboard, Mouse, Monitor.

5.4 Software Requirements

Linux Operating System

6. System Analysis and Modeling

6.1 Structured Analysis and Functional Modeling

6.1.1. Level 0 of Data Flow Diagram

Level 0 of data flow diagram is shown in Figure 2. The diagram shows the general input and

outputs of the program. The structure shown in diagram is same for both client and server.

Figure 2 ‐ Level 0 Data Flow Diagram

Program takes input commands via keyboard and mouse, and recorded sound via microphone from the

user. At the same time, program sends the audio output to the speaker. In addition, program takes

configuration data, script, audio, video, models and textures from repository (hard disk), and saves the

configuration data, saved game, and statistics back to repository. Program sends the graphic outputs to

graphic card that will be displayed in the monitor of user. Furthermore, program communicates with

other programs running on other users’ machines through the network card.

6.1.2. Level 1 of Data Flow Diagram (Client Side)

The recorded audio data are sent to other users over the network module. Similarly, other users’

recorded audio data are transferred over network module to audio module of the client. Input handler

evaluates the keyboard and mouse inputs and sends the data that will affect all users of the program to

server via network module. The data that affect only the user like menu commands are sent to game

engine by input handler. On the other hand, the game state coming from server is passed over network

module to game engine. Game engine then sends the information about sound data to audio module and

audio module gets the corresponding audio data from repository. Like audio module, graphics module

gets the information about graphics data from game engine and gets the data itself from repository.

Figure 3 ‐ Level 1 Data Flow Diagram (Client Side)

6.1.3. Level 1 of Data Flow Diagram (Server Side)

Level 1 of data flow diagram for server side is given in Figure 3. The diagram is very similar to the one

for client side. However, there are minor differences. Server is the decision centre of the program and

the real game state is stored in the server. Other client machines have approximate game states, so

server continuously sends game state to clients and the clients updates their data accordingly. Also,

server gathers all the requests from users about the game flow, and makes decisions about flow by

using script engine.

Figure 4

6.2. Use Case Diagrams

6.2.1 Start Menu Use Case

6.2.2. Pause Menu Use Case

7. Project Scheduling

7.1 Project Schedule

To schedule our project, we first needed to identify main tasks and subtasks in the

project. Also, determining relationships between subtasks was important to make a

consistent schedule. While assigning start and finish dates for the tasks, we tried to

distribute the workload in time equally so that we would never fall behind the schedule.

Following the schedule, we will manage our time efficiently and in the meantime, finish

all tasks in the specified time interval. Task assignment is done considering team

members' interests and skills. Also equal distribution of workload among team members

was taken into consideration. We grouped our tasks into 8 main groups. Documenting our

project, analyzing development tools and developing game concept are the main tasks we

schedule to complete this semester. Tasks related to game resource production and

implementation are planned to be started and finished next semester. Specifically, these

tasks are divided into groups such as game resource & game art production, graphics &

audio development, network development, game logic development and game

deployment and testing.

7.2 Gantt Chart

8. Risk Management

Risk management is a key issue for completing a project successfully in time. Having a

plan before hand would certainly decrease the impact of a risk. As the subject of the

project is mainly about saving human life, it is risky by nature. The people who are using

this simulation program are always faced with challenging conditions involving risk.

Their each decision may result in many people’s death or survival. Therefore, training of

them also involves risk. Implementing the project successfully is crucial in this sense.

Requirements should be understood very well. The pathways that the user will choose

should not cause him to be trained incorrectly and the application should evaluate the

user correctly. Especially for this project, not achieving those criteria are possible and

hazardous risks. Therefore, we try to do a detailed risk plan and avoid the possible risks

as much as possible.

8.1. Project Risks

8.1.1. Staff Size and Experience

• Member’s lack of training on the used technology and tools: Current experience of team

members on game programming may result in inefficiency and may require extra

training.

• Underestimated minor roles: While working on major tasks, extra details may be

overlooked and they may cause overhead later.

• Members lacking sense of responsibility: Considering the fact that team is small and

tasks are equally divided to team members, members not finishing the given task in a

certain time may cause problems in meeting project deadlines.

8.1.2. Customer Characteristics

• Customer’s being instable about requirements: Changes on the given project scope and

objective or additional requests that are not stated in the project layout, may force team to

reconsider the project plan and redefine project design.

• Customer’s dissatisfaction: End‐users dissatisfaction from the project such as

demanding enhancements may force team to reconsider project scope and may cause

changes in project layout.

8.1.3. Project Parameters

• Wrong estimation of hardware requirements: Since the project has an important

graphics feature that depends on CPU and Graphics Card wrong estimation of hardware

requirements may cause harm to reality of program and may end up with dissatisfaction

of end users.

• Misconception in project subject: Since the project subject is about saving human life,

the project involves risk by nature. Misunderstanding the subject and requirements would

certainly result in unpleasant situations.

8.1.4. Development Process

• Lacking Component Integration : As the project involves many different technologies

and environments, project team may have difficulty in integrating the components and

making the application work

• Lacking Software Quality Assurance: As the software quality assurance encompasses

entire development process, disregarding it in any phase of the project may result in a

unsatisfactory product.

• Lacking Systematic Tests: In the construction phase, project team’s getting stuck

with the coding would cause them to overlook testing and this would inevitably

result in many bugs.

8.1.5. Development Environment

• Used technology’s being defective, halfway or incompetent: In the project, mainly open

source tools and environments are used. If those are not examined carefully at the

beginning, project team could face with many problems such as bugs, halfway

components, etc… and this would definitely slower the project for no reason.

• Use of complicated technology: Especially for game programming, there are lots of

libraries, engines and tools. Although they could be quite useful, learning to use them is

another big task. Getting stuck with those could result in hazardous delays in the project.

9. References

http://unter-hund.com/2009/01/24/top-10-linux-games-fps/

http://en.wikipedia.org/wiki/First-person_shooter

http://www.ogre3d.org/

http://www.unrealtournament.com/

http://www.enemyterritory.com/