分布式游戏引擎研究
Design Document for:
ParaEngine
A Survey and Outlook on Distributed Game Engine
Document No.1.12
“Evaluate on previous technology, look for the future trend”
All work Copyright ©2005 by Li, Xizhi
Written by Li, Xizhi
Email: [email protected]
Version # 1.41
Thursday, September 11, 2008
Version history:
| 2005-3-29 |
Version 1.0 of the paper is started |
A Survey and Outlook on Distributed Game Engine
| Xizhi Li The CKC honors School of Zhejiang University , P.R. China |
|
Chair of the Supervisory Committee:
Professor He Qinming Department of Computer Science |
Abstract:
This article surveys on game engine prototypes for constructing distributed 3D computer games. The first part of the paper will discuss technologies for general 3D game engines, as well as common software architectures used in present day game development. The purpose of this part is to provide a reference guide to game technologies: i.e. in what conditions a certain technology should be used, how many choices there are for its implementation and where they can be found or purchased. The second part enumerates new requirements to distributed 3D computer games, which are not sufficiently supported or exploited in present day game engines. These are possible places that future game engines may evolve from. In the third part, I will reference a collection of recent research works for the less explored game genre: i.e. the distributed computer games. They have been organized in a loose framework of distributed game engine. In the end, several new research directions are pointed out, which is the conclusion and the main purpose of this paper.
Key words: Distributed game engine, networked virtual environment, simulation
Hangzhou , 2005/03
Extended Abstract in Chinese:
The Chinese abstract is identical to the Introduction Section of the paper.
文献综述：分布式游戏引擎研究
作者：李西峙
2005/04
摘要：
3D游戏引擎已有较长的发展历史，现代游戏引擎已经并正在成为人类开发的最为复杂的软件系统。游戏引擎将渐渐演变成为一个构建和运行高复杂性和交互性3D虚拟世界的标准平台。然而本文涉及的分布式3D游戏引擎目前尚处于原型阶段。本文第一部分讨论了大多数3D游戏引擎所采用的技术，以及基于这些技术形成的游戏引擎的软件体系结构。同时也讨论了不同游戏类型，可采用的技术和可供选择的实现方式，以及提供了相关技术的出处和供应商信息，其内容可作为一般游戏技术研究的参考和指引。第二部分列举了分布式3D游戏新增的技术需求。而现阶段的游戏引擎并不能充分支持这些技术需求。所以，未来的游戏引擎可以在这些方向上进行深入研究。第三部分介绍了一个尚处于初步研究的分布式游戏类型，也即一个松散的分布式游戏引擎框架的原型。文章最后部分指出了一些新的研究方向，它既是本文的总结也是目的。
关键词：分布式游戏引擎，网络虚拟环境，仿真
介绍
如果我们将网页和3D游戏世界作对比，将网页中的超链接和服务同3D游戏世界中的活动物体作对比，将网页浏览器和游戏引擎在运行时的环境作对比，我们将可以想象出一个分布式游戏的简单景象。可能有一天，整个网络将会成为，巨大的虚拟现实游戏世界的一部分。
从20世纪90年代初期，游戏引擎渐渐演变为一个构建和运行高复杂性和交互性3D虚拟世界的标准平台。在最近几年，游戏引擎方面的研究越来越多的获得众多科研机构的关注，不仅仅是因为迅速发展的游戏产业的需要，也是由于它为广泛的计算机科学和工程技术的研究与开发，提供了成熟和可以扩展的平台支持。它的应用领域包括：计算机图形学、动画系统（如电影）、网络化身、人工智能，虚拟现实和增强现实系统、网络虚拟现实、立体视觉、人机交互、互联网3D技术、多Agent系统、分布式计算和仿真、教育、军事仿真、机器人，等等。有关内容详见参考目录[1] [2] [3] [4] [5] [6] [7] [8]。
“游戏引擎”一词在二十世纪九十年代中期被提出，特别是和3D游戏（尤其是第一人称射击游戏（FPS），如id软件公司设计的Doom和Quake）紧密相连。其他的经过授权的软件设计商可以使用它们的内核来设计自己的游戏。随后出现的游戏，例如Doom3和Epic's Unreal就是采用这种模式的游戏及引擎，即，将引擎和游戏内容分开来开发。后来持续发展的游戏引擎技术允许游戏内容设计、脚本设计、美工、策划，独立的进行。现代游戏引擎已经成为了人类开发的最为复杂的软件系统之一，它往往要通过数十个系统协调工作，才能使得玩家能够获得最佳的游戏控制和视觉体验。
本文对尚处于原型界段的分布式3D游戏的引擎进行综述。分布式游戏和传统游戏模式不同。传统游戏基本上分为单机游戏、客户端/服务器游戏和多角色扮演游戏（MMRPG）等。分布式游戏与之不同之处主要表现在以下几个方面：第一，分布式游戏将游戏的逻辑和运算分布在网络上的多台计算机上；第二，它实现了一个动态的游戏世界网络拓扑结构，即允许网络游戏世界的规模可以在不重新启动系统的情况下进行扩展；第三，它允许网络中的多个游戏世界可以在一个场景中被展示和仿真，也就是说，在一台计算机上融合了一系列连续的游戏世界。
文章的第一部分将讨论大多数3D游戏引擎所采用的技术，以及由这些技术组成的游戏引擎软件体系结构。讨论不同游戏类型，可采用的技术和可供选择的实现方式，以及提供了相关技术的出处和供应商信息，其内容可作为一般游戏技术研究的参考和指引。所讨论内容是按照一般游戏引擎框架的内容来组织的。我们可以看到目前大多数商业游戏引擎所支持的多种不同类型的游戏框架，例如室内/室外混合场景游戏，等等。也有一部分游戏引擎是专门为某一类特殊类型的游戏所设计，例如赛车和飞行仿真游戏，外太空仿真游戏等等。在这些游戏中所使用的大多数技术都是类似的，为了达到这些特殊的功能和效果，人们对现有的游戏引擎进行了不断修改和扩展。由于缺少对于这些特殊游戏引擎的详细资料，仅能简单介绍其有关内容。
文章的第二部分列举了分布式3D游戏新增的一些技术需求。这些技术需求在现阶段的游戏引擎中并没有被充分支持。所以未来的游戏引擎可以在这些方面进行深入研究和开发。正如前面所提到的，分布式游戏具有与现行的大众游戏不同的显著特征。所以有必要为这类游戏设计一套全新的游戏引擎框架，以满足其特殊功能的需要。现有的已被广泛采用的游戏引擎，则可以通过扩展，快速吸收和采纳新的功能。这一部分所讨论的技术，也将成为未来游戏引擎中的重要组成部分。
第三部分中，介绍了一个尚处于初步研究的分布式游戏类型，也即一个松散的分布式游戏引擎框架的原型。文章最后一部分指出了一些新的研究方向，它既是本文的总结也是目的。
3D游戏引擎已有较长的发展历史，它是当今计算机邻域发展最迅速的研究方向。现代游戏引擎已经和正在成为人类开发的最为复杂的软件系统，引擎将渐渐演变成为一个构建和运行高复杂性和交互性3D虚拟世界的标准平台。然而本文涉及的分布式3D游戏的引擎目前尚处于原型界段。
感谢：
我要特别感谢我的导师 何钦铭 教授，对我研究内容的认可与支持，以及对论文中研究方法的指导与指正。
Forward
I have been involved in distributed game engine development for over a year, during which time I implemented my own computer game engine called ParaEngine. And it is still under active development. The paper will not talk about how a computer game engine can be constructed, but it does discuss on most of the issues that an engine designer will almost inevitably face with. The purpose of the paper is given in the abstract and it is assumed that the reader knows something about game engine already. In this paper, I will talk about game engine related issues in a high level of abstraction and direct the reader to other literatures for their great details. In a way, the paper is also suitable for reading to people who are new to computer game engine.
Game engine is a vast and rapidly evolving subject in computer science. Many new features mentioned today might be outdated tomorrow. I have tried my best to quickly grasp a good many of them for implementation in my own game engine. But I am sure a good many of them has not been covered by this survey or by my knowledge. Yet, I still started this survey, because my mind felt full and I may add new things to it in the future. I would like to hear your opinion about the mistakes in this paper or important things that I have missed.
Finally, the paper is in partial fulfillment of my bachelor thesis entitled: “Research on Distributed Computer Game Engine”. I would also take the chance to introduce you to some of my other works in AI, networked virtual environment, HCI and agent technologies, etc. Please find them in the self-reference section.
Acknowledgement
I wish to express sincere appreciation to my supervisor, Prof. He Qinming for his vast reserve of patience and knowledge. I would also like to thank my friends and family, specially my father. Without their encouragement and devotion, I could never complete this work.
1 Introduction
If we compare web pages to 3D game worlds, hyperlinks and services in web pages to active objects in 3D game worlds, and web browsers and client/server side runtime environments to computer game engines, we will obtain the simplified picture of distributed computer games. It is likely that one day the entire Internet might be inside one huge virtual reality game world.
Since early 1990s, game engine has evolved to become a standard platform for constructing and running 3D virtual game worlds of high complexity and interactivity. In recent years, game engine research has drawn increasing academic attention to it, not only because it is highly demanding by quick industrial forces, but also because it offers mature and extensible platform support for a wide range of researches in computer science and engineering. These includes computer graphics, autonomous animations, web avatars, artificial intelligence, virtual reality (VR) and augmented reality (AR), networked VR, stereo vision, HCI, web 3D technologies, multi-agent framework, distributed computing and simulation, education and military training, robotics, etc. See also [1] [2] [3] [4] [5] [6] [7] [8].
The term "game engine" arose in the mid-1990s, especially in connection with 3D games such as first-person shooters (FPS). Such was the popularity of id Software's Doom and Quake games that rather than work from scratch, other developers licensed the core portions of the software and designed their own graphics, characters, weapons and levels—the "game content" or "game assets." Later games, such as Doom 3 and Epic's Unreal were designed with this approach in mind, with the engine and content developed separately. The continued refinement of game engines has allowed a strong separation between rendering, scripting, artwork, and level design. Modern game engines are some of the most complex applications written, frequently featuring dozens of finely tuned systems interacting to ensure a finely controlled user experience.
This article surveys on game engine prototypes for constructing distributed 3D computer games. Distributed games differ from other game genres, such as standalone games, client/server multiplayer games and massively multiplayer role playing games (MMRPG), in the following aspects: first, a distributed computer game has game logics explicitly distributed on multiple computers on the network; second it features a dynamic game logic topology which allows the scale of networked game worlds to grow without restarting the entire system; third it allows multiple game worlds on the network to be displayed and simulated (interacting) in a single scene, i.e. merging in to one piece of continuous game world on a single computer.
Section 1 of the paper will discuss technologies for general 3D game engines, as well as common software architectures used in present day game development. The purpose of this part is to provide a reference guide to game technologies: i.e. in what conditions a certain technology should be used, how many choices there are for its implementation and where they can be found or purchased. Section 1 itself is organized in terms of a general game engine framework. We will see in this section that most commercial game engines today support a wide range of game types, such as indoor/outdoor mixed type games, etc. There are also game engines targeting on a specific game type, such as vehicle or flight simulation, outer space simulation games, etc. Many of the technologies used in these games are the same, while special functions may be achieved by modifying an existing game engine. Due to lack of first-hand knowledge on these special game functions, I will only mention some in brief words in this paper.
Section 2 enumerates new requirements to distributed 3D computer games, which are not sufficiently supported or exploited in present day game engines. These are possible places that future game engines may evolve from. As mentioned previously, distributed games have distinguished features that are not commonly shared by present day games. It is absolutely necessary to prototype a new game engine framework for the functioning of such games. Like many new features that are quickly absorbed by other well formed game engines, the prototype discussed in this section is also likely to be merged in existing ones.
In Section 3, I will reference a collection of recent research works for the less explored game genre: i.e. the distributed computer games. They have been organized in a loose framework of distributed game engine. In the end, several new research directions are pointed out, which is the conclusion and another main purpose of this paper.
2 Review of Game Engine Technologies
Game engine is an all encompassing subject in computer science. The part that deals with graphic storage and displaying is often called 3D engine or rendering engine. Rendering engine is usually the core component in a present day game engine; but a game engine usually includes support for many more aspects of a game's architecture than just the 3D rendering. Some part of game engine may be implemented by “middleware”. Middleware developers attempt to "pre-invent the wheel" by developing robust software suites which include many elements a game developer may need to build a game. Most middleware solutions provide facilities that ease development, such as graphics, sound, physics, biped animation, networking and AI functions. E.g. physics engines such as Novodex [10] and Havok [11] are commonly used by top commercial game engines to construct physically convincing games. In the viewpoint of a game development corporation, integrating middleware in their game engine is usually called outsourcing [12].
The continued refinement of game engines has allowed a strong separation between rendering, scripting, artwork, and level design. It is now common (as of 2005), for example, for a typical game development team to be composed of artists and programmers in an 80/20 ratio. Hence, game engine should also include a complete suite of virtual world constructing tools, which are usually used by artists. For example, 3D models, key framed animations, physical specification of game objects, etc are usually made by professional tools such as 3DsMax and Maya, and then exported to engine digestible file format by exporters; cinematic, game levels, etc may also be made in a similar way, whereas some game engine provides more specialized tools, such as visual script editor, level editor, which allow artists and level designers to compose game scenes on the fly (i.e. graphics attained at design time appear exactly as in the final game). For example, Quake series level editing tools are popular among hobbyists and also used optionally by some open source game engines [13] [14].
In this section, a general game engine framework used in my own game engine (ParaEngine) is presented for organizational purposes; because without proper organization, a brainstorming jot-down of game engine technologies can be quite a chaos. See Table 1.
Table 1 A quick jot-down list of game engine technologies
| Category |
Items |
| Graphics |
scene hierarchy, skinning, shadow / lighting model, particle systems, shader model / material system / associated tools, vertex and skeletal animation, alpha/texture sorting, terrain, clipping/culling/occlusion, frame buffer post-processing effects, split-screen support, mirrors/reflection, procedural geometry, text rendering/font issues, level of detail, projected textures, … |
| Resource management |
loading, resource lifetimes/garbage collection, streaming resource scheduling, rendering device change management, file access (pack files)… |
| sound/music |
3D, 2D, looping, looping sub range, effects, … |
| in-game UI |
also related to graphics and scripting. |
| I/O |
key remapping, force feedback (haptic devices) |
| time management |
frame rate control: time synchronizations with various engine modules |
| Scripting |
Lua/python/?, saving and loading game state, security, performance, profiling, compiler and debugging, in-game cinematic, … |
| Tools |
level editor, terrain editor, particle system editor, model/animation viewers trigger system tool, cinematic tool, MAX plug-ins – exporter, … |
| Console |
In game: debugging, in-game editor, recording/playback: frame-based, time-based compatibility: cross-platform compatibility, graphic device support |
| Networking |
distributed client/server, single client/server, peer-to-peer, security/hacking issues, package misordering, time synchronization, delay, bandwidth usage, error handling … |
| Physics |
stable physics integration, frame rate control, outsourcing physics engine?, collision detection (continuous or discrete) , collision response (approximation or impulse-based), integration with key framed animation, line of sight/ray queries, … |
| Animation |
inverse kinematics, key framed animation, motion warping/blending, |
| AI |
fuzzy logic, machine learning, state machines, path-finding, tools (scripting)… |
| General |
memory management, exception handling, localization, enhancing concurrency/multi-threading, … |
The four major modules in game engine are 3D rendering (graphics), scripting, physics simulation and networking, as shown in bold text in the table. This framework design as well as individual component implementations decides the general type of games that could be composed by it. I will first propose the game engine framework as used by my own computer game: Parallel World [self reference], and then I will review previous works for its major components.
2.1 A General Game Engine Framework
When designing the functioning core of an interactive software system, we usually start from its main loop. This has not changed much with multi-threading, message driven and event based system. The infinite loop in a computer game engine is called game loop [16], which drives the flow of the engine, providing a heartbeat for synchronizing object motion and rendering of frames in a steady, consistent manner. A general game loop is given in Table 2. It has been extended to include more details of the engine framework.
Table 2 Game loop
| Main game loop callback function { Time management: update and pre calculate all timers used in this frame. Process queued I/O commands (IO_ TIMER) { Mouse key commands: ray-picking, 2D UI input Key stroke commands Animate Camera (IO_ TIMER): Camera shares the same timer as IO } Environment simulation (SIM_TIMER) { Fetch last simulation result of dynamic objects Validate simulation result and update scene object parameters, accordingly. Update simulation data set for the next time step: Load necessary physics data to the physics engine; unload unused ones. Calculate kinematic scene objects parameters, such as player controlled character (this usually results from user input or AI strategies.). Update necessary simulation data affected by kinematic scene objects. Start simulating for the next time step (this runs in a separate thread than the game loop). Run AI module (SIM_TIMER) { Run game scripts (SIM_TIMER): Currently networking is handled transparently through the scripting engine. } } Render the current frame (RENDER_TIMER) { Advance local animation (RENDER_TIMER) Render scene (RENDER_TIMER) Render 2D UI: windows, buttons … } In-game video capturing (RENDER_TIMER) } |
Besides the game loop, there may be other game threads running. These include: the Windows message handler, script language runtime, network daemons and physics engine. In most cases, Windows message handler and script language runtime are running in the same thread as the game loop. However, since no knowledge is known about the activation rate of the Windows message handler, it is treated similarly with multithreaded functions with the exemption of handling exclusive data writing. Physics engine such as Novodex [10] is multithreaded; while most other physics engines are still single threaded. Network daemons are inevitably multithreaded. Some thread-safety issues should be properly dealt with in multithreaded environment. A common method is to duplicate public data which can be seen by both the working thread and the game loop. A benefit of this method is that the game loop can always access data in a uniform manner. Based on the above game loop, we will review several related techniques in the following sub sections.
2.2 Review of Rendering Techniques
2.2.1 Scene management
Game scene objects are usually organized in a scene graph [19] [17]. A scene graph is a tree where the nodes are objects in a scene arranged in some sort of hierarchy. These nodes may be actual physical objects, or simply 'abstract' objects. For example we can organize objects spatially in a scene graph, such as in a quad tree and octree, so that it could be used for clipping and occlusion of unseen objects. Various usages of scene graph have been explored, such as in a distributed environment [18].
2.2.2 Rendering Pipeline Overview
Much of work in scene rendering has to do with transversing a scene graph and selectively draw its nodes in a certain order. An open source game engine [20] is named after it. The details of a rendering pipeline can differ greatly for different game engines. I will present here one pipeline used in my game engine. It continues with the Render Scene function in Table 2. The pipeline presented is suitable for both outdoor and indoor rendering. Please see Table 3.
Table 3 Rendering pipeline
| Render scene (RENDER_TIMER){ Set up scene state: camera frustum, rendering device and other user parameters, etc Draw the sky with depth buffer off Render the outdoor landscape{ Build LOD terrain based on current viewport and camera settings. Draw the terrain, water, tree, grass: we may delay their rendering for occlusion sorting. } For each global objects in the scene graph{ Perform rough clipping test using its bounding shape, such as box and sphere. Add to post rendering list or animated biped list or sprite object list according to its type. } Transverse quad tree scene graph{ For each scene object{ Perform rough clipping test using its bounding shape, such as box and sphere. Switch (object. type){ Octree, BSP or Portal nodes (usually level mesh):{ do occlusion test draw the mesh Add any scene objects in its leaf nodes to post rendering list } Other small sized mesh nodes: { add to post rendering list } Animated biped nodes: { add to animated biped list } Billboard or sprite objects: { add to sprite list } } } } Transverse post rendering list { Sort by texture, alpha or rendering state Perform rough occlusion test with depth buffer using its bounding shape. Draw the object: it may perform future optimizations internally. } Sort and draw object in sprite list Advance animation in animated biped list (RENDER_TIMER) Draw shadow casters in animated biped list: only cast shadows on object rendered previously For each object in animated biped list{ Perform rough occlusion test with depth buffer using its bounding shape. Draw the object } Render dummy objects for debugging purposes } |
A good 3D rendering pipeline can be divided into clipping, culling, occluding and computing the right level of detail (LOD). Different game genres may emphasize certain components to reach the desired performance. Generally, it falls into three categories [21] [20]: outdoors, indoors, and planetary (outer space). The first two are commonly used. We can formally define an indoors rendering algorithm as one software piece that optimizes the rendering pipeline by quickly determining occlusions (in addition to clipping and culling) in the level geometry, thus allowing interactive rendering. This draws a distinction with outdoors rendering methods (explained in later sections), which will in turn emphasize LOD processing [22] because view distances will be large. This characterization does not imply that indoors algorithm does not use LOD, but it is the occlusion component that will be dominant.
As one may notice from the rendering pipeline in Table 3, it combines outdoors and indoors rendering, by ordering them in a certain way. Generally speaking, I render outdoor scene followed by indoor scene, postponing the rendering of any small-sized but high-poly object until large objects which may occlude them have been drawn. Shadow casters are rendered only before objects that do not receive shadows.
2.2.3 Indoor and Outdoor Rendering
Popular indoor rendering techniques include:
(1) Binary Space Partitioning (BSP) tree [23] [24]: It is a very efficient way of computing visibility and collision detection in occluded environments. It may include bounding boxes for clipping test. Leafy BSP tree with potentially visible sets (PVS) matrix can do fast occlusion test. The drawback is that BSP only supports static mesh, involves much preprocessing and consumes much maintenance memory.
(2) octree (3D) or quad tree (2D) [25]: It is a very general, scalable and widely applicable data structure for storing objects spatially. It may be weak at occlusion test. Yet with occlusion test supported in hardware, it is sufficient to use this simple data structure in most cases.
(3) Portal rendering [26] [27]: Like BSP, it allows programmers to paint only what is effectively seen. Unlike BSP, the world hierarchy is not automatically computed, and visibility is computed in real time, not preprocessed. It is also the most difficult one of the three methods discussed.
Outdoor rendering techniques mainly deal with large areas of landscape or terrain rendering. An extensive overview of terrain rendering techniques is given in [15]. Popular outdoor techniques include ROAM, Chunked LOD, etc [28] [29]. Almost all outdoor rendering techniques are relatively difficult to implement.
2.2.4 Shadow Rendering
Since a vast number of hard and soft shadow methods [31] [31] [32] [33] [34] [35] [36] [37] exist for general and very specific situations, I will only briefly discuss some methods here, focusing on those suitable for interactive and real-time applications. For a good starting point, please refer to Woo et al.'s paper [30] for a broader survey of shadow algorithms. Table 4 shows a comparison of some commonly used real-time shadow rendering algorithm.
Table 4 Shadow Rendering algorithm comparison
| Plane Projected Shadows |
Projected Shadows |
Depth Shadow Mapping |
| Quick, not much calculations |
Quick, almost no calculations |
Very quick, not much calculations |
| Vertex Projection |
Shadow Volumes |
Smoothies |
| Slow with high-res meshes |
Slow, lots of calculations |
Very quick, not much calculations |
2.3 Review of Animation Techniques
In game development, most game characters, complicated machines and some moving platforms may be hand-animated by talented artists. There are two extremes in synthesizing animations used in computer games. One is to motion blend full-recorded clips from motion library. Another is to use qualitative method to calculate the motion at real time. In modern game engine, an intermediary method is usually used, which separates the entire character animation in to several parts, such as legs, upper body, neck, arms, and facial expressions, etc. Each may either use pre-recorded motion or dynamically computed motion. The motions of these different parts are then integrated to form the final character animation. Please refer to [38][39][40][41][42][43][44] for advanced topics on character animation. In a typical game engine, usually the simplest method is used.
It is also worth mentioning for some common animation file format commonly used in the open source community and among game hobbyists. There are many proprietary and free 3D model and animation file formats available. Among the most popular are 3DS, MD2, MD5 and X. 3DS is kind of old and does not explicitly support skinned animation. X file format is primarily used through the DirectX retained mode API. It directly supports skinned animation and has both text and binary formats. Most file formats are interchangeable without losing critical information by tools such as [45].
2.4 Review of Scripting and Networking
Scripting is a very popular method used these days where large teams work on even larger games. It streamlines the creation of the AI and logic content by placing that responsibility in the hands of people different from those actually coding the engine. There are many different approaches to using scripting languages. One can code your own, use an embedded language such as Lua [46] [47] or Python, or even communicate with the engine using a network connection.
Some game logic which involves communications over a network can also be programmed in scripts. Script runtime environment can be designed to enable programmers working in a network-transparent manner [self: 2].
2.5 Review of Physics Simulation in Game Engine
Although a game engine can directly implement the entire simulation framework, it is common these days to use a middleware physics engine [10] [11] for handling the portion of physics which requires more complex simulation. [12] provides a comprehensive overview about a wide range of problems when outsourcing the physics engine in game development.
Two critical problems in integrating physics engine into a game engine are simulation time management and collision response. Simulation time is the current time used in the physics engine. Each frame, we advance simulation time in one or several steps until it reaches the current rendering frame time. Choosing when in the game loop to advance simulation and by how much can greatly affect rendering parallelism.
In game development, we usually have many hand-animated game characters, complicated machines and some moving platforms. These objects are not obligated to obey the laws of physics. So the third problem is how physical and non-physical object should react to each other. For example, we may consider key framed motion to be nonnegotiable. A key framed sliding wall can push a character, but a character cannot push a key framed wall. Key framed objects participate only partially in the simulation; they are not moved by gravity, and other objects hitting them do not impart forces. They are moved only by key frame data. For this reason, the physics engine usually provides a callback function mechanism for key framed objects to update their physical properties at each simulation step. And game developers need to manually tell the engine how the objects should respond.
2.6 Review of AI in Game Engine
AI in Games is the computer simulation of intelligent behaviors. Funge has overviewed it in his book [49]. [48] suggests some potential “next steps” towards the creation of virtual autonomous characters that are lifelike, intelligent and convey empathy.
2.6.1 Path finding
Path finding is one of the most visible types of Artificial Intelligence in video games. Few things make a game look "dumber" than bad path finding. Fortunately, path finding is mostly a "solved" problem. A* and its extensions [50] are popular algorithms, which can efficiently build optimal paths between two endpoints, even if we have to cross many miles and obstacles in the process.
3 A Survey and Outlook of Distributed Game Engines
The term “Distributed Game Engine” introduced in this paper refers to a game engine platform suitable for constructing and running games as described in Section 1. Another widely used term for it is Virtual Reality Engine (VR engine). But I prefer to use Distributed Game Engine to emphasize its relationships with games.
3.1 Review of Distributed Virtual Reality Engine
The following VR engine projects are reviewed: Dive, VREng, CVE and Croquet.
3.1.1 DIVE
The SICS Distributed Interactive Virtual Environment (DIVE : http://www.sics.se/dive/dive.html) [51] [52] [53] [54] is an experimental platform for the development of virtual environments, user interfaces and applications based on shared 3D synthetic environments. Dive is especially tuned to multi-user applications, where several networked participants interact over an internet.
Dive is based on a peer-to-peer approach with no centralized server, where peers communicate by reliable and non-reliable multicast, based on IP multicast. Conceptually, the shared state can be seen as a memory shared over a network where a set of processes interact by making concurrent accesses to the memory.
Consistency and concurrency control of common data (objects) is achieved by active replication and reliable multicast protocols. That is, objects are replicated at several nodes where the replica is kept consistent by being continuously updated. Update messages are sent by multicast so that all nodes perform the same sequence of updates.
The peer-to-peer approach without a centralized server means that as long as any peer is active within a world, the world along with its objects remains "alive". Since objects are fully replicated (not approximated) at other nodes, they are independent of any one process and can exist independently of the creator.
The dynamic behaviour of objects may be described by interpretative scripts in Dive/Tcl that can be evaluated on any node where the object is replicated. A script is typically triggered by events in the system, such as user interaction signals, timers, collisions, etc.
Users navigate in 3D space and see, meet and collaborate with other users and applications in the environment. A participant in a Dive world is called an actor, and is either a human user or an automated application process. An actor is represented by a "body-icon" (or avatar), to facilitate the recognition and awareness of ongoing activities. The body-icon may be used as a template on which the actor's input devices are graphically modeled in 3D space.
A user `sees' a world through a rendering application called a visualizer (the default is currently called Vishnu). The visualizer renders a scene from the viewpoint of the actor's eye. Changing the position of the eye, or changing the "eye" to another object will change the viewpoint. A visualizer can be set up to accommodate a wide range of I/O devices such as an HMD, wands, data gloves, etc. Further, it reads the user's input devices and maps the physical actions taken by the user to logical actions in the Dive system. This includes navigation in 3D space, clicking on objects and grabbing objects etc.
In a typical Dive world, a number of actors leave and enter worlds dynamically. Additionally, any number of application process (applications) exists within a world. Such applications typically build their user interfaces by creating and introducing necessary graphical objects. Thereafter, they "listen" to events in the world, so that when an event occurs, the application reacts according to some control logic.
3.1.2 VREng
VREng (http://vreng.enst.fr) is an Interactive and Distributed 3D Application allowing navigation in Virtual Environments connected over the Internet using Unicast or Multicast if available. Worlds and their objects are described in a XML format.
VREng is a Web3D [2] which allows its users to navigate in Virtual Worlds like rooms, campus, museums, workshops, landscapes, networks, machines,... Visitors may interact with each other through their avatars. They may also communicate by exchanging short textual messages (Chat), audio and/or video channels, shared white-boards and interact with objects in the 3D environment like Web panels, virtual workstations, documentation on-line, MP3/Midi music, MPEG audio/video clips, MPEG4 animations, and remote applications and servers. Moreover, the user can put into worlds all kind of electronic documents and publish them to other participants on a message board keeping persistency.
VREng gives the opportunity to experiment with a more attractive and pleasant way accessing to multimedia data usually located in Web sites.
3.1.3 CVE
CRG Virtual Environment (CVE) [55] is also referred to as MASSIVE -2 in some papers. CVE is a distributed multi-user virtual reality system, current features of which include: networking based on IP multicasting; support for the new extended spatial model of interaction, including third parties, regions and abstractions; multiple users communicating via a combination of 3D graphics, real-time packet audio and text; extensible object oriented (class-based) developers API.
3.1.4 CROQUET
Croquet (http://www.opencroquet.org/ ) is a combination of open source computer software and network architecture that supports deep collaboration and resource sharing among large numbers of users. Such collaboration is carried out within the context of a large-scale distributed information system. The software and architecture define a framework for delivering a scalable, persistent, and extensible interface to network delivered resources.
The integrated 2D and 3D Croquet interface allows for co-creativity, knowledge sharing, and deep social presence among large numbers of people. Within Croquet's 3D wide-area environments, participants enjoy synchronous tele-presence with one another. Moreover, users enjoy secure, shared access to Internet and other network-deliverable information resources, as well as the ability to design complex spaces individually or while working with others. Every visualization and simulation within Croquet is a collaborative object, as Croquet is fully modifiable at all times.
3.2 VR Engine vs. Game Engine
The following comparison was conducted by Bendik Stang in [56].
If we look at the development of the game engines and compare that to the development of the VR-engines there is one major difference. The game engine has and will be created for mainstream personal computers and console platforms, where as the VR engine up till now has been created for a high end system like a SGI super computer. Until right after the turn of the century, the high-end VR-systems outperformed the game systems by being capable of handling
several orders of magnitude more polygons, textures and fill rates. The VR input system was and still is, quite a bit more advanced than the average home computer. 3D tracking devices and advanced audio video input are very expensive and fragile, and probably will be for some time. Still, it was almost disturbing to see the supercomputers immense power fade in comparison to the mainstream graphics cards during 2000 – 2002. Within those two years a US$ 1 million system was outperformed by a US $ 200.- graphics card in many ways. Of course the supercomputer still had other valuable features, like lots of RAM and multiple CPUs, but their days of superior graphics were gone.
The way the graphics processors develop makes it unwise to invest huge amounts of money on high-end graphics processors as a new and much better will make the investment obsolete in less than nine months.
So where does all this lead in relation to the difference between a VR engine and a Game Engine? The gaming marked is always craving the best visual effects and computer art. This has caused the gaming industry to develop game engines that gets the very maximum out of the available hardware. The competition has been tight, and optimization and quality has been vital for the sales. Huge amount of development money have been put into the development of the various game engines available today.
The VR industry being focused on high-end systems have had a much smaller marked. In many ways a more lucrative marked. When the computer system cost more than a million dollars, the software was possible to sell for tens of thousands of dollars, and there was hardly any competition. This has changed, and prices on relevant software have dropped so rapidly that it is hard to fathom. Examples like Maya Unlimited 4.0 went from approximately USD$ 15,000.- to less than 4,000.- in one month. Same happened to Softimage and other 3D modeling and animation applications. Such overpricing and lack of competition as well as the enormous computer capabilities may have caused the development of the Virtual Reality Tools to fall behind the accelerating development of competitive commercial game engines for the main stream computers.
4 Conclusion
Game engine is a vast and rapidly evolving subject in computer science. Many new features mentioned today might be outdated tomorrow. In recent years, game engine research has drawn increasing academic attention to it, not only because it is highly demanding by quick industrial forces, but also because it offers mature and extensible platform support for a wide range of researches in computer science.
Reference:
[1] Singhal, S., and Zyda, M. Networked Virtual Environments: Design and Implementation, ACM Press. 1999.
[2] Web3D Consortium. http://www.web3d.org/
[3] Manninen T. Interaction in Networked Virtual Environments as Communicative Action - Social Theory and Multi-player Games. IEEE Conf. Proc. CRIWG’2000.
[4] Axel Buendia and Jean-Claude Heudin. Towards Digital Creatures in Real-Time 3D Games. Virtual Worlds, p44-53, 2000.
[5] Marc Evers and Anton Nijholt. Jacob - An Animated Instruction Agent in Virtual Reality. ICMI 2000, LNCS 1948, pp. 526-533, 2000.
[6] Kuffner, J. J., Autonomous Agents for Real-Time Animation. Ph.D. thesis, Stanford. 1999.
[7] Pedro Morillo et al. A grid representation for Distributed Virtual Environments. European Across Grids Conference 2003: 182-189. 2003
[8] Marko Meister and Charles A. Wuthrich. On Synchronized Simulation in a Distributed Virtual Environment. In Proceedings WSCG 2001.
[9] Ying Liu, Interactive Reach Planning for Animated Characters using Hardware Acceleration. Ph.D. thesis, U. Penn, 2003.
[10] Novodex physics engine. http://www.ageia.com/novodex.html
[11] Havok solutions. http://www.havok.com
[12] Outsourcing Reality: Integrating a Commercial Physics Engine. Game Developer Magazine, 2002
[13] OGRE Project Site. http://www.ogre3d.org
[14] 3D Engines Database. http://www.devmaster.net/engines/
[15] An extensive overview of terrain rendering. http://www.vterrain.org/
[16] Robert Dunlop. Writing the Game Loop . Microsoft DirectX MVP site. http://www.mvps.org/
[17] Lars Bishop et al. Designing a PC Game Engine. IEEE Computer Graphics and Applications archive vol.18, Issue 1, p46-53. 1998.
[18] Bob Zeleznik et al. Scene-graph-as-bus: Collaboration between heterogeneous stand-alone 3-D graphical applications. In Proc. EUROGRAPHICS 2000, volume 19(3), 2000.
[19] Gerhard Reitmayr. Flexible Parametrization of Scene Graphs. Virtual Reality. 2005.
[20] Don Burns et al. OpenSceneGraph: http://openscenegraph.sourceforge.net/index.html 2005
[21] Fritsch, D. 3D Building Visualization – Outdoor and Indoor Applications. Photogram metric Week ’03, pp. 281-290. 2003.
[22] Lindstrom, P. et al. Real-Time, Continuous Level of Detail Rendering of Height Fields. Proceedings of SIGGRAPH ’96, pp. 109-118. 1996.
[23] Shumacker, R., Brand, R., Gilliland, M., Sharp, W. Study for Applying Computer-Generated Images to Visual Simulation. 1969.
[24] Feldman, Mark. Introduction to Binary Space Partitioning Trees. 1997
[25] Cheng, J.H. et al. Quadtree/Octree Meshing with Adaptive Analysis. Numerical Grid Generation in Computational Fluid Mechanics `88, Pineridge Press, pp.633-642, 1988.
[26] Jones, C.B. A New Approach to the `Hidden Line' Problem. The Computer Journal, vol. 14 no. 3 (August 1971)
[27] Perez, Adrian . Peeking through Portals. GameDeveloper 2 (March 1998).
[28] Lindstrom, Peter et al. Real-Time, Continuous Level of Detail Rendering of Height Fields. ACM SIGGRAPH 1996 (August 1996): 109–118.
[29] Ulrich, Tatcher, Super-size it! Scaling up to Massive Virtual Worlds. (course notes) SIGGRAPH 2002.
[30] Andrew Woo, Pierre Poulin, and Alain Fournier. A survey of shadow algorithms. IEEE Computer Graphics and Applications, 10(6):13-32, November 1990.
[31] AGRAWALA, M., RAMAMOORTHI, R., HEIRICH, A., AND MOLL, L. 2000. Efficient Image-Based Methods for Rendering Soft Shadows. In Proceedings of ACM SIGGRAPH 2000, ACM Press/ACM SIGGRAPH, New York . K. Akeley, Ed., Computer Graphics Proceedings, Annual Conference Series, ACM, 375-384.
[32] Ulf Assarsson and Tomas Akenine-M¨oller. A Geometry-based Soft Shadow Volume Algorithm using Graphics Hardware. SIGGRAPH 2003.
[33] Frank Crow. Shadows Algorithms for Computers Graphics. Computer Graphics, Vol. 11, No.3, Proceedings of SIGGRAPH 1977, July 1977.
[34] Cass Everitt and Mark J. Kilgard. Practical and Robust Stenciled Shadow Volumes for Hardware-Accelerated Rendering. developer.nvidia.com. 2002.
[35] CARMACK, J. 2000. E-mail to private list. Published on the NVIDIA website.
[36] Samuel Hornus et al. ZP+: Correct Z-pass Stencil Shadows. ACM Symposium on Interactive 3D Graphics and Games - April 2005.
[37] Eric Chan, Fredo Durand. Rendering Fake Soft Shadows with Smoothies. 14 th Eurographics Symposium on Rendering. 2003.
[38] Okan Arikan et al. Motion Synthesis from Annotations. ACM Transactions on Graphics (ACM SIGGRAPH 2003), vol. 33, no. 3, pp 402--408, 2003
[39] C. Karen Liu et al. Synthesis of Complex Dynamic Character Motion From Simple Animations. ACM Transactions on Graphics (SIGGRAPH 2002), 21(3):408–416, 2002
[40] Mira Dontcheva et al. Layered Acting for Character Animation. In The proceedings of ACM SIGGRAPH 2003, 2003.
[41] M. Girard and A Maciejewski. Computational modeling for the computer animation of legged figures. In Proc. of SIGGRAPH '85, 1985.
[42] Prem Kalra et al, Real-Time Animation of Realistic Virtual Humans. IEEE Computer Graphics and Applications archive Volume 18 , Issue 5 (September 1998)
[43] R. Boulic, D. Thalmann, and N. Magnenat-Thalmann. A global human walking model with real time kinematic personification. The Visual Computer, 6(6), December 1990.
[44] S.-K. Chung and J.K. Hahn. Animation of human walking in virutal environments. In In Proceedings of CA '99 : IEEE International Conference on Computer Animation., pages 4{15, Geneva , Switzerland , May 1999.
[45] Right Hemisphere, Deep exploration v3.5, 2004
[46] R. Ierusalimschy, L. H. de Figueiredo, W. Celes. Lua-an extensible extension language. Software: Practice & Experience 26 #6 (1996) 635-652. 1996.
[47] Cristina Ururahy, Noemi Rodriguez. Alua: An event driven communication mechanisms for parallel and distributed programming. PDCS-99, pp.108-113. 1999.
[48] Damian Isla and Bruce Blumberg. New Challenges for Character-Based AI for Games. The Synthetic Characters Group, MIT Media Lab.
[49] John David Funge. AI for games and animation: a cognitive modeling approach. A. K. Peters, Ltd. ISBN:1-56881-103-9. 1999
[50] Craig Reynolds. Steering Behaviors For Autonomous Characters. in the proceedings of Game Developers Conference 1999. pp 763-782. 1999.
[51] Carlsson and Hagsand. DIVE - A Multi User Virtual Reality System. IEEE VRAIS, Sept, 1993
[52] C. Carlsson and O. Hagsand. DIVE - A Platform for Multi-User Virtual Environments. Computers and Graphics 17(6), 1993
[53] O. Hagsand, Interactive MultiUser VEs in the DIVE System. IEEE Multimedia Magazine, Vol 3, Number 1, 1996.
[54] Emmanuel Frécon, Mårten Stenius, DIVE: A scaleable network architecture for distributed virtual environments, Distributed Systems Engineering Journal (DSEJ), 5 (1998), pp 91-100, Special Issue on Distributed Virtual Environments. 1998
[55] Benford, S., Greenhalgh, C., Lloyd, D. Crowded Collaborative Virtual Environments. ACM CHI'97.1997.
[56] Bendik Stang. Game Engines features and Possibilities. IMM DTU 2003
Selected books and websites (highly recommended):
[1] Daniel Sánchez-Crespo Dalmau. Core Techniques and Algorithms in Game Programming. New Riders Publishing. ISBN: 0-1310-2009-9. 2003
[2] A collection of good papers: Game Programming Gems. Vol. 1, 2, 3, 4, 5. 2005
[3] Game development resources: http://www.gamasutra.com
[4] Best game development forum: http://www.gamedev.net/
[5] Best game development news and resources: http://www.flipcode.com/
Some other books and articles:
[1] Alex Varanese. Game Scripting Mastery. The Premier Press. ISBN: 1-931841-57-8. 2003.
[2] Jim Adams. Programming Role Playing Games with DirectX. The Premier Press. ISBN: 1-93 1841-09-8 . 2002.
[3] Chris Crawford. The Art of Computer Game Design. First version in 1982. (reprinted in 1997).
[4] Jake Simpson. Game Engine Anatomy 101. 2002
Self Reference:
[1] Xizhi Li. DHCI: an HCI Framework in Distributed Environment.
[2] Xizhi Li. Using Neural Parallel Language in Distributed Game World Composing.
[3] Xizhi Li. Synthesizing Real-time Human Animation by Learning and Simulation.
ParaEngine document written by me:
[4] 1.0 ParaEngine Outline.doc
[5] 1.1 ParaEngine and GUI & OPC.doc
[6] 1.2 ParaEngine and MeshAnimationFile.doc
[7] 1.3 ParaEngine and SpecialEffects.doc
[8] 1.4 ParaEngine and new pipeline.doc
[9] 1.5 ParaEngine and Overview.doc
[10] 1.6 ParaEngine and DHCI (paper).doc
[11] 1.7 ParaEngine and WorldEditor.doc
[12] 1.8 ParaEngine and VRML (unused).doc
[13] 1.9 ParaEngine and Parallel World Game.doc
[14] 1.10 ParaEngine and Reference Guide.doc
[15] 1.11 ParaEngine and Frame Rate Control.doc
[16] 1.12 ParaEngine and Game Engine Survey.doc
[17] 1.13 ParaEngine and Physics.doc
[18] 1.14 ParaEngine and Scripting Reference.doc
[19] 1.15 ParaEngine and Research Proposal.doc