A puzzle game based on the placing of explosive charges to do maximal damage to the game building. The building will be constructed of rectangular shaped blocks that react properly to explosion and interactions between other block. The block with have some connectivity that will not necessarily break under the force of a distance explosion. There will be several types of explosives: radial blasts, directional charges and rockets. The score will be determined by structural connections broken, positions of structure relative to its initial position, and maximum total kinetic energy. The game uses a physics engine based on impulse based collisions and implicitly solved contact and frictional forces, mainly implementing papers by Baraff.

I'll keep this very brief since you have probably read way too many of these already. For the most part the project worked out as I envisioned it. 95% of the Development time was spent working on the engine. Finally, late last thursday the physics engine was complete. I spent friday though monday developing the game and gui. I suppose it just goes show that you can have a decent game without spending a lot of time worrying about whether the final result will be fun or not. I took a very primal idea playing with blocks and destroying and made it into a game. It's hard to lose when you've got good material. Of course, it was a bit nerve racking to risk the entire game on the development of a physics engine, all the versions of the engine before thursday would have been able to support a game. Had it not gotten completed, there would have been no game. But thankfully, everything worked out.

There was almost no graphically flashiness in the entire project. The graphics would have no problem running on super-low end hardware. There were probably less than 500 polygons abused in the whole project, though no textures were harmed in the making of the project. The simulation however tanked even the most power of PCs. In the end, as was the joke around the cluster, my game was really a hasty front-end for a rigid body physics engine.

The main issues in the project were due only to the engine. There were two main issues robustness and performance. Clearly, in order to make a game both had to be optimized and balanced. The problems with robustness mainly stemed from numerical problem in simulation model. What might be ok for real numbers isn't for doubles. It took a lot of tweaking and numerical methods to get things working smoothly. Performance was another problem, the simulation needs to run in more or less realtime, otherwise the user will get frustrated. Since every bit of the code that I used was mine (aside from the standard C libraries) I had complete control to optimize anything I wanted. I spent half a day fiddling with gprof and probably got a 10x speedup. I also buffered the simulation output so things weren't as choppy. I made other more technical changes to the physical modelling that reduced realism slightly for a huge performance and robustness kick, but I won't go into them.

On a whole, I enjoyed the project. I think the biggest advantage I had in working on this project (other than I'm also a physics major) is that I spent the majority of my working time in the cluster, where I could talk about ideas and bounce things off other people in the class. Also it encouraged some healthy competition. That really it don't have much else to say. My engine is some 11000 lines, I'm sure less than 0.5% of those lines are thoughtful comments so if you would like to understand something more specific about the project email me. The main sources I drew on for the core engine were two papers by Baraff. First a 1994 SIGGRAPH paper on fast contact force computation and the second was the course note for his 1997 SIGGRAPH course on physically based modelling. Just Google for them.

veni, vidi, ludo (latin always makes things sound more noble somehow)

• View from free floating camera over a mostly 2 dimensional world plane
• Single Player Game
• Data Driven level
• Realistic Physics and Collision Model (rolling balls tumbling boxes, with friction)
• Variety of explosives and bonus block types
• Cel Shaded environment

• Free Floating Player Controllable Camera (Implemented)
• Fully Modeled Dynamics and Collisions
  • Integrator (Implemented)
  • Collision Detection (Implemented)
  • Collision Response (Impemented)
  • Contact Forces (Implemented)
  • Friction (Implemented)
  • Complex Structural Connected Blocks (Implemented)
  • Destructable (Implemented)
  • Monte Carlo Explosion Fields (Implemented)
• Data Driven Levels (Implemented)
• Cel Shading (Not Implemented, bah going low tech)
• Menu Driven UI (Implemented)

• Borrowed:

  All the source code will be original except for possibly some model loading code and maybe some vertex shaders from the Nvidia demos.

• Previously Developed:

  Previously developed particle system that will have to be upgrade to handle rigid body motion and collisions.

• New:

  Everything else will be new.

• Mar 19:
  Complete Design Spec for physics model and game play includes listing requirements for the physics model and description of all the elements of game play (types and functions of traps, Lemmings and world objects).
  Having thought about it for a while, I decided that the Lemmings game might be fun but only if I had a much larger amount of time to produce it. Plus the delay of lab 3 pushed development time even further back.
• Mar 26:
  Complete Physics and Collision Model
  Looked in the creation of the physics model read a number of paper's by David Baraff and decided to based the core of my physics engine on notes from his 1997 SIGGRAPH physically based modelling course.
• Apr 2:
  Continued to work on physics model.
• Apr 6 ~ Milestone 1:
  The game is not currently playable. It is not currently a game. There cannot be a game until the physics is correct. Once the physics is done, however, the completing the game will be straightfoward. The collision detection and impulse collision repair are complete. The implicit calculation is nearly debugged, there remains a nasty bug makes forces degrade over time. Contact forces have been disabled for Milestone 1, because they are still in the debugging phase. However, this also affect how impulse collisions work as well, meaning they cannot be correct until the contact forces are working. The demo (mostly non-interactive) shows some blocks colliding with a fixed plane.
  Some not very interesting screenshots are shown below:
  
  Controls:
  Left mouse button + motion - rotate scene about x- and y-axis.
  Right mouse button - quit and toggle wireframes.
  
  
  
• Apr 9:
  Get Contact forces and friction working.
• Apr 16:
  Allow construction of structural connections between blocks and make interactive level editor (level editor not complete).
• Apr 20 ~ Milestone 2:
  (update) Almost feature complete and cel shading done (cel shading not complete) The game is currently not playable, there still is are no game features to speak of. The physics model is more or less complete and much more stable than at the past milestone. There are a number of optimization that need to be made to allow the engine to perform better and be more robust; they should take less than a day's work. All that remains is the GUI, game features like scoring and goals, cel shading and the level editor, which should progress quickly when the engine is fully complete.
  
  Controls:
  p : pause animation
  + : speed up animation
  - : slow down animation
  LMB + motion : rotate scene
  LMB + shift + motion : scale scene
  
• Apr 23:
  Add game elements like scoring, bonus blocks and explosive types
• Apr 30: (updated)
  Add special visual effects and texture map and light world. Add GUI. Add level Editor.
• May 5: (updated)
  Add physics engine optimizations
• May 10: (updated)
  Play testing and balancing complete. Game is done. Add Cel shading.

• I am a little concerned about the speed of the final engine, a lot of the techniques that it must employ are computationally difficult, especially the implicit solving for the contact based forces. Simulating large scene of many connected block may be very slow, however, I can't know how slow until I can get the system correct. Even so, I think there are a couple of hacks I can make to speed it up a bit at the cost of realism if it comes down to that. There are also a few seeming numerical instabilities that need to be worked out.
• The main reason that I changed game was because I did not believe the "Lemmings: Deathtrap" game would be fun unless it was very complex, and good complexity is difficult to construct in a short period of time.