The following text is the original MASCOT functional specification dating from about 1987. Amazingly, most of it is still accurate. All I have done is run it through a spelling checker (such things weren't generally available on home computers when it was first written!), added links to the diagrams, and a few explanatory notes where things have changed in the intervening 13 years!!

Introduction
------------
This document is the initial draft Functional Spec. for the
MASCOT ( Multi-Access Space COmbat Trainer) game. A game played
over a network with more than one computer. One computer being
a controller and the remaining computers being ships. The object
of the game is to pilot your craft and conquer the universe.
Initially the game will cater for QLs only. Reader are asked to
study this document to find errors and suggest improvements.
At a later date this document will become the rules of the game
and a tech note for ship writers.

MASCOT is these days regarded as standing for  Multi-Access Space COmbaT - (no trainer). The current version of the MASCOT Universe runs under the Linux operating system on IBM PCs, and communication is carried out using TCP/IP. Therefore any computer which can communicate over TCP/IP (e.g. can connect to the internet) could be used to host a ship. The Sinclair QL Network system is no longer supported.

The Universe and Coordinate Structure
-------------------------------------
The universe has size +/- 32k square. Positions are always
integer and relative from the ship's starting position, i.e.
each ship has his own co-ordinate system.
The universe is wrap around. Moving one Position left at
-32769 will move the ship to 32767 and moving one position down
will do the same. Co-ordinates are quoted with the x position
first.

Fuel
----
Fuel starts at 100,000 units and is an integer. Some activities
will cost fuel others are free. When it reaches zero no fuel
using activities will be allowed.

Hit Points
----------
Hit Points will start at 300 and indicate the damage caused.
When this reaches zero all fuel is lost and the ship is dead.

Movement
--------
Movement is performed by the use of thrust. Thrust is specified
in direction and force. 1 unit of thrust will increase a ship's
speed by 1 unit in the opposite direction to where the thrust
was applied. The speed of the ship is limited to 2000 units/
unit-time. The cost of 1 unit of thrust is 1 unit of fuel. Force
is specified as an integer and the direction as a heading from
north(?) with an accuracy of 0.1. The maximum thrust is 500.
The ship's speed and new position is calculated during the
sub-unit time and returned to the ship in the standard header.
Thrust is a single burn event and must be respecified on the
next time slot to maintain acceleration.

Ship Collision
--------------
This will not occur in this game and ships can occupy the same
location.

Radio
-----
This is used to pass a message to another ship. The radio
command has two parameters, the ship number and a string of
characters terminated by a newline. Receiving ships will only
receive one message at a time. Messages waiting will be queued

Scans
-----
Scans are of two types : long and short.
The long range scan will give the direction of the nearest
object outside the range of the short range scan. The long
range scan will give an indication if the object is further or
closer than 15,000 units away. The scan is only on request and
will cost 10 units of fuel.

The short range scan will give the positions of all objects
within a 1000 unit radius. Identification of ships is not
done. This is supplied without cost and is part of the standard
reply.

Weapon
------
Shooting is by use of the space bomb. A depth charge type
device which is sent on a course with a fuse that will blow
when it is at a certain range from its firing Point. They move
with infinite speed. Own ship's movements are calculated before
the bomb detonates (see figure 3). The charge they contain is
also selectable.
The bomb has direction, fuse range and explosive strength. The
fuse range is an integer with maximum value of 500. The
direction is a bearing from north(?) to an accuracy of 0.1
degrees . The explosive strength is an integer with maximum 200.
1 unit of fuel is used to make 1 unit of explosive. Any bomb
that hits before the fuse range will explode immediately.

Direction is indeed a bearing from North.

Damage
------
Damage is caused by bombs. A direct hit causes hit point damage
equal to the explosive strength of the bomb. If it is not a
direct hit then there is a reduction of 2 hit points per unit
distance between the bomb and the ship.
One can not be hit with one's own bomb , but damage can be
caused due to the nearness of the explosion.

Shields
-------
Shields can be put up to prevent damage. One unit of shield
will cost one unit of fuel per time slot. Maximum shield
strength is 100 units. Shields once put up will remain up until
set to zero or to another level. 1 unit of shield will reduce
the hit point damage by 1 up to a maximum of 50 hit points.
Shield strength is also reduced by 1 unit for every hit point
saved.

Commands
--------
All the commands are summarized in figures 1 and 2. Figure 1
shows the data that is returned from the universe for each of
the commands sent by a ship. Figure 2 shows the various commands
that are available to a ship.
The null command is used to request the standard message
without having to Perform a functional command. Two other
replies are returned that differ from the standard reply. These
are
1. "You are dead". Returned when the ship's hit points are zero.
2. "Syntax error in command". Returned after an illegal command.

Networking
----------
The game will be designed to communicate with many networking
devices. However as a starting point the game will communicate
only with QLs and Spectrums over the QL network. The addition
of RS232 will only be made after the game has been proven.

Currently communication is over TCP/IP, with the Universe providing a listener service on a predefined port number. There is no intention to support any other means of communication.

QL Network Rules
----------------
the following rules are to aid game design. If the initial
design is successful then these rules may become relaxed as new
networking techniques evolve.
1. Keep to the protocol. After one has sent a command the ship
must not keep the universe waiting. A small amount of delay in
replying to ships is inevitable and during this time a small
amount of house keeping is allowed.
2. Do not attempt to interfere with other ship's messages.
3. Cooperating ships must mot use the network to communicate
unless it is via the universe's radio messages.

Protocol and Timings
--------------------
The time to service all ships and the universe console is
called the unit time. The unit time is also the time it takes
between responses to one ship. The sub-unit time is the time
it takes to process the commands of one ship. These times are
unknown but will depend on the number of users and processing
speed of the universe computer.
In order to get some feel for the timing I have decided as a
starting point a sub-unit time of 2 seconds and a maximum number
of ship of 5. This makes the unit time equal to 12 seconds. I
hope to reduce this by a large amount, so be prepared. Figure 3
gives the order that the functions are carried out.

Typically in recent combats, the sub-unit time has been between 0.5 and 1 second.

The protocol of message transfer is as follows:-
1. The ship sends a message and waits for the reply
2. The universe will read it during the correct time slot
3. If there is no command then goto 5
4. The reply is returned when processed
5. Wait for next time slot
6. Goto 1. for next ship

Newline
-------
The newline character is used to terminate the command and
reply messages. Different machines may use different newline
characters. When sending messages to a target machine one must
ensure that the string can be read by an input statement of the
target machine.

The "newline" character currently used is ascii.nul (i.e. '\0' to C users). This means that received and transmitted commands are C compatible null-terminated strings.

Specification is copyright © WD Morgan 1987. All rights reserved.