The main software that we implement was the design and development of two games, this in order to evaluate our system. The two games that we designed were Tetris and Blue racing.
6.1.1. General description
The concept of the game is based on the original Nintendo game. The idea of the game is to remove lines that are generated during the game. (See Figure 6.1)
Figure 6.1: Tetris screenshot.
6.1.2. How to play
As blocks fall downwards the player should remove them by using the navigation key on the Gameboy, to direct the falling blocks in openings to remove lines. In Tetris one has the ability to remove 1 to 4 lines depending on the block and space available.
6.1.3. Short description of the Code
To make it easier to make menus, a menu library was made, where one can create a data structure describing a menu, and then just call a menu function that return what was selected. In the menu system is mostly to select different kind of games and dial-up menus. In the game state, we use no sprites, all block changes are made in the background tilemap. All blocks are stored as relative positions to the center block. For blocks there are three different operations put, removed and test. Put and remove just put/remove blocks to/from screen. The test routine checks if there is any pixels set on the block positions where the block should be put. If pixels are set, then the block canít be put there. Most of the game state code in Tetris is based on a previous game project by Rickard Gunéeís micro controller page, which can be found at www.i.am/thekingofpic. The source code for Tetris is available in Appendix C.
There is not much data sent between the two players during the game, just one byte when a line is removed telling the opponent to scroll up. One byte is also sent when a player looses or quits.
The delay is a small problem. As delays from Bluetooth and GSM are added, we get a delay of 1-2seconds. In Tetris however, this is not critical, as the play-field is not shared between the two players.
To make the game a little bit more interesting we also send a screen dump, showing the opponentís play-field. Each dump is 33 bytes sent, and the screen is dumped a couple of times per second. It is the screen dump that requires most of the bandwidth, but the bandwidth available is much higher than needed. The bottleneck of the system is the CPU in the Gameboy as we overload it too much. We added a menu alternative to select how often we should update the screen dump, and we found that about every 64 screen (about one frame per second) could be sent if the system should remain stable enough for a demonstration. Since the 64Mb cartridges had a built-in vibrator to create a rumble effect, we implemented this in the game. The rumble effect is turned on when a line is received from the opponent.
6.1.5. Evaluation of the Game
When the game is set to not send any screen dumps it works very well. Thanks to the nature of the game, the delays are not any problems. When screen dumps are sent, the game usually crashes quite often, but that is due to that the serial solution canít handle this amount of data. This game really doesnít push the system very far, but is very fun to play, the rumble feature really makes one feel the presence of the opponent even though he might be hundred of kilometers away.
6.2. Blue racing
6.2.1. General description
The concept of the game is based on a multi-player racing game, where in two-player case you have a map of the whole circuit in the memory but you as a player only see the part that is relevant for you. (See Figure 6.2 where the views for the two players are marked as rectangles.). This is not a complete car racing game, a real game would for example require much more physics and menu systems etc. The delay would also require some common time to synchronize all events on both screen, which would require some predicting routines to predict where the cars will be in when the information arrives on the opposite side.
Figure 6.2 : Blue Racing screenshot.
6.2.2. How to play
The players steer their cars by using the navigation key on the Gameboy. It is just two cars on a common map. One has to count the score and make sure the opponent does not cheat manually.
6.2.3. Short description of the Code
The menu systems work just like for Tetris. In the game state, sprites are used for the cars, four for each car. There are 24 angles of the cars in the graphics. By setting different palettes on the sprites, the cars get different colors even though they are using the same sprite data. The background is 32x32 tiles and is loaded at the beginning of the game and then scrolled by setting the position of the screen. When the car is getting close to the edge, the screen is moved so the background gets scrolled. As the car position of the opponents car isnít given each frame the position is interpolated based on the old speed and angle until the correct coordinates are received. There is no common time, to car position predicting routines would be needed to make a real game with collision detection and lap counter. See the source code for the game in Appendix D.
The main data that is sent between the Gameboy consoles are sync, position, angle and speed.
As mentioned before timing is very critical here, as the delays are between 1 to 2 second one has to solve this problem by either guessing, interpolating or predicting.
In our game bandwidth is not critical but can be a problem in an actual game.
6.2.5. Evaluation of the Game
This game turned out to be extremely demanding, resulting in that it frequently crashed the system. Like in the Tetris game this was due to the fact that the Gameboy uses too much time communicating, and would probably work for the cartridge or GBA solution. The game was not completely developed, there is no common time, so if a real game was to develop, more had to be done with the delay problems.