Introducing Discrete Simulation into Games

by Inmaculada García, Ramón Mollá and Emilio Camahort

Computer games have traditionally followed a scheme of continuous simulation, coupling the rendering phase with the simulation phase. Using a discrete event simulator as a game kernel allows pure discrete simulations, pure continuous simulations and mixed simulations. Discrete simulators support rendering and simulation phase independence while still maintaining the game structure and functionality, changing only the event management. This allows us either to execute the video game in less powerful computers or to improve the game quality.

Most of the computer-game source code currently available corresponds to non-commercial, low-quality, free games. They lack internal organisation, employ rudimentary simulation techniques and are not representative of the current level of technology. Only a few commercial computer games have their source code published (eg DOOM, QUAKE, Serious Sam).

There also exist video-game kernel toolkits such as 3D GameStudio, Crystal Space, Genesis 3D, The Nebula Device and so on, but these are mainly rendering kernels and follow the same continuous simulation scheme. A continuous coupled simulation model has many disadvantages. Firstly, all objects in the scene are simulated and rendered even though many objects will never generate events. The number of simulation steps is the same for all objects. Consequently, fast objects are insufficiently simulated while slow objects are over-simulated. This is not controlled by the programmer and depends on variables that can change during the game, including available computer power, world complexity, other active tasks in system or current simulation and rendering load. Secondly, the object priority for simulation and events execution order depends on the object's situation in the scene, which can produce erroneous simulations. Thirdly, the simulation events are artificially synchronised, meaning they are not executed in the very moment they happen. Lastly, each new simulation cycle requires the entire world to be rendered, although many frames will never be shown on the screen. Up to 70% rendering power may be wasted on current technology.

A Discrete Simulation Video-Game-Kernel
Our goal is to modify a video-game continuous kernel to make it discrete, while decoupling the simulation and rendering phases. To achieve that goal (see Figure 1) we have adapted the discrete event simulator (DESK) to work as a video-game kernel (this new kernel is called GDESK), and integrated GDESK into Fly3D SDK.

Figure 1: DFly3D and Fly3D main loops.

Any video game created using Fly3D may be translated to use DFly3D. This requires changing videogame objects like avatars, characters or weapons. The remaining objects are static and do not need to be translated. Only the simulation modelling must be changed. Object behaviour and object interaction with other objects must be modelled by message passing.

DFly3D Rendering Process
DFly3D allows the simulation and rendering processes to run independently. The rendering process now generates only as many renders as screen refreshes, thus avoiding rendering frames that are never shown on the screen. It also adapts the number of renderings to the system load, assuring quality of service (minimum number of renderings per screen refresh).

Figure 2: Videogame execution.

Discrete decoupled systems can avoid unnecessary renderings in systems with low computer power (simulation time and render time is larger than the refresh interval). The render object can decide to generate a render event in a refresh interval if it knows that there is a possibility that the frame will be shown on the screen. Alternatively, it can decide to put off the render until the next refresh interval and continue simulating.

Results
Our results show that when using the Fly3D kernel, an increase in the simulation load produces a decrease in the rendering process, causing the game screen refresh rate (SRR) to decrease as well. Similarly, an increase in the rendering load produces a decrease in the simulation time.

Using the DFly3D kernel, the video-game time is not completely shared by rendering and simulation. Hence, the DFly3D kernel allows the SRR to be tuned while the system is not collapsed. The frame generation ratio may be fixed to any value under SRR ensuring no flicker effect.

The time spent rendering a frame depends directly on the complexity of the scene. Our experiments show that the rendering time in DFly3D is lower than that in Fly3D. DFly3D avoids unnecessary renderings, and then delivers the computing power thereby freed up to other tasks, or uses it to improve artificial intelligence and collision detection accuracy, to increase realism etc. Every object can be sampled at its own independent rate, thus distributing computer power accurately. This means the kernel may be used in very low-power machines such as PDAs or mobile phones. It uses a very small amount of memory, while reducing the event overhead to lower than 0.05%.

Link:
http://www.sig.upv.es/

Please contact:
Inmaculada García, Ramón Mollá, Emilio Camahort, Technical University of Valencia, Spain/SpaRCIM
Tel: +34 96 3877007 ext 73573
E-mail: {ingarcia, rmolla, ecamahort}dsic.upv.es