Bolo (computer game)
From Wikipedia, the free encyclopedia
- For other uses, see Bolo.
| Bolo | |
|---|---|
 |
|
| Developer(s) | Various |
| Publisher(s) | Various |
| Release date(s) | 1982, 1987 |
| Genre(s) | Real-time tactics |
| Mode(s) | Single player, Multiplayer |
| Platform(s) | Apple II, BBC Micro, Mac OS, Mac OS X, Linux, Windows |
| Media | Download |
| System requirements | network connection for multiplayer |
| Input | Keyboard, Mouse |
Bolo is a video game originally developed for the Apple II computer by Synergistic Software in 1982. An update inspired by the original was created for the BBC Micro computer by Stuart Cheshire in 1987, and later ported to the Macintosh in its most popular incarnation. The original Bolo was a single-player game. Cheshire's Bolo is a networked multiplayer game that simulates a tank battlefield. It is thus a very early example of a real-time tactics game. While the graphics are somewhat primitive compared to modern video games, Bolo remains popular.
When the Mac version added TCP/IP networking support, it became one of the first real-time games to be played on the Internet with a large following, preceding major commercial titles by years[citation needed].
Contents |
[edit] Description
In Bolo the player commands a tank that can be driven around a battlefield that is viewed from above. The tank's primary weapon is its cannon which fires only in the direction the tank is pointed and has a fairly fast rate of fire. The tank also carries mines as a secondary weapon, which can be dropped on the move, or which alternately can be planted by an engineer who runs from the tank and "drills" the mine into the ground. The mine is invisible to other players until they drive quite close to it (often too close to stop in time), although it remains visible to the player who planted it, and other members of his team.
Ammunition, both for the cannon and mines, can be refilled at a limited number of supply and repair bases scattered around the map. The bases also repair damage to the tank. Bases can be captured by shooting at them until they are destroyed and then driving onto them. Their supply of ammunition refills slowly, so keeping several bases and protecting them is the primary strategic goal of the game.
A secondary strategic goal, and the primary tactical goal of the game, is the capture and planting of pillboxes, which are also scattered around the map. Pillboxes are initially neutral, and will shoot at any tank that approaches them. Like the supply bases, pillboxes can be shot at until destroyed, at which point they become friendly to that player's team. Unlike the bases, pillboxes can be picked up by the tank's engineer, and then moved to more strategic locations, normally closer to allied supply bases. In the early Macintosh versions the pillboxes were fairly easy to kill, but in later versions this was changed so they progressively increase their rate of fire as they are attacked, eventually becoming extremely deadly. Players have developed an array of tactical tricks to accomplish speedy pillbox capture, such as the decoy (where a player draws fire away from the pillbox while an ally shoots it) and the pillblock (where a friendly pillbox is placed so that it blocks the hostile pillbox's shots but allows the tank to shoot past it at the hostile pillbox).
The engineer can also perform building tasks. In order to do this he must first be sent into a forest to cut trees, which are essentially "cash" in the Bolo world. He can then built roads in order to speed travel, or concrete walls to protect bases and form traps. The engineer can be killed on these missions, and a replacement will parachute in after a time delay. Killing enemy engineers has also developed its own set of tactics, one of the nastiest being to plant a mine in an forest where an enemy is collecting trees.
The game never actually "ends". When one side has successfully captured all of the supply bases and is able to defend them, the other team is in a hopeless position; when they run out of ammunition the are effectively impotent. The game is generally ended when both sides agree to do so.
[edit] Networking
The key to Bolo's popularity was its networking support, which allowed up to sixteen players to join a single game. Networked games (as opposed to online games) were still extremely rare in the late 1980s, and those that were available were generally fairly simple. Bolo was one of the first to allow a net game to be set up quickly and easily, while still being fairly complex and engaging. In the "early days" the game supported only AppleTalk and did so through an interesting implementation that formed the basis of Cheshire's dissertation for Stanford University.
On startup, Bolo advertised itself on the LocalTalk network using the Name Binding Protocol, AppleTalk's system that allowed programs to be registered with human-readable names. If such a service could be found already, the new instance sent a message to that machine, asking to join the game. To the user, this was invisible and automatic.
The game used only a single packet that was sent from machine in a round-robin fashion. Each new instance had its address inserted into one of the sixteen slots in the package, on a first-come-first-serve basis. The packet was then passed to the first machine in the list, who inserted any updates to the state of the player's tank into a payload area, read the next address on the list, and passed the packet along. That machine then received the latest data from all the machines in the packet.
This approach dramatically reduced overall network traffic, compared to a system where updates are sent individually to each machine. In more common networking systems one machine is chosen to be the "host", and the other machines send their updates to that host. Given a sixteen-player game like Bolo, at any particular point in time up to fifteen clients are sending their update data to the host, which then sends fifteen larger packets with the game state back out. Bolo's implementation had only one of the larger packets on the network at any given time. Another major advantage to this system was that there was no "host" machine. Games could join or leave at any time, by simply adding or removing their address from the slots in the packet.
The downside of this approach is that any particular machine has to wait the entire round-trip in order to receive updates. Thus the overall latency was relatively high. In an era when practically every network was "local" and a round trip might take only a few hundred milliseconds this was not a problem, whereas the low speed of LocalTalk might be. In modern networking, where most or all of the links are likely to be over the Internet, the latency of this approach makes it unworkable. Even with "fairly local" players the delay between machines is likely to be a few tens of milliseconds, and a round trip would typically be well over a second.
Unfortunately there was one other problem with the implementation as well. On larger games the machines had to be added to the game roughly in the order of their physical location on the network. If machines were added "at random", all the games would crash. It appears the system included some sort of round-trip timeout, and if the games joined in a fashion that did not minimize the overall latency, it was possible to hit this timeout.
[edit] Versions
Bolo has been ported to Windows and Linux by John Morrison, under the names WinBolo and LinBolo.
There are two independently developed Mac OS X versions of Bolo. One is XBolo by Genga Software, which seems to be out of current development. The other is nuBolo by C.R. Osterwald, which is a direct port of the original Bolo 0.997 source code. Neither of these versions is capable of networking with the WinBolo or LinBolo clones (according to the XBolo readme, the author states he has not received a reply in his request for documentation of the networking function from the WinBolo/LinBolo group).
In more recent times (2004) a Palm OS freeware version was released by the third-party developer Konstantin Dimitrov under the name Bolo: Resurrection.
