P. 1
Oisin A. Conolly - Physics and Novelty in Computer Games

Oisin A. Conolly - Physics and Novelty in Computer Games

|Views: 74|Likes:
Published by Oisin Conolly
A Game programming project exploring physics and novelty through the use of Nintendo's Wii controller and ODE, the Open Dynamics Engine.
[Oisin A. Conolly's Dissertation for BSc in Computer Science, 2010]
A Game programming project exploring physics and novelty through the use of Nintendo's Wii controller and ODE, the Open Dynamics Engine.
[Oisin A. Conolly's Dissertation for BSc in Computer Science, 2010]

More info:

Published by: Oisin Conolly on Mar 10, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less






Oisin Akiboye Conolly

BSc in Computer Science 11 May 2010

SCHOOL OF COMPUTING AND MATHEMATICS Keele University Keele Staffordshire ST5 5BG

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.


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 would also like to thank Tess Piper for moral support, and for providing the Wii controller used to develop this project.


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 .............................................................................................. 11 4.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


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.


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.

Figure 1: Wii remote

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 2: Nunchuk extension


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 6

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 the time 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 for simulating 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 the needs 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


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 provides supports 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 project plan. With these aspects gone, the project was deemed to be within capabilities.


Chapter 3 Requirements
The game concept proposed for this project focused on a sandbox type environment where the user controls a small selection of characters and navigates their way through the world interacting with objects present. There is no main aim of is type of game, you do not win or lose; you just explore and have fun. 3 different characters were designed. The first is a simple car which the user can drive around the world. The other two are experimental creatures, one being a 4-legged bug, the other being a sphere with an array of pistons on its surface. These experimental creatures are an attempt to explore new and novel ways to control characters based on physical interactions using joints, and to create a fun and challenging game out of it.

3.1 Requirement
System Requirements 1. The physics simulation side of the system must support: a. Rigid body collisions (for both primitive and custom polygon shapes) b. Creation and simulation of joints between bodies c. Motor functions for bodies/joints (applying linear/angular momentum to bodies, torque to joints etc.) d. Real-time simulation which is both fast and accurate enough to seem realistic. e. Simulation of aspects of real world physics (such as gravity, friction, momentum etc) 2. The system requires a means for human interaction a. Mouse input to control a camera and possibly characters in the game. b. Keyboard input to control characters and other elements of the game. 3. The system requires a graphical representation of the simulation a. Needs to be 3D drawn either in a window or fullscreen b. Must support basic shaders (custom textures and colours minimum) c. Must allow for the view point to be moved around d. Must be fast with low spec requirements 4. The system must facilitate an automatic camera system a. The camera must automatically follow the selected character around b. The character must stay in view c. The camera must point the same direction as the character Character Requirements 1. Car character a. User must be able to control acceleration in 2 directions (forward, reverse) b. User must be able to steer the car


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 legs b. 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 for the 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


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 should be 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 Initial Prototype Week Due Objective Autumn Integrate the physics simulation, graphics Semester – rendering, and input capturing together into one Week 8 whole system. Create a simple environment composed of static and dynamic geometry with this system. Autumn Semester Week 11 Spring Semester Week 2 Create the basis for the characters – comprised of bodies and joints, but with no functionality.

1st Increment

2nd Increment

Add motor functions to allow the characters to move, and use keyboard input to control the characters

3rd Increment

Spring Add ‘simulation reset’ capability to the system. Semester – Integrate a simple camera system that follows the Week 5 characters around. Spring Create levels for the characters to explore and Semester – interact with. Week 8

4th Increment

Figure 4: Prototype Plan


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.


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 (sphere mass and box mass) Setting the body position Connecting the stored geom to the body Rendering the geom In its current position


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 the primitive 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 iteration through 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.


Figure 6: A Hinge-2 joint

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).

Figure 7: Bug Creature

Figure 8: A Universal joint

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.


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.

Figure 9: Unit Circle 𝐶𝑜𝑠𝜃

= 𝑆𝑖𝑛𝜃 = 𝑎𝑑𝑗𝑎𝑐𝑒𝑛𝑡

𝑥 = = 𝑥 ℎ𝑦𝑝𝑜𝑡𝑒𝑛𝑢𝑠𝑒 𝑟 𝑜𝑝𝑝𝑜𝑠𝑖𝑡𝑒 𝑦 = = 𝑦 ℎ𝑦𝑝𝑜𝑡𝑒𝑛𝑢𝑠𝑒 𝑟

Figure 10: Derived formulae

These x and y values were then also used to create a rotation matrix, using Euler angles, 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.


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 pistons dReal 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 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.


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 is zero. 16

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.


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 basic functionality 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


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 Bluesoleil stack Result

Wii remote connected as a HID with limited functionality; vibration and LED display. Wii remote connected as a HID. No functionality displayed. Would not recognise the Wii remote as a HID Wii remote connected as a HID. All features fully functional.

Widcomm Toshiba Microsoft

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 application programming 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. 18

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. The D-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.


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 programmer learning how to use C++. The library itself also provides wider compatibility with 19

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 same point 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. Looking at the memory use of the program it was obvious that objects were not being deleted 20

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.


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 camera system (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 Final code heading = atan2(matrix[0][2], matrix[2][2]); 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 be controlled 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 21

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.


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 possibly the 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:


First value on the line v vn f

How to handle the line

Increase the total vertex count for each value on the line Increase the total normal count for each value on the line 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 v vn f How to handle the line

Load the next 3 values into vertices Load the next 3 values into normals Load the next 3 values into a temp stringstream and process further before loading into indicies Load the next value into meshName ignore the succeeding values until one of the cases above

g Any other value

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 23

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 total number 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 the trimeshes 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. 24

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.

Figure 18: Car made of primatives

Figure 19: Car made using trimeshes

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 that the 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.



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. A couple 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.


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.


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 just wasn’t practical. The car character on the other hand was a complete success, meeting all requirements successfully.

Figure 20: Firing a piston group

Figure 21: Firing all pistons

Figure 22: Driving in a level 28

Figure 23: Smashing through a wall

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 chaos present, 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).


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.


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].


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.


Appendix A: Time Plan
Time Plan Overview
Autumn Semester
Week 1 Charter Background Reading, research, etc Design Implementation Log Book Supervisor meetings 2 3 4 5 6 7 8 9 10 11 12 Holidays 1 Examinations 2 3 4 1 2

Spring Semester
Week 1 Poster Background Reading, research, etc Design Implementation Log Book Supervisor meetings Final Report 2 3 4 5 6 7 8 9 10

Semester Dates

Autumn Semester o 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


Monthly Planner
November (Shaded days)
Monday 1 2 Week 5 Week 6 supervisor meeting supervisor meeting Initial Prototype Meeting cancelled 1st Increment Tuesday Wednesday Thursday Friday Saturday Sunday


Week 7


Week 8


Week 9


Week 10

December (Shaded days)
Monday 1 Week 10 Tuesday Wednesday supervisor meeting supervisor meeting 2nd Increment Christmas day End autumn semester Thursday Friday Saturday Sunday


Week 11


Week 12



January (Shaded days)
Monday 1 2 3 Start autumn assessment End autumn assessment Week 1 Start Spring Semester 3rd Increment Tuesday Wednesday Thursday Friday Saturday Sunday




February (Shaded days)
Monday 1 Week 2 4th Increment Tuesday Wednesday Thursday Friday Poster talk Saturday Sunday

2 3

Week 3 Week 4 supervisor meeting supervisor meeting Poster Deadline Poster session


Week 5

March (Shaded days)
Monday 1 2 Week 6 Week 7 5h Increment supervisor meeting Tuesday Wednesday Thursday Friday Saturday Sunday

3 4 5

Week 8 Week 9 Week 10 6h Increment

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

2 3 4 Final Exams supervisor meeting 7h Increment


Deadline: May 11th


You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->