| Revision as of 18:20, 5 June 2020 editPJvanMill (talk | contribs)Extended confirmed users2,301 edits →Description: trimming down this section← Previous edit | Revision as of 18:28, 5 June 2020 edit undoPJvanMill (talk | contribs)Extended confirmed users2,301 edits →Further reading: adding a potential sourceNext edit → | ||
| Line 75: | Line 75: | ||
| ==Further reading== | ==Further reading== | ||
| {{refbegin}} | {{refbegin}} | ||
| * Andrew Wilson and Stephen Intille, , MIT Media Lab Fall 1995 - this paper describes using Bolo as a system for developing a ] system. | * Andrew Wilson and Stephen Intille, , MIT Media Lab Fall 1995 - this paper describes using Bolo as a system for developing a ] system.<!--Did this paper appear in a peer-reviewed journal, or has it been cited by other papers a significant number of times?--> | ||
| *Silberman, S. (1995). . NetGuide Magazine, May issue. Archived from on the 5th of June, 2020. | |||
| {{refend}} | {{refend}} | ||
| <!--Did this paper appear in a peer-reviewed journal, or has it been cited by other papers a significant number of times?--> | |||
| == External links == | == External links == | ||
Revision as of 18:28, 5 June 2020
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
| 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 |
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.
Name
Another tank game with the same name was created for the Apple II in 1982. Cheshire says this was "an unfortunate coincidence". He says that the name comes from the Hindi word for communication, which is "bolo".
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 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 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. 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". 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