Gravity Bound
Introduction here.
Deliverables
This section covers the deliverables for the game class.
Part 1: Project Proposal
The project proposal is a pdf file. The proposal is attached below.
The in-class presentation sheets are attached below as well.
Part 2: Interim Report 15.April 2007
Prototype Impressions
The following screenshots show some impressions of the current prototype. The first one shows the main charakter (big sphere) thd some monsters (small spheres) bustling around.
The second screenshot shows the level view from the top. The blob was jumping when the screenshot was taken.
The old mockups until now can be seen in the project proposal.
Review of the Critiques
Most concerns from other people were about the gravity features. On one side it's a fun element, on the other hand it's playability was highly questioned. But to fully evaluate the playability of the gravity feature, it has to be implemented first and then tested.
The Current State
At the moment we are on track with implementing our game. We are on good way to achieving the functional minimum, which is targeted for next week. The current demo is a first playable version, which allows us to study the behaviour of the control system and check the playability of level designs.
While implementing we had to realize that the design of the XNA API has some restrictions regarding the content management, which define very strictly how the resources have to be defined. The difference between the PC and XBox360 environment are also annoying, since the Compact .NET Framework supports less API elements than the full blown .NET version. It's also a pity that the IDE doesn't support projects for both target platforms (PC, XBox360).
On the other hand the control system proved to be really easy to use and the XNA support for the DirectX PIX tool is fantastic.
So far no design revisions had to be considered. We are on track.
Demo
Playable Demo
The controls work as described in the proposal. At the moment moving, looking and jumping is supported.
Part 3: Interim Report 13. May 2007
Since the last progress report the implementation went on with good pace. So far we are in most parts within schedule (i.e. reached the Low-Target). There are some parts where we are beyond it and some parts where we are slightly behind schedule.
Project tasks
Given the development targets after the functional minimum, which was reached with the last progress report, we had the following tasks scheduled for the low target:
- Fully functional camera
- Level loader
- Textures
- Sounds
- Blob simulation
- Monster models and AI
- Lighting
- Graphical user interface
- The gravity feature
- Shooting (including direction)
- Game play
With the exception of the amount of available sounds and monster models all targets where reached, and thus we have reached our low target.
Quality
There are some areas, where the completion state is only formal. As for the blob simulation there is some instability, due to the huge amount of constraints, which have to be considered for the simulation. Also the monster models we have in the game are less nice than we expected, but there are available and can be used for testing.
Comments: Camera
In contrast to what we thought the camera was far very easy to implement. The camera moves behind the blob with an exponential falling of delay, which was coded in about an hour time and proofed to be very robust. There are some issues when a wall comes in between the camera position and the blob, but we are optimistic that we can resolve this issue.
Comments: Blob
The implementation of the blob as a mass spring system was straight forward. We used a rotational invariant representation of a sphere (in this case a subdivision of an icosahedron) with a central point, which has springs to all peripheral points. The problem that proved to be the hardest is to find the right parameters (as usual in physically based simulations). Once the blob was stable the second problem appeared. The blob should change its size when looses/gains oil and still behave the same. Changing the size meant a dynamic adaption of several crucial parameters like mass, stiffness and size.
To make the simulation more stable we added a sub stepping mechanism, which turned out to be hard to integrate into the collision detection (a problem we still try to fix).
Comments: Collision Detection
Collision Detection is based on an octree, which is rebuild from scratch every time. This might seem suboptimal, but an adaptive octree is very hard, even impossible to implement efficiently. The overhead of recreating the octree has been shown to be negligible even under extreme conditions
The only remaining issue is a performance issue if there are too many objects in one place. I'm still unsure how much of an issue this is in our game, but I'm likely to fix it soon.
Targets reached from the next level
While we were programming and defining the program structure, we could include the design and basic implementation of the bonus item functionality. So this target should be includable with not much effort. The design also is already more or less ready for multiplayer support, so this one is also in reach.
| From the graphics point of view, we also implemented a first version of the environment mapping (although there still must be an error in the formula or the definition of the textures). The harder part seems to be to give the blob an oilier and a less metallic look. Using shaders makes lighting in general very flexible and adaptable to the needs of each object. Finding the right parameter is much harder. |
 |
Problems regarding the Xbox360
During the whole development of the game we used Windows as the main platform for testing. When we first tried to use the XBox360 for more than some simple demo we run into serious troubles.
First of all we had to realize that the XBox and Windows DirectX implementation are not the same. The XBox version is stricter regarding errors the user input. Although the program code we was semantically wrong the Windows version of DirectX ignored wrong input and displayed the correct results. The XBox implementation on the other hand penalised the wrong inputs with wrong outputs.
As for an example:
When using Viewports one has to the define position, size and z-buffer range. If you don’t set the z-buffer range Windows still outputs correct results. The XBox on the other hand draws the object as if no z-buffer was enabled.
The second problem we encountered lies in the virtual machine of used in the .NET Compact Framework:
http://blogs.msdn.com/netcfteam/archive/2006/12/22/managed-code-performance-on-xbox-360-for-the-xna-framework-1-0.aspx
http://blogs.msdn.com/netcfteam/archive/2006/12/22/managed-code-performance-on-xbox-360-for-xna-part-2-gc-and-tools.aspx
We encountered massive performance problems when we were running our game on the XBox and we think that the reasons lie in the problems stated in those two blog entries. What impacts us the most are the following two short comings of the .NET Compact Framework virtual machine:
- Not yet optimal implementation of the floating point part of the JIT compiler
- No auto inlining by the JIT compiler
Looking at the runtime measurements of the game, we found out that 25% of the time are spent in the method BlobBase.Update(). This method call a vast amount of operations on Vector3, which none of them are inlined by the JIT compiler. Just to be clear; the measurements were made on a Core2 Duo System clocked at 2.13 GHz. On the XBox much more time is spent in the BlobBase.Update() method. We will try some optimisations (like using the “by ref” methods of the Vector3 class), but first the blob has to get more stable.
There was a third short coming that came to our mind when we saw these documents. We feared that the garbage collector could impact our runtime, due to the vast amount of object allocation and de allocations caused by our octree. The current implementation rebuilds the tree each frame, which produced a vast amount of garbage objects. We than replaced the part which produced the allocations with a memory pool. This way we could reduce the amount of object allocations by 60% and we could half the garbage collector runs. Unfortunately this didn’t bring any kind of performance improvements on the XBox, which strengthens our believe that the two short comings mentioned above are the main cause.
Demo
Playable Demo
The controls work as described in the proposal. At the moment moving, looking and jumping is supported.
Part 4: Alpha Release
The following report describes the state of the project and gives an overview of the goals we achieved or had to give up due to complexity of the matter or the lack of time to implement them.
Implemented game items
Bonus Items
We have implemented almost all of the bonus items. The oil cane, the shooting stabiliser, the extra lives, the shield and the jump enhancer are implemented and function as defined. The shooting enhancer and the special oil were left out so far, due to the lack of time to implement them.
The usability of the shooting stabiliser could suffer a bit from the different expectations people could have of the feature. Play testing will show I will have to make some adaptations to it.
Game Level Elements
We omitted the described level elements (Jump pads and beamers) due to the lack of time to implement them.
Game rules
We mentioned that it would be possible to use attractors to pull shots to the blob. This feature was in the desirable target, but had to be omitted for we needed time for other stuff.
State of the project target levels
As discussed in the previous report the functional minimum and low target were fully implemented.
Graphics
The only thing from the higher targets we implemented was a more advanced rendering for the blob using an environment map and some approximate Fresnel falloff.
Animated monsters where hard to find and exporting textures was hard, for we planned a bit to less time to learn Maya. Also we figured that shadows wouldn’t be hard to implement, but had two drawbacks. First off all we thought they weren’t really needed and secondly, we didn’t have time for them.
Physics
The blob can stick to the wall if desired.
Game logic
We implemented the multiplayer split screen mode. But due to our performance problems we still have on the XBox360, it’s unlikely that it ever will be useable.
Schedule
After reaching the low target, we had to redesign our schedule, for we noticed that the way it was designed wasn’t applicable anymore. We started a new schedule, which looked like the following passages.
Basil would have to spend his time on rendering, and finding enough models for monsters and bonus items. Split screen seemed to be an easy task and the environment mapping was almost ready in the since the presentation of the last target.
Henning would have to spend much time in stabilising the blob and its behaviour. Benjamin would be involved in making sounds and fixing issues found in the game play behaviour and extending what we had to integrate all the features lying around.
We also completely underestimated the time it would take to produce a decent user interface. This job would go to Basil and Henning to carry it out.
Given this vision we hand after the last presentation started with this new schedule. It turned out to be better suited to our needs and we could stick to it until today. The cost was to sacrifice some of the features of the desired target to bring more polish to the things we already had.
Development strategy
When we started implementing the game, we decided to work with an “extendable prototype” scheme. We implemented the features to the extent that made sense with the current prototype. After each round some features had to be extended a bit more to meet the new requirements we had for the next target.
This turned out to be a good strategy with one exception. The programming part functioned quite well this way. But adapting the same scheme to content was much less well doable. As with programming most work will be spent with the last 20% of the code. For the content we underestimated a bit the first 80%, so we had to spend much more time for content than initially anticipated. The reasons for this clearly lie in the fact that we all are good programmers and have a lot of experience in estimating the programming effort. But producing content was a new field for us. We naturally underestimated the effort needed.
The XBox360 Problem
Unfortunately the problem isn’t resolved yet. To keep the blob stable we need signification resources and the XBox360 can’t provide them in the way we would need it.
Part 5: Playtesting and Final Paper
The final paper is provided as a PDF:
The final report
Mutual Project Critiques
Benjamin Schindler
Basil Fierz
Henning Avenhaus
Attachments
pdf 
ppt 
zip 
png 
