| Name: | Bobobot |
|---|---|
| Version: | Preview 2 |
| Authors: | Melissa Hardenbrook, Bill Kendrick, Marianne Waage |
| License: | Free, but requests distribution without changes |
| Operating System: | Linux (possibly other Unixes) |
| Website: | http://www.newbreedsoftware.com/bobobot/ |
Bobobot is a platform arcade game based after Capcom's MegaMan series. From the Bobobot web site:
This is the story of "BoboBot," the robo-monkey. Built by the World Peace Federation, BoboBot is one of the most powerful robots on Earth.
But now, an evil force has begun taking control of Earth, and it's his job to stop it. To do this, BoboBot must travel the globe and defeat eight evil bosses to get access to the evil force, wherever it is hiding. As he defeats these bosses, he also gains special weapons and abilities.
The game does a pretty good job capturing the feel of MegaMan. It has the ice, conveyor belts, and bosses, as you would expect. Its main difference is the lack of scrolling.
None of the game development kits were used for the display, instead it uses X windows. Unlike many action games under X, it doesn't use the shared memory extensions. It has a fixed window size of 320 by 256 which allows for 32 tiles in both directions.
The tiles for the game are stored in ppm files. They are converted to X pixmaps when loaded. This process takes some time, which causes the game to wait while initially loading. Under 256 color mode I noticed some of the images were totally black. Currently colors are added as needed without any check for failures from XAllocColor. Because the colors are added as needed there is no easy recovery procedure even if you detect the problem. If you knew the whole palette before hand you could check if there are enough free color cells and perhaps modify the palette to fit the available slots. At some point you would still have to allocate a private color map or abort.
Three background screens are stored for a single area. This allows tiles to have up to three images giving the impression of movement. Each turn the appropriate background is copied to the main drawing area and all the sprites are drawn. Although keeping three copies of the screen may waste some memory, it may be faster than trying to draw all the moving backgrounds.
Sound uses the SDL Libraries. Music is done through the mixer library available in the SDL Examples. The sounds are stored as simple wav files. Similarly music is stored as mod files. I haven't installed either so I don't know how good they sound. The API looks rather simple and easy to use.
Keyboard input is done through the standard X library functions. Interestingly the author choose to convert keyboard symbols to strings. Comparison then requires string compares instead of integer equality. Although most modern systems are sufficient to handle such a process, I've constructed a patch to remove most of it.
In constructing this patch, I discovered that the input process is duplicated in a couple of places, making the changes more complex. Each area accepts a slightly different input which would make a generalized input function more difficult but not impossible. Early in the program, there are defines for the keyboard commands but the input functions check a lot more than that. (There is a hidden feature on the menu screen for those who read the code.)
Joystick support is available under Linux as well.
Ensuring a consistent game speed is very important to a game. Bobobot attempts to use frames of 22500 microseconds. This gives about 44 frames per second. At the beginning of an event loop the program checks the time with gettimeofday. After all activities are done, gettimeofday is once again called. If less than 22500 microseconds have passed, the program calls usleep for the remaining time. If the program is running on a slow computer, it will run as quickly as possible but no frames will be skipped.
The core of most games is the event loop. Basically input is read, everyone performs an action, graphics are displayed, and then the program waits until it's time to do it again. In Bobobot this is done in the aptly named eventloop function.
This function may look a bit daunting because of the 3500+ lines. Although I personally prefer small functions, Bill Kendrick has made extensive use of white space and comments to ensure readability. For the most part, each thing in the game has it's own array. The problem with having so many arrays is that they consume memory even when not in use. Since not all the elements may be active you're forced to either sort active items to the array's front or use a byte to signify active or not.
The enemies array is one of the unusual ones in that it has a type code that distinguishes what enemy type it contains. An immense if-then-else-if statement performs the appropriate action for the monster. Two of these massive control structures are needed, one for actions and one for sprite display. The second could possibly have been avoided by adding a sprite field to the enemy data. This would prevent displaying two images for the monster simultaneously but that is not currently done.
The level data is stored in simple text files. Up to 100 screens may be store for a single level. Here is a sample from the first screen of Freeze Man's level:
0: QQQQQQQQQQ Q`'QQQQQQQ QQQQQQQQQQ QQQQQQ`'QQ <=====>QQQ IIIIIII>== IIIIIIIIII WWWWWWWWWW -1 1 -1 -1 S Antarctica 0 6 5 ENDIt begins with screen number and colon. The next eight lines describe the screen. The four numbers specify what screen to goto when leaving the screen. A negative one indicates the direction is impassable. This is followed by a string specifying anything special about the screen. In this case the screen is snowy. Antarctica is the text that appears when you first come onto the screen. The rest of the data until the "END" tag describes the monsters and where they are.
Using a text file allows it to be edited without any special tools but doesn't allow you to see the result until the game is run. For Bobobot you have to keep a list of what all the different letters translate to on screen.
Another thing to note is the text included in the level file. If someone later wishes to translate the game to French, he would have to create new level files. This could be avoided by keeping the text in a separate file and storing some sort of indicator to it. That way any new language would just modify the single file. This patch does just that. Now this isn't a total solution unless the text is removed from the executable as well.
Despite the easily changed level files the stage select is hard coded into the executable. One could potentially move this information into the level files. It would alleviate this problem, but would require searching each of the level files first. Another possibility is creating a separate file containing stage select information.