In the summer term 2007, I participated with two friends in the game programming lab. The objective of this lecture is to go through the whole process of developing a computer game: From the initial design and planning phase, up to implementation and game testing. Throughout the whole project we did excellent team work, and, despite the hard work, enjoyed the project to the fullest.

Design and planning phase

1. In the first phase of the course, we designed the game we were going to make. We decided on the type, motivational factors, looks and feeling. Additionally we broke down the work into manageable parts and split them up among us. Our proposal slides sum up the results.
   

Implementation

1. •Collision Detection
   

1. One of my first tasks was the development of the collision detection. We had decided that we wanted to have the technical optimum: Direct sphere-mesh collisions, so we needed a data structure that allowed fast lookup of the around 50k faces. We decided on a „Binary Space Partitioning“ tree. The first thing I needed to do, was to get access to the level geometry somehow. To this end I wrote an importer for .obj files, which would parse a given file and extract the vertices, faces and normals. As a next step I implemented the recursive tree generation itself. Please note that I didn‘t do polygon splitting. Instead each polygon intersecting a separating plane would be passed down the tree on both sides of the plane. This does generate some overhead, as we end up with duplicate geometry in the leafs of the tree, however, the collision detection already performed that well, that it didn‘t matter at the end. The generated tree was then stored in a binary file, which could be read by the game itself. This allowed us to stay independent of the fully detailed level geometry, if we had wished, we could have used reduced geometry for collision tests.
   

2. Overall, collision detection turned out to be very fast, typically each collision test had to check only between 50-150 triangles for collision. All collision tests for one update() usually take around 1 ms.
   

1. •Game Logic
   

1. My next task was the implementation of the game logic. As a starting point, I identified the states the game could be in, and the transitions between the states. I then drew a detailed state diagram, reflecting the previously determined information. Finally, when the diagram was complete, I went over to the implementation, which was an easy task.
   

1. •Sound and Event System
   

1. XNA already provides a nice interface for authoring sound effects and playing them in the game. The only thing missing was a nice and consistent interface for playing sounds in our implementation. To this end, I devised an event system based loosely on the observer design pattern.
   

1. •Shadow Mapping
   

1. After finishing all these tasks, and some minor things as implementing a mini map, player input, and the finish scene, there was still a fair amount of time left for improving the game. As the physics was also finished, I decided together with Roni, to start improving the visual quality. We came to the conclusion that we wanted to have shadows, and so we implemented shadow mapping. The first version of our shadow mapping looked terrible, lots of artifacts and very pixellated. To get rid of bad resolution and the hard edges, we implemented an adaptive sampling strategy of the shadow map. For each pixel, we sample the shadow map at 8 random positions in the neighborhood of the „real“ pixel. If all positions are shadowed, we conclude that the pixel is in complete shadow. If all positions are in the light, we conclude the opposite. The interesting case happens when a part of the pixels is shadowed, and another part isn't. In this case we conclude that we are in penumbra, and increase the sampling accuracy. We add another 24 samples to the shadow calculation, and average then over the shadow intensity. This gives us very nice shadows, however, one can still see the randomness in the process. To get rid of that, we perform another screen space blurring of the shadows.
   

2. As a result we obtain very soft, dynamic full scene shadows, but with high computational cost. However, this is within bounds, since our game still runs at 30fps on the Xbox 360.
   

Test phase

1. When all features were finally implemented and the game ran stably, we started the play testing phase. We invited some friends, and let them play the game. During this time, a lot of bugs and difficulties were uncovered. We also got a lot of interesting suggestions and ideas to improve the game.
   

1. Here you can find the report of the play testing phase.
   

Final presentation

1. During the final presentation of all games developed in the game programming lab, a jury consisting of course assistants, Prof. Markus Gross, Silke Lang and Adam Moravanszky (principal engineer at Novodex, now NVIDIA) decided to award the games „Titors Equilibrium“ and „S.P.H.E.R.E.S“ with a special jury award. Here you can view the slides for our final presentation.
   

For more screenshots and a playable Xbox version, please visit the S.P.H.E.R.E.S website.

Copyright: Theodor Mader, 2008