Stuart Cheshire
Sidney Sussex College
A simple program was first written in Basic using the normal Operating System serial port routines, to test that the link was reliable over that distance, and that the idea was practical.
The serial port was being used in the conventional manner -- duplex communication between two machines -- where each machine sends to the other the information that it will need. This is the way that the serial port usually operates when being used to connect a micro to a mainframe, or to a modem, or to a printer etc.
It was realized, however, that this is not the only way to use the serial port. It would also be possible to make special cables in which the input and output halves of the function are separated, and to use these to connect an arbitrary number of machines together in a ring (see the "The Network" for further explanation).
This idea seemed exciting -- it appeared that it might be possible to produce a genuine[1] multi-player game for the BBC micro which required no more specialized hardware than three DIN plugs and two pieces of wire -- a total cost of less than £1 per player. This made it commercially feasible as a game for sale to the public, where any game requiring expensive Econet[2] hardware could only ever be seen as a novelty in schools and universities where Econet networks are already set up.
While it was clear that it was possible to set up a system in which interrupt software was used to relay information around the ring, there were serious doubts as to whether it could actually do this fast enough to provide a workable basis for a network running a real-time game.
The fastest rate supported by standard RS232[3] hardware is 19200 baud which is exceedingly slow by `real' network standards:
In fact, it turned out that it was not possible to run the serial port faster than 4800 baud with the initial software, despite the fact that performance estimates at this speed were not encouraging and suggested that a higher speed would be necessary to make the game viable:
If we assume that it takes 8 bytes to encapsulate the state of one player's machine[4] then we can transmit 60 such blocks per second. If the sixteen machines take turns to transmit a block of data, then each is transmitting less than four times per second. The movement on your screen of an enemy tank whose position is being updated only four times per second will be noticeably jerky. Even if this speed of update were acceptable, the network would still have to be running faster than this, to provide the necessary safety margin to cope with bursts of data when large numbers of shells are being fired, or when dense minefields are exploding. These large bursts of data will occur when two or more tanks meet and become engaged in a battle -- precisely the time when you want to be able to see exactly what other tanks are doing.
Despite these discouraging estimates, it was felt that it was still worth attempting to write the program because, while it would not cope with sixteen players, it was within the realm of possibility that it could perform adequately, with the required safety margin, with four or perhaps even six players. Although not so impressive, this is still something which has not to my knowledge been done on a microcomputer before, and, if the principle could be demonstrated on a BBC micro, then it would show that on a faster machine with a faster network far more ambitious games could be created[5].
Disregarding the doubts about the feasibility of the network, there was another major worry about the program in general. Each machine would, in some sense, have to do sixteen times as much work as it would in a conventional computer game, because each machine would have to deal with, and display on the screen, every tank, shell, explosion etc. generated by all the other machines, as well as its own. Clearly, the algorithms needed to be written carefully so that each machine did not do sixteen times as much work as it would on its own, or the performance would degrade unacceptably as more machines were added to the ring.
Under these constraints, a program was written in a very much bottom-up fashion. Low level routines were written to handle the networking and the drawing on the screen (the two major time-consuming procedures) as quickly as possible. Once this was done, layers of `game' were tentatively written on top, at every stage expecting the whole program to fall over under the weight of interrupts occurring faster than they could be processed. In fact this did happen occasionally, and certain parts of the code had to be re-thought and re-written to make them more efficient.
When the game was tested in the Biometry Room at the end of Easter Term 1988 it became clear that, despite all the initial doubts, the game was actually extremely playable. The movement of enemy tanks and shells was as jerky as expected, but nobody noticed. This was a psychological aspect which had not been anticipated. Players only pay close attention to their own tank and shells, and other objects are regarded far less critically.
With this encouragement, it was decided that a more carefully thought out version of the program should be written, based on the lessons learned from this ad-hoc prototype. The knowledge that the network was capable of providing the required performance enabled the development of a top-down specification of what was required of the game, instead of the process described above, of gradual and uncertain addition of individual features one at a time.
There was also the need to address many problems with the playability of the game, such as the fact that allies couldn't see each others minefields and kept running into them by mistake, especially when working together laying a minefield around the edge of a fortress. Cries of "No! I've already done that bit ... Too late." were common. This required the re-writing of the whole mine-handling routine because the existing one required that one and only one machine must know about each mine. Many problems such as this had not been apparent until the game was played by a large number of people.
Eventually, the implementation of the network software was also totally re-written, reflecting the more exacting demands being made upon it. The new version of the network software is far more stable and will even run without problems at the full 19200 baud, although the rest of the foreground routines do tend to slow down noticeably with this level of interrupt loading. Hence, a new network speed of 9600 baud has been settled on, which provided improved frequency of updates across the network without too much degradation of the screen updating speed and other foreground processes.
There has still been no opportunity to test the program with a full 16 players, but, since it ran acceptably with 8 players at 4800 baud then there is no reason that it should not run just as well with 16 players at 9600 baud. In fact, it should run significantly better because the atypical bursts when a player starts shooting or sets off a minefield will be more evenly spread:
Assume that a player transmits three times as much data in a combat situation than when simply driving around the island.
This means that where a two-player game running at 1200 baud would not be feasible, a sixteen-player game running at 9600 baud would. It also means that it is not possible to estimate the performance of the sixteen-player game by, say, trying a four-player game at 2400 baud and pretending that it is equivalent to a sixteen-player game at 9600 baud.