Stuart Cheshire
Sidney Sussex College
The real reason for this was, in fact, dealings with Acorn. I had hoped to be able to get an Archimedes Development System -- machine, hard disc, C-compiler, technical manuals etc. -- at the discounted price that Acorn offers to members of their I.S.V. (Independent Software Vendors) scheme. I wrote countless letters to them, thinking that they would be interested in a project of this kind, but I got no-where. I never even managed to get a price-list out of them. I had not realized that they do not want to support the development of any games for the Archimedes. They are determined to promote the Archimedes as a business machine, and to this end they pursue the twin goals of supporting the development of business software and discouraging games.
It is possible that Acorn are right, that the existence of games for a machine detracts from its credibility to business purchasers.
I have now decided to produce Bolo for the Macintosh and IBM PC instead.
... the Macintosh because I have one, so I already have a machine to work on.
... the IBM PC (& compatibles) because of the sheer number which exist in the world, and the fact that so many in offices are already connected together by networks such as Token Ring and Ethernet. Perhaps, with good fortune, Bolo could become as popular and commonplace as Flight Simulator is now.
Part II
Project Proposal
College: Sidney Sussex College
Director Of Studies: Victor Poznañski
Project Overseers: Dr L. C. Paulson
Prof. D. J. Wheeler
Project Title: An Experiment in Real-Time Networking
Project Originator: Stuart Cheshire
Project Supervisor: Dr J. K. M. Moody
The aim of the project is to produce a real-time, multi-user, graphical game, running on a Local Area Network. The intention is to support up to sixteen players, and to provide each with a screen display updated 25 times per second in order to create the appearance of smooth movement. This should be achieved with a total network traffic measured in terms of hundreds of bytes per second instead of the more familiar hundreds of kilobytes per second now associated with LAN's.
The game is set on an island. Each player is in control of a tank, which can drive across the land at differing speeds determined by the terrain. Tanks can also board ships, which they control, in order to cross lakes or to travel quickly around the coast. Players can build bridges in order to facilitate the crossing of rivers, and can perform other building work such as the construction of roads and buildings. In this way, they can build a fortress to use as their home base, which can be defended in their absence by automatic pill-boxes (which shoot at any hostile tanks) and minefields. Players can also make formal alliances and work as a team, or may simply agree a temporary truce in order to concentrate on attacking a stronger player. In either case, the question of if and when and how to break the alliance is all important.
A simple prototype has already been written (and tested with 8 players) for the BBC micro which implements a subset of the full game planned, and suggests that the above performance goals are reasonable.
The BBC micro code must first be re-written more rigorously, in accordance with some principles of Computer Science. In particular it is necessary to implement reliable semaphores. Currently the only protection on shared resources is to disable interrupts in short routines, and to hope that nothing goes wrong in routines too long for this approach. Other potential problems such as buffer overflow are also dealt with in a similar manner.
The code will be divided into three distinct modules: The game itself, working on internal data structures; the display driver, providing the user with a graphical representation of the said data structures; and the network driver, insulating the game from the details of the actual type of hardware interface being used.
A version for the Archimedes will also be written. This should only take a short time, since the graphics modes and operating system of the Archimedes are so similar to the BBC micro. It also provides the opportunity to write the program in a language such as C instead of machine code, since the ARM processor provides sufficient processing power for this to be feasible.
Several interesting topics are to be covered, including:
When the program is finished, it will be necessary to test it. Unfortunately, this would require a large number of players, playing for a long time, in order to ensure an exhaustive test. There is however an alternative -- which in itself makes an interesting challenge.-- that of writing a program to play the game. This need not attempt to be a completely autonomous and `intelligent' pseudo-player, but instead could just pick, in a semi-random way, goals which are regarded as generally `good things to do'. It would be provided with simple algorithms to enable it to, for example, find its way across the map to any given coordinates.
Since all the machines will be communicating via the network driver, there is no reason why human players should not be able to play simultaneously with the computer-controlled ones without any special modifications to either program. Another possibility is that, instead of the semi-random choice of goals, there could be a provision for manual choice, enabling a human user to act as a commander over several tanks simultaneously.
Acorn Archimedes microcomputer (to be purchased by me): For writing the Archimedes version and for Part II of the project.
BBC Master series microcomputers, required (owned by the Department): 8 in the Old Biometry Room, for occasional testing purposes.
Acorn Archimedes microcomputers (owned by the Department): 18 in the Old Biometry Room, also required for occasional testing.
November Re-write simple BBC version.
December Begin full implementation on the Archimedes.
January Working version ready in time for progress report.
Part II
February Finish off details, test, debug, and write game-tester.
March User interface for the game-playing routines.
April Finish debugging and write dissertation.
Graphics editor and compilers.
Map editor program.
Ring transfer program.
Simple graphics. Basis of setob and refresh routines designed
Tank driving and communicating but only just.
Mine laying but no explosions on other machines.
Mines made to work.
Shooting routines written.
Message system to allow messages to be typed to other machines (important for communicating between our two separate rooms in Cromwell court).
Simple building operations (only at the tank's location).
Still crashing occasionally.
Remote views from pillboxes.
Hiding of tanks under cover of forest.
Targeting cross-hairs and manual setting of tank's gun range
General bug fixing and
re-coding of the values of the opcodes used in the network packets.
Score counters showing the number of `kills'
and the number of times the player has been killed.
Screen indicators showing tank inventory and other status information.
Building Man and parachute for when another is needed.
Farming mode to provide building materials.
New Network Opcodes (again).
Buildings made more robust so that it takes several shots to destroy them
(difficult because of the meagre information stored in the map).
New map with curved edges (arbitrary shape).
Simple and Advanced mode controls.
Regrouping of code into two separate parts (because it got too big) -- one part in normal RAM and one part in ROM space (actually RAM
for development, but eventually to be blown in EPROM when finished).
Fireball when tank dies, followed by `static' on screen.
Crater left on land where tank explodes when it is destroyed.
Boats, both leaving and re-boarding.
Tanks swept along by flooding water.
Pillboxes scattered around tank's location when it is destroyed.
Pillboxes remain loyal to alliance if one player leaves it -- none remain loyal to that player.
Mines shown on allies screens.
More bridge characters & pillbox characters.
Map character compaction.
optimisation of tank coords -- don't send if not moved.
Taking bases and pillboxes out of map to tables.
Intelligent scrolling to automatically show hostile elements in the game.
Making Refueling bases manufacture products at a fixed rate and
notion of capture and ownership of a base by a player.
Sound effects.
Realistic looking growing of forests.
New players arriving and leaving.
Dynamic recolouring of pillboxes (during plotting on the screen) to indicate
whether they are hostile or friendly.
(iii) The source was separated into 6 modules of about 16K each, each using the CHAIN command to call the next, and the final one saving the object code. This did produce the slight disadvantage that inter-module calls could only make backward references, but assembly was very fast[47].
Characters can be loaded into a scratchpad region on the screen where they are seen real size. They can be moved around and superimposed on other characters. Areas can be filled with colour, and manipulated in various ways such as rotation and reflection (useful for producing a tank facing in all directions without having to draw every one by hand).
The program saves files in a simple format -- a byte for the width in pixels, a byte for the depth, and then one byte per pixel with values 0-3 for colours or 4 for transparent.
These files are read by two other programs, the background character compiler, and the foreground character compiler, which compress the data in different ways.
A simple filing system was written which supported just the LOAD command and its derivatives. Then, when the loader program loaded the various constituent files (the code, the graphical data, the map etc.), they were read in from the serial port at 76,800 baud[52], almost as fast as a floppy disc. No `requests' for files were made -- it simply relied on the required files being transmitted by the host in the right order, which of course they were. The bytes were passed on to the output of the port as soon as they were received, so that all the machines in the ring received the required files (virtually) simultaneously.
The only problem remaining was how to get the filing system program into each machine. The solution was to use a bootstrap program, written in Basic, to receive the bytes of the machine code with a FOR/NEXT loop and place them in memory before executing the command *DUD[53] to run the game. The Basic program of course also transmitted all the bytes it received, so that all the other machines in the ring would receive them too.
The only problem remaining was how to get the Basic bootstrap program into each machine. The solution was to use the Operating system command *FX2,1 which selects the serial port as the current input stream. This causes all bytes received by the serial port to be treated in the way normally associated with keystrokes typed on the keyboard.
The host machine could then send the line of Basic down the serial port, and it would be received and executed as if it had been typed on the keyboard. The only remaining problem was that the receiver must also pass on the line to the next machine in the ring, and so on, round the ring, back to the host again.
The program:
*FX3,3
FORF%=0TO&1BF:F%?&E00=GET:VDUF%?&E00:NEXT
CALL&E00:*DUD
must also send on a copy of itself to the next machine. We use *FX3,3 to send the output stream to the serial port, and then use PRINT to send the required characters. Eg.
*FX3,3
PRINT"*FX3,3
FORF%=0TO&1BF:F%?&E00=GET:VDUF%?&E00:NEXT
CALL&E00:*DUD"
FORF%=0TO&1BF:F%?&E00=GET:VDUF%?&E00:NEXT
CALL&E00:*DUD
Unfortunately, the functional part of the code is sent, but not the PRINT statement itself, so the code will be sent to the next machine, but that machine won't transmit it any further. We need to put the PRINT statement inside a PRINT statement itself. I won't attempt to do this, because it involves infinite regressing, putting the whole program above inside a PRINT statement, and then putting the whole result of that inside a PRINT statement etc. etc. ad infinitum.
The solution used at the time was simply to put the whole thing onto a single long line, and to use PRINT$&400 to send it on:
OSCLI"FX3,3":PRINT$&400:FORF%=0TO&1BF:F%?&E00=GET:VDUF%?&E00NEXT:CALL&E00:*DUD
Basic reads its input into a line buffer at location &400 in memory, so printing the string at location &400 simply causes the entire line, whatever it may be, to be printed.
This is a very inelegant solution, and highly machine specific, so I decided that, as a Computer Science Project, I ought to smarten it up.
The following program prints itself in its entirety, in a machine independent way, without reading any dubious memory locations:
*BASIC
0*FX 3 3
1PRINT;CHR$13;"*BASIC";CHR$13;:FORF%=0TO4:READA$:PRINT;F%;A$;CHR$13;:NEXT
2RESTORE:FORF%=5TO9:READA$:PRINT;F%;"DATA ";A$;CHR$13;:NEXT
3PRINT"RUN";CHR$13;
4FORF%=0TO&1BF:F%?&E00=GET:VDUF%?&E00:NEXT:CALL&E00:*DUD
5DATA *FX 3 3
6DATA PRINT;CHR$13;"*BASIC";CHR$13;:FORF%=0TO4:READA$:PRINT;F%;A$;CHR$13;:NEXT
7DATA RESTORE:FORF%=5TO9:READA$:PRINT;F%;"DATA ";A$;CHR$13;:NEXT
8DATA PRINT"RUN";CHR$13;
9DATA FORF%=0TO&1BF:F%?&E00=GET:VDUF%?&E00:NEXT:CALL&E00:*DUD
RUN
The secret is that the program contains an entire listing of itself as data.
Only the code which deals with the networking has been included.
This comprises roughly 1/4 of the total volume of code written.