Bolo (1987 video game)
Bolo is a video game initially created for the BBC Micro computer by Stuart Cheshire in 1987. It is a networked multiplayer game that simulates a tank battlefield. It was one of the earliest simultaneous multiplayer networked games.
| Bolo | |
|---|---|
| Developer(s) | Various |
| Publisher(s) | Various |
| Platform(s) | BBC Micro, Mac OS, Mac OS X, Linux, Windows |
| Release | 1987 |
| Genre(s) | Tactical shooter |
| Mode(s) | Single player, Multiplayer |
Name
Another tank game with the same name was created for the Apple II in 1982. Cheshire says this was "an unfortunate coincidence".[1] He says that the name comes from the Hindi word for communication, which is "bolo".[2]
Description
Players are divided into two teams. Each player commands a tank that can be driven around a battlefield within an orthogonal, top-down view. The tank has a cannon, which fires forward, and it carries mines as a secondary weapon, which can be dropped while moving or be placed somewhere on the map. Tanks have a certain amount of "armor" (hit points), which is reduced by enemy shots. A tank is destroyed if its armor reaches zero or if it is driven into the sea.
Cannon ammunition and mines can be refilled by going to a friendly "base". The bases also repair damage to tanks, but this depletes the base's armor. Bases' ammunition and armor regenerate slowly.
The goal of the game is to capture all of the bases on the map. Neutral bases may be captured by driving one's tank over them. Hostile bases can be made neutral again by shooting them until their armor supply is reduced to zero.
Another game element is the "pillbox". Pillboxes are initially neutral and will shoot at any tank that approaches them. Like the supply bases, pillboxes can be shot at until destroyed, after which a player can restore it, making it friendly. Unlike the bases, pillboxes can be moved around the map by the players.
Inside the tank is an engineer, who places mines and moves pillboxes. The engineer can also perform building tasks, after collecting wood in a forest. The structures that can be built are roads, which speed up travel, and walls, which act as a barrier. The engineer can be killed by enemies while out of the tank.
Networking
Bolo's networking support allows up to sixteen players to join a single game. Networked games were still extremely rare in the late 1980s, and those that were available were generally fairly simple. The game supported only AppleTalk.
Bolo made use of AppleTalk's Name Binding Protocol (NBP) that assigned human-readable names to network addresses. On startup, Bolo would use NBP to find all the devices advertising a Bolo port, collecting the unique names to produce a games list. These were then presented to the user, allowing them to select an existing game, or start a new one. If the user chose to start a new game, Bolo then registered a new Bolo device with NBP. New players starting up could then join this game by name, and if they did so their own machine would register itself on the network with the same name.
The game used only a single packet that was sent from machine to machine in a round-robin fashion. The packet was fixed-length, with enough room to carry the information for the sixteen players. Each machine in the game inserted its AppleTalk address into one of the sixteen slots in the packet, on a first-come, first-served basis. The first machine on the list would insert its game data (position, whether they are firing, etc.) into a payload area, then look for the next address on the list and send the packet there. That machine would then read out the first's state, insert its own, and pass it off again. The list was looped, so the last machine would send the packet back to the first. After one such loop, the packet contained the game state for every player.
The single-packet approach reduced network traffic compared to a system where updates are sent individually to each machine. This was advantageous in a time when computer networks were much less powerful than they are today. The downside of this approach is that any particular machine has to wait the entire round-trip in order to receive updates, which results in high latency. In an era when most networks were local and a round trip might take only a few hundred milliseconds, this was not a problem. In modern networking, however, the latency matters a lot more, because most or all of the links are likely to be over the Internet.
One consequence of the design is that it was completely decentralised. New players could join by sending a request to anyone, and existing players could leave by simply removing their address from their slot in the packet. This meant that if the starting user left the game, the rest of the machines in the game could continue as normal.
References
- "MacBolo Instructions". Archived from the original on 18 May 2007. Retrieved 27 May 2007.
- "Frequently Asked Questions". Archived from the original on 18 May 2007. Retrieved 27 May 2007.
Further reading
- Andrew Wilson and Stephen Intille, "Programming a Bolo Robot: Recognizing Actions By Example", MIT Media Lab Fall 1995 - this paper describes using Bolo as a system for developing a programming by example system.
- Silberman, S. (1995). O Bolo Mio. NetGuide Magazine, May issue. Archived from the original on the 5th of June, 2020.
External links
- Bolo home page
- Stuart Cheshire, the author of Bolo