Return to Jamie Cameron's [final report (1995)]



A sim server is responsible for everything within one part of a sim world
called it's map. All players who's avatars are within that map are connected
to the sim server and all information about players and objects within the
map is stored by the server.
Upon startup, a server reads text files containing the current state of it's
map into data structures in memory. Every 5 minutes or when the server
is shut down, the files are re-written so that map state is kept and not lost
if the server is killed (or crashes :-). At the moment, to add new rooms or
objects to a server's map it must be shut down, it's map files edited and
then restarted.

The sim server should run on any unix system with a fast connection to the
Internet. It doesn't make use of X, though it would be helpful to have X
installed so you can run the graphical clients. The sim server executable is
called sims, and can be obtained by either
- Downloading and compiling the source code from
ftp.x.org
- Downloading a pre-compiled version. Versions are available for
Once this is done, you should create a directory for the server to store it's
map data files in. The sims distributions all come with a directory
of example files defining a simple world running on one server, in
sims/example. Each running server on the should have it's
own private directory, as server create additional files in their directories
when running. The map data files you need to create are :
- The map file. This contains information
about the name and creator of the map plus the names of the other
files.
- The nodes file. This defines the
nodes in the map, the positions which players can move
between.
- The paths file. This contains the
pathss between nodes, along which players can move.
- The shape file. This contains the 3d
shape definitions for all the walls, floors, objects and
people in the map.
- The objects file. Contains the
objects in the map, such as books, computers keys and
doors. Each object will have a corresponding shape
with the same name.
- The persons file. Stores the
player controlled and non-player persons in the map.
Each person has a 3d shape of the same name.
- The players file. Contains
information about the players who are in this server's
map. Each player has a corresponding person of
the same name.
- The actions file. Contains the
actions for objects and non-player
persons. Actions determine what happens when something
is done to an object (for example, opening a door) and how
non-player persons behave.
All data files are run through the C preprocessor (/lib/cpp on most
systems) before being parsed, so standard C comments, #define and
#include directives can be used. However when the files are
written out again by the server, comments will be lost and preprocessor
directives (like #define) expanded.
When the necessary map files have been created, the sim server can be started.
The command line arguments for sims are :
- map file
The path to the map file decribed in the list above. The server will
extract the names of all the other map data files from this one and read
them in. Note that the server assumes that the map file and all the map
data files are in the same directory.
- -port number
Listen on the given port for connections from players and other servers.
By using different port numbers, you can have multiple sim servers running
on the same host. Because a sim server uses about 20 port numbers above
the one given, you should make sure that server port numbers are at least
20 apart. If this argument isn't given, port 13333 is used.
- -dont_dump
Prevents the server from writing out the map data files every 5 minutes
or when it is shutdown. Useful for when you are testing changes to a
server's map, but definately NOT recommended for when the server is being
connected to by others.
- -fd_debug
Output debugging info on everything sent by the server over the network.
There's no good reason why anyone would want to use this option.
- -parse_debug
Output debugging info on tokens read during parsing of map data files.
You don't want to use this option either.
When the sim server is started it should list the map data files as it reads
them in, and then print something like Started server on
indy09.cs.monash.edu.au port 13433. If something goes wrong reading in
one of the data files an error message will be displayed and the server
will exit.
However, if everything goes OK the server will open the file server_log
in it's directory to write status and error messages to, and start waiting for
connections on the given port. Status messages will be written to stdout
and to the log file whenever
- A client connects with a newplayer or oldplayer request
- A player enters or leaves this server's map
- A locateplayer request is received, or this server sends a
locateplayer request to another server
- A status request is received
- A getshapes request is received
- A shutdown request is received
- The server is killed by a signal (for example, by ctrl-c)
- The server finishes writing out the map data files after being shutdown
- A transfer request of some kind is received from another server
- A new player is created on this server
In addition, error messages will be written to stderr and the log file if
something goes wrong. Some errors (such as failure to allocate memory) are
fatal and will shutdown the server, while others (such as a broken connection
to a client) are properly dealt with :-)

Once your server is running, it should be able to receive connections from
players, status programs and other servers. Possible connection types are :
- newplayer
A client trying to find on which server player is on. When
a client program is run, the first thing it does is connect to a
server and send a newplayer request. Because a world can be
split over many servers, the server that received the request
queries others to find if the player exists, and if so on what
server. If the player does not exist anywhere in the world,
new shape, person and player data
structures are created at one of the safenodes on this
server.
- oldplayer
A client that knows that it's player is located on this
server. If the player is found on this server and the
client provides the correct password, map data is sent to the
client and the player enters the simulation.
- locateplayer
A server looking for a player. If the named player
isn't on this server, a list of other servers to try is sent back.
- transfer player / person / etc..
A server transferring something to this one. When a player
moves from one server's map to another, the old server
sends the player, person and shape data
to the new server, plus any objects carried and the
shapes and actions associated with them.
- shutdown
The server admin shutting down this server. When this connection
command is received, the server writes out map data to it's files
and exits.
- noop
A server ping program (like simsping) seeing if this server
is up. This command is ignored by the server.
- status
A server status program (like simsstat) wanting to know who
is logged onto this server. A list of persons is sent back
in response.
- con_getshapes
A shape viewer (like av3d) requesting the 3d shapes on
this server. A list of shapes is sent back.
Because some of these connection commands could be used to do evil things
like creating bogus players, the status, shutdown and all
the transfer commands require a password from the other end before
doing anything. When one server transfers something to another, the sender
uses the password from it's map file to authenticate itself to the
receiver. Because all the servers in a world have the same password in their
map files, and these files are kept secret, all and only the servers
making up a world can transfer things between them.
Commands like simskill and simsstat which send
shutdown and status requests take a password as a command
line parameter, which must match the password on the server the command is
being sent to. This prevents just anyone from shutting down a sim server :-).
Return to Jamie Cameron's [final report (1995)]