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 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. Former player Ulfilas points out how the network design was suited to ensure fairness: "Therefore, within a Bolo game all players have equal resources, such as speed. It cannot happen that a player with a better network connection to the server gets an advantage.".
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.
Read more about this topic: Bolo (1987 video game)