History of Bolo
Bolo was a video game released on the Apple II computers in 1982 by Synergistic Software, partly inspired by an earlier novel, Bolo: Annals of the Dinochrome Brigade, which features self-aware, intelligent tanks.
This Interpretation
As part of my experiments with the Windows Phone platform and parallel building on the XBLA platform (Xbox Live Arcade), I decided to create an interpretation of the original game as a homage.
There are a few interpretations and clones floating around the internet, but they are either direct clones or re-imagined versions with new features.
I decided to create a flexible environment that allows players to enjoy the original concept of the game or choose a more modern interpretation with additional enemies, obstacles and intelligence.
Versions
I created 3 versions, with increasingly more difficult and complex features, as outlined below:
*Galaga is a homage to the classic Namco/Midway game, Galaga, created in 1981 by Namco in Japan, and published by Midway globally. If you are interested in this game, check out their latest rendition, Galaga Legions, for Xbox Live.
Objective of the Game
The objective is simple - destroy each of the enemy bases on each level without being destroyed yourself. The player starts with 4 lives, infinite weapons, but finite fuel for the tank.
The player must destroy or avoid the hordes of enemy tanks (some of which fire back, and some of which will chase the player), and complete the mission before the player's tank runs out of fuel.
Fuel can be replenished by destroying an enemy base, or in the re-imagined version, by collecting fuel tanks.
Windows Phone Interpretation
Due to the resolution of the windows phone, the game play is oriented into the landscape mode, to provide players with a more natural orientation.
Movement
Whilst it is relatively trivial to implement true 360 degree movement, I decided to implement 8-direction movement in the spirit of the original game.
Components
The game components are surprisingly simple - a set of sprites are used to represent the enemies, the player, bullets and missiles, various obstacles, the enemy bases and the walls of the arena.
Intelligent Enemies
One of the challenges I encountered was a mechanism for creating enemy tank that demonstrated a level of intelligence - in this instance, the ability for an enemy to follow or chase the player.
Each level contains a random set of walls and obstacles, and whilst the walls don't represent a maze in the true sense of the word, a maze-solving algorithm is the fastest and simplest approach to creating a process that controls the direction of intelligent enemy tanks.
To accomplish this, I have turned to the A* (pronounced A-Star ) path finding algorithm - a process designed to evaluate the most efficient path between two points whilst avoiding obstacles.
This algorithm was first described in detail in the 1960 s at SRI, and has been expanded upon somewhat over the years.
A simple way to describe this algorithm in the context of this game is the simple formula:
Where
- G is the movement cost for the enemy cost in order for it to move to an adjacent position
- H is a the estimated distance between the enemy tank and the player.
As the game is effectively a large grid, G can be calculated based on the distance the enemy has to travel to the next square in the game.
As the distance to move diagonally is slightly more than horizontally or vertically, diagonal squares are weighted slightly more. This provides a form of preference for horizontal or vertical movement.
H can be calculated quite literally by finding the distance between the enemy on a 2 dimensional grid and the player on the same grid. This is a simple high-school formula - one of those that you never think you'll use in real life, but end up finding an actual use for it!
or in .NET parlance:
Math.Sqrt((Math.Abs(X2 – X1) ^ 2) + (Math.Abs(Y2 – Y1) ^ 2))
We then cycle through each of the 8 possible directions that the enemy can travel, and calculate the value of F by adding G and H.
The algorithm then finds the smallest value of F, which is chosen as the best path .
This whole process is repeated as the enemy continues to move according to each best path, with the result that it will complete its journey to the player unimpeded.
In my implementation, and grid item that contains an obstacle (such as a wall, a gravity mine, an enemy base, etc.) is assigned a very high H value, to ensure that it does not get chosen as a valid path.
By creating a little test application, the process can be tested very easily and quickly, to iron out any bugs or obstacle-related algorithm faults.
What's Next?
Future versions may include network connectivity to allow for cooperative play between players, and a level editor to allow people to create custom levels to replace the randomly generated arena.
I’m in the process of improving the sprites and sound effects, and resolving a few remaining collision detection issues. Once finished, this game will be put live on the Windows Marketplace.
Interesting References and Further Reading
