Blockade

All original code written in python using the Panda3D and ODE physics engines.

Here is an outline of the code files:

• Physics.py
  The main file with the update loop.
• Init.py
  Global variables.
• Block.py
  The block class that is used to create the three types of blocks.
• Creep.py
  The creep class that is used to create the three types of creeps.
• Grid.py
  The grid class which keeps track of where all of the creeps and blocks are for path finding and block stacking.
• ResourceManager.py
  This files keeps track of score, money, and health.
• MouseAndKeyboard.py
  UI controls.
• Sound.py
  Imports the music and sound effects.

• There is a models folder that holds the vegetable and cube models. These are models that we created for a previous game.
• The textures folder holds the textures for the models.
• The sounds folder holds the music and sound effects which were created for this game.

1. integrating ODE physics with Panda3D
   There wasn't any documentation for this so it was challenging getting the ODE physics engine to work with Panda3D. We tried a number of things including using both Panda's collision detection for some things and ODE's physics and collision detection for others. Eventually we settled on using ODE for all of the collision detection and physics.
2. optimizing performance with physics and path finding
   Once we got path finding and physics working, we realized that the game would slow down too much when there were a lot of creeps and blocks in the scene. We tried a number of different ways to get the game to perform on a level that was still fun to play like limiting the number of creeps and blocks and simplifying the path finding. Eventually we settled on not using path finding for the creeps, and using a clean up routine for the blocks. Every ten seconds or so, any used blocks would be deleted. These changes allowed for the game play to still be fun and for everything to run at a speed that made it fun while still having the feel of a unlimited number of creeps and blocks.
3. using physics as a game mechanic
   Our main goal was to use physics, force and velocity, as the main mechanic behind killing creeps. This turned out to be more difficult than we expected. It was hard to calculate damage based on the force of a block impacting a creep and then have a reasonable response from the creep. We realized that it got complicated quickly when trying to have the creeps react to impacts from blocks or other creeps when they didn't die. We ended up settling on a compromise to the physics-based damage. We used a stone, paper scissors mechanic where certain block types were needed to kill certain creep types but the physics aspect was that the blocks had to have a certain downward velocity in order to cause a kill.

1. general premise and design
   We were really happy with being able to explore the general premise of a non-shooting tower defense game that used physics collisions to cause damage. Blockade shows the potential for some alternate ways to create a tower defense game. Since most tower defense games rely on placement to have the greatest effect within the range of the tower, mazing towers in a certain pattern to cause the creeps to move to certain locations or receive fire for longer, and then other characteristics of the kind of projectile and aura effects such as "slow", we were able to explore how these mechanics work when a 3D space can be explored more fully and placement of towers becomes more important than quality of projectile or effect.
2. simplified technology
   We chose to use the Panda3D engine because we knew that it was good for rapid development. We knew we didn't have as much time as we would have wanted to create the game we envisioned so we chose technology like Panda3D and using existing models to help speed up the development process so that we could focus on exploring gameplay.
3. iteration and play testing
   We started with a simple game within the first week of work. This helped a lot and we tried to keep iterating and play testing through out the process. Making changes based on how the game played help make it fun and helped us know what to work on.

1. path finding wasn't that useful
   We spent a good amount of time working on path finding because it is so essential to most tower defense games, but found that with our physics-based model that path finding actually took away from the fun of the game. A big part of the fun is to have the creep crash into your structure and then watch it collapse on the creep. If the creeps always avoid the structures, then you will not be able to get any points since there are no projectiles in the game. At the end, we decided not to use path finding. Also, it slowed things down.
2. physics engine and path finding slowed things down
   We struggled with the performance of the game throughout our work. The path finding wasn't fast enough once there were a lot of creeps and blocks, and the physics engine slowed down even more. We were able to come up with ways to minimize these performance problems, but it would be great if we could return to these issues and see if we could further optimize the game so that it could handle many different physics objects at once.
3. interest curve
   While we were happy with the premise and overall design of the game, we realized it was hard to make this game last as long as many tower defense games do. Most tower defense games can last any where from 30 minutes to an hour and we were just not able to match this level of depth in the gameplay. We ended up making a pretty enjoyable short game and can see that with more time we could extend the strategy and progression of the game so that it would build in challenge and reward.