oisin a. conolly - physics and novelty in computer games

8/7/2019 Oisin A. Conolly - Physics and Novelty in Computer Games

http://slidepdf.com/reader/full/oisin-a-conolly-physics-and-novelty-in-computer-games 1/36

PHYSICS AND NOVELTY IN

COMPUTER GAMESOisin Akiboye Conolly

BSc in Computer Science

11 May 2010

SCHOOL OF COMPUTING AND MATHEMATICS

Keele University

Keele

Staffordshire

ST5 5BG



1

Abstract

The aim of this project was to follow an iterative development process which would

arrive at the production of a fun and novel new game using experimental characters,while also providing the basic knowledge required to create a game using physics

simulation.

Through the use of the Open Dynamics Engine, the Wiiyourself library and

Nintendo’s Wii controller, a sandbox type game demo was created in which the user

controls a small selection of characters to navigate and interact with a world which

displays real-time physics simulation.

Ultimately the experimental characters produced in this game demo, while being

novel and interesting to control, were deemed too in-practical to create a proper game

from. However one of the characters was deemed a success and so the game demo

revolves around this not so novel character. With further experimentation using the

Wii controller and the endless possibilities it provides, a different novel game could

be arrived at in the future.



2

Acknowledgements

I would like to thank my supervisor, Dr. Alastair Channon for all the support he

provided and for helping me find solutions to some very difficult problems. I wouldalso like to thank Tess Piper for moral support, and for providing the Wii controller

used to develop this project.



3

Contents

1. INTRODUCTION.................................................................................................... 4

1.1 BACKGROUND....................................................................................................... 4

2. INITIAL PROJECT SPECIFICATIONS AND FEASIBILITY ......................... 6

2.1 INITIAL PROJECT SPECIFICATIONS ......................................................................... 6

2.2 PROJECT FEASIBILITY ........................................................................................... 7

3. REQUIREMENTS ................................................................................................... 9

3.1 REQUIREMENT ...................................................................................................... 9

4. INCREMENTS ...................................................................................................... 11

4.1 INCREMENTS PLAN.............................................................................................. 114.2 INITIAL PROTOTYPE ............................................................................................ 12

4.3 1ST

INCREMENT ................................................................................................. 12

4.4 2ND

INCREMENT ................................................................................................. 16

4.5 3RD

INCREMENT ................................................................................................. 17

4.6 4TH

INCREMENT ................................................................................................. 19

4.7 5TH

INCREMENT ................................................................................................. 21

4.8 6TH

INCREMENT ................................................................................................. 22

4.9 7TH

INCREMENT ................................................................................................. 26

5. FINAL TESTING .................................................................................................. 27

5.1 BUGS................................................................................................................... 27

6. EVALUATION ...................................................................................................... 28

7. CONCLUSION AND FUTURE WORK ............................................................. 29

7.1 FUTURE WORK.................................................................................................... 29

REFERENCES ........................................................................................................... 31

BIBLIOGRAPHY ...................................................................................................... 32

APPENDIX A: TIME PLAN .................................................................................... 33



4

Chapter 1

Introduction

The gaming industry has become a saturated market, with thousands of individuals,

groups, small and large commercial companies all competing with each other for the

attention of the gaming community. A large amount of games are created every year

however we rarely hear about or see most of these games. The games that usually

don’t make it are the ones that are simply recycling ideas; re-inventing the wheel

essentially.

Thus the only way to make an impact or impression is to have an aspect of novelty in

a game. This can be anything from an impressive use of graphics, to a new and

interesting game concept or a novel control system, the latter combination being the

aim of this project.

This project ultimately aims to be an introduction to the world of game programming,

while exploring novel possibilities which could be used to penetrate the gaming

industry and make an impact. Fundamentally I am trying to achieve something that

has not been seen before. The actual objective is to create a game demo, using a

physics simulator, that displays a certain aspect of novelty.

1.1 Background

Physics Simulation in Games

Physics simulation has become part of almost every game created these days. It could

be something simple like collision detection with gravity in a platformer game, or a

full blown fluid, rigid and soft-body dynamics simulation used in a first-person

shooter. A physics simulator will typically re-create the interactions between objects

one would expect to see in the real world. For rigid body dynamics this could include

simulation of joints (like hinges), contact and collision, friction, gravity etc., while for

fluid dynamics this could be wave simulation, liquids streaming down surfaces and

collision and splashing etc.

Nintendo Wii Controller

Nintendo’s Wii controller (Figure 1) is a revolutionary approach to gaming, allowing

the user more freedom of expression and control within games than standard

controllers. It resembles a standard TV remote but has the buttons and features of a

typical control pad; a direction pad, trigger button, rumble feedback etc. This

controller has become the catalyst for many innovative game concepts seen over the

last couple of years since its release, and is quite often the main source of novelty in

games made for the Wii.



5

The Wii controller incorporates wireless Bluetooth connectivity, a 3-axis

accelerometer for motion-sensing, an optical sensor to determine where the Wii

remote is pointing (requiring an IR Sensor Bar), a 4 direction D-pad, 7 other buttons,

basic audio functionality, and rumble functionality all into a single controller. As well

as this there is an expansion port to connect other devices for increased functionality.

The Nunchuk extension (Figure 2) brings added functionality to the Wii controller as

a whole. It features the same accelerometer as the Wii remote to track movement, and

has an analogue stick, C button and a Z trigger button.

Figure 1: Wii remote

Figure 2: Nunchuk extension



6

Chapter 2

Initial Project Specifications and

Feasibility

2.1 Initial Project Specifications

At the start of this project the initial project specification was decided upon, that is

what the main objective of this project is. This was just a rough idea, leaving plenty of

room for refinement as the project progressed. The whole idea was to create a game

demo where the user can control a character or multiple characters, and explore a

world while interacting with objects in a realistic way. The game demo had to use a

physics engine to realistically simulate real-world physics, and there was the

possibility of incorporating artificial intelligence as well. Essentially a fun and novel

game was what was being sought after in this project.

Due to the nature of this project it was decided that a mixture of incremental and

iterative development would be used. The idea behind incremental development is to

break the work down into smaller pieces, or increments, which are scheduled to be

developed over time and integrated into the whole system once they are completed.

Iterative development then is a strategy in which time is set aside to revise and refine

the various existing parts of the system (Cockburn, 2008).

Figure 3: The incremental development process



7

Using a mixture of these two processes in this project resulted in the integration of

new elements at each increment of the system. At the same time with each increment

came the refinement of existing elements from previous increments.

This strategy of mixing incremental with iterative development works well with

projects such as this one. It allows a learning programmer to take advantage of the

knowledge gained through the development of previous increments, as well as

ongoing research, and to then apply this knowledge to refine the system as a whole.

2.2 Project Feasibility

The overall feasibility of this project was assessed, focusing on two main aspects:

Technically feasible – Is all the technology required available? Will it be

possible to learn what is needed to use that technology?

Time-wise feasible – Is it possible to complete the proposed project within thetime limitations?

Technical Feasibility

Programming a game requires certain different technologies, and the knowledge to

use them. Research concluded that all the necessary technology for this project was

easily available, and the learning curve involved with each was not too steep.

Open Dynamics Engine (ODE) became the engine of choice for the physics

simulation. ODE is an open source, well documented and free library making it an

excellent choice for this project. This high performance library is designed forsimulating rigid body dynamics in real-time, featuring advanced joint types and built

in collision detection with friction.

The library has several advantages over other freely available physics engines. Firstly

it is very stable even while trading off accuracy for speed. It is written in C++ with a

C interface provided for cross compatibility between the two languages. On top of this

there are bindings for many other programming languages, a few being Delphi, .NET,

Python, and Java. It can be compiled to run on various systems such as Linux, Mac

OS, and Windows, as well as consoles such as Sony’s PS2 and Microsoft’s Xbox, and

the source code is provided allowing the engine to be customised according to theneeds of the system it is being used in. All of these characteristics of ODE provided a

great deal of freedom in this project, making it possible to....

For the rendering of graphics to the screen, Drawstuff was decided to be the best

option. This library comes integrated with ODE and provides simple graphics as well

as handling mouse and keyboard input. It uses openGL to render, in a window, a 3D

visualisation of the dimensions and positions of the objects used as the simulation

progresses. It supports simple shadow projection, RGB shading, and textures.

However in order to use different textures from the ones supplied requires editing of



8

the source code. As the main focus of this project is not on graphics, this option was

the most viable to use given the short development time available for this project.

As ODE was written in C++ it was decided for simplicity to stick with this language

and write the whole game in C++. This was done despite the fact that all previous

programming experience was with Java. While there are bindings available for ODE

and java, it is a significantly slower language compared to C++ when used for game

programming, especially when it comes to graphics (Davison, 2005). This is mainly

due to features of the language such as Java’s garbage collector and the way in which

objects are handled.

C++ was designed to support data abstraction, object-oriented programming

(Stroustrup, 1985), and generic programming in addition to traditional C

programming techniques, making it a very versatile language for a large array of

different programming uses. As a result C++ has become one of the leading

programming languages in the gaming industry, where a single program will often

need to cover several areas, such as graphics, audio and controller input, at different

levels of abstraction.

C++ is a very large language, and it can take a long time to become proficient in it.

However it was decided that it was perfectly feasible to learn this new language for

this project there are a lot of similarities between Java and C++ which would

ultimately help the learning process along. In addition to this the programming

practices learned over the course of University, while being aimed at Java, are largely

applicable to C++, and there is a large community which writes libraries and providessupports for this language. This makes it very easy to find a solution to almost any

problem which potentially could be encountered during the coding of this project.

Microsoft’s Visual C++ 2008 express edition was the integrated development

environment (IDE) proposed for the coding of this project, being the most commonly

used and documented free IDE available at the time of this project.

Time Feasibility

Certain aspects which were desired, but not important were left out in order to assure

the completion of this project in the time frame. Artificial intelligence, audio, and the

use of a self written openGL library or DirectX for graphics were cut from the projectplan. With these aspects gone, the project was deemed to be within capabilities.



10

c. The car needs to be stable enough to go over ramps and other collision

geometry without toppling.

d. The car needs to be stable while turning sharply.

e. If the car becomes stuck then it must be able to be reset.

2. Experimental Character 1: Bug

a. Movement is brought about by 4 legsb. Legs must be able to move up and down, forward and back

3. Experimental Character 2: Ball

a. Movement is administered by an array of pistons surrounding a sphere

b. The pistons must be arranged radially around the sphere, with

movement along this single axis.

c. Pistons must retract after being fired

d. User must be able to select which pistons to fire

Environment Requirements

1. Static geometry must be present for the characters to navigate around

a. This could be ramps, walls, floors and ceilings making up a level forthe character to move over and collide with.

2. Dynamic geometry must be present for the characters to interact with

a. This could be balls for the character to push around, or walls composed

of bricks that the character can smash through



11

Chapter 4

Increments

4.1 Increments Plan

The proposed game was broken down into several increments which guided the

project through its development. Each increment had a set of requirements which had

to be reached before the next increment could be started. These increments were open

to changes to account for issues found in previous increments or new things which

were learned from the ongoing research. At the end of each increment a working

prototype was produced. Testing was carried out on this prototype to make sure the

requirements were being met and to identify functions and functionality which shouldbe added or refined in the next increment. The increments had rough due dates fitting

into the time plan (see Appendix A: Time Plan, page: 33), though it was hard to

predict how long a certain increment would take or what extra increments might be

needed so these were expected to change.

Prototype Week Due Objective

Initial Prototype Autumn

Semester –

Week 8

Integrate the physics simulation, graphics

rendering, and input capturing together into one

whole system. Create a simple environment composed of static and dynamic geometry with this

system.

1st

Increment Autumn

Semester -

Week 11

Create the basis for the characters – comprised of

bodies and joints, but with no functionality.

2nd

Increment Spring

Semester -

Week 2

Add motor functions to allow the characters to

move, and use keyboard input to control the

characters

3rd

Increment Spring

Semester –

Week 5

Add ‘simulation reset’ capability to the system.

Integrate a simple camera system that follows the

characters around.

4th

Increment Spring

Semester –

Week 8

Create levels for the characters to explore and

interact with.

Figure 4: Prototype Plan



12

4.2 Initial Prototype

The beginnings of the game were created at this stage. ODE and Drawstuff were

integrated in a new project in the IDE, and the necessary steps required in carrying out

physics simulation, input capturing and graphics rendering were coded. These steps

were:

1. Create a dynamics world and a joint group to hold the contact joints.

2. Create dynamics bodies, joints and collision geometry (called geoms) in the

dynamics world.

3. Simulation Loop:

a. Capture input keyboard and change variables accordingly.

b. Apply forces to the bodies and modify joint properties.

c. Call collision detection.

d. Create a contact joint for every collision point, and put it in the contact

joint group.

e. Take a simulation step.f. Render objects on the screen in their new positions.

g. Remove all joints in the contact joint group.

4. Destroy the dynamics and collision worlds, and close ODE.

A simple world was created with a static box object, and a dynamic sphere object

which dropped and rolled around the environment. This tested object creation and

collision in the system, as well as graphics rendering. Keyboard input was tested by

using the ‘+’ and ‘-‘ keys to increase/decrease gravity in the simulation. The system

was ready to move onto the first increment.

4.3 1st

Increment

To cut down on the amount of duplicated code involved in creating the characters,

two custom classes were created: ODESimulationObject and ODECreature.

ODESimulationObject Class

This class encapsulates the process behind creating and rendering primitive objects(boxes, cylinders, spheres etc.) in ODE along with that object’s attributes. The class

handles:

Adding a body for dynamics

Storing collision geometry

Giving the body a uniformly distributed mass of one of two types (spheremass and box mass)

Setting the body position

Connecting the stored geom to the body

Rendering the geom In its current position



13

The collision geometry is created in the main program using ODE’s internal functions,

and then assigned to the class’ geom variable (Figure 5 for example), as is the mass of

the associated body.

ODESimulationObject.geom = dCreateBox(space, x, y, z);

Figure 5: creating a box

Rendering of these primitive objects is handled by the class in a function called

drawSelf(). This function first determines which type of geom has been stored,

then in a switch statement it gets the dimensions particular to that object type (for

example a rendering a box requires the lengths, while a sphere requires the radius),

the position and rotation of the geom, and then the appropriate Drawstuff function is

called to render the object. Drawstuff has an internal drawing function for each of theprimitive types which can be created in ODE, simplifying the rendering process down

to a single function call.

ODECreature Class

This class brings a hierarchical aspect to the design of the user controlled characters.

An ODECreature is a collection of parts (ODESimulationObjects), and Joints which

work together as one whole object. Dynamic arrays contain the different parts and

joints of the creature, with the total number of each stored to facilitate iterationthrough these parts. The class allows the entire creature’s position to be translated via

the function changePosition(x, y, z). This function iterates through the

ODESimulationObjects, moving them to the x,y,z position passed as arguments while

maintaining their positions in relation to each other.

Building the Characters

With the classes in place the characters could now be created as single objects with

attributes and useful functions associated with them. The 1st

character, the car, was

coded using one of ODE’s included demos as a basis. This was a 3 wheeled buggy

which had a rectangle for the body and subsections of spheres as wheels. The design

was changed to a 4 wheeled car to provide better stability. The body of the car

remained a rectangle, while the wheels were constructed as cylinders attached with

hinge-2 joints (see Figure 6 ). The front wheels able to rotate around both axes to

allow for steering of the car, while the rear wheels had axis-1 locked in place.



14

Construction of the experimental bug character (Figure 7 ) was straightforward.

Rectangles made up the body and arms. The arms had two sections; the first was fixed

to the body, while the second section was the part that moves. The joints used here

were universal joints which act on 2 axes only (Figure 8).

The experimental ball creature was significantly more troublesome to construct than

the others, requiring a lot of thought and mathematics to create with ODE. The pistons

(capped cylinders) firstly had to be arranged on the surface of the sphere radially, and

then they had to be rotated such that they were all perpendicular to the surface.

Figure 8: A Universal joint Figure 7: Bug Creature

Figure 6: A Hinge-2 joint



15

The pistons were arranged around the x,y and z axes in 45 degree increments. The x,y

coordinates for these positions were found using the formulas Cosθ = x, Sinθ = y

which were derived from the Unit Circle.

These x and y values were then also used to create a rotation matrix, using Eulerangles, which was used to rotate the pistons to their appropriate positions. All of this

was put into two different ‘for’ loops:

1. Firstly covering the sphere with 8 pistons around the z axis (Figure 11)

2. Then adding a further 6 around the y axis, skipping the two pistons already

present from the z axis.

= ℎ

= =

=

ℎ =

=

Figure 10: Derived formulae

Figure 9: Unit Circle



16

The pistons were attached using slider joints. The advantage of these joints was that

all movement was limited to be along one axis. This axis was set using ODE’s

dJointSetSliderAxis() function which took the same x,y,z values used to set

the position of each piston around the sphere.

Prototype Testing

Testing of the prototype produced from this increment showed that the pistons of the

ball creature would slide along their joint to infinity, or until they collided with

something. This would need to be limited to a certain range in the next increment.

4.4 2nd

Increment

In this increment motor functions and key bindings were created to provide a way to

move the characters created in the previous increment. There are two steps involved

in moving a creature. Firstly a key press is captured from the keyboard and used to

change a variable such as speed or turning factor. This variable is then used by a

motor function to apply forces to bodies or to modify joint properties.

For the car, the demo from which it was based also provided code which allowed the

car to be steered and to move forward/backwards. Here, steering is carried out by

applying a velocity to the joint of the front wheels until the difference between the

desired angle and the joint angle is zero. Forward and backward motion is then done

by directly applying a velocity to the hinges of the back wheels.

A similar system was applied to the bug creature. To move the legs

up/down/forward/back, a positive or negative velocity is applied to the appropriate

axis of the joint until the difference between the desired angle and the joint angle iszero.

for(i=0; i<8; i++){

int angle = i*45;dReal x = cos(angle*PI/180)*ballRadius;dReal y = sin(angle*PI/180)*ballRadius;

dReal z = 0;ball.parts[i].setPosition(x,y,z);

//rotate pistonsdReal yaw = (90*PI/180);dReal pitch = ((90+angle)*PI/180);dReal rotation = 0;dRFromEulerAngles (R,yaw,pitch,rotation);dBodySetRotation (ball.parts[i].body, R);

}Figure 11: arranging pistons around a sphere



17

For the ball creature there are two stages involved in the motor function; the piston

must first be fired outwards, using the function dJointAddSliderForce() and

Lo/Hi stops to prevent it from going too far, and then it must be retracted. This is

done in the same way as the firing of the piston except with a negative force.

Prototype Testing

At the end of this increment the prototype produced was tested, resulting in the

conclusion that the ball character needed more pistons to provide better coverage over

the surface. A new control system would also be needed as it was impossible to

organise the firing of 14 pistons individually. It was also found that the force exerted

outwards by firing a piston would cause the whole body to move in a realistic but

undesired way. This would need to be fixed in the following increment.

Furthermore it was decided that a new type of control input would be sought after;

control via a keyboard was limited and not very fun or intuitive, especially with the

bindings for the experimental creatures. A small amount of research into controllers

resulted in the discovery of wiimote libraries which permit the use of a Nintendo Wii

controller (or Wiimote) with a computer. Following a little more research into the

feasibility of incorporating the Wii controller into this project, it was decided to

implement it in an extra increment of the system.

4.5 3rd

Increment

In this increment Nintendo’s Wii controller was integrated as a human input device

(HID) for the system. Integration of the Wii controller was no easy task, and took a

significant amount of research to achieve and to solve all issues encountered.

Bluetooth Protocol Stacks

As the Wii remote is not intended for use with windows there are understandably

issues with coupling it via Bluetooth. Certain combinations of Bluetooth Device and

Bluetooth protocol stack will work, while others will fail partially if not fully. During

the integration of the Wii Controller various different stacks were tested. Glovepie

(Kenner, 2010), short for Glove Programmable Input Emulator, was used to test basicfunctionality while doing this.

Contrary to the retailer’s description, the Bluetooth device purchased for this project

was identified it to be a Cambridge Silicon Radio device. This device was listed as

‘working’ on the WiiBrew website (WiiBrew, 2010) and was allegedly compatible

with ITV’s Bluesoleil Bluetooth stack. This stack was the most documented and

recommended stack found while researching the connecting of a Wii remote to a PC.

However using the Bluesoleil stack resulted in a connection where only the vibration

and led display on the Wii remote would work. All other functionality didn’t appear



18

to be translating. This was put this down to a hardware incompatibility as this stack

was subsequently tested with a Laptop’s integrated Bluetooth with complete success.

Several different stacks were tested in total. Some installed without problems, while

others required workarounds using unsigned drivers in order to work with the

Bluetooth device. The Microsoft stack was finally used for this project as it was the

only successful Bluetooth stack tested (Note: the project was also occasionally

developed using a Laptop with a different Bluetooth device, in which case the

Widcomm stack was used as it provided full functionality with the Wii remote).

Bluetooth

Stack

Result

Bluesoleil stack Wii remote connected as a HID with limited functionality;

vibration and LED display.

Widcomm Wii remote connected as a HID. No functionality displayed.

Toshiba Would not recognise the Wii remote as a HID

Microsoft Wii remote connected as a HID. All features fully functional.

Figure 12 Bluetooth stack testing

Wii Remote and C++

There are several C and C++ libraries available to connect one or more Wii remotes

and to send and receive data from them. These libraries provide an applicationprogramming interface (API) making them easy to incorporate into a system with

little effort or understanding about how the data sent from the Wii remote is encoded.

Wiim (Boyd, n.d.)

o A simple set of C++ classes allowing the sending and receiving of

commands through Windows' HID interface. Capabilities are limited to

receiving button presses and motion data as well as the ability to set

rumble and LED status. There's no support for IR or any extension

devices yet.

Wiiuse (Laforest, 2009)

o A library written in C that connects with several Nintendo Wii

remotes. Supports motion sensing, IR tracking, nunchuk extension,

classic controller, and the Guitar Hero 3 controller. Single threaded and

nonblocking makes it a light weight and clean API.

Of the two libraries found, the Wiiuse library was the API used due to its full list of

support. With this library the Wii remote was polled every iteration of the simulation

loop. This checked if any buttons had been pressed or if any acceleration data was

sent from the remote. If so then appropriate functions were called or variables were

changed to handle the different cases.



19

A control system was created for the car where the Wiimote was held horizontally

with the D-Pad under the left hand, and the 1,2 buttons under the right hand. Tilting

the Wii remote left and right steered the car while the 1 and 2 buttons were for

forward and reverse. Bindings for the bug character were created similarly, where

tilting the Will remote forward/back moved the bugs legs forwards/backwards. TheD-Pad and 1 and 2 buttons were used to move the legs up/down.

Also in this increment the ball creature was refined. Another 4 pistons were added to

the ball creature, bringing the total to 18 which provided greater control over the

direction of the creature’s movement. Also the issue highlighted in the previous

increment about the effect firing pistons had on the creature was fixed by increasing

the main body’s mass and decreasing each of the pistons masses, thus decreasing the

effect of the momentum of the pistons on the body to a negligible amount.

The 18 pistons were grouped into 3 groups of 6 and several different methods of

control were created for testing. These methods of control included different ways of

selecting a group (button to select a group, or different orientations of the controller),

and different ways to fire the pistons (a button press, or shaking the remote to fire the

selected group).

Prototype Testing

It was found that the speed of the whole simulation had become jerky due to the

addition of the Wii controller polling in the main simulation loop.

Also 6 groups of 3 pistons for the ball character was still too difficult to control; there

were too many buttons needed to make the selections and this was not easy to map to

the wii controller. Also the ‘select then fire’ method was unintuitive and slow to use.

4.6 4th

Increment

Wiiuse’s help document suggested a solution to the jerkiness found with the library

when used in a single thread which was to switch to continuous polling mode. While

this strongly alleviated the issue, it also resulted in a noticeable delay in the creation

of events captured from button presses and from movement of the Wii remote.

This prompted the search for a new library, which arrived at Wiiyourself (Gl.tter,

2010); a fully-featured native C++ library for Windows with support for all

extensions available to the Wii remote. Upon successful integration into the main

program it became apparent that Wiiyourself was a significantly more stable library.

Feedback was instant and had no visible impact on the speed of the simulation. This

was due to the fact that the library implements threading and runs separately from the

main program. It was also easier to code with as the library was written in C++ and

integration simply required the addition of a .cpp and a header file. Wiiuse on the

other hand was written in C and integration required dynamically linked libraries

(DLL) to be built and added to the project, a cumbersome task for a programmerlearning how to use C++. The library itself also provides wider compatibility with



20

different Bluetooth stacks, and supports more of the Wii controller’s functions than

any other library found during the research in this area making it overall the best

choice.

Firstly a callback function is set to notify us when the status of the Wii remote

changes (if an extension was added/removed, and what the extension was).

wiicontroller.ChangedCallback = on_state_change;

Figure 13: wiimote callback function

Then when the program starts, the Wii Remote is connected and an instance of the

wiimote class is initialised. The wiimote object is then polled at the beginning of the

main simulation loop. Polling the wiimote object refreshes its state to see if any

events have occurred. If so then the event is handled where appropriate functions are

called and global variables are changed.

1) initWiimotes(wiimote &remote)

2) wiipolling(wiimote &remote)

3) handle_event(wiimote &remote)

Figure 14: wiimote functions

Finally, when the program is closing the Wii controller is disconnected.

With a new library in place, the existing key bindings for the characters were updated.

The ball character was modified to use 3 groups of 6 pistons now, meaning that only 3

buttons would be needed on the controller. Also the method of control was changed to

direct firing of the group via a single button press.

A simple camera system was implemented in this increment. This system worked by

finding the position of the subject, and then subtracting a certain distance from this to

use to set the camera’s position. The positions were updated in the simulation loop so

that the camera followed its subject and kept it in view at all times. The camera’s

rotation, pitch and heading were locked though, so the camera always faced the samepoint on the horizon. A simulation reset function was also added in this increment,

whereby the simulation was deleted and then recreated in its initial state.

Prototype Testing

The results from testing concluded that the camera system needed to be refined in the

next increment so that the heading of the camera matched that of the character and

also so that the camera could be actively controlled by the user.

It was found that the simulation reset function was resulting in memory leaks. After

several resets of the system the simulation slowed down, eventually freezing. Lookingat the memory use of the program it was obvious that objects were not being deleted



21

before being recreated, so the simulation was handling more objects than it should.

The car was also found to be unstable and toppled over when turning suddenly at high

speed.

4.7 5th

Increment

In this increment the character selection system was changed so that only one creature

exists in the world at a time. Changing the character deleted the old one, and spawned

the next one in its place. The ‘reset’ function was refined to be cleaner without the

memory leaks, and the car’s centre of gravity was moved to be below the car to make

it more stable. A simple level was created for testing the characters in, comprising of

an arrangement of box objects.

Refinement of the camera system in this increment saw the use of an ODE Joint to

maintain a connection between the camera body and subject while also making sure

the camera body faced the same direction as the subject. Attaching the actual camera

to the body required the conversion of rotational matrices to Euler angles however.

After some research a conversion algorithm for 3x3 matrices to Euler angles was

found (Baker, 2010), however it didn’t work as expected. As the structure of ODE’s

matrices were unknown, and the fact that ODE’s rotation matrices are actually stored

in 4x3 matrices, it was hard to figure out which formulae were needed or how they

should be applied. After some experimentation a combination was found that

correctly obtained the heading value. As this was all that was needed for the camerasystem (pitch and roll were to be kept constant.), experimentation and research into

converting matrices was stopped at this point. Figure 15 shows how the equation was

used to find the heading Euler angle.

Initial equation heading = atan2(matrix[0][2], matrix[2][2]);

Final code heading=atan2(rotation[4],rotation[5]);

Figure 15: Conversion formula

As a joint was used to connect the camera to its subject, the camera could now becontrolled and rotated around the subject. This was done by changing angle of the

joint between the two bodies in the same way used for steering with the car character.

Support for the Wii controller’s Nunchuk extension was integrated in this increment,

and the analogue stick was used to control the camera both when it’s locked to a

subject and when it’s in free-roam mode. A second control system was added for the

car for when the Nunchuk is attached. With the Nunchuk attached and held in the left

hand, and the Wii remote held like a remote tilting the remote on it’s Roll-axis steered

the car, while the A and B button accelerated/reversed the car. A second control

system was created for the 4-legged bug as well, similar to that of the car. The



22

Nunchuck controled the camera, while tilting the Wii remote up/down moved the legs

forward/ back and the A and B buttons moved the legs up and down.

Prototype Testing

It was found that the capped cylinders used for the ball character’s pistons result in

inaccurate collisions with other objects. As well as this the system was crashing due

to stack overflow issues with Windows. Also it was decided that level creation using

only primitives is a long and cumbersome task. Using mesh files modelled in an

external 3D program would speed this process up significantly. As ODE supports

trimeshes it was decided that support for mesh files would be added in the next

increment. Development would be stopped for the bug character after this point in

order to focus on the other two characters and the integration of mesh files.

4.8 6th

Increment

This increment signifies major changes to the overall system and refinement of

existing elements. A new class was added to encapsulate the process involved in

reading and using mesh files.

meshFile Class

This class handled the converting of a 3D mesh file into a trimesh, which could then

be rendered and used within ODE as a rigid body with collisions. This was possiblythe most difficult task in the development of this project, and took the most time to

test, debug and complete. The countless issues encountered were handled by creating

test cases where the expected outcome was compared with the actual outcome. From

this the source of the bug or problem was worked out and a solution created until this

class worked 100% as expected and required.

3D models, created using 3D Studio Max 2010 [www.autodesk.co.uk ], were

converted to a triangle mesh and exported in Wavefront’s .OBJ format. This file

contains 3D geometry details: the position of each vertex and the vertices that make

up each triangle (referred to as the indices).

The .OBJ file, the path of which is passed as an argument to the class’s

loadOBJ()function, is opened by an ifstream in ‘read’ mode. In order to

initialise the dynamic arrays in the right size to hold the vertices and indices, the total

number of vertices and indices had to be known. The file is read line by line, value by

value (separated by a space character), under a set of rules:

http://www.autodesk.co.uk/






23

First value on the

line

How to handle the line

v Increase the total vertex count for each value on the line

vn Increase the total normal count for each value on the line

f Increase the total faces count for each value on the line

Figure 16: Rules for counting data

Note: normal data was handled as well in case of a future move to a different graphics

library which might use them.

As the vertices and normals compose of x,y,z values the totals had to be divided by 3

to get the actual number of vertices and normals. The dynamic arrays are initialised,

and then the file is opened again and read in a similar manner under a different set of

rules:

First value on the

line

How to handle the line

v Load the next 3 values into vertices

vn Load the next 3 values into normals

f Load the next 3 values into a temp stringstream and

process further before loading into indicies

g Load the next value into meshName

Any other value ignore the succeeding values until one of the cases above

Figure 17: Rules for reading data

Once all the data is loaded into arrays, a triMesh can be built using ODE’s

dGeomTriMeshDataBuildSimple() function. From this a geom can also be

created for collisions.

The class then covers all functions related to this triMesh and geom:

Addition of a body for dynamics

Setting a uniformly distributed mass for the body

Connecting the trimesh geom to the body

Setting the position of the geom or body

Setting the colour and transparency of the trimesh

Setting the texture for the trimesh

Rendering the trimesh



24

The above functions use standard body and geom functions to fulfil their tasks, with

the exception of the rendering process. Drawstuff doesn’t have any inbuilt function to

draw trimeshes, all it has is the ability to draw a triangular face given the vertices. It

was found that the normal (the direction to render the face) is implicit in the order the

vertices are given in. The drawing function in the class iterates through the totalnumber of faces, getting the vertices for each face and then drawing them as a triangle.

dGeomTriMeshGetTriangle(geom,index,&V1,&V2,&V3) is an ODE

function which takes a trimesh geom and an index (one for each face in the trimesh),

and copies the coordinates of its vertices into the addresses of the 3 given arrays.

dsDrawTriangle(pos,rot,vertex1,vertex2,vertex3, true) is the

Drawstuff function which renders the triangle’s face. The position, rotation, vertices,

and a Boolean value to draw solid/wireframe are passed as arguments. A very

important point was discovered here after a large amount of issues with drawing thetrimeshes was encountered. Initially the position and rotation of the trimesh geom,

obtained with dGeomGetPosition(geom), was used when drawing a trimesh

which had moved from its initial position. However it was discovered that the vertices

obtained from the trimesh geom are in world coordinates i.e. they are the absolute

positions of the vertices in the world, not the positions of the vertices relative to each

other as described by the mesh data from the file. As a result when the trimesh moved,

its collision geometry was in one place but the trimesh was actually drawn in another.

Fixing this involved passing a zero-rotation matrix and a zero-position array (all

values are zero) to dsDrawTriangle(), and letting the position and rotation of the

geom. be taken care of automatically when getting the triangle information.

The colour, alpha (transparency), and texture which were set earlier are stored in

private data members and used at this stage when drawing each triangle via the

Drawstuff functions:

dsSetColorAlpha(Red, Green, Blue, Alpha);

dsSetTexture (texture_number);

An alternative method of drawing was also created, where the mesh file is drawn

straight from the vertex data using a proxy object for position and rotation in the

world. This is useful as it allows a less detailed mesh or maybe even just a primitive

like a box to be used for simple collisions while a high poly mesh is used for

rendering. Trimesh collisions are highly computational, and the more faces present

the slower the simulation becomes. This method of drawing required a different

process from the previous one as there is no trimesh to obtain triangles from. Instead

for each index, the vertices associated with it are taken from the 2 dimension array of vertices and used to draw that triangle.



25

With the ability to load and use mesh files in place, major changes could now be

made to the game. Mesh files were used to change the look of the car (Figure 19), and

a low poly level was created for the characters to explore.

As well as this further refinement was done to some existing elements of the system

also in this increment:

1. Modified the ODECharacter class so that meshFiles were included, and so thatthe drawing of all parts of the ODECharacter happened via a single function

call.

2. Modified the ODESimulationObject class so that it also stored colour and

texture data for the object allowing all object to be drawn differently from

each other.

3. Changed simulation step to dWorldQuickStep to fix the stack overflow issues.

This method is less accurate, but uses less memory and is faster.

4. Modified experimental ball creature – changed pistons from capped cylinders

to boxes to fix the unstable collisions with certain geom types.

Prototype Testing

After the testing of this prototype it was decided that more levels could be added now

that it was easier to model and incorporate them. As well as this more items for the

characters to interact with should be added. To make it more fun a shooting ability

would also be added to the car so the user can drive around, shooting spheres at

objects in the world.

Figure 19: Car made using trimeshesFigure 18: Car made of primatives



26

4.9 7th

Increment

For this, the final increment, new levels were created with the ability to cycle through

them using the ‘L’ key. A function was created which could make a wall of bricks

along the x or y axis to smash through. The size and mass of each box could be set, as

well as the width and height of the wall in terms of bricks and the wall’s position. Acouple of these walls were added to the levels for the user to interact with.

A shooting ability was also added to the car, allowing the user to shoot small balls

from the camera viewpoint. This was achieved by moving one of the balls which had

already been created to the same point as the camera body attached to the car. The

orientation of the body was then obtained using dGeomGetRotation() and this

matrix was multiplied with another which had been rotated by 90 degrees. This gave

an orientation which was the same as the direction the camera was facing, and using

this, a force could be applied to the ball to fire it in this direction.

Furthermore, to make the car more fun and interesting the surface settings were

changed. The slip and bounce between surfaces was increased so that car skids and

handles more like a buggy.

A release version of the prototype produced from this increment was created and then

the final system testing was carried out.



27

Chapter 5

Final Testing

Due to the time constraints very little in depth final system testing could be carried

out. Some black box testing was done with a small test group of just 2 people. From

this testing some bugs were found, and the game itself was evaluated.

5.1 Bugs

Most bugs were fixed during the development of the project; however some were

missed and only found during the final system testing.

It was found that when shooting the balls while driving the car, the balls quite often

did not collide with trimeshes but passed straight through them. This seemed to be

related to the speed at which the balls hit the trimeshes.

It was also found that connecting the Wii remote at the start of the game with the

Nunchuk already inserted results in the automatic disconnection of the Wii remote

after a few seconds.



28

Chapter 6

Evaluation

It is hard to evaluate if this project was a complete success or not. While the final

product meets the requirements specified in chapter 3 and the main objective of the

project, to create a game demo using physics simulation, was successfully achieved,

there are shortcomings of the project when it comes to the experimental creatures.

One of the aims of this project was to find a new and novel idea for a game using the

experimental characters; however they cannot be deemed a success as it was found to

be almost impossible to control them in a desired way. The system testing carried out

showed that it was possible to move the creatures around, but difficult to predict

where they were going. While this made for an interesting and novel idea it justwasn’t practical. The car character on the other hand was a complete success, meeting

all requirements successfully.

Figure 23: Smashing through a wallFigure 22: Driving in a level

Figure 21: Firing all pistonsFigure 20: Firing a piston group



29

Chapter 7

Conclusion and Future Work

In conclusion this project saw the creation of a sandbox type game where a user could

explore a world displaying physics simulation using a Nintendo Wii controller and a

small selection of characters. This report explained the aims, objectives, specifications

and development process of this project and highlighted where the result succeeded

and didn’t succeed.

This Project itself has been a massive learning experience, drawing and improving on

skills and knowledge gained from previous and current studies at Keele University.

This project highlighted in particular the importance of knowledge in the area of

‘systems development’, and has improved my understanding of the related concepts

greatly. It has also accomplished one of my aims, which was to gain an introductory

level of knowledge required for game programming. The other aim was to find a new,

novel aspect to gaming through the control of experimental characters, and while this

aim wasn’t successfully accomplished, perhaps with more time and exploration a

workable solution could be found.

In reflection it was quite hard to stick to the proposed time plan. Certain sections took

longer than expected, while others were completed in a couple of days. It was also

found that at the beginning project management was relaxed with an element of chaospresent, however as the project matured different aspects, especially those related to

the system development process, became more fully understood and so project

management and development became smoother and more organised.

7.1 Future Work

There are a lot of possibilities for future work on this project. Drawstuff was clearly

intended as a simple visualisation tool to allow ODE simulations to be view and

explored by a user. It lacks all the advanced options and capabilities seen in graphics

engines these days, and doesn’t use optimisations which would allow it to run faster.

This can be seen when a high detailed mesh is used with the system (with or without

the use of a collision trimesh). The whole program slows down as Drawstuff struggles

to render all the faces. A next step would be to make the move to DirectX (DirectX 9

if developed on Windows XP, otherwise DirectX 10 or DirectX 11 depending on

hardware and operating system). Audio would be another possible addition to the

system, as would a more advanced interface perhaps using Microsoft Foundation

Classes (MFC).



30

With the current system there is plenty more room for experimentation with the Wii

remote. With the increased freedom the controller and its extensions provide there are

so many possibilities and openings for novelty in games using this technology.

In relation to the game concept, the car character could be developed further to create

a multiplayer game where users race against each other while shooting each other

with different types of objects. While this concept doesn’t make for an innovative

game, it certainly is considered to be a fun one and with the Wii controller’s

capabilities the idea could be made more novel quite easily.

The ball character would perhaps perform better in a two dimensional environment.

Limiting the movement to an X and Y axis could lower the complexity of the control

system, while still holding on to the novel aspect of it. A proposed future endeavour

would be to use this character alone to create a puzzle-platformer type game.

Another interesting area where the experimental creatures could be used is in artificial

intelligence. Neural Networks could learn and evolve a method to control the

creatures in an intelligent way. This would open up further possibilities for different

types of games.



31

References

Baker, M.J., 2010. Maths - Conversion Matrix to Euler. [Online] Available at:

http://www.euclideanspace.com/maths/geometry/rotations/conversions/matrixToEuler/index.htm [Accessed January 2010].

Boyd, E., n.d. WiiM. [Online] Available at:

http://digitalretrograde.com/projects/wiim/ [Accessed December 2009].

Cockburn, A., 2008. Using Both Incremental and Iterative Development. CrossTalk,

II(5), pp.27-30.

Davison, A., 2005. Killer Game Programming in Java. O'Reilly Media.

Gl.tter, 2010. Wiiyourself. [Online] Available at: http://wiiyourself.gl.tter.org/ [Accessed December 2009].

Kenner, C., 2010. GlovePIE. [Online] Available at: http://glovepie.org/ [Accessed

November 2009].

Laforest, M., 2009. wiiuse. [Online] Available at: http://www.wiiuse.net/ [Accessed

December 2009].

Stroustrup, B., 1985. The C++ Programming Language. 1st ed. Addison-Wesley.

WiiBrew, 2010. List of Working Bluetooth Devices. [Online] Available at:http://wiibrew.org/wiki/List_of_Working_Bluetooth_Devices [Accessed December

2009].

http://www.euclideanspace.com/maths/geometry/rotations/conversions/matrixToEuler/index.htm



http://digitalretrograde.com/projects/wiim/


http://wiiyourself.gl.tter.org/



http://glovepie.org/



http://www.wiiuse.net/



http://wiibrew.org/wiki/List_of_Working_Bluetooth_Devices











32

Bibliography

Anon., n.d. WiiM. [Online] Available at: http://digitalretrograde.com/projects/wiim/

[Accessed December 2009].

Bourke, P., 2010. Object Files (.obj). [Online] Available at:

http://local.wasp.uwa.edu.au/~pbourke/dataformats/obj/ [Accessed April 2010].

Corporation, I., 2010. bluesoleil. [Online] Available at: www.bluesoleil.com

[Accessed December 2009].

Hower, C.Z., 2010. Kudzu World. [Online] Available at:

http://www.kudzuworld.com/blogs/Tech/20070817A.en.aspx [Accessed December

2009].

Jelovic, D., n.d. Why Java Will Always Be Slower than C++. [Online] Available at:

http://www.jelovic.com/articles/why_java_is_slow.htm [Accessed 11 April 2010].

Jin, G.B., Jones, B. & Smith, J., 2009. Smoothboard Wiki. [Online] Available at:

http://www.boonjin.com/smoothboard/index.php?title=Main_Page [Accessed

December 2009].

Maas, D., n.d. Rotation matrix to Euler angle conversion. [Online] Available at:

http://vfxbrain.com/questions/5/rotation-matrix-to-euler-angle-conversion

Pressman, R.S., 2001. Software Engineering - A Practitioner's Approach 5th. 5th ed.

Thomas Casson.

Smith, R., 2007. Products That Use ODE. [Online] Available at:

http://www.ode.org/users.html [Accessed 1 April 2010].

Stroustrup., B., 2000. The C++ Programming Language. Addison Wesley.




http://local.wasp.uwa.edu.au/~pbourke/dataformats/obj/


http://www.bluesoleil.com/



http://www.kudzuworld.com/blogs/Tech/20070817A.en.aspx


http://www.jelovic.com/articles/why_java_is_slow.htm


http://www.boonjin.com/smoothboard/index.php?title=Main_Page




http://www.ode.org/users.html












33

Appendix A: Time Plan

Time Plan Overview

Autumn SemesterWeek

1 2 3 4 5 6 7 8 9 10 11 12Holidays1 2 3 4

Examinations1 2

Charter

BackgroundReading,research, etc

Design

Implementation

Log Book

Supervisormeetings

Spring SemesterWeek

1 2 3 4 5 6 7 8 9 10

Poster

BackgroundReading,

research, etcDesign

Implementation

Log Book

Supervisormeetings

Final Report

Semester Dates

Autumn Semestero Week 01: 28/09/2009

o Week 12: 14/11/2009

Spring Semester

o Week 01: 25/01/2010

o Week 10: 29/03/2010



34

Monthly Planner

November (Shaded days)Monday Tuesday Wednesday Thursday Friday Saturday Sunday

1 Week 5

2 Week 6 supervisormeeting

3 Week 7 supervisor

meeting

4 Week 8 Initial

Prototype

5 Week 9 Meeting

cancelled

6 Week

10

1st

Increment

December (Shaded days)Monday Tuesday Wednesday Thursday Friday Saturday Sunday

1 Week 10 supervisor

meeting

2 Week 11 supervisor

meeting

3 Week 12 2nd Increment

End autumnsemester

4 Christmas

day

5

January (Shaded days)Monday Tuesday Wednesday Thursday Friday Saturday Sunday

1

2

3 Start

autumn

assessment

4 End autumn

assessment

5 Week 1 Start Spring

Semester

3rd

Increment



February (Shaded days)Monday Tuesday Wednesday Thursday Friday Saturday Sunday

1 Week 2 4th

Increment

Poster talk

2 Week 3

3 Week 4 supervisor

meeting

4 Week 5 supervisor

meeting

Poster

Deadline

Poster

session

March (Shaded days)Monday Tuesday Wednesday Thursday Friday Saturday Sunday

1 Week 6

2 Week 7 5h

Increment

supervisor

meeting

3 Week 8

4 Week 9

5 Week

10

6h

Increment

April (Shaded days)Monday Tuesday Wednesday Thursday Friday Saturday Sunday

1 Meeting

cancelled

2

3

4 Final

Exams

5 supervisor

meeting

7h

Increment

Deadline: May 11th

oisin a. conolly - physics and novelty in computer games

Documents