| Revision as of 21:41, 22 September 2006 editMaury Markowitz (talk | contribs)Administrators76,006 edits better caption← Previous edit | Revision as of 11:39, 24 September 2006 edit undoMaury Markowitz (talk | contribs)Administrators76,006 edits some clarifications in the game description areaNext edit → | ||
| Line 21: | Line 21: | ||
| ] | ] | ||
| In Bolo |
In Bolo the player commands a tank that can be driven around a battlefield that is viewed from above. The tank's primary weapon is its cannon, which has a fairly fast rate of fire. The tank also carries mines as a secondary weapon, they can be dropped on the move, or alternately they can be planted by an engineer who runs for the tank and "drills" the mine into the ground. The mine is 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. Bases can be captured by shooting at them and then driving onto them. Their supply of ammunition refills slowly, so keeping several bases and protecting them is the primary strategic goal of the game. | Ammunition, both for the cannon and mines, can be refilled at a limited number of supply and repair bases scattered around the map. Bases can be captured by shooting at them until they are destroyed and then driving onto them. Their supply of ammunition refills slowly, so keeping several bases and protecting them is the primary strategic goal of the game. | ||
| A secondary strategic goal is the capture and planting of ]es, 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, at which point they 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, normally closer to allied supply bases. In the early Macintosh versions the pillboxes were fairly easy to kill, but 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 ''the pillblock'' (where a friendly pillbox is placed so that it blocks the hostile pillbox's shots but allows the tank to shoot past it at the hostile pillbox). | A secondary strategic goal is the capture and planting of ]es, 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, at which point they 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, normally closer to allied supply bases. 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 ''the pillblock'' (where a friendly pillbox is placed so that it blocks the hostile pillbox's shots but allows the tank to shoot past it at the hostile pillbox). | ||
| The engineer can also perform building tasks. In order to do this he must first be sent into a forest to cut trees, which are essentially "cash" in the Bolo world. He can then built 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 |
The engineer can also perform building tasks. In order to do this he must first be sent into a forest to cut trees, which are essentially "cash" in the Bolo world. He can then built 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 an forest where an enemy is collecting trees. | ||
| The game never actually "ends". When one side has successfully captured all of the supply bases and is able to defend them, the other team is in a hopeless position; when they run out of ammunition the are effectively impotent. The game is generally ended when both sides agree to do so. | The game never actually "ends". When one side has successfully captured all of the supply bases and is able to defend them, the other team is in a hopeless position; when they run out of ammunition the are effectively impotent. The game is generally ended when both sides agree to do so. | ||
| Line 33: | Line 33: | ||
| ==Networking== | ==Networking== | ||
| 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 engaging. In the "early days" the game supported only ] (for obvious reasons) and did so through an interesting implementation that formed the basis of Cheshire's dissertation for ]. | 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 ] (for obvious reasons) and did so through an interesting implementation that formed the basis of Cheshire's dissertation for ]. | ||
| On startup, Bolo advertised itself on the LocalTalk network using the ], AppleTalk's system that allowed programs to be registered with human-readable names. If such a service could be found already, the new instance sent a message to that machine, asking to join the game. To the user, this was invisible and automatic. | On startup, Bolo advertised itself on the LocalTalk network using the ], AppleTalk's system that allowed programs to be registered with human-readable names. If such a service could be found already, the new instance sent a message to that machine, asking to join the game. To the user, this was invisible and automatic. | ||
| The game used only a single packet that was sent from machine in a round-robin fashion. Each new instance had its address inserted into one of the sixteen slots in the package, on a first-come-first-serve basis. The packet was then passed to the first machine in the list, who inserted any updates to the state of the player's tank into a payload area, read the next address on the list, and passed the packet along. That machine then received the latest data from all the machines in the packet |
The game used only a single packet that was sent from machine in a round-robin fashion. Each new instance had its address inserted into one of the sixteen slots in the package, on a first-come-first-serve basis. The packet was then passed to the first machine in the list, who inserted any updates to the state of the player's tank into a payload area, read the next address on the list, and passed the packet along. That machine then received the latest data from all the machines in the packet. | ||
| This approach dramatically reduced overall network traffic, compared to a system where updates are sent individually to each machine. In more common networking systems one machine is chosen to be the "host", and the other machines send their updates to that host. 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 of the larger packets on the network at any given time. Another major advantage to this system was that there was no "host" machine. Games could join or leave at any time, by simply adding or removing their address from the slots in the packet. | |||
| The major advantage to this system was that there was no "host" machine. Games could join or leave at any time, by simply adding or removing their address from the slots in the packet. Most modern games still require one machine to act as the "host", and if the host exits the game all the other players are "kicked off" as well. Given the need to lower latency as much as possible, this sort of architecture may be difficult to avoid, however. A single host can asynchronously receive and send data to all of the players in the game at the same time, whereas with the packet-passing system the data is not received until it has passed through all of the other machines; given a "ping" time on the order of a few tens of millisecond common on the ], this might mean that updates will not be seen for periods well over a second. Bolo's system sacrificed latency for traffic, a very reasonable trade-off in an era when practically every network was local. | |||
| 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 speed of LocalTalk might be. In modern networking, where most or all of the links are likely to be over the ], 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 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 |
||
| ⚫ | Unfortunately there was one 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 didn't minimize the overall latency, it was possible to hit this timeout. | ||
| ==Versions== | ==Versions== | ||
Revision as of 11:39, 24 September 2006
For other uses, see Bolo.1982 video game| Bolo | |
|---|---|
| XBolo for Mac OS X. | |
| Developer(s) | Various |
| Publisher(s) | Various |
| Platform(s) | Apple II, BBC Micro, Mac OS, Mac OS X, Linux, Windows |
| Release | 1982 |
| Genre(s) | Real-time tactics |
| Mode(s) | Single player, Multiplayer |
Bolo is a video game originally developed for the Apple II computer by Synergistic Software in 1982. An update inspired by the original was created for the BBC Micro computer by Stuart Cheshire in 1987, and later ported to the Macintosh in its most popular incarnation. The original Bolo was a single-player game. 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 somewhat primitive compared to modern video games, Bolo remains a popular and addictive phenomenon.
Description
In Bolo the player commands a tank that can be driven around a battlefield that is viewed from above. The tank's primary weapon is its cannon, which has a fairly fast rate of fire. The tank also carries mines as a secondary weapon, they can be dropped on the move, or alternately they can be planted by an engineer who runs for the tank and "drills" the mine into the ground. The mine is 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 and repair bases scattered around the map. Bases can be captured by shooting at them until they are destroyed and then driving onto them. Their supply of ammunition refills slowly, so keeping several bases and protecting them is the primary strategic goal of the game.
A secondary strategic goal 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, at which point they 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, normally closer to allied supply bases. 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 the pillblock (where a friendly pillbox is placed so that it blocks the hostile pillbox's shots but allows the tank to shoot past it at the hostile pillbox).
The engineer can also perform building tasks. In order to do this he must first be sent into a forest to cut trees, which are essentially "cash" in the Bolo world. He can then built 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 an forest where an enemy is collecting trees.
The game never actually "ends". When one side has successfully captured all of the supply bases and is able to defend them, the other team is in a hopeless position; when they run out of ammunition the are effectively impotent. The game is generally ended when both sides agree to do so.
Networking
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 (for obvious reasons) and did so through an interesting implementation that formed the basis of Cheshire's dissertation for Stanford University.
On startup, Bolo advertised itself on the LocalTalk network using the name binding protocol, AppleTalk's system that allowed programs to be registered with human-readable names. If such a service could be found already, the new instance sent a message to that machine, asking to join the game. To the user, this was invisible and automatic.
The game used only a single packet that was sent from machine in a round-robin fashion. Each new instance had its address inserted into one of the sixteen slots in the package, on a first-come-first-serve basis. The packet was then passed to the first machine in the list, who inserted any updates to the state of the player's tank into a payload area, read the next address on the list, and passed the packet along. That machine then received the latest data from all the machines in the packet.
This approach dramatically reduced overall network traffic, compared to a system where updates are sent individually to each machine. In more common networking systems one machine is chosen to be the "host", and the other machines send their updates to that host. 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 of the larger packets on the network at any given time. Another major advantage to this system was that there was no "host" machine. Games could join or leave at any time, by simply adding or removing their address from the slots in the packet.
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 speed of LocalTalk might 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 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 didn't minimize the overall latency, it was possible to hit this timeout.
Versions
Bolo has been ported to Windows and Linux by John Morrison, under the names WinBolo and LinBolo.
There are two independently developed Mac OS X versions of Bolo. One is XBolo by Genga Software, which seems to be out of current development. The other is nuBolo by C.R. Osterwald, which is a direct port of the original Bolo 0.997 source code. 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 PalmOS freeware version was released by the third-party developer Konstantin Dimitrov under the name Bolo: Resurrection.
External links
- Mobygames entry on the original 1982 Bolo
- Official home page
- Stuart Cheshire, the author of Bolo
- Windows and Linux version and league site
- WinBolo.us community website
- Cool Fool's Bolo Multimedia Website
- Xbolo (Mac OS X version)
- nuBolo (alternate Mac OS X version)