Bolo (video game)
From Wikipedia, the free encyclopedia
| Bolo | |
|---|---|
| Developer(s) | Various |
| Publisher(s) | Various |
| Platform(s) | BBC Micro, Mac OS, Mac OS X, Linux, Windows |
| Release date | 1987 |
| Genre(s) | Tactical shooter |
| Mode(s) | Single player, Multiplayer |
| Media | Download |
| System requirements | network connection for multiplayer |
| Input methods | Keyboard, Mouse |
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. It is thus a very early example of a real-time tactics game. While the graphics are primitive compared to modern video games, Bolo and its derivatives retain a certain amount of popularity.
When the Mac version added TCP/IP networking support, it became one of the first real-time games to be played on the Internet with a large following, preceding major commercial titles by years.[1] Currently, an active contingent play both Apple and Windows versions of bolo, and interact on forums and IRC channels to coordinate and discuss games and strategy. Many current players previously played the game in its early years and began playing again upon discovering that the game is still active on multiple platforms.
The etymology of the name "Bolo" has been the source of some confusion over the years. Contrary to popular opinion, the name "Bolo" was not derived from the Bolo series of science fiction stories by Keith Laumer; nor did the game have any connection with a similarly-named 1982 tank game created for the Apple II, " an unfortunate coincidence," as Cheshire put it.[2] In fact, Cheshire's 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 importantly about humans communicating with each other, as they argue, negotiate, form alliances, agree stategies, etc." [3]
Contents |
[edit] Description
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 drowning 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 which alternately can be 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 it (often too close to stop in time), 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. The bases also repair damage to the tank, 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 tactical goal 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, but in later versions 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 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.
[edit] Networking
The key to Bolo's popularity was its networking support, which allowed 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. Bolo was one of the first to allow a net game to be set up quickly and easily, while still being fairly complex and engaging. In the "early days" the game supported only AppleTalk and did so through an interesting 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". It might seem odd that the new game would use the same name, but the reason will become clear in a moment.
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 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 dramatically 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 major 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.
Unfortunately there was one other 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 some sort of round-trip timeout, and if the games joined in a fashion that did not minimize the overall latency, it was possible to hit this timeout.
[edit] Versions
Bolo-like games have been developed for Windows and Linux by John Morrison, under the names WinBolo and LinBolo,[4] respectively. Although graphically these games appear quite similar to Bolo, they differ fundamentally in that they employ a client-server network architecture instead of Bolo's ring model. [The major difference in gameplay between Bolo and Morrison's games is that Winbolo's networking makes it vastly more difficult to directly engage enemy tanks in "dogfights," necessitating greater reliance on pillboxes for fire support.]
LinBolo has been ported to the iPod by the iPod Linux team. The iPod version is dubbed "iBolo"[5]
There are two independently developed Mac OS X versions of Bolo. One is XBolo by Genga Software,[6] which seems to be out of current development. The other is nuBolo by C.R. Osterwald, which was reverse engineered from Bolo 0.997 and features gameplay very similar to that of the original Bolo.[7] 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 Palm OS freeware version was released by the third-party developer Konstantin Dimitrov under the name Bolo: Resurrection.
[edit] References
- ^ Bolo Clone Projects. Retrieved on 2007-06-28.
- ^ MacBolo Instructions. Retrieved on 2007-05-27.
- ^ Frequently Asked Questions. Retrieved on 2007-05-27.
- ^ WinBolo.com: News (2006-04-23). Retrieved on 2006-12-23.
- ^ iBolo page on the iPod Linux wiki (2007-01-06). Retrieved on 2007-03-14.
- ^ XBolo. Retrieved on 2006-12-23.
- ^ nuBolo Home Page (2006-12-07). Retrieved on 2006-12-23.
