Sunday, November 1, 1998

Finishing up Rocketship

PROGRAMMING POWER

By Alan Jay Weiner

In my previous two columns, I worked on a small game for my son. This month we'll finish it off by adding a goal (docking the rocket with a space station), a win or lose response, and some changes here and there.

Along with the changes to the Rocketship game, we'll look at how I took a short cut with the animation, and why it won't work for games with more intense animation. The full listing for the November installment of Rocketship is at http://www.component-net.com/pp-extras/rocket1198.html.

Sources for GCC

First let's start with some great news for GCC users. Two readers sent copies of their port to GCC. I made a few changes in this month's version to make it easier to port to GCC and I'll have a GCC version available for download on my personal website at http://www.ajw.com.

This month we continue the Rocketship game, adding several new features and changing a number of things that already existed.

Changes to Rocketship

Let's quickly go over the new things for this month. For porting to GCC, I changed some bitmap numbers. The application icon always has an ID number of 1000 and when dumping the bitmaps, this was annoying to deal with if there was also a bitmap with an ID of 1000. Additionally, I merged everything to a single source file. This was just easier to deal with all around. In reality, many of the small routines are in a library that I use for most of my applications. As you program you'll create your own library of useful, little routines.

For game play, the biggest change is to add a goal and a response upon winning or losing. Since this is still a game for my son and he's only four years old, the goal is rather simple -- when the game starts, a small docking bay appears at the top of the screen. The goal is to dock the rocket with the docking bay. When the rocket reaches the docking bay or crashes into the rest of the docking ships either a smiling face or a frowning face appears.

This necessitated changing the start and reset sequences. Instead of starting a new game immediately upon game completion, it needs to display the final response and wait for to the user to reset for a new game. I implemented this as a state machine. The game is in one of the following states: ready to play, initializing the docking day, playing, or game over.

Up until now, we displayed bitmaps directly from the resources; opening the resources, display it, and closing it each time it's displayed. To improve performance, this month I changed the program's behavior so that it opens several bitmaps at the start of the game and leaves them open until the game exits, at which time they're each closed.