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...... 4 3.2 Team Organization...... 6 3.3 Project Constraints...... 6 3.3.1 Project Schedule...... 6 3.3.2 User Interactivity/Controls Constraint...... 7 3.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...... 8 4.1.2 Sound...... 9 4.1.3 Network...... 10 4.1.4 Other Tools...... 11 4.2 Existing System Analysis...... 11 4.2.1 Quake Live...... 11 4.2.2 Unreal...... 12 5. Requirements Specification...... 12 5.1 Functional Requirements...... 12 5.1.1 Menu Requirements...... 12 5.2 Non-Functional Requirements...... 15 5.2.1 Usability...... 15 5.2.2 Quality...... 15 5.2.3 Documentation...... 15 5.2.4 Platform Compatibility...... 15 5.2.5 Reliability and Robustness...... 16 5.3 Hardware Requirements...... 16 5.4 Software Requirements...... 16 6. System Analysis and Modeling...... 17 6.1 Structured Analysis and Functional Modeling...... 17 6.1.1 Level-0 of Data Flow Diagram...... 17 6.1.2 Level-1 of Data Flow Diagram(Client Side)...... 18 6.1.3 Level-1 of Data Flow Diagram(Server Side)...... 20 6.2 Use Case Diagrams...... 22 6.2.1 Start Menu Use Case ...... 22 6.2.1 Pause Menu Use Case...... 23 7. Project Scheduling...... 24 7.1 Project Schedule ...... 24 7.2 Gantt Chart ...... 25 8. Risk Management...... 26 8.1 Project Risks ...... 26 9.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 3D As we had not decide about the programming language, we examined both kind of engines written in ++ 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 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. It is a developing project which is supported by 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/