Towards a Reference Architecture for 3D First Person Shooter Games

Transcription

1 Towards a Reference Architecture for 3D First Person Shooter Games Philip Liew-pliew@swen.uwaterloo.ca Ali Razavi-arazavi@swen.uwaterloo.ca Atousa Pahlevan-apahlevan@cs.uwaterloo.ca April 6, 2004

2 Abstract First person perspective video games are an important part of the many genres that make up the multi-billion dollar gaming industry. The concept is to immerse the player within the environment by providing a controllable view from the players perspective. This 3-dimensional environment allows for greater realism and interactivity. In this report, we present a reference conceptual architecture derived from the comparison of existing open-source first person perspective video games. It is intended as a starting point for people interested in learning about, or developing games as well as development teams. Keywords Reference Architecture, Conceptual Architecture, Video Game, First Person Shooter Game, Quake, Cube

3 Contents 1 Introduction Background Architecture Extraction and Analysis Process Quake Quake Concrete Architecture Overview Quake Server Subsystem Quake Client Subsystem Cube Cube Top Level Concrete Architecture Cube Server Subsystem Cube Client Subsystem Quake II Top-level Concrete Architecture of Quake II Server Architecture of Quake II Client Architecture of Quake II Proposed Reference Architecture Top Level Architecture Client Subsystem Architecture Server Subsystem Comparison of Reference and Concrete Architectures Conclusion

4 List of Figures 1 Extraction Process of Concrete Architecture Concrete Architecture of Quake Concrete Architecture of the Quake Server Subsystem Concrete Architecture of Quake Client Top lever Architecture of Cube Concrete Architecture of Cube Server Concrete Architecture of Cube Client Top-Level Architecture of Quake II Concrete Architecture of Quake II Server Concrete Architecture of Quake II Client General components for video games Client Server Architecture Client Subsystem of the Reference Architecture Server Subsystem of the Reference Architecture Game Engine Internals

5 1 Introduction Current thinking for the video game industry is that it is five or so years behind the rest of the industry [1]. Where it is common practice to move directly from the design phase to the programming phase. Video game programmers suffer the mind-set of not built here syndrome, where anything not developed in-house is not used. And this tends to lead to reinvention of the wheel, increased development time, and poor quality software. As well, due to market pressures, documentation, and technical design documents become an after thought. This phenomenon can be seen by the lack of any technical papers on entertainment-oriented software. This mind-set against reuse is slowly being changed as consumers expectation for software quality increases, and the time to market decreases. One company that seems to have changed the mind-set of video game developers is id-software. Known for its state of the art first perspective shooter games, it has created an aftermarket for other development companies to build their games on top of id s gaming engine. With the increased attitudes towards using other game engines, it can be seen that most on the market share a defined set of functionalities, and most likely share design patterns. The goal of this paper is to derive a reference architecture, specifically for 3-dimensional first person perspective style games. A reference architecture is useful for development of new and existing game engines to maintain consistency between the design phase and implementation phase. The reference architecture is based upon the comparison of the concrete architecture of Quake [2], and Quake II [3] and Cube [4]. The reasoning for basing it on Quake is two-fold: The source code is freely available under the open source GPL license Many popular games are based upon this genre (Half-Life, Alice, etc.) Section two of this paper introduces the background concepts of a first person shooter, game engines, and what features are typically found in a gaming engine. Section three discusses the software architecture extraction process, while sections four, five, and six present the architecture of Quake, Cube, and Quake II respectively. Section seven presents our reference architecture and compares them to the previously discussed architectures, and then gives a brief conclusion of the paper. 3

6 2 Background Games have provided the first market for advanced graphics techniques. The cost of developing ever more realistic simulation has grown so large that game developers can no longer rely on recovering their entire investment from a single game.this has led to the emergence of game engines that were not written for specific game but were general enough to be used for a family of similar games. In fact, the game engine is like an engine of an automobile. You can take it out of the car and build another shell for it. The game engine is a collection of simulation code that does not directly specify the game s behavior or environment. The engine includes modules such as Input/Output, 2D or 3D graphics, physics, collision detection, AI, sound, and database. Different games will have all or some of the mentioned modules. The 3D First Person Shooter(FPS) games use 3D engines to create games that are as realistic as possible. A typical FPS is a shooting game with a first person perspective that can be extremely immersive. Wolfenstein 3D, the first true FPS game, was originally released by id-software for DOS in In Wofenstein 3D the items and enemies are sprites. Sprites are a collection of static images that are moved around,resized, and even animated. For example, an enemy s feet moving would be an animation only a few images in length,the enemy s traveling left and right would be movement of the sprite, and the enemy coming closer would be an enlarging of the sprite. The levels are single-layered; this means that even though the game is a 3D first-person shooter, you can only move in 2 dimensions: left/right and forward/back. In Wolfenstein 3D, you can not jump,crouch, climb stairs,etc. Since Wolfenstein 3D, games have steadily improved. Doom added the ability to walk up stairs thus creating differing heights. Descent and Duke Nukem 3D made the levels even more 3D by allowing rooms to actually be on top of each other; there is also jumping/crouching in Duke Nukem 3D. Quake added high-quality 3D items and enemies by using polygon models rather than sprites. Light-maps, Mirrors and Mesh Interpolation were new technologies introduced in Quake II. Since then, game makers have been constantly improving on graphics and gameplay.the engine of Quake II has been used by other games, like Half Life and Soldier of Fortune. Basically a game is a real-time database with a pretty front end [1]. It mainly consists of an infinite loop that processes all the objects in the game and then draws the next frame of animation with a deterministic frame-rate. In first stage of a typical game loop the game starts up and initializes all its variables and the program s setup data structures, allocates memory and 4

7 loads graphics and sound files. Then the game enters the main menu loop in which the player can select game options and control the overall game experience. After the player starts the game, the program activates the main game loop, highest level loop in the game code where game s logic is reset for the next frame. At this point, the program retrieves the player s input. In response to the player s actions the program executes the internal game logic and moves all the objects, processes all the AI, performs collision detection, and so on. At this stage the current animation frame is ready to be rendered, so the program draws all objects to an invisible part of memory and then renders the off-screen video image representing the next frame to the visible display. The synchronization step is the final stage of the game loop pipeline. 3 Architecture Extraction and Analysis Process The process followed for extracting the architecture of the case studies for this work is heavily based on extraction tool-kit provided by SWAG [6]. This tool-kit consists of a couple of fact extractors, Ldx and Bfx. LDX which is based on GNU ld linker collects static dependencies during the linkage phase and generates the output in TA format. Bfx looks inside compiled objects and extracts library calls and puts them in another TA file. In later stages of architecture extraction, these two files would be processed using several scripts written in QL scripting language, a language designed specifically for analyzing tuples and sets. Clustering of files is the most critical section of architecture extraction and requires a general conceptual knowledge of the software. And finally a graphical view of concrete software architecture would be generated. Figure 1 shows the complete flow of extracting concrete software architecture. 5

8 Compile and Link with LDX Extract Lib. dependencies with BFX Cluster files into subsystems (manually based on conceptual documents and source review) raw TA files Process TA files with Prep, Lower and ALV scripts Contain file (rsf format) Refined TA files Use Addcon script to filter connections and add subsystem s dependencies based on Contain file. Generate graphical view using ASVIEW unshaped Concrete Architecture View Concrete Architecture with LSEDIT Final Concrete Architecture Figure 1: Extraction Process of Concrete Architecture. Although static architecture extraction works quite well for many software systems, it is proved to be inefficient for programs that take advantage of dynamic linked libraries or implicit invocation. Since those libraries object files are not linked with the rest of the program, LDX is not able to collect function calls and variable access to those libraries. The method used in this work for extracting implicit dependencies is very similar to one introduced in [7] except that automatic logging of call stack was not used. We observed the execution path for a predefined scenarios and added observed implicit dependencies to the extracted concrete architecture. 6

9 4 Quake Quake is a first person shooter (FPS) game that was published by id-software in Upon release it was revolutionary due to it s utilization of three dimensional polygons for both scenery and players. A popular feature of Quake is the network multi-player mode which allows fellow players to play against each other over a network. In order to achieve the necessary synchronization between multiple players, the system is based on a client-server architecture. By having clients responsible for sending user input to the server, it is possible to coordinate events between all clients on a single server. Once all information is processed, all visual rendering information is sent back to the clients for display on their monitor. 4.1 Quake Concrete Architecture Overview Figure 2 shows the concrete top-level architecture that was extracted from the source code. Legend: Weakly Dependent Normally Dependent Strongly Dependent Game Common Client Server NETWORK Game Engine Figure 2: Concrete Architecture of Quake 7

10 4.2 Quake Server Subsystem Quake server maintains the games time-base and states, performs object movements and physics, and runs the AI for all computer controlled characters. Analysis of the concrete architecture reveailed the following subsystems: Progs Subsystem - implements the Quake scripting language. This language is used by artists and level designers to describe game entities such as monsters, weapons and etc. for the game engine. World Subsystem - responsible for storing information regards to maps, entities, and levels. Physics Subsystem - governs the physics of the whole world. Rules like speed, friction and gravity inside the virtual environment of the game are all set by this subsystem Command Subsystem - implements script command processing in Quake. It is basically responsible for managing input command buffers, handling combined commands, realizing command name aliasing, and auto completion of commands. Figure 3 illustrates the concrete diagram of Quake Server. 4.3 Quake Client Subsystem Quake utilizes the client subsystem as the main component for user interaction. It is responsible for immersing the player through a plethora of audio and visual stimulation. Figure 4 shows the extracted architecture for Quake Client. Each client polls for user input (e.g. keyboard, and mouse) every frame and sends them to the Server. The Client subsystem consists of following subsystems: Input Subsystem - responsible for gathering keyboard, mouse, and joystick events for each frame. Audio Subsystem - generates music or sound effects. Video Subsystem - responsible for visualizing each frame on the screen with and acceptable frame rate. Model Subsystem - responsible for loading and parsing entities data structures. 8

11 SERVER Main World Physics Command Progs Figure 3: Concrete Architecture of the Quake Server Subsystem Miscellaneous Audio Input System Models Video Renderer Client Subsystem 5 Cube Figure 4: Concrete Architecture of Quake Client Cube is an open source gaming engine that is freely available under the terms of the GNU Public License (GPL). It is a first perspective shooter that is based upon the same concepts as Quake. 9

12 5.1 Cube Top Level Concrete Architecture Figure 5 shows the concrete architecture that was extracted from the source code. Similar to Quake, it is based off client-server architecture, and most communication is done through a Network subsystem. The Common subsystem contains all utility functions that are used by both Client and Server subsystems. The Network subsystem encapsulates the message passing routines to communicate between the client and the server. Legend: Dynamic Interactions Highly Dependent Normally Dependent Weakly Dependent Common Client Server NETWORK Figure 5: Top lever Architecture of Cube 5.2 Cube Server Subsystem An overview of the Cube Server subsystem is shown in Figure 6. The Cube architecture runs off of a fat client, thin server architecture, in that the server is merely used for synchronization purposes during multiplayer gaming. Each subsystem is described below: Server Subsystem - responsible for processing information received and keeping track of individual players Server Messaging Subsystem - responsible for sending out the information 10

13 Server Standalone Server Server Messaging Utilities SERVER SubSystem Figure 6: Concrete Architecture of Cube Server Utilities Subsystem - are commonly used libraries Stand-alone Subsystem - are the components for running pure server 5.3 Cube Client Subsystem Figure 7 shows the internals of Client Subsystem. The Cube architecture places all game specific and non-game specific components together in the Client subsystem. This allows for less modularity, and is most likely due to a design focus on graphics rather than network play. Despite the large client subsystem, it is still possible to isolate game engine components and game specific code components are noted with dashed line boxes within Figure 7. 11

14 Game Code Physics Monster Editing Weapon Game Engine Console Rendered Clien Common Code World Sound Command 6 Quake II Figure 7: Concrete Architecture of Cube Client Quake II is the second game in Quake series developed and published by id-software in 1998[3]. The main technology improvement from Quake was mesh interpolation and surface shading in Graphics subsystem. However in terms of software engineering process, Quake II showed to have a more well-designed architecture than Quake after its source code was revealed in Top-level Concrete Architecture of Quake II Quake II uses Client-Server architecture. Client, Server, Network and Common Utilities are the main subsystems identified at top level of Quake II engine. Game specific code is also part of the server code but can be easily abstracted as a separate subsystem in top-level architecture. Top-level clustering is mostly based on the directory structure that original developers released the code with. Figure 8 shows the concrete diagram of top-level Quake II structure extracted with SWAG extraction tools. 12

15 Legend: Dynamic Interactions Highly Dependent Normally Dependent Weakly Dependent Game Common Client Server NETWORK Game Engine Figure 8: Top-Level Architecture of Quake II Concrete architecture of Quake II is very similar to the conceptual expectation. There is a weak unexpected dependency between client and server which proved to have the same reason as Quake. It is just used for some initialization code to determine if the client and server are running on the same machine. On most of other execution scenarios, Network subsystem is the only way of communication between Client and Server which is compatible with the concept of client-server architecture. 6.2 Server Architecture of Quake II Quake II Server can be divided into engine part and game (in this case Quake II itself) specific part. In contrast to Quake, in Quake II Physics and AI subsystems are considered as Game Specific materials and are put in Game code. This abstraction allows developers to use Quake II game engine to develop games with different AI and Physics rules which makes the game-engine more flexible and reusable. Game specific code also compiles and links into a separate DLL 1 named 1 Dynamic Linked Library 13

16 game.dll. Any interaction between this part of server and engine part is done via the standard interface of this DLL. This resembles employment of Facade design pattern [8] for this subsystem. A global structure of function pointers which are initialized at the beginning of the program to proper functions is the standard way for the Engine and Game part to interact with each other which conceals explicit library calls. Extraction of these calls for the concrete architecture was done using the debugging method described in previous sections. Figure 9 shows concrete architecture of Quake II Server subsystem. AI Physics Monsters Playing Save Game Combat Game Interface to the Game Engine Interface to the Game DLL Operator Commands User Management World Packet Encoder Server Send Game Engine Figure 9: Concrete Architecture of Quake II Server 6.3 Client Architecture of Quake II Concrete architecture of Quake II client is shown in Figure 10. Coupling of Renderer inside the Video subsystem is somehow different from previous case studies. In Quake II Renderer is compiled and linked as a separate DLL and all calls to this subsystem is passed through the standard DLL interface 14

17 as described in previous sections. This allows on the fly substitution of the Renderer module, User can switch from OpenGL rendering system to software rendering system during the game. Audio Menu System Input Misc. Video Renderer Client Subsystem Figure 10: Concrete Architecture of Quake II Client 7 Proposed Reference Architecture Through analysis of the concrete architecture of Quake, Quake II and Cube, it is quite inherent that there are similar common design elements of each game. Despite the common mind-set that each genre of video games requires its own specific design, according to [1] the architecture of a game can be abstracted as shown in Figure 11 The subsystems are each described below: Event Handler - is responsible for managing events that trigger a new state (i.e. player input, game objectives, etc.) Physics Engine - dictates the simulated physics that governs each player within the game Logic Engine - is responsible for the artificial intelligence of every computer character within the game Game Data - corresponds to all domain specific information for the game such as graphics, levels, maps, etc. 15

18 Event Handler Physics Engine Logic Engine Game Data Graphics Level Misc. User Interface Graphics Engine Sound Engine Input Engine Graphics Audio Hardware Legend Dependency Figure 11: General components for video games Input Engine - is responsible for keeping track of user input and sending them to the Event Handler Graphics Engine - renders all information to the screen using capabilities of available computer hardware Audio Engine - is responsible for playing audio through the hardware Analysis of all the components of a video game show that we can organize all subsystems into two domains consisting of game specific content, and nongame specific content. The Event Handler, Physics Engine, Logic Engine, Input Engine, Graphics Engine, and Audio Engine are reusable components that are applicable across all genres of video games. Domain specific subsystems like Audio, Graphics, User Interface and Game Data are unique to each game. It is important to keep in mind the abstraction between game specific components and non-game components to ensure maximum re-usability. 7.1 Top Level Architecture From analysis of the concrete architectures of previous games, we noticed that another architecture was present in all games; this was the Client-Server architecture as shown below in Figure

19 Client Communications Layer Server Figure 12: Client Server Architecture All communications between Client and Server are performed through the Communications Layer. This layer of abstraction is a convenient way to allow extensibility for future protocols. This abstraction is relevant for both networked multi-player games, and non-networked single player games. In the case of Quake, when in single player mode, the communications layer was merely passing a pointer between the client and server. During multi-player mode, all communication was done through a network protocol. This allows for component-oriented design that allows for easy future modifications. 7.2 Client Subsystem Architecture Figure 13 below introduces the client subsystem of the reference architecture Audio Menu System Input System Legend Dependency Video Subsystem Renderer Game Dependent Subsystem Client Subsystem Figure 13: Client Subsystem of the Reference Architecture The client subsystem captures all non-game specific components. These components are usually hardware dependent, so abstraction onto the client is a logical step. Each subsystem is described below. Audio subsystem - responsible for outputting audio through the computer hardware 17

20 Input System - keeps track of all user received input Video subsystem - displays graphics to the users, and abstracts the underlying hardware for rendering purposes Menu System - is specific to each game, and is responsible for the User Interface (UI) accessible by players. By making the client responsible for hardware specific systems, it allows for greater reuse due to the fact that the only game-specific component is the Menu system, which drives the UI for the game. Hardware specific optimizations are always executed in the Client-side to increase performance of the game. 7.3 Server Subsystem Figure 14 below introduces the server subsystem for the reference architecture. Game Data Artificial Intelligence Event Handler Legend Dependency Physics Server Subsystem World Subsystem Game Dependent Subsystem Figure 14: Server Subsystem of the Reference Architecture This subsystem contains all of the game specific components. Each subsystem is described below. Event Handler - responsible for parsing input and determining how to process the event Artificial Intelligence (AI) - determines how characters defined in the game act 18

21 Physics - governs how each player and character interacts within the defined world Game Data - specific information such as characters, weapons, entities, etc. World - defines the world that the player interacts in All components within the server subsystem are game specific. In terms of a Game Engine, typically, the AI, Physics, and World subsystems are included as well as the hardware specific components found in the client like the Input, Audio, and Video subsystems. Games based on a certain engine usually have the same look and feel. Figure 15 shows the components of a game engine. Physics A.I. World Audio Video Input Game Engine Figure 15: Game Engine Internals 7.4 Comparison of Reference and Concrete Architectures In this section we compare the previously discussed software architectures with our presented reference architecture and analyze how they fit comparatively. Quake Upon comparison, it can be seen that the Quake architecture conforms to the client-server model. Some of the notable differences is the inclusion of a Common subsystem which includes all functions and routines used by both the Client, and Server. The inclusion of the Game subsystem is the point of 19

22 modularity that allows Quake to be increasingly customizable and attractive to other software development houses. With most game specific software components in the Game subsystem, the underlying components comprise the Game Engine that is licensed out. The server subsystem corresponds to the reference architecture in that they both share a World, and Physics subsystem. The AI subsystem within Quake is abstracted through the Progs subsystem, which is a parser. The Progs subsystem allows developers to develop their own AI logic through the use of a custom scripting language. This feature improved the extensibility of the system, and created a large development community in which fans provided their own bots with custom AI. The client subsystem was also similar in that it presented all the audio and visual interfaces to the user. Cube Cube is based off of a fat client - thin server concept, in that most of the features found in the reference architecture was implemented within the client side, rather than balanced on both sides. The server subsystem is primarily used for synchronization and discovery of other clients for multiplayer gaming. This design decision was most likely due to the fact that the emphasis for Cube is towards graphics rather than network gameplay. Despite the monolithic client, all game specific code could be isolated into specific subsystems, which compared well with the reference architecture. The design of cube with respect to balancing of components of client and server subsystems shows how the architecture can be modified to focus on specific requirements. Quake II The Quake II architecture adheres to the client-server model, much like Quake I did, but goes one step further by extracting all game specific elements into an external dynamically linked libary. By abstracting these components into an external library, both game developers, and hobbyists are able to add modifications without having to view the underlying code within the game engine. 20

23 8 Conclusion In this report we presented a reference architecture for FPS games, and compared the architecture with the concrete architecture of various popular commercial games such as Quake, Quake II, and Cube. We noted that despite the common opinion that there is no architecture for video games, there were clear and similar exchanges of ideas across all three examples. From this we were able to ascertain a common reference architecture which most multiplayer FPS games are based upon. By analyzing the drift between the reference architecture and the various concrete architectures, we were able to show the various design factors and decisions that must be made when any organization is implementing a game, or gaming engine. 21

24 Bibliography [1] Rollings, Andrew, and Morris, Dave, Game Architecture and Design, 1st ed. New Riders Publishing, Indianapolis, Indiana (2004). [2] id-software Quake web page, [3] id-software Quake II web page, [4] Cube official web site, [5] Garlan D. and Shaw M., An Introduction to Software Architecture. Advances in Software Engineering and Knowledge Engineering. Vol. 1, [6] SoftWare Architecture Group, Department of Computer Science, University of Waterloo, [7] C. Pal., A Technique for Illustrating Dynamic Component Level Interactions Within a Software Architecture. In Proc. of CASCON 98, pp , Toronto, Canada, November [8] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of reusable Object-Oriented Software, Addison Wesley