Design Decisions in Game Middleware Development ...

Design Decisions in Game Middleware Development: Experiences from Lucid Platform Milo K. Yip

Elvis S. Liu

Man K. Cheung

Ricky M. Lung

Gino Yu

Multimedia Innovation Centre School of Design The Hong Kong Polytechnic University {mcmilo, mcelvis, mcmanc, mt.lung, mcgino}@polyu.edu.hk http://www.lucidplatform.com

ABSTRACT

2.

Developing game middleware is a challenging task, which involves the understanding of game production process, expertise in various research areas, and software engineering. During the game middleware design process, a lot of decisions have to be made. These decisions affect the applications, functionalities and performance of the middleware. This paper illustrates some of these design decisions, with our experience during development of Lucid Platform 1.0. Some design decisions can also be used collectively as evaluation metric for game middleware.

Here we firstly summarize some literature related to game middleware design. Simpson[2] introduced various technical aspects of game engine. Eberly described the design and implementation issues of Wild Magic engine in [3] and [4], focusing on mathematical aspects. Watt and Policarpo [5][6] presented many real-time graphics rendering techniques for games, and used their open-source Fly3D as example.

1.

INTRODUCTION

The scale of commercial game development has been grown dramatically throughout the past 30 years. For example, Bioware’s Never Winter Nights [1] released on 2002, has been developed by 75 full-time employees at peak, approximately 160 man-year, for 5 years. The scale of software development for game is still growing, due to increasing complexity of gameplay and rapidly advancing hardware. To reduce the developmenttime and cost, game middleware is developed to support game development. Game engines, game development platforms or game related software libraries are examples of game middleware. Game middleware provides the common functionalities of specific functions of a game application, such as 3D graphics, physics simulation, artificial intelligence, networking, etc. Therefore, each game developer needs not to reinvent the wheels, and be able to put more effort in gameplay development. However, the development of game middleware is also a huge task, which involves wide areas of research. In this paper, we tried to summarize some design decisions which may encountered during the design phrase of game middleware, according to our experiences in designing Lucid Platform. These design decisions are also useful as metric for evaluating game middleware on the market. This paper will be organized as follows. Section 2 will describe the background and related work about game middleware. Section 3 will state some general considerations in game middleware development. Section 4-7 will discuss design decisions in specific areas. Conclusion and future works will be given in section 8.

BACKGROUND AND RELATED WORKS

To discuss development of game middleware, we will firstly discuss a taxonomy of game middleware. And then we will give a brief background about Lucid Platform 1.0.

2.1

A Taxonomy of Game Middleware

Game middleware can be categorized by their major function. We have tried to categorize them into the following 8 categories. Here, we will briefly describe each category, their common features and some examples of the category.

2.1.1

Graphics

Real-time graphics rendering middleware, or graphics engine, is often the most familiar middleware towards players, as it determines the visual quality of a game. Graphics engine is responsible for real-time rendering of 3D scenes, which involves features like lighting and shading, scene management (indoor and outdoor), camera control, animation, special effects, and workflow tools. Commercial examples include Renderware Graphics[7], Gamebryo[8]. In research, graphics engine relates to computer graphics, computer animation and virtual reality areas.

2.1.2

Audio

Audio engine provides real-time audio playback and special effects support to games. Audio engine often include channel mixing, 3D positioned sound playback, environmental effects (e.g. Creative EAX[9]). FMOD[10] is a popular cross-platform audio engine in the market.

2.1.3

Physics

Nowadays games only applied a few fields in Physics. The most common one is real-time computational mechanics simulation. Physics engines normally provide two basic aspects in physics simulation, collision detection and Dynamics simulation. These features can create realistic interactive movement of rigid bodies, and enabling setup of physical constraints between bodies, such as hinge joints. Some

Figure 1: Screenshots of Virtual Three Kingdoms - a demo game using Lucid Platform 1.0

Figure 2: Auroral Snare - an award-winning Xbox MOG developed based on Lucid Platform 1.0 engines provide specialized mechanical simulation, such as land vehicle and flight simulation. Some newer engines also support soft-body simulation, such as cloth and volumetric soft-body. Popular Physics engines include Havok[11], PhysX[12], Open Dynamics Engine (open source)[13].

2.1.4

Artificial Intelligence

Artificial Intelligence (AI) in games is mainly used to simulate the behavior of Non-playable Characters (NPCs). Although the requirements of AI varies among different game genres, there are some AI middleware that help the development, for example, Renderware AI[14]. The main features of these middleware include path finding/planning, decision making, behavior modeling, knowledge modeling, etc. Developers need to provide information about the world that the agents can perceive, including the environment and information of the game objects.

2.1.5

Multiplayer

There are two basic types of multiplayer middleware. One type is network communication middleware, such as RakNet [15], HawkNL[16]. These middleware provides low-level communication features, including TCP/UDP transport, session management, voice communication, etc. The other type is complete multiplayer solution, for example, Net-Z[17], Emergent[18]. These middleware do not only handle network communication but also synchronization of game objects, authentication, account management, etc. Some middleware are not particularly designed for games but have been applied to multiplayer games, for example, Adaptive Communication Environment(ACE)[19], Internet Communications Engine(ICE)[20].

2.1.6

Synthesis

Synthesis middleware is used to create content procedurally by computer. Different types of contents can be procedurally generated. One common area is tree model generation, for example, SpeedTreeRT[21], RealNAT[22]. Another recent area is motion synthesis middleware, such as KungFu Motion Synthesis[23], Endorphin[24]. MIC is also researching on an automatic music arrangement project. Using synthesis middleware, the content of a game can be more interactive and richer.

2.1.7

All-in-one

Finally, there are some all-in-one middleware, commonly called “game engine”, which integrates most of the functionalities of above categories. Some famous commercial game engines with their representative games are Unreal Technology (Unreal Tournament 2003)[25], Source Engine (Half-life 2)[26], JupiterEX (F.E.A.R.)[27]. These middleware provide a complete solution to game development. The developers are mainly responsible for plugging game content into the game engines. However, most of these game engines only support limited number of concurrent players. Some middleware are particularly designed for massively multiplayer games, such as BigWorld[28]. Devmaster.net[29] maintains a database of 3D game and graphics engines.

2.1.8

Other tools for game development

Apart from the above game-oriented middleware, some multimedia tools can also be used for game development, such as Virtools[30], Director[31]. However, since these tools are not mainly targeted for commercial game development, there may be performance issue and development issue on large scale game development.

2.2

Lucid Platform 1.0

In this section we briefly describe the architecture of Lucid Platform 1.0. The Lucid Platform [32] is an all-in-one game development middleware developed by the Multimedia Innovation Centre (MIC) of The Hong Kong Polytechnic University which provides complete solution for MOG and single player game development. Since the launch in May 2005, several demo games, VR applications and commercial MOGs were developed based on the middleware including our latest demo game Virtual Three Kingdoms (Figure 1) and the awardwinning Xbox game Auroral Snare [33] (Figure 2) developed by Treasure Box. Two software development kits are included in the Lucid Platform 1.0, namely, Lucid3D [34] and LucidNet [35]. Lucid3D aims to provide software libraries for front-end functionalities such as 3D graphics, audio and AI, where LucidNet provides back-end software libraries such as synchronization, interest management and transaction. Figure 3 shows the architecture of Lucid Platform 1.0.

Currently, PC, game consoles and arcade platforms can provide high quality real-time 3D rendering. However, portable consoles and mobile devices are catching up for 3D capability, such as Portable PlayStation and OpenGL ES enabled mobile phones. Although different platforms provide different technical capabilities, nowadays, more game middleware provide crossplatform capability, especially for PC and game consoles. In recent years, many games are developed for multiple platforms concurrently, especially for those supported by crossplatform game engines. In the beginning stage of Lucid Platform, due to the limited budget and experiences, we chose not to develop for game consoles. We decided to firstly support PC/Windows for client-side, both PC/Windows and PC/Linux for serverside. Upon the decision, we have reserved rooms for future cross-platform development by abstracting hardware and software platform related functions. Section 4.1 will discuss some issues in cross-platform development.

3.3 Game Application Layer4: Application Framework

Standalone

Multiplayer

Graphics

Audio

Layer2: Simulation

Physics

AI

Layer1: LucidCore / Common

System

Layer3: User Interface

Mathematics

Input

GUI

Resource

Scene

Operating System / Hardware

Game Server Layer5: Application Framework Layer4: Synchronization

Game Client

Multiplayer Interest Synchronization Management

Layer3: Communication

Session Management

BDRMI

Layer2: Simulation

World Management

Transaction

Layer1: LucidCore

System

Mathematics

Dead Reckoning

Persistency

Account Management

Operating System / Hardware

Figure 3: Architecture of Lucid Platform 1.0

3. GENERAL DESIGN CONSIDERATIONS 3.1 Category of Middleware The first consideration is to choose the category of middleware to be developed. Lucid Platform is targeted to provide a complete solution to game development. However, if the middleware is only developed for in-house purpose, the developer should choose a smaller scale of middleware and try to integrate with other existing middleware.

3.2

Target Platform

The target hardware and software platform is an important consideration. Currently, the major gaming platforms include personal computers (IBM PC/Windows, Macintosh), game consoles (PlayStation 2, XBox, GameCube), mobile game consoles (PlayStation Portable, Nintendo Dual Screen, GameBoy Advance), mobile devices (J2ME, Symbian OS, WindowsMobile, PalmOS), arcade platforms and web (HTML, J2SE, Flash, Director). These platforms have different consumer markets and technical capabilities.

Programming Language

The choice of programming language is mostly related to the user of the middleware. Traditionally C/C++ is the choice for game industry. The advantages of C/C++ include high performance, cross-platform, third-party libraries support. However, there are also disadvantages of C/C++ over other common programming languages (e.g. Java, C#, Visual Basic), such as steeper learning curve and difficulties in implementation/debug. Finally, we have chosen C++ in Lucid Platform. We tried to reduce the difficulties in using C++ based middleware, including the use of reference counted object to ease the memory management tasks, which will be described in Section 4.1. Another disadvantage of C++ is the relatively long build time. A complete rebuild of Lucid Platform is about one hour on a P4 3GHz machine. Some distributed build tools, such as Incredibuild[36], can help. It is also noted that, although C++ has been standardized, many compilers are not fully complaint to the standard. Lucid Platform currently supports Microsoft Visual C++.Net 7.0, 7.1 (2003 Edition), and gcc 3.3. We need to carefully workaround the compilers’ defects, such as many issues related to C++ template.

3.4

Application

Some game middleware are targeted for particular type of game genre, especially for those game middleware that is inititally developed for a game, e.g. Quake for First-Person Shooting (FPS). Some other game middleware are more generic, such as Renderware, Gamebyro. We have decided to choose generic way instead of specific. Also, we target Lucid Platform to non-game application (or serious game). We have developed a driving simulator (Figure 4) for our department of optometry and radiography. The driving simulator is used as an apparatus to conduct scientific experiment to test the performance of driving during different visual situations.

specific functions, the higher level modules and game code can be written more cross-platform-friendly. We enforce the following policy: Lucid Platform (excluding the application framework) headers do not include platform specific header (such as windows.h in Win32). However, we do not abstract the standard C/C++ libraries. We use many C/C++ functionalities in Lucid Platform, including STL and string.

Figure 4: Driving Simulator

3.5

Integration

There are mainly two ways of integrating game middleware to games. First, the middleware is provided as an add-on library to the developer’s code base. For example, the developer integrates a third-party audio library into their game. Second, the game middleware is the host, where the developer integrates their code base into the middleware. It is the case for most game engines, where developer adds game contents into game engines. We observed that there are various needs in our local (Hong Kong) game industry. Some game development companies have developed their 2D online game technologies, while some companies have developed single player 3D games technologies. By this observation, we decided to use an hybrid way of integration. Lucid Platform is divided into libraries, such as graphics, audio, physics, communication, and so on. The developer can choose to only use some of the libraries. So that companies can use the 3D modules only, or multiplayer modules only, or both or just a few modules. At the same time, we provide application frameworks above the libraries, which by default integrate all the libraries. The application frameworks are provided as open source, which can be customized easily. This would be a good choice for new game companies.

4.

CORE ENGINE

Here we define core engine as low-level system, mathematics systems, and other systems that are common to the remaining parts of the game middleware. Core engine provides common functionalities to more specific features, such as providing Mathematics functions to 3D graphics rendering and physics simulation.

4.1

Low-level system

The low-level system is mainly for abstracting the platformspecific functions. Common abstraction including the data types, endianness, time, file handling, thread/process management, memory management. By abstracting the platform-

Besides, to reduce the difficulties in memory management for developers, we developed an intrusive, reference-counted smart pointer, with reference to [37]. By using this smart pointer, developers only need to call the new operator to create theses kind of objects, and need not (cannot) call the delete operator at the end. This design decision has performance overhead but we think that it is the balanced solution between raw pointer and garbage collection alternatives. We enforced pass-by-const-reference for smart pointer parameters for efficiency. Also we convert smart pointers to raw pointers inside functions which need to dereference smart pointers twice or more.

4.2

Encoding

When designing text related API, we specify all displayable text (gameplay related text) as Unicode. This decision comes from the fact that nowadays MMOGs often involves multiple language regions. Unicode is the most suitable encoding for handling mixed languages. However, for other strings, such as filenames, we use native encoding to reduce the overhead.

4.3

Mathematics

Mathematics is normally the largest module in core engine. Most 3D game middleware contains 2D/3D vector, matrix and quaternion computation. Lucid3D also provide several 2D/3D geometric shapes such as 2D/3D AABB, 2D/3D OBB, circle/sphere, disk/cylinder, capsule, cone, line, linesegment, ray, plane, etc. and the distance/intersection utilities among these shapes. Besides, Lucid Platform also provides some integral types for 2D user interface, including point and rectangle. Another supported area is color computation. During the later stage of Lucid Platform 1.0 development, we incorporate exmat[38], an expression template library with SIMD optimization, to facilitate compile-time and runtime optimization to mathematics performance.

4.4

Resource Management

Game software nowadays need to manage a lot of resource, including textures, 3D models, sound, font, etc. Many game middleware use a compressed archive format to aggregate all resources into a single archive. However, this also has disadvantage that it increase the round-trip time for putting modified files into archive and test the build. We decided to provide two file systems, which are transparent to the resource access. One file system is used to mount a directory as root folder. Another file system uses archive root as root folder. Therefore, developer can firstly run the game application using simple file system, and finally uses the archive file system in the release build. Since the available memory in PC is variable, we created a Least-Recently-Used (LRU) policy for read-only resource

caching. User can specify the capacity of a type of resources, and the resources will be loaded and unloaded according to LRU policy.

Physics

Gui

Input

4.5

Scripting

5.

3D ENGINE

3D engine includes Human Computer Interaction (HCI) and game simulation related features in a 3-dimensional world. The HCI related modules visualize 3D environments to user by visual and audio, and accept feedback from user via input devices. The game simulation related features is used to model the gameplay in 3D environment, such as physics simulation and artificial intelligence.

5.1

Architecture

The main challenge in designing 3D engine is the integration of different modules, while maintains loose coupling among the modules. Our approach is to use a common scene management system to represent a 3D environment, such that different types of 3D environment (visual, audio, physics, AI) can be plugged in. Besides, we decided to use a layering approach to clarify the dependencies inside some complicated modules, as shown in the package diagram (Figure 5). For example, the graphics module is divided into four layers: Driver, Resource, Scene and Render. Each layer represents a level of functionalities. Driver layer provides graphics API abstraction. Resource layer provides graphics related resources, which are associated with driver objects. Scene layer provides graphics related scene nodes, such as camera, light, mesh, and associates with driver and resource objects. Finally Render layer is responsible for managing and executing render pipeline, which involves 3D rendering with a scene defined in Scene layer.

Vehicle

Graphics

Driver

InputMethod

The first decision in supporting scripting is the scripting language. We do not want to create our own proprietary scripting language due to time constraints. In game industry, popular choices of scripting languages include Python[39], Lua[40], Ruby[41], etc. After our evaluation, we have chosen Lua for its advantages, including light-weight, compact, flat learning curve, and easy to create multiple contexts. Binding C++ code to scripting code has various options. One option is to create stub functions manually. This would be very time-consuming for our platform which has few ten thousands of functions. Another option is to use some toolkits, for example, Simplfied Wrapper and Interface Generator (SWIG)[42]) to generate binding automatically. However, we started the scripting development in very late development stage. It makes difficulties to change the APIs to adapt to the requirements of such toolkits. Our final decision is to create a custom solution. We create an generator which create wrapper functions according to the mangled names in DLLs. Since this cannot handle all the cases, we added another solution which use meta-template programming to create wrappers with manual customization. It will be better if we can establish the scripting framework before developing the rest of the platform. In the next generation of Lucid Platform, we will provide reflection mechanism to simplify the script binding issues, and support more scripting languages.

Ragdoll

Audio

Render

Dynamics

Scene

Collision

Resource

Driver

Kinematics

Scene

Math

Render

Scene

Resource

Resource

Driver

System

Figure 5: Lucid3D Package Diagram This layering design seems to be complicated at the first sight. However, we found that it can actually help users to understand the domain concepts in using the API.

5.2

Scene Management

There are various ways to represent a 3D scene. The most common one is scene graph. Scene graph can be a Directed Acyclic Graph (DAG) or a tree. The advantage of DAG is to share sub-graph from different nodes as the result of cloning. However, we decided to use a tree structure to represent a scene. Instead of referencing a node multiple times for cloning, we let the scene nodes share common resources (e.g. 3D model, material). Traditionally, some scene graph contains nodes representing render state for optimal render state changes. However, we think that this is unintuitive to scene graph mixed with graphics, audio and other scene nodes. Also, nowadays the graphics render pipeline becomes more and more complicated. The pipeline often includes multiple render passes and different sorting criteria. Therefore, we use a tree structure to represent a hierarchy of 3D nodes, as in most digital content creation tools. Scene nodes in Lucid Platform contain local/world transform, name, and optionally bounding volume and user-defined data. The world transform update is done by lazy-evaluation. Only nodes with modified local transform, and their descendents, will be updated.

5.3 5.3.1

Graphics Graphics API

A major decision in graphics is the choice of graphics API. The common choices in PC/Windows platform is Direct3D and OpenGL. Direct3D has advantage of fast update to latest features. OpenGL is always appreciated for its crossplatform compatibility. We chose Direct3D finally, mainly due to its latest features and the familiarity of it among our team. Although we only use Direct3D in the current implementation, we have abstracted the driver layer through abstract factory pattern[43] and Dynamic Link Library (DLL), so that we can write OpenGL driver later without changing the other layers of code.

5.3.2

Programmable Graphics Pipeline

Since the introduction of programmable graphics pipeline, shaders become a very important consideration in graphics engine design. At the time of design, the latest Direct3D shader version is 2.0. We decided to support the latest 2.0 shader, and also fallback to 1.0 and fixed pipeline. A convenient way to implement multiple versions of shaders is via HLSL Effect Framework (or CgFX). However, general shaders implementation is often for a single light source. We need to create custom semantics for render passes to support multiple lights of multiple types. Also we need to handle other graphics effects, such as stencil shadow volume, shadow mapping, projective texture and combinations of these in each shader (Figure 6). These generate high complexity in writing different shaders. Our solution in 1.0 is to create combinations of shaders by macros. It involves writing a complicated include file, and then creates different combinations of shaders which defines combinations of features, for example, LightDiffuse.fx for lighting with diffuse map, BumpGloss.fx for bump mapping with gloss map, etc. We have compiled more than a thousand of these shader files. These shader files can be suitable for most usage. However, this will generate combinatorial explosion if we add more features. So we will try to make it more flexible in the next version, by creating a custom shader editor to combine the features.

sound source and listener nodes, which can be attached to our scene graph system. For example, if the developer attaches an engine sound to a car, the gamer with 3D sound equipment can perceive the 3D position of sound source when the car moves.

5.5 5.5.1

Input Immediate and Buffered Mode

The Windows version of Lucid Platform uses DirectInput API to handle input. However, there are two modes in DirectInput API, immediate and buffered mode. To simplify the developer’s task, we choose to support both modes concurrently. It is done by using buffered mode to emulate immediate mode. So that the developer is not restricted to single input mode, but using both modes at the same time.

5.5.2

International Character Input

A common requirements for asian game developer is to let gamers input Chinese-Japanese-Korean (CJK) characters. There is problem using Input Method Editor (IME) window in full-screen mode on Microsoft Windows. To help the developers overcoming this problem, we decided to develop a input method module, which handles the IME events on windows. GUI module uses this module to support CJK character input in GUI controls. And the developer can customize the display of IME information.

5.6

Graphical User Interface

At the design stage, we would like to create a simple Graphics User Interface(GUI) module, which contains a few common controls (label, button, textbox, etc.) to be used in games. However, due to the development of SceneBuilder (details will be discussed in later section), we need to create many more GUI controls, for example, window, menu, treeview, combobox, etc.

5.6.1

Figure 6: Multiple types of lights, shadow volume and projective texture applied on a shader-based material

5.4 5.4.1

Audio Format

There are many audio file formats suitable for game development. To support compressed streaming audio, we have considered MPEG Audio Layer 3 (MP3). Its major advantage is popularity and good quality. However, using MP3 in game requires royalty fee[44]. Since Lucid Platform is targeted to minimize the development costs for local industry, we decided to use an open and patent-free audio Codec, Ogg Vorbis[45].

5.4.2

Customizable Look and Feel

We decided to support customizable look-and-feel because many games have their stylized user interface. We provide two levels of customization. First level is to change the GUI texture and an image map describing the areas of subimages. Since all the controls support variable size, each image is divided into 9 regions, where the four corners are fixed-size, other regions are resizable. The second level is customizing by programming. As shown in Figure 7, we divided each control into logic part and presentation part. A control can plug-in a custom presentation part, so that developer can change the appearance programmatically.

3D Audio

As described previously, we would like to mix graphics and audio into the same scene graph. To achieve this, we create

5.7

Physics

Different games require different levels of Physics simulation. Therefore, we decided to divide the physics modules into sub-modules. The collision detection module can be used independently for some type of games. Dynamics simulation with collision detection module can be used to simulate more realistic interaction of physical bodies in the game world, with the cost of more CPU cycles. We were facing three options in providing Physics features in Lucid Platform. One option is to integrate a commercial engine. The second one is to integrate an open-source



TButtonUI

Plane









Tri-mesh

TButton





Terrain

TSkin





Sphere

1

Cylinder

TControlUI

Capsule

Box Capsule Cylinder Sphere Plane Terrain Trimesh

1

TControl

Box

GUI













Table 1: Supported pairs in collision detection Default

6.

TDefaultSkinUI

TDefaultButtonUI

6.1 Figure 7: GUI skin class diagram (left-side is logic part, right-side is presentation part)

engine. The last one is to build everything from scratch. The first one is not possible for our project nature. And we decided to integrate an open-source engine, ODE[13], for dynamics simulation. But due to the limitation of the collision detection in ODE, we decided to develop our own collision detection system with support to the collision primitives (Some in figure 8) and collision tests (Table 1). We have not supported tri-mesh vs tri-mesh collision in 1.0 because it requires high CPU costs. So tri-mesh, terrain and plane is basically used as colliders in static environment. Collidision primitives are represented as ”‘collider nodes”’ in scene graph. So that the collision nodes can attached to moving objects, such as bones in character skeleton. Also, multiple collider node can be attached to a single node to better approximate the shape of an object. This can be used to reduce the need for trimesh vs trimesh collision.

Figure 8: Collider types

5.8

Artificial Intelligence

Due to limitation of time, we have only created a pathfinding system for AI in Lucid Platform. The path-finding system is based on hierarchical graph of way-points, with pre-computated all-pair shortest paths. This algorithm provides O(1) complexity in finding path at run-time.

MULTIPLAYER ENGINE

The multiplayer middleware serves as the back-end of Lucid Platform which consists of a series software libraries that handle data communication, data persistence and network security.

Architecture

The logical communication model of LucidNet is based on the client/server architecture. Each client communicates to other clients via the server. Since our original target was not to design a middleware for very large scale multiplayer online games; despite being likely bottlenecks, this model provides best control and coordination of message delivery and introduces less management problem than multiple server architecture.

6.2

Interest Management

The question of whether or not to use interest management itself is a big problem that troubles many multiplayer online game developers. The main idea behind this technique is to filter irrelevant messages for each game participant and thus reduces bandwidth consumption on the network. However in doing so we may also impose CPU cycle overheads for the filtering process. This becomes a tradeoff situation. In a networked game (or more generally, real-time distributed simulations) point of view, the game servers are usually under a well-controlled and well-managed situation. We can always upgrade the servers’ CPU or add more memory to them. However the nature of heterogeneous network environments is usually uncertain since the bandwidth and latency of individual user networks are impossible to be guaranteed. Thus we believe that, the network resources (e.g. bandwidth) are always more expensive than the computational and storage resources and the tradeoff is worth to make. We chose to apply HLA object management and data distributed management services [46, 47, 48] because they are able to provide the most precise class-based and value-based filtering mechanisms which ensure the game participants receive the minimal set of data they interest. However, the more precise the filtering schemes, the more computational overheads are imposed for the interest matching processes. Thus, we use an efficient interest matching algorithm (which is based on caching of matching results) for the implementation. Details of the matching algorithm and the interest management system are discussed in [49, 50]. The architecture of the interest management system is shown in Figure

Server Client Proxy A

Client A

RTIambassador FederateAmbassador

Client Proxy B

RTIambassador

RTI

FederateAmbassador

Client B

Figure 9: Architecture of the Interest Management System 9.

6.3

Synchronization

Nearly all computers have an internal clock for keeping track of time. In a single player game, event inconsistency is unlikely to occur since all processes on the computer refer to the same internal clock. However, as soon as multiplayer online game are introduced, each participant with its own clock, the situation changes. It is almost impossible to guarantee that the timers in different computers all run at exactly the same frequency. As a consequence, different game participants may not agree with the order of events which may lead to the wrong result of simulations. Many algorithms have been proposed for doing physical clock synchronization, which are generally based on two basic ideas: 1) Using external master clock for reference. 2) Manipulating the timers by their difference, based on statistical data. However in a classic paper [51], Lamport showed that it is not necessary that all physical clocks of the participants be synchronized because the lack of synchronization would not be observable and thus could not cause problems. What usually matters is that all participants agree on the same event order, so that the simulations can be taken place properly. This idea is suits perfectly for multiplayer online game simulations. Thus we decided to apply only the logical time synchronization to the Lucid Platform synchronization module.

7.

APPLICATION FRAMEWORK

To use all the functions provided in previous sections is complicated. Many game engines provide standard application frameworks, which simplify the usage of different features, and standardize how new contents are added to the engine. We also created two application frameworks for Lucid Platform, namely Standalone and Multiplayer. To design these frameworks, we need to decide the levels of support to the developers. In many game engines, the application framework include the definition of game entity (or game object, game actor), which is a part of the game logic. Developers are responsible to derive new classes from game entity to create custom behavior, and linked to graphics/audio objects. However, we have not included this feature in our application frameworks for several reasons. One reason is to make Lucid Platform neutral to game genres. The second reason is that we want to provide the maximum flexibility of using Lucid Platform. Third, we want to keep the application frameworks in 1.0 as simple as possible, and

Figure 10: Exporting shader material in 3D Studio Max provide them as open-source for developers to customize. As a result, our application frameworks only provide two functions. First is to do initialization and setup of all the underlying modules. Another one is providing a game-state machine, which simplifies the handling of game states, for example, opening animation, main menu, gameplay, game over, etc. In our next-generation, we would like to enhance the features of application frameworks, especially for integration with the additional tools we are going to develop. We will provide a complete game logic framework which separates from presentation. Also, the game logic framework will be used as a foundation for testing framework, which has not been addressed in most of the game engines nowadays.

8.

TOOLS DEVELOPMENT AND INTEGRATION 8.1 DCC Tools Digital Content Creation (DCC) Tools are the primary software for artist to create content. For 3D game graphics, the popular tools are 3D Studio Max, Maya and Softimage. 3D engine needs to access the content created in these tools. There are mainly two methods. One method is to write a loader to read a known file format created by the DCC tools. Another one is to write an export plug-in for the DCC tool to export an engine-specific format. Many non-commercial

other scene. So that particle systems are normally created as template, which are then re-used in other scenes.

9.

CONCLUSIONS AND FUTURE WORKS

Developing game middleware is challenging. Developers need to make a lot of decisions, which affects the middleware in long-term. This paper showed some of the choices in design phrase, and what have been chosen by us during developing Lucid Platform 1.0. These choices become the characteristics of a game middleware.

Figure 11: Particle system created in SceneBuilder engines prefer the former one, while commercial engines prefer the latter one. It is because writing an export plug-in can get all the available information inside the DCC tool, for example, real-time shader based materials (Figure 10). So we also chose the plug-in way at that time. And by a survey, we decided to firstly create a 3D Studio Max 6 (and 7 later) export plug-in. We have planned to create a Maya export plug-in in near future. For the next version, we have considered using COLLADA[52], an open format initiated by Sony, as the data exchange bridge. It is because all three DCC tools vendors support this project and will create official exporters for this format. This will reduce our development time for each DCC tool.

8.2

Custom Level Editor

In the design phrase of the project, we planned not to develop a custom level editor. We presumed the artists or level designers to create a level in DCC Tool and use our exporter plug-in to export to our proprietary scene format. However, we later found that, this approach has various weakness, including inaccurate preview in DCC tool and lack of engine specific features (e.g. lighting, shadow, particle systems, billboards, etc.) At the middle of the project, we decided to develop a custom level editor, SceneBuilder. This is a tremendous task. We need to enrich the existing GUI module and develop the framework of SceneBuilder, including the scene views, property editing, undo/redo, navigation, node selection, node creation, etc. We find that SceneBuilder is very useful to content creators. Not only doing simple scene composition, they can also do experiments on the particle systems and other effects. We have also created special editors for terrain, billboard, AI path, etc. Other developers also find it as a good tool to test and debug newly developed nodes. Many engines create special tools for particle system effect. However, we follow the tradition of DCC tools, we combines particle system editing into scene editor (see Figure 11 for an example). We emphasize the use of template-instantiation feature in SceneBuilder, which can let artists create scenes as templates, which can be recursively instantiated in an-

A game middleware has a long life cycle. After about 6 months of release of Lucid Platform 1.0, we have developed version 1.1 for feature and performance enhancements. We are now developing further enhancement for 1.x versions. At the same time, we are planning the requirement specifications and designs of the next generation of Lucid Platform, which will change some decisions we have made in 1.x, for example, next-generation consoles support, distributed architecture for multiplayer server, collaborative content creation tool, etc.

10.

ACKNOWLEDGEMENTS

Our work was supported by SME Development Fund (SDF) of the Trade and Industry Department, HKSAR Government, under the grant D02002077: “Mini-Scale Multiplayer Online Game Development Platform”. We would like to thank Prof. Lorraine Justice, Jackson Lai, Mingfai Chan, Patrick Cheung, Edwin Cheng, Bus Tsui, Cyrus Wong, Percy Tse for their contributions and supports for carrying out this project. We would also like to thank Treasure Box for the permission of using the screenshots of Auroral Snare.

11.

REFERENCES

[1] Scott Grieg, Ray Muzyka, James Ohlen, Trent Oster, and Greg Zeschuk. Postmortem: Bioware’s neverwinter nights, http://www.gamasutra.com/features/20021204/greig 01.htm, 2002. [2] Jake Simpson. Game engine anatomy 101, http://www.extremetech.com/article2/0,3973,594,00.asp, 2002. [3] David H Eberly. 3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics. Morgan Kaufmann, 2000. [4] David H Eberly. 3D Game Engine Architecture: Engineering Real-time Applications with Wild Magic. Morgan Kaufmann, 2005. [5] Alan Watt and Fabio Policarpo. 3D Games, Vol. 1: Real-Time Rendering and Software Technology. Addison Wesley, 2000. [6] Alan Watt and Fabio Policarpo. 3D Games, Vol. 2: Animation and Advanced Real-Time Rendering. Addison Wesley, 2003. [7] Renderware Graphics, http://www.renderware.com/graphics.asp. [8] Gamebryo, http://www.emergentgametech.com/.

[9] Sound Blaster EAX, http://www.soundblaster.com/eax/. [10] FMOD, http://www.fmod.org/. [11] Havok, http://www.havok.com/. [12] PhysX, http://www.ageia.com/. [13] Open dynamics engine, http://www.ode.org/. [14] Renderware AI, http://www.renderware.com/ai.asp. [15] RakNet, http://www.rakkarsoft.com/. [16] HawkNL, http://www.hawksoft.com/hawknl/. [17] Net-Z, http://www.quazal.com/. [18] Emergent, http://www.emergentgametech.com/. [19] Adaptive Communication Environment, http://www.cs.wustl.edu/ schmidt/ace.html.

[36] IncrediBuild, http://www.xoreax.com/. [37] Andrei Alexander. Modern c++ design, 2001. [38] Ricky Lung. Exmat, http://exmat.sourceforge.net/. [39] Python, http://www.python.org/. [40] Lua, http://www.lua.org/. [41] Ruby, http://www.ruby-lang.org/. [42] Simple Wrapper and Interface Generator, http://www.swig.org/. [43] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: Elements of reusable object-oriented software, 1995. [44] Mp3 royalty rates for games, http://www.mp3licensing.com/royalty/software.html. [45] Ogg vorbis, http://www.vorbis.com/.

[20] Internet Communications Engine, http://www.zeroc.com/ice.html.

[46] DMSO, Department of Defense, High Level Architecture Interface Specification Version 1.3. 1998.

[21] SpeedTreeRT, http://www.speedtree.com/html/speedtreert.htm. [22] RealNat, http://www.bionatics.com/.

[47] KL Morse and Jeffrey S. Steinman. Data distribution management in the HLA, multidimensional regions and physically correct filtering. In 1997 Spring Simulation Interoperability Workshop, March 1997.

[23] Newman Lau, Samuel Cheung, and Gino Yu. Example-based synthesis of martial arts sequence. In The First International Symposium on Game’s Science, Art, Education and Applications, 2005.

[48] K. Morse and M. Petty. High Level Architecture Data Distribution Management migration from DoD 1.3 to IEEE 1516. Concurrency and Computation: Practice and Experience, 16(15):1–17, 2004.

[24] Endorphin, http://www.naturalmotion.com/pages/products.htm.

[49] Elvis S. Liu, Milo K. Yip, and Gino Yu. Scalable Interest Management for Multidimensional Routing Space. In Virtual Reality Software and Technology (VRST) 2005, 2005.

[25] Unreal, http://www.unrealtechnology.com/. [26] Source, http://www.valvesoftware.com/sourcelicense/. [27] JupiterEX, http://www.touchdownentertainment.com/jupiterex.htm. [28] BigWorld, http://www.bigworldtech.com/. [29] DevMaster.Net 3D Engines database, http://www.devmaster.net/engines/. [30] Virtools, http://www.virtools.com/. [31] Director, http://www.macromedia.com/software/director/. [32] MIC, SD, The Hong Kong Polytechnic University, Lucid Platform 1.0, http://www.lucidplatform.com, 2005. [33] Treasure Box. Auroral Snare, http://www.auroralsnare.com/xbox. [34] Elvis S. Liu, Ricky M. Lung, and Patrick C. Cheung. LucidNet Programmer Guide. MIC, SD, The Hong Kong Polytechnic University, 2005. [35] Milo K. Yip, Man Cheung, Patrick C. Cheung, and Ming-Fai Chan. Lucid3D Programmer Guide. MIC, SD, The Hong Kong Polytechnic University, 2005.

[50] Elvis S. Liu, Milo K. Yip, and Gino Yu. Lucid Platform: Applying HLA DDM to Multiplayer Online Game Middleware. In 3rd International Game Design and Technology Workshop and Conference (GDTW), 2005. [51] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. In Communications of the ACM, 1978. [52] COLLADA public forum, http://www.collada.org/.