Bolo (computer game)
Encyclopedia
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. Most recently a Windows clone named Winbolo was developed by John Morrison. Cheshire's Bolo is a networked multiplayer game that simulates a tank
battlefield.
A similarly named tank game was created for the Apple II in 1982. Cheshire claims this was "an unfortunate coincidence", 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 stategies, etc."
In Bolo the player commands a tank that can be driven around a battlefield that is viewed from above. 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 too-deep water.
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 hostile, 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 "baseraping" (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.
and did so through an implementation that formed the basis of Cheshire's dissertation for Stanford University
.
AppleTalk included a protocol 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 Bolo "devices", producing a list of games. 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. Each machine in the game inserted its AppleTalk address into one of the sixteen slots in the packet, on a first-come-first-serve 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 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 packet on the network at any given time, similar to the larger "return" packet of the conventional approach.
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 "Stewart's 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 practically every network was "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. 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.
One other problem with the implementation was that 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.
BBC Micro
The BBC Microcomputer System, or BBC Micro, was a series of microcomputers and associated peripherals designed and built by Acorn Computers for the BBC Computer Literacy Project, operated by the British Broadcasting Corporation...
computer by Stuart Cheshire
Stuart Cheshire
Stuart Cheshire is the author of Bolo, a networked tank game, originally written for the BBC Micro and later ported to the Apple Macintosh....
in 1987, and later ported to the Macintosh in its most popular incarnation. Most recently a Windows clone named Winbolo was developed by John Morrison. Cheshire's Bolo is a networked multiplayer game that simulates a tank
Tank
A tank is a tracked, armoured fighting vehicle designed for front-line combat which combines operational mobility, tactical offensive, and defensive capabilities...
battlefield.
A similarly named tank game was created for the Apple II in 1982. Cheshire claims this was "an unfortunate coincidence", 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 stategies, etc."
Description
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 hostile, 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
Parachute
A parachute is a device used to slow the motion of an object through an atmosphere by creating drag, or in the case of ram-air parachutes, aerodynamic lift. Parachutes are usually made out of light, strong cloth, originally silk, now most commonly nylon...
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 "baseraping" (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
Bolos 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 AppleTalkAppleTalk
AppleTalk is a proprietary suite of protocols developed by Apple Inc. for networking computers. It was included in the original Macintosh released in 1984, but is now unsupported as of the release of Mac OS X v10.6 in 2009 in favor of TCP/IP networking...
and did so through an implementation that formed the basis of Cheshire's dissertation for Stanford University
Stanford University
The Leland Stanford Junior University, commonly referred to as Stanford University or Stanford, is a private research university on an campus located near Palo Alto, California. It is situated in the northwestern Santa Clara Valley on the San Francisco Peninsula, approximately northwest of San...
.
AppleTalk included a protocol 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 Bolo "devices", producing a list of games. 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
Round-robin
The term round-robin was originally used to describe a document signed by multiple parties in a circle to make it more difficult to determine the order in which it was signed, thus preventing a ringleader from being identified...
fashion. Each machine in the game inserted its AppleTalk address into one of the sixteen slots in the packet, on a first-come-first-serve 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 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 packet on the network at any given time, similar to the larger "return" packet of the conventional approach.
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 "Stewart's 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
Lag
Lag is a common word meaning to fail to keep up or to fall behind. In real-time applications, the term is used when the application fails to respond in a timely fashion to inputs...
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 throughput of LocalTalk
LocalTalk
LocalTalk is a particular implementation of the physical layer of the AppleTalk networking system from Apple Computer. LocalTalk specifies a system of shielded twisted pair cabling, plugged into self-terminating transceivers, running at a rate of 230.4 kbit/s...
could be. In modern networking, where most or all of the links are likely to be over the Internet
Internet
The Internet is a global system of interconnected computer networks that use the standard Internet protocol suite to serve billions of users worldwide...
, 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.
One other problem with the implementation was that 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.
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 exampleProgramming by exampleIn computer science, programming by example , also known as programming by demonstration or more generally as demonstrational programming, is an End-user development technique for teaching a computer new behavior by demonstrating actions on concrete examples...
system.