Design Tradeoffs
The original plan was to have multiple types of items which the player would be able to "pick up". We wanted the items to be both advantageous and malicious to keep the game interesting. Some example effects would have been speeding up and slowing down the enemy and player movements, increasing or decreasing the player's health/life, and a pick up which would allow the player to use a weapon and shoot the enemies.
We opted to leave the creation of usable items for the end of the game development and concentrate on adding more depth to game play. We decided to have 2 players for our game. We thought that it would be more fun and interesting if 2 people played against each other, however, that meant a more complicated item effect algorithm. With that in mind, we decided that we would not be able to create an effective or realistic action items, so we looked into providing the players a wider range of movement.
We originally allowed the player to move only left and right. However, when we added a second player, the right and left mobility was both inadequately challenging and boring. So, we gave the players the ability to move up and down as well, therefore allowing them to switch sides. Finally, we still didn't think that all of these would replace the item effects, so we added the players' option to jump. With the ability to jump, we introduced a third dimension to the game, especially when we created air enemy units. So, when these were all implemented we felt that they satisfied the lack of items in the original design.
Overall Software Design
When we started off with the development, we didn't use any state machines. In the actual program, we used a lot of global variables, but not any user defined types. Basically the game runs in a do loop and various functions and sub programs are called.
AI
Most of our effort on AI was put into the movement of the enemy
The enemy that changes direction randomly is actually coded to follow an invisible box at the bottom of the screen. This way we achieved the effect that the enemy seems to be moving randomly
The enemy follows the player calculate the distances to each of the player at every clock cycle and moves towards the player that is closer to it after determines who is closer.
The movement of the frogs was mainly based on the collision status. regular movement detects collision and bounce him back if collision returns true. when it jumps, there are 3 variables for each frog that record the horizontal and vertical directions that they were moving at, as well as the height. This way, the frog will not jump into the other one. If the jumping forg ended on the top of the other one, it will simply maintain its height and keep moving in the horinzontal direction that it was moving at until it is able to drop back down to the ground.
Special Effect
All animation of the characters are made in 3D Canvas. The introduction and ending of the game was first made in flash files using some templates, then converted to divx files. During this process, there was a little loss of quality because of the codec we chose to use. And also the ending video was actually combined from 3 separate clips and we were forced to take out the origianal sound contained in it. However DBP did a good job mixing the video and the new audio we had by playing them togather. There was no sync problems at all there, unlike when we were trying to combine the video and audio using other softwares.