Bolo (1987 video game)
| Bolo | |
|---|---|
| Developer(s) | Various |
| Publisher(s) | Various |
| Platform(s) | BBC Micro, Mac OS, Mac OS X, Linux, Windows |
| Release date(s) | 1987 |
| Genre(s) | Tactical shooter |
| Mode(s) | Single player, Multiplayer |
Bolo is a video game created for the BBC Micro computer by Stuart Cheshire in 1987, and later ported to the Macintosh in its most popular incarnation. It is a networked multiplayer game that simulates a tank battlefield. It was one of the earliest simultaneous multiplayer networked games.
A similarly named tank game was created for the Apple II in 1982. Cheshire says this was "an unfortunate coincidence",[1] and that his Indian wife inspired the name. As Cheshire noted in his original documentation for the game, "Bolo is the Hindi word for communication. Bolo is about computers communicating on the network, and more important about humans communicating with each other, as they argue, negotiate, form alliances, agree strategies, etc."[2]
Description
In Bolo, the player commands a tank that can be driven around a battlefield within an orthogonal, top-down view. This gives the visual impression that the battlefield is being viewed from above with the player's tank being controlled remotely. The tank is relatively well armored and will take a number of "hits" before being destroyed. Tanks can also be destroyed by driving them into deep sea.
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 planted by an engineer who runs from the tank and "drills" the mine into the ground. In games where the "Hidden Mines" setting is activated, such mines are invisible to other players until they drive quite close to them (often too close to stop in time). Hidden mines remain visible to the player who planted them, and to 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. The bases also repair damage to tanks, but this depletes the "armor" of the base. Bases' supplies of ammunition and armor refill slowly.
The strategic goal of the game is to capture all of the bases on the map. Unclaimed "neutral" bases may be claimed by simply driving one's tank over them, after which the player and his/her team may draw upon such "friendly" bases' resources. "Hostile" bases can be captured by shooting them until their armor supply is reduced to zero, after which any player may drive over them to claim them for one's own team. Bases that have recently re-armored damaged tanks are more easily seized since their armor supplies take some time to regenerate.
A primary tactic 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, after which they can be redeployed and 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. In the early Macintosh versions, the pillboxes were fairly easy to kill; in later versions, pillboxes 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 various pilltakes (where one or more walls and/or friendly pillboxes are placed so that they block the hostile pillbox's shots but allow the tank to shoot past it at the hostile pillbox).
The engineer, better known as the "LGM" (for "little green man") can also perform building tasks. In order to do this he must first be sent into a forest to cut trees, which act as cash in the Bolo world. He can then build 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 a forest where an enemy is known to be collecting trees.
Internet games typically begin with a period in which teams are set up while players remain in deep sea, generally returning to agreed-upon starting points prior to an agreed-upon signal initiating active gameplay. The next phase is usually a base run where players attempt to quickly seize as many neutral bases as possible. After this initial phase, various strategies may be employed. Most involve the quick capture of a number of neutral pillboxes, which may be used defensively to prevent opponents from aggressive attacks on one's bases, which can quickly result in resource depletion. Pillboxes are frequently used offensively, however, by pushing them forward toward an opponent's bases, using their firepower to control territory. Games frequently feature fronts of opposing pillboxes – when one side breaks through or flanks the opponent's front, they will often deploy pillboxes to spike bases and force the opposition to refuel farther back. Eventually, the successful team will push more pillboxes forward and/or seize ill-defended enemy bases, progressively limiting the territory of its opponent until all of the enemy's bases are captured or under fire.
Although it is possible to set a time limit, this feature was rarely used. Instead, the game ends when one side has successfully captured all of the supply bases, preventing the other team from gaining ammunition. In practice, most games generally end before all the bases have been captured, as the losing team concedes that its supply situation has become untenable due to a combination of lost and spiked bases.
Networking
Bolo's networking support allows 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. The game supported only AppleTalk and did so through an implementation that formed the basis of Cheshire's dissertation for Stanford University.
AppleTalk included a feature known as Name Binding Protocol (NBP) that assigned human-readable names to network addresses. This was commonly used to find printers, file servers, and other network resources. In Bolo it was also used to find games on the LAN. 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, say "Stewart's Bolo Game". New players starting up could then join this game by name, and if they did so their own machine would also register itself on the network with the same "Stewart's Bolo Game".
The game used only a single packet that was sent from 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. In most common networking schemes one machine is chosen to be the host, and the other machines send their updates to that host, which then sends the aggregated updates out to all of the machines again. Given a sixteen-player game like Bolo, at any particular point in time up to fifteen clients would send their update data to the host, which then sends fifteen larger packets with the game state back out. Bolo's implementation had only one large packet on the network at any given time, greatly reducing traffic.
In the case of a newly starting game, the first machine to start up would generate the packet, but seeing no other addresses in the list, would do nothing. When a new player asked to join a game, they did so by sending an interrogation packet to the first machine that responded when it asked NBP to list all the Bolo Game machines on the network. In this example there is only one such machine on the network so far, so the new machine would send this request to the machine that started the game. That machine would respond by sending back the current game state, inserting the new machine's address into the packet, and then handing the packet off. The packet would then bounce between the two machines. If another machine joined, the list generated by NBP could return either of the machines already listed in "Stewart's Bolo Game" as the first hit, so in this fashion even joining the game was distributed across the machines.
The advantage to this design was that there was no host machine. 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 the game was completely headless; even if the starting user left the game, the rest of the machines in the game would continue to pass the packet and respond to join requests as normal. As long as there was at least one machine remaining in any particular game, it would continue to be available for new players to join.
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 most networks were local and a round trip might take only a few hundred milliseconds, this was not a problem, whereas the low throughput of LocalTalk could be if the protocol used many separate packets. 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.
References
- ↑ "MacBolo Instructions". Retrieved 27 May 2007.
- ↑ "Frequently Asked Questions". 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.
External links
- Bolo home page
- Stuart Cheshire, the author of Bolo