Faculty of Engineering, Science and Mathematics …chrislord.net/files/ies.pdfA project report submitted for the award of MEng Computer Science ... Building type one is the weakest,

UNIVERSITY OF SOUTHAMPTON

Faculty of Engineering, Science and Mathematics

School of Electronics and Computer Science

A project report submitted for the award of

MEng Computer Science

Supervisors: Dr. Hugh Glaser

Domino Blast

by Christopher I. Lord and Heather S. Packer

June 11, 2007

http://www.soton.ac.uk

http://www.engineering.soton.ac.uk

http://www.ecs.soton.ac.uk

ABSTRACT

This paper covers the inception and development of a physics-based driving game.

The objective of the game is to use a toy car to demolish a set of tower-blocks

constructed from dominos. To add challenge, there is a target score and time-

limit for each level, and once the target score has been met, the player must drive

to an exit point before the time runs out. The main challenges tackled in this

project were realistic physical modelling of an environment, random generation

of buildings and per-pixel lighting. In the end, a fun and challenging game was

produced, based on these concepts. It is concluded that such complex physical

simulations are not possible in real-time without extremely aggressive optimisation

of the physics engine.

Contents

1 Overview 1

2 Design 2

2.1 Game-play . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1.1 Influence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Buildings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3.1 Building Type 1 . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.2 Building Type 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.3 Building Type 3 . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5 Game Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Implementation 9

3.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Physics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 Vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.2 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1 Normal-mapping . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 Textures and Sounds . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.5 Buildings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.6 Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.7 Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.8 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Evaluation 18

4.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Bibliography 21

Appendix A - Physworld Arhitecture Diagram 22

Appendix B - Building Modules 23

ii

CONTENTS iii

Appendix C - Subversion commit logs 24

Appendix D - Screenshots 29

Chapter 1

Overview

Domino Blast is a hybrid driving and destruction game with a children’s toys

theme. Its environments consist of buildings constructed from domino tiles and

a player-controllable toy car. The objective of the game is to wreak as much

havoc as possible, within a time limit. Its game-play is simplistic yet satisfying;

similar to the satisfaction gained from watching a tumbling Jenga tower, except

the objective is to tumble the tower, rather than slowly deconstruct it. As the

game progresses, levels become more dense and the buildings that inhabit them

become larger and more complex.

The game takes advantage of the Open Dynamics Engine (ODE), an open source

library for simulating rigid body dynamics (Smith (2007)). ODE is used to detect

collisions between elements in the environment, and to model their reaction in a

semi-realistic manner. OpenGL is used to render graphics, and SDL to monitor

input events. Libvorbis is also used to stream Ogg Vorbis audio from the hard-disk.

This combination of libraries provides an abstract, cross-platform development

base, allowing the game to build and run on a number of different platforms.

The concept of Domino Blast allowed a number of novel concepts in graphics,

physics, optimisation and game-play to be explored. Techniques such as normal-

mapping, multi-pass rendering and aggressive physics-simulation culling are ex-

plored. In addition, the question of whether a game based almost solely on phys-

ical interactions could be fun is also posed. The challenges faced and the features

implemented are covered in the following document.

1

Chapter 2

Design

2.1 Game-play

The objective in Domino Blast is to destroy the environment in the most violent

way possible. The only tool at your disposal is a controllable toy car, which can

be driven into the buildings to knock them over. Although this is a very simple

concept, the choice of how to destroy the environment can be considered very

interesting. If a player does not take into consideration how they knock over a

building, it is possible to trap or overturn your car. Each level has a target score

and time limit. Once the target score is reached, an exit is opened. This exit must

be driven through before the time-limit is reached, or the game will end, offering

you a chance to take a score penalty and continue, or to return to the title screen.

Certain restrictions are placed to prevent there from being a dominant strategy.

It will be possible for a player to press a button to give their car a sudden burst

of upwards momentum. This allows the player to free themselves if they overturn

their car or get trapped. However, using this ability imparts a score penalty,

meaning it cannot feasibly be used in any but the most desperate of situations.

The weight of the car and dominoes are also to be tuned to stop the car from

being able to drive straight through the level without becoming stuck.

Each level has a varying amount and size of buildings, meaning different strategies

must be employed depending on the environment. In levels where buildings are

taller, the player must be careful not to become trapped under rubble. In levels

with multiple buildings, the player can take into consideration that making a

building fall in a particular direction may cause a ‘domino’ effect and topple other

2

Chapter 2 Design 3

buildings. Due to the complexity of the environment, the choices and strategies

are wide and varied. The time-limit also means that these decisions must be made

in short order, adding a manic quality to the game. Strategic thinking is rewarded

by the highest score; i.e. the most violent destruction isn’t always the result of

the most violent action.

Score will be calculated by measuring the magnitude of the vector representing the

distance a block has travelled from its original position. Only the block’s highest

distance is recorded, meaning that the score can only ever increase. With this

in mind, the best game-play choices will be those that maximise the distance of

travel of the affected dominoes.

2.1.1 Influence

The design of this game is influenced by two other games; the physical block-game,

Jenga, marketed by Hasbro, and the computer game ‘Blast Corps’, developed by

Rare for the Nintendo 64 and released world-wide in 1997. To play Jenga, players

build a tower made of groups of three blocks, stacked perpendicularly in alternate

layers. Players then take turns removing blocks one-by-one, with the loser being

the person that topples the tower. The influence of this in Domino Blast is obvious;

the sensation of watching, or indeed causing a tower to fall is virtually recreated.

The primary objective of Blast Corps is to destroy buildings using an array of

vehicles. These buildings are made up of sections that once impacted at a certain

velocity will be destroyed. The idea is to use this mechanic to clear a path for

a truck carrying volatile nuclear missiles. The idea of using a vehicle to destroy

a highly-interactive environment is one present in both Blast Corps and Domino

Blast.

2.2 Environment

The game’s environment is created using standard size wooden dominoes, which

have a ratio of 2:4:1 on the x, y and z axes (see Figure 2.1). This building block is

used to create building structures that will be physically modelled. A standardised

block allows the rapid stacking of domino building levels. It enables the buildings

to be constructed randomly with a domino unit’s common dimensions.

Chapter 2 Design 4

Figure 2.1: The basic environment building block

2.3 Buildings

There are three types of domino buildings and two types of base unit, which are

depicted in figure 2.2. Initially a building was designed to be a solid structure

(see figure 2.3); but early prototyping showed it isn’t feasible to model so many

elements at an interactive frame-rate. To limit the number of dominoes in each

level, a building is assembled with four walls. Roof structures were considered

to enhance the aesthetic appeal of the buildings, although a complete cover of a

hollow building would have had to have been supported. This was undesirable;

using a domino support structure would use a high domino count.

Building type one is the weakest, it uses the least number of dominos out of the

types to create structures with the same dimensions. Building types two and three

both have a base of 4 units; type three is typically denser depending on the random

function. A building is constructed by specifying its width, depth and height. The

x, y, and z parameters allow placement of the building in a level.

Figure 2.2: Basic environment structures

Chapter 2 Design 5

Figure 2.3: A building made of solid units

2.3.1 Building Type 1

The first building structure, as shown in diagram 2.4, is constructed with the

domino unit 1. For the north and south walls it uses the same unit with a rotation

of ninety degrees around the y axis. Each level has a height of 5 units.

Figure 2.4: A type 1 building

Chapter 2 Design 6


The second building structure, as shown in diagram 2.5, is constructed using the

domino unit 2. Again, the north and south walls use the same unit with a rotation

of ninety degrees around the y axis. Each level has a height of 3 units.



The last building type uses both domino units and their rotations. Each level of

the building is randomly created with units of the same height. The unit base is 4

by 4 units. Domino unit 1 has a depth of 2 units, and therefore to allow stacking

with domino unit 2, another unit 1 is place adjacent to the first unit to create a

depth of 4 units.

2.4 Level Design

The difficultly of levels is designed to increase as they progress to encourage the

user to plan the most efficient way to demolish the building. Each level has a

time allowance and a required minimum score for game progression. There are

ten set levels, after which levels become randomly generated. The required score

Chapter 2 Design 7


will increase and time allowed will decrease with the randomly generated levels.

The first three levels introduce the user to the three different building types and

their weaknesses. A developed strategy to knock down buildings and car handling

is important to meet the later level targets. The next four levels use predefined

building dimensions and positions. After the seventh level, levels are generated

randomly using basic parameters. Generation requires the number of buildings in

rows and columns, sporadic factor a percentage that determines if a building will

be placed, and the maximum width and height of buildings. The type of building

constructed is also random. Buildings are placed in a block area. Figure 2.7 shows

top down views of levels where the row and column equals 3, with a maximum

width of 4 and height 3, and a sporadic factor of 0.25 and 0 respectively.

Figure 2.7: Example random levels

Chapter 2 Design 8

2.5 Game Engine

To implement the game design, a Linux-based development platform was chosen.

Domino Blast will take advantage of existing technology in the form of the Simple

Direct-media Layer (SDL) for input and sound, OpenGL for graphics, libmodelfile

for model loading, the Open Dynamics Engine (ODE) for physics, and libvorbis

for music streaming. Although development will take place in Linux, the use of

a cross-platform base means the game will easily be modified to compile on other

platforms, such as Windows, BSD and Solaris. The chosen language is C. All

the libraries have considerable documentation and examples for the C language,

meaning any disadvantage of its low-level nature are overruled by the availability

of information for it. C’s low-level nature means the code it produces is generally

more optimal than the equivalent code written in a higher level language. Domino

Blast’s complex nature requires the possibility of the most optimal code achievable.

Subversion has been chosen to provide revision control, allowing mistakes to easily

be corrected and the ability to wind back to a snapshot of the project at any given

time.

Chapter 3

Implementation

3.1 System Architecture

The game is implemented in two layers; one (‘Physworld ’) dealing exclusively with

the abstract concepts of a world, physics, audio, etc. and a second (Domino Blast)

that deals with the specific game logic. Using this method allows the abstract

layer (the ‘engine’) to be reused in future projects, or optimised independently of

any game that uses it. The engine layer is split further into four sections that

deal with different aspects of a game. These sections are World, Audio, Maths

and Utils (this latter section dealing with aspects that do not easily fit the other

three). The particular detail of these sections can be seen in Appendix A, and will

be elaborated on in the following sections. The game engine is tightly coupled with

the dependent libraries stated in Section 2.5, and so it is not attempted to abstract

any of the associated data-types, such as ODE worlds or spaces. A particular game

logic layer can interface with the engine via a series of procedures and customisable

call-back functions, that allow the game logic to tailor the response to particular

events.

The game logic layer is written to take advantage of the engine layer, but also

makes heavy use of OpenGL, ODE and SDL functions. Domino Blast makes use

of almost all the call-backs exported by Physworld. Time-based game logic code

is executed in the ‘step’ call-back, input is handled in the ‘loop’ callback, user

interface elements are rendered in the ‘postrender’ call-back, and so on. Certain

elements of the game are almost completely independent of the engine, however,

such as the normal-mapping, collision detection and building construction.

9

Chapter 3 Implementation 10

The Subversion commit logs can be seen in Appendix C.

3.2 Physics

The most basic model of physics using ODE involves a single ‘space’, in which is

contained multiple ‘bodies’ that consist of one or more ‘geometries’. Spaces are

just a way of grouping bodies, bodies hold parameters about an object (such as

position and linear velocity), and geometries describe the actual shape of a body

and are used for collision detection. Physworld provides a very basic collision

detection function and a global space with which it operates. As Domino Blast

requires some specific knowledge about types of collision, however, this function

is overridden. For both game-play and optimisation purposes, buildings and the

player-controlled vehicle are kept in their own specific spaces and collision detection

functions are manually called for their interactions. In this way, the car space can

collide with the building space, but collisions inside the car space can be ignored.

A separate space for buildings also reduces the amount of computation required

to find out information about the domino blocks, and their contribution to the

score.

3.2.1 Vehicle

The vehicle is simulated using four spheres for the wheels and a box for the chassis.

Due to instability in ODE’s cylinder class, the wheels cannot be represented by

cylinder objects. Despite this, the vehicle’s custom drawing call-back renders

cylinders, as few people expect to see spheres as wheels and the difference in

collision isn’t perceptible without prior knowledge. The front two wheels drive

and steer the car, while the back wheels are locked along the steering axis. Each

wheel is connected to the car via a ‘Hinge2’ joint, as shown in Figure 3.11.

The mass and centre of gravity of the vehicle are carefully tweaked so as to prevent

the vehicle from being easily toppled. During the collision call-back, if a collision

involves the vehicle, friction is lowered. This allows the vehicle to slide when turn-

ing at high speed, and prevents dominoes from ‘sticking’ to the car unrealistically.

1Figure 3.1 taken from the ODE wiki, http://opende.sourceforge.net/wiki/


Figure 3.1: An ODE ‘Hinge2’ joint

3.2.2 Optimisation

ODE has built-in optimisation for collisions. By setting thresholds for linear and

angular velocity, ODE can automatically disable bodies that have come to rest.

Unfortunately, this is nullified by the buildings in Domino Blast. When a disabled

body collides with an enabled body, the disabled body becomes enabled and its

physics are modelled. As the buildings are made of stacked dominoes, this causes

an oscillation effect that forces the dominoes to remain enabled. To overcome

this, collisions are examined in the custom callback. When a collision involving a

disabled body occurs, if the enabled body that caused the collision is below a set

threshold for linear and angular velocity, this body is disabled and the collision is

cancelled. This is also coupled with ODE’s built-in auto-disable feature to perform

aggressive culling of the physics simulation. Unfortunately, this can occasionally

lead to errors where blocks are incorrectly disabled, but the increase in performance

makes it a profitable trade-off.

3.3 Graphics

Apart from the vehicle model used, only primitive objects are used to model

the environment. Although the game’s appeal is based on the player’s physical

interactions with the world, it has been attempted to make the game visually

appealing as well. The world geometry is very simple, so aesthetic appeal is added

by careful use of lighting. Domino Blast takes place in a dark area, over an infinite

expanse of table. Lighting is provided by the head-lights of the controlled car, and


another light above the play area that provides a low level of ambient light and a

high specular light to make the car look shiny. Although the geometry is basic, the

combination of subtle lighting effects and the sheer quantity of blocks in the level

provide an understated, but elegant look. The darkness draws attention away from

the low geometry detail, where as the car’s headlights draw attention towards the

immediate, important play-area. It was decided that a third-person perspective

would be advantageous, as it allows the player a greater spatial awareness of their

surroundings (Salamin et al. (2006)). There is also a user-controllable camera to

admire the scenery (and its destruction) from an overhead perspective. Changes in

game-state (such as navigating between menus or level progression) are separated

with screen-fades. This gives a visual indication that variables are about to change,

as well as masking any stutter that might happen during loading.

3.3.1 Normal-mapping

If the graphics hardware supports multi-texturing and the DOT3 texture exten-

sion, normal-mapping is used to add artificial detail to the scene. Normal-mapping

is a technique that allows per-pixel lighting to a surface using a texture-map that

represents the normals of each point on that surface (Ambrus (2007b)). This tex-

ture stores the normals of a point by representing the magnitude of the three axes

vectors in the red, green and blue components of the image. Figure 3.2 shows a

height-map and its corresponding normal map. To aid in the creation of normal

maps, a tool was created to convert the easily-creatable height-maps to normal

maps, using the Sobel filter (Nixon and Aguado (2002)).

Figure 3.2: A height-map and its corresponding normal map

Normal mapping is usually performed using three texture units. The first texture

unit is bound to the normal map and blends normally. The second texture unit


is assigned to a cube map (a regular 3D texture). This cube map is created

once on initialisation, and holds the normal vectors of a point in the centre of

the cube pointing towards the particular cell of the cube map. The size of this

cube-map is arbitrary, although larger sizes will provide more realistic lighting.

Domino Blast uses a size of 32x32x32. The texture co-ordinates of the second

unit are assigned by the component vectors of the object-space light in texture-

space, relative to the vertex being processed. Once these two textures have been

combined, a monochrome light-map is produced that can be modulated with a

standard texture to provide lighting. This technique is elaborated on by (Astle

(2006)). Domino Blast uses a fourth texture unit in-between the light-map and

texture-map stages to apply ambient lighting by brightening the light-map. This

can also be done in a second pass using additive blending, however this is very

inefficient when there is a large amount of geometry being rendered. Figure 3.3

illustrates the difference made by using normal-mapping.

Figure 3.3: Left: Scene without normal-mapping, Right: With

3.3.2 Models

There were three main models used in the game, a domino, a low polygon car and

a high polygon car. Blender was used for modelling and exporting models to the

MD3 file format for use in-game.

The low polygon car was produced in the early stages of development to allow

refinements of mass and the centre of gravity. It enabled the environment to

be optimised and debugged without hindering performance during development,

which can be associated with high polygon models. Figure 3.4 shows the low

polygon car. The high polygon car model was sourced from the turbo squid

website (Ambrus (2007a)), see figure 3.5.


Figure 3.4: Low polygon car

Figure 3.5: High polygon car

3.4 Textures and Sounds

The dominos and ground plane are textured and normal-mapped with wood grain

textures. Menu options are depicted with traffic signs, one way and stop. They

were created using the GIMP. A selection of the textures used can be seen in

Figure 3.6.

Figure 3.6: A selection of in-game textures


The user may place audio files in the music directory to listen to in-game. A wav

file sound effect file is used for the collision between the dominos and car, and the

dominos and surface plane.

3.5 Buildings

The buildings are created modularly, with six base wall units, a spacer and top

unit. Each unit is created from a collection of rotated domino objects. Appendix

B details the plans for each unit.

Building type one is created from modules with unit base of two by four, it con-

structs the north and south wall with module one with the specified width. The

west and east walls are constructed with module two, and use one less than the

specified depth to allow for the width of the south and north wall. This stage is

built upon for each required level.

Building type two uses modules that have a unit base of four by four. It uses

width, depth and height parameters. The north and south walls are constructed

from module three, and the east and west walls from module four. This base is

built upon for each level.

Building type three uses four modules, types two, three, four and five, to construct

a level. A level has a probability of 0.5 of having a height of five and three, a regular

height for each level allows the building to be built level by level. Once the height

is determined the level is constructed randomly with a probability of 0.5 with the

two corresponding modules with the same height. Between each level there is a

0.5 probability that there will be a spacer level. A spacer level has a base of four

by four and is layered on top of a level, having a height of one unit. Each level is

then generated. Once the height has been fulfilled it has a fifty percent chance of

adding a spacer and roof level.

The building generation function produces a block of buildings, with the dimen-

sions specified by the parameters. It uses a random number to generate the width

and height of the buildings, and they are constructed row by row. It has a 75

percent chance of placing a building; this was designed to allow ease of traversal

for the toy car.


3.6 Audio

The Physworld audio layer provides theoretically infinite-channel stereo sound,

with prioritised virtual sound channels and independent left and right volume.

Mixing is done in software by manipulating the byte-stream of the audio. SDL

functions are used to convert between different sample/bit-rates. Music is streamed

from the hard-disk using libvorbisfile, leaving more RAM free for the physics sim-

ulation. Music is given a higher priority than other sounds so as not to be inter-

rupted when many sounds are played at once and the channels become saturated.

Domino Blast uses sound for all collisions. Their volume is determined by cal-

culating the magnitude of the vector between the collision and the car. Using

Physworld’s music capabilities, the game provides the option to play all compati-

ble music files in a specified directory on start-up.

3.7 Interaction

Interaction with the game environment happens via the controllable toy car. The

car has a modest acceleration and very low centre of gravity, to avoid overturning

too easily. Physics are tweaked to allow the car to skid slightly, providing a more

believable driving experience. Building blocks can be moved by ramming the car

into them, however, a player must be careful when demolishing a building, as it

is possible to overturn the vehicle, or worse, become trapped. In these situations,

a ‘jump’ action is possible that gives the car a pre-determined linear and angular

velocity that should set it on its wheels. As discussed previously, using this action

impacts a score penalty, so it is not possible to use the jump strategically to

increase the score.

Input is handled by responding directly to SDL events in the Physworld ‘loop’

call-back. The car is controlled by the arrow keys, and jump is bound to the

space-bar. The player is given the option of detaching the camera from the car

and placing it manually using the classic w/a/s/d for controlling strafing and the

mouse to control the viewing direction. Although the controls are hard-coded,

this could easily be changed. The player can quit the game at any time by either

navigating to the title menu and choosing the quit option, pressing the escape key

or closing the window.


3.8 User Interface

Menu choices are visually represented with domino towers; to select an option the

player moves the car into the desired tower. There are two game menus, the first

allows the player to start a game or quit, the second enables you to retry a failed

level or return to the first menu. The menu system was designed to enhance game

immersion, the player can adjust to the movement of the car before the game

starts. It enables continuity between the levels and menus, creating a seamless

interaction.

Chapter 4

Evaluation

The greatest technical challenge was the optimisation of the physics modelling.

ODE is used to simulate the physics in the environment, however it is resource

intensive when simulating more than a handful of bodies. Various optimisations

have been employed to create a real-time game play experience. ODE provides a

basic auto-disable feature for inactive bodies, but in its current form, this doesn’t

work for stacked objects. A naive complimenting optimisation was added that culls

collisions by disabling slow-moving bodies that collide with other static, disabled

bodies. Although this occasionally results in visible errors, it allows buildings

consisting of hundreds of blocks to be simulated. In addition, important structures

are separated into separate spaces to reduce the computation involved in retrieving

data derived from their collisions.

To create an aesthetically pleasing environment normal mapping of textures has

been used to create more realistic-looking surfaces. The grains of the wooden

textures are more apparent, creating a tactile feel to the dominoes and table. A

normal map tool was created to generate the normal maps used in the game, based

on images with a small amount of manual pre-processing. The car model was ex-

ported from Blender; its curves and size emulates the shape of a toy car. This was

to reinforce the game theme of children’s toys. The in-game menu interface en-

hances game immersion and continuity, allowing the user to become more familiar

with the control, even when they aren’t explicitly playing the game.

The buildings in the environment are generated randomly with building and city

block functions, using a standard domino size. To minimise the number of blocks,

18

Chapter 4 Evaluation 19

each building is constructed of four walls. There are three different types of build-

ings, this allows the cityscape to be varied, creating different types of levels re-

quiring alternate strategies.

Game-play is based on a time based score system. Each level has a target score

that needs to be acquired to progress to the next level. The level progression

is designed to allow the player to adapt their tactics used to demolish buildings.

The player will have to consider the most time-efficient way to pull down buildings

while planning an escape route to the exit when the target score has been reached.

Screen-shots of the final game can be seen in Appendix D.

4.1 Future Work

Domino Blast is the result of a short, but concentrated period of development.

The resulting game is accomplished and fun to play, but given more time, many of

its aspects could have been improved or expanded upon. For example, although

a fully-featured sound sub-system was developed, the audio component of the

game remains relatively undeveloped. Future developments include adding more,

and more varied sound events. Sounds such as engine noise, tyres screeching and

more realistic collision noises would easily be possible with more development

time. Using a library such as OpenAL1, it may even be trivial to replace the

Physworld sound sub-system and augment the engine with 3D sound capability.

Game controls are similarly under-developed and could easily be improved, by

adding support for key configuration and joy-pad input.

Further research and work into physics optimisation may have given the ability

to create larger buildings, or even whole villages. Although much effort was put

into optimisation, it is possible that world-partitioning techniques such as oct-tree

may have allowed rapid determination of large areas of inactive bodies. ODE is

a relatively undeveloped library when compared to its commercial alternatives,

however; it is entirely possible that future versions will make Domino Blast run

much faster without any code changes. The game dynamics would be significantly

changed (and perhaps improved) if thousands of blocks could be modelled, instead

of the current hundreds.

Finally, the core game-play of Domino Blast could be developed further. Taking

the example of Blast Corps (see Section 2.1.1), level objectives could be added and

1http://www.openal.org/, accessed 11/06/07

Chapter 4 Evaluation 20

other active members could be included in the environment. These could include

computer-controlled cars that are trying to demolish the same building, or trapped

people waiting to be rescued. A simple game mechanic that could easily be added

without changing much infrastructure would be special buildings that must remain

unscathed, adding another element of strategy to the game proceedings. There

is much room for expansion and improvement, however, given the time, Domino

Blast is a very accomplished game.

Bibliography

Adam Ambrus. TurboSquid - 350z-v2.zip. http://www.turbosquid.com/FullPreview/

Index.cfm/ID/328237, 2007a.

Anthony Ambrus. Real-time approximations of the rendering equation. Technical

report, 2007b.

Dave Astle. More OpenGL Game Programming. Thomson Course Technology,

2006.

Mark Nixon and Alberto Aguado. Feature Extraction & Image Processing. Newnes,

2002.

Patrick Salamin, Daniel Thalmann, and Frdric Vexo. The benefits of third-person

perspective in virtual and augmented reality? In ACM symposium on Virtual

reality software and technology, pages 27–30, 2006.

Russell Smith. Open Dynamics Engine. http://www.ode.org/, 2007.

21

Appendix A - Physworld

Arhitecture Diagram

Figure 1: Physworld Architecture overview

22

Appendix B - Building Modules

Figure 2: Building Modules

23

Appendix C - Subversion commit

logs

r44 — (cwiiis) — 2007-06-11 14:18:42 +0100 (Mon, 11 Jun 2007) — 2 lines

- Don’t draw a mesh for the plane when using per-pixel lighting


- Fix level exiting bug where the car would have to clear the exit area

- Stop count-down after exiting (can finish a level with 1 second left)

- Do ambient lighting in a single pass (massive speed up)

r42 — (heather) — 2007-06-11 03:10:58 +0100 (Mon, 11 Jun 2007) — 2 lines

Level scoring and time adjusted


- Add in-game menus (navigated by knocking down buildings)

- Add road-signs for menus

- Add level progression

- Make car a little skiddier and give it stronger brakes

- Add screen fades between state transitions

- Display score/total score/level time a bit nicer

- Make chase-cam a bit less prone to getting caught in the ground

- Various small hacks to get things working

r40 — (heather) — 2007-06-10 19:19:14 +0100 (Sun, 10 Jun 2007) — 2 lines

Level targets added, scores and times

r39 — (cwiiis) — 2007-06-10 16:11:47 +0100 (Sun, 10 Jun 2007) — 3 lines

- Add functions to Physworld to get the object/light lists

- Add a function to reset the world (destroy dominos, reset car)


- Tweak car model (fix wing-mirrors, export at a larger size)

24

Appendix Appendix C - Subversion commit logs 25

- Colour the car model nicely when rendering

- Tweak lighting a little

- Improve car handling (can skid slightly, turn sharper, more powerful engine)

- Add a function to set car orientation

- Split phys md3 draw into model and mesh drawing functions


- Add car model

- Replace phys object get [inverse ]matrix with generic functions to get

the matrix or inverse transform matrix from a position/rotation - Enable vertex

arrays before trying to use them with draw md3 function

- Temporarily disable md3 texture-mapping


- Allow buildings to be put in separate spaces

- Take a dSpaceID parameter when creating a domino

- Inline matrix transform and dot product functions

- Add a new ’quit’ callback that gets called on exit (to free data)

- Call collision callbacks in the physics callback (including car)

- Free most data on exit

- Add score calculation

r35 — (cwiiis) — 2007-06-09 21:08:24 +0100 (Sat, 09 Jun 2007) — 4 lines

- Make sure collisions involving the car *always* happen

- Make disabling optimisation only disable for actual collisions, not

potential ones


- Add callback function for physics steps

- Make the near callback customisable

- Add a ’right’ button (needs some work)

- Add a body-disabling optimisation (needs some major tweaking..)

- Use multi-pass rendering when bump-mapping to allow multiple lights

(only the first light is used for normal-mapping)

r33 — (heather) — 2007-06-09 18:35:23 +0100 (Sat, 09 Jun 2007) — 2 lines

Added two new types of buildings


City generation function added, fixed unit structure 3



- Fix inverse transform matrix functions (+remove hack to fix normal mapping)


- Stabilise car (much lower centre of gravity, heavier)

- Add chase-cam for car

- Add a camera call-back function

- Make camera operations matrix-oriented (as opposed to position+Euler)

- Fix normal-mapping on dominos, enable when supported (bit of a hack)

- Add more maths functions

- Fix buildings header


Building position added


Static variables added

r27 — (heather) — 2007-06-08 20:13:36 +0100 (Fri, 08 Jun 2007) — 2 lines

Update buildings code again

r26 — (heather) — 2007-06-08 18:59:15 +0100 (Fri, 08 Jun 2007) — 2 lines

Update buildings code

r25 — (cwiiis) — 2007-06-08 18:47:41 +0100 (Fri, 08 Jun 2007) — 4 lines

- Adjust default density of domino blocks

- Add more vector maths functions

- Fix vehicle (4 wheels, now works correctly) - needs adjustment

r24 — (cwiiis) — 2007-06-08 04:14:43 +0100 (Fri, 08 Jun 2007) — 6 lines

- Remove unused files

- Split out some testing functions from the main file

- Add #ifndef foo around buildings.h

- Call behaviour callbacks on objects during physics simulation

- Add some very preliminary, very broken vehicle code

r23 — (cwiiis) — 2007-06-07 22:15:22 +0100 (Thu, 07 Jun 2007) — 4 lines

- Correct winding order and enable back-face culling

- Add normal-mapping for dominos (disabled, not working correctly?)

- Fix up warnings in buildings.c


r22 — (heather) — 2007-06-07 17:04:23 +0100 (Thu, 07 Jun 2007) — 2 lines

Building block structures added


- Add get matrix / get inverse matrix utilities for PhysworldObject

- Textured dominos


- Allow for arbitrary amount of geometries per body (uses a linked list)

r19 — (heather) — 2007-06-07 00:06:19 +0100 (Thu, 07 Jun 2007) — 2 lines

Started adding building unit structures + jointed roof code

r18 — (cwiiis) — 2007-06-06 23:01:54 +0100 (Wed, 06 Jun 2007) — 4 lines

- Turn off specular by default, re-instate old cube-drawing code

(nothing wrong with it)

- Do normal-mapping in a single pass


- Fix normal-mapping (swapped y/z axis, thanks Tony!)

- Default to zero shininess on object material properties

- Domino blocks are still lit incorrectly(?)


- Add y-axis movement going forwards/backwards


- Lighten some textures

- Use additive blending so we can see the floor until the lighting /

normal-mappingis fixed properly

- Add some basic movement code to make debugging easier (wasd+mouse)


- Fix normal mapping for ground surface

- Fix cuboid drawing (incorrect normals, just rewritten)

- Change default light settings to GL defaults


- Remove generated file

- Add phys maths.[ch] with basic vector/matrix stuff


- Add height maps and normal maps for all wood textures

- First run at normal-mapping (not 100% I don’t think?)

r12 — (cwiiis) — 2007-06-05 19:55:52 +0100 (Tue, 05 Jun 2007) — 2 lines

Check in missing files


Remove generated files


Fix memory leaks in height2normal utility


Add tool to convert height-maps to normal-maps (requires GTK)

r8 — (heather) — 2007-06-04 03:13:06 +0100 (Mon, 04 Jun 2007) — 2 lines

Initial check-in of buildings code (in progress)


- Modify default light settings to be a bit more useful

- Draw infinite plane in segments to allow for smooth lighting


Remove spurious Makefile.in

r5 — (cwiiis) — 2007-06-03 20:10:33 +0100 (Sun, 03 Jun 2007) — 1 line

Create global data structure for game, add infinite plane-drawing function


- Add domino creation function

- Make collisions act more domino-like

- Add tasks to TODO list


Changing AUTHORS file (test commit)


Initial check-in


Add directory for final IES project

Appendix D - Screenshots

29

Documents

Faculty of Engineering, Science and Mathematics …chrislord.net/files/ies.pdfA project report submitted for the award of MEng Computer Science ... Building type one is the weakest,