This is an old revision of this page, as edited by Maury Markowitz (talk | contribs) at 21:32, 22 September 2006 (wording). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Revision as of 21:32, 22 September 2006 by Maury Markowitz (talk | contribs) (wording)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff) For other uses, see Bolo.1982 video game| Bolo | |
|---|---|
| XBolo for Mac OS X. | |
| Developer(s) | Various |
| Publisher(s) | Various |
| Platform(s) | Apple II, BBC Micro, Mac OS, Mac OS X, Linux, Windows |
| Release | 1982 |
| Genre(s) | Real-time tactics |
| Mode(s) | Single player, Multiplayer |
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 a popular and addictive phenomenon.
Description
In Bolo, the player commands a tank that can be driven around a battlefield viewed from above. The tank's primary weapon is its cannon, which has a fairly fast rate of fire. As a secondary weapon, the tank also stocks mines, which can be planted by an engineer who runs for the tank and "drills" the mine into the ground. The mine is invisible to other players, 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 bases scattered around the map. Bases can be captured by shooting at them 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 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 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 methodologies, one of the nastiest being to plant a mine in an forest where an enemy is collecting trees.
Networking
Key to Bolo's popularity was its networking support, which allowed up to sixteen players to join a single game. In the "early days" the game supported only AppleTalk (for obvious reasons) and did so through an interesting implementation that formed the basis of Cheshire's dissertation.
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.
The 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. Most modern games still require one machine to act as the "host", and if the host exits the game all the other players are "kicked off" as well. Given the need to lower latency as much as possible, this sort of architecture may be difficult to avoid, however. A single host can asynchronously receive and send data to all of the players in the game at the same time, whereas with the packet-passing system the data is not received until it has passed through all of the other machines; given a "ping" time on the order of a few tens of millisecond common on the internet, this might mean that updates will not be seen for periods well over a second. Bolo's system sacrificed latency for traffic, a very reasonable trade-off in an era when practically every network was local.
Unfortunately there was one 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 a hard round-trip timeout, and if the games joined in a fashion that didn't minimize the latency between machines, it was possible to hit this timeout.
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 PalmOS freeware version was released by the third-party developer Konstantin Dimitrov under the name Bolo: Resurrection.
External links
- Mobygames entry on the original 1982 Bolo
- Official home page
- Stuart Cheshire, the author of Bolo
- Windows and Linux version and league site
- WinBolo.us community website
- Cool Fool's Bolo Multimedia Website
- Xbolo (Mac OS X version)
- nuBolo (alternate Mac OS X version)