My role in this project was head of environment design. While this was my main job, most of the work I did was integrating different versions of the code, and fixing glitches as they arose.
The first week or so was devoted to working through the Whack-a-Mole and Fish Game tutorials. I didn't finish the tutorials, I just worked through them until I felt comfortable enough with TGB and torquescript to start my own coding.
The fish tutorial was useful for learning how to deal with collisions, and the Whack-a-Mole was good for learning how to spawn t2d scene objects at random locations. Once I knew how to do this, I felt I was ready to start working on the environment.
Programming the environment meant a couple of things. One of our ideas from the start was to have randomly placed obstacles within each level, to reduce the amount of coding. The other idea is that these obstacles are all interactive, and can be blown up by bullets or mines.
Below is an example of the original level generator, which contains a bouncing bullet. The bullet just bounces around the level damaging the bolt obstacles. The bitmap on the bolts is changed each time it's hit, and after 3 times it gets removed.
This code served as a template for the random level generator Chris used to place obstacles on his AI grid.
This code includes code for a tank that can lay mines. The tank (represented by a stand-in image of an asteroid) can move around using WASD and lay mines using space bar. The mines explode after five seconds (with a cute stand-in animation of a Whack-A-Mole). The explosions destroy any nearby tanks or obstacles. There is also a button to upgrade the number of mines you can have on the screen at any time.
Mines contains source code for the random level generation, source code for mines, and playable build
The upgrade button was eventually trashed. We originally planned on having a lot of different upgrades you could purchase, but in the end we settled on only three upgrades (mines weren't one of them).
Peter and I spent a couple of afternoons integrating this mine code with the tank he coded. We used my Mines code as a template, and added in things that Peter had created such as a sweet particle effect explosion. We also added code features to make the mines explode when they are shot by your bullets, but not enemy bullets. This can be useful during the gameplay to make an impomptu wall. Finally we made it so that if you run into your own mine, it will set off. Coding this was interesting, because we had to schedule collision callback to be enabled, so that we wouldn't call the collision->explosion as soon as the mine came down. Our mine code can be seen in the final game (Located on smb://filer/personal/tinyTanks/Greg/TinyTanksMac.4.2).
One problem we had with the tank was that its turret would only get refreshed when the mouse moved. If you held the mouse still, you could orient the tank so that it was between the crosshairs and the turret, so that when the bullet was fired it would hit the tank on its way to the crosshairs. I used Peter's onMouseMove code as a template to write an onUpdate for the turret rotation. This way the turret is always refreshing so you wouldn't be able to shoot yourself.
After integrating the environment with the tank, we had to make some changes to make it compatible with other aspects of the game. For example, most the tank's fields (such as speed and armor) were set up coded in torquescript without global variables, so they couldn't be changed later by upgrades. To fix this, I went back and added several global variables to control different aspects of the tank. These global variables could then be changed in Nikki's upgrade GUI to change different aspects of the tank.
Other issues concerning gameplay included adding multiple levels. Peter and I worked on changing the code in the GUI to load a random level whenever the play button is hit. Andrew fixed some bugs with this where enemy tanks weren't being removed properly after each level.
Another concern was the enemy tank difficulty. We messed around with changing the enemy firing rate and bullet speed. Eventually I decided to code a version where the tanks firing speed and bullet speed were controlled by global variables, which increase as you kill more tanks. In all the levels, enemy tanks start with the same firing rate and bullet speed. However, each level requires you to kill more enemies in order to pass. Eventually the enemies start getting very difficult, shooting what appears to be a rapid-fire cannon.
I also wrote a couple of songs. The first one was used for the Startup splash screen. The other one didn't make it into the game (I guess it was a little too hardcore for a "Toy Tanks" game, but maybe you'll hear it next semester in my 3D game!)
While there are countless other small changes and bugs I worked out when coding this program, I feel that I have highlighted the most important ones. All in all I thought this was a very interesting project, and I learned a ton about using TGB, which should come in handy over the next semester. I'm very satisfied with the final product (although as Peter said, we could keep working as long as we want and still find new things to add or change). Thanks for an awesome JanPlan!