Why I Play Games, Part Two

Earlier I wrote about how I first became interested in computer games, and how the cooperative elements of some of them interested me more than the standard gameplay.

One of the first things I did after starting in college was the school newspaper; friends of mine had quite literally been left in charge after a corruption induced vacuum of power. I quickly took advantage of the institution's antiquity to spend some money on gaming hardware... I mean, desktop publishing equipment.

To be honest, the Mac Classic we bought to do the newspaper with was a horrible machine for playing games on by today's standards. It had a tiny 9" greyscale screen. It had a tiny, tinny speaker that made nothing but incomprehensible beeps. But it did have one thing that almost every computer has today and that almost no computer had at the time: built-in networking.

Of course, networking wasn't useful at all without something else to connect to. At the time-- back in 1991-- almost nobody had heard of the Internet. The newspaper didn't even have an email address at the time. Neither did I, for that matter. Later on, we would expand and purchase a second computer, but that was more than half a year away. What to do? How not to waste this god-given gift of networking?

The solution was under our noses. Right next door was the yearbook office. They also had a Macintosh they used for laying out their publication. I picked up a couple of phone net connectors from the campus store, and spent a few minutes wedging an RJ11 jack under the makeshift wall that separated our organizations.

We'll share files, I thought. We'll exchange information and resources. We'll synergize! We'll refocus on our core competencies!

Instead, we played Bolo. I don't even remember where the game came from. At first glance, it didn't look like anything interesting. The graphics were extremely primitive, even for the time. It looked like a slightly more colorful version of the game Combat, the cartridge that the Atari 2600 came with so you could learn how the system worked, and so you wouldn't feel like you were completely getting rooked when you paid $200 to play games on your television, only to find out that the games cost extra.

However, first glances can be deceiving. Yes, like everybody's favorite variants in Combat, in Bolo you controlled a small tank. It had a cannon and could drop mines. Game maps had a variety of terrain: paved roads, unpaved wilderness, swamp and shallow water that slowed your progress, deep water that would sink you.

The game also had a resource management element: A little green man (referred to lovingly by Bolo players everywhere as the "Little Green Man", or "LGM") could be made to emerge from the tank and perform a variety of tasks: building a road or bridge to make the tank's progress speedier, build a section of wall to protect your base, lay a mine to ambush an opponent, or collect trees used for construction. While ou

The game had several objectives: there were a finite number of bases one could use to replenish the tank's ammunition and repair its armor, and a finite number of gun emplacements, or "pillboxes" that started out a game hostile to all players, until destroyed and rebuilt-- at which point it would not fire on its owner, but on his enemies. Bases could also be owned by players, were fixed and could not protect themselves. Pillboxes could be moved into positions to protect bases and each other.

All of which was fine and dandy-- except when I first played the game, I didn't see the point. I could drive around, I could capture bases, and I could destroy and rebuild pillboxes. But the game never ended, and there was never anything else to shoot at but pillboxes. Boring.

The whole point of the game, however, was networking. It was, in fact, written as an exercise in what is called peer to peer networking-- a phrase that has now, because of names like Napster and Gnutella and Kazaa, fallen into common usage. At its most basic, this just means a network of computers that treat each other as equals, rather than a "server" that has authoritative control, and a collection of "clients" that take directions.

In fact, as attractive as Bolo's gameplay was-- and, I might add, still is, compared to today's gaming offerings-- the point of it was always the networking technology. In fact, the author of Bolo, Stuart Cheshire, was a computer science student at Stanford who went on to work for Apple's implementation of Zeroconf, called Rendezvous-- a technology that allows computers to interact with each other as peers over network connections without any configuration. Which is really just bringing us back to 1991. The AppleTalk networks used by the Macs of that day required almost no configuration at all to work-- they were completely plug and play. The popularity of the Internet forced Microsoft and Apple to make TCP/IP, the lingua franca of the Internet, the foundation of all their networking technologies, despite the fact that it is relatively complicated to configure and troubleshoot, especially for the layperson. Rendezvous and Zeroconf are designed to make networking easy again.

Machines running the Bolo program could set up a "ring" over a network connection. They would pass information to each other over the network. The upshot of this was is that if you had two computers running Bolo over the network, and both computers had the same map files available to them, you could create a game between the two computers: each of them would be participating on a virtual playing field that existed not on a remote server, and not entirely on one computer or the other, but a kind of electronic collaboration between the two.

Nearly all of this is taken for granted, of course, in a day and age when companies like Microsoft charge $49.99 a year for a plug and play online gaming system that lets you do all this from the comfort of your couch without giving a moment's thought to how it works, let alone crawling under a desk with a couple of phone net connectors.

But in 1991, this was heady stuff.

So now I could spend time in the afternoons laying mines for unsuspecting editors. But even that wasn't the end of Bolo's genius.

A network of two machines, each with a solitary player, still isn't that interesting. A human player can be much more challenging, head to head, than even the best computer program, assuming the program doesn't take advantage of its unique abilities-- such as the knowledge of where all resources on the map are, or where the human player is, and things of that nature.

But two players is still a small game. Bolo's other great achievement was a modular architecture for things called Brains and Bots. These allowed other programmers to write bits of code that would create AI-controlled tanks. Bots were designed to augment the experience of a human player-- by creating different map displays, and by automating some game functions. Brains, on the other hand, created entirely autonomous, computer-controlled players.

If your computer was fast enough and had enough memory, you could run three or four copies of Bolo on a single machine. Put two machines together and you could have an eight player game-- the maximum Bolo supported-- with two human players and six computer brains. And what's more, you could arrange those players, on the fly, into any number of alliances, and play games of 4 against 4, or 3 against 3 against 2, or 2 against 2 against 2 against 2, or 4 against 2 against 2, or any other combination of human and computer players. Humans could pick up a brain or two and play against each other, or the two humans could ally with each other against the computer. The alliances could shift during the game, as players dropped out or joined in, and the ownership of pillboxes and bases followed the shifting alliances. There were different brains that played different styles-- brains called Indy and Ladmo and scores of others.

Bolo fit on a single 3.5" disk, along with several map files and even a Brain or two. And yet it offered gameplay far richer than games that ship today on DVDs that hold gigabytes of graphics and sounds. Because the essential element was creating a flexible environment that enabled people to play with each other, rather than just with machines.

Of course, this entire sequence was played over again and again with other games, starting with Quake, the second game by Id Software, makers of the shareware hit Doom, and one of the early first person shooters to be played by large numbers of people on the Internet. My first experience with Doom will be the subject of the next installment.

Related Links:

The Bolo Home Page

Stuart Cheshire's Bolo Pages

Rendezvous

Stuart Cheshire - Stuart Cheshire's own site

It's the Latency, Stupid - by Stuart Cheshire. Article on the importance of latency, rather than bandwidth, as the most important factor in network gaming performance.