-The ./confserver/world file defines the map object types, actions available to
-them and the map itself. Each definition consists of a multi-line block wherein
-each line sets one attribute of the object type, action or the map.
-
-Here's a typical map definition block:
-
-MAP_TYPE 0
-HEIGHT 64
-WIDTH 64
-
-A line of "MAP_TYPE" followed by a non-empty token starts the map definition
-block. In the future, the second token may differentiate different map types,
-but as of right now, only one is available and the value is not interpreted.
-The numbers after "HEIGHT" and "WIDTH" give the map's vertical and horizontal
-extensions in cells. They must be >= 1 and <= 256.
-
-Here's a typical action definition block:
-
-ACTION 1
-NAME move
-EFFORT 5
-
-A line of "ACTION" followed by a number starts an action definition block and
-sets the action's id (must be > 0) for internal use to 1. The number after
-"EFFORT" determines how many turns this action takes for the actor performing
-it. The string after "NAME" names the action. Furthermore, if it is one of
-"move", "pick_up", "drop" or "use", it matches internal functions described by
-these strings to this action. All other names (including "wait") currently are
-matched to a do-nothing wait function.
-
-Here's a typical map object type definition block:
-
-OBJECT 2
-NAME ZOMBIE
-SYMBOL z
-LIFEPOINTS 3
-CORPSE_ID 5
-CONSUMABLE 0
-START_NUMBER 9
-
-A line of "OBJECT" followed by a number starts it, and the number sets the
-object type's internal id. The number after "CONSUMABLE" defines the object
-as consumable (and to so many hitpoints gain). The character after "SYMBOL" is
-the one shown on the map to represent to object type. "LIFEPOINTS" is the start
-hitpoints value for this object type and defines it as animate if it is
-non-zero. The string after "NAME" sets the object type's name. "CORPSE_ID" sets
-the id of the object type that objects of this type degrade to if their
-hitpoints drop to zero if they start out as inanimate (what is not implemented
-yet: or if they are inanimate, but are otherwise crushed). Note that the
-"CORPSE_ID" must match the id of an object type defined in the file (before or
-after, it may even be the same). "START_NUMBER" sets the number of objects that
-are to appear of the given type on the map on game start.
-
-All these definition block members must be present within their blocks, but only
-"ACTION" / "OBJECT" / "MAP_TYPE" must be positioned at their respective blocks'
-first line; the others may appear in whatever order and even multiple times. If
-an object or action definition block is finished, however, it cannot be
-re-defined by starting a new block with the same object type or action id.
-
-Tokens in this config file are separated by whitespace. Single quotes can be
-put around string values that are to include whitespace by themslves. Note that
-all numbers must be decimal representations of unsigned 8 bit integers, i.e.
->= 0 and < 256 and sans preceding "+".
-
-All source files are thoroughly documented to explain more details of
-plomrogue's internals. The ./roguelike-server executable can be run with a -v
-option for helpful debugging info (mostly: what messages the client sends to the
-server). Server and client communicate via files in the ./server/ directory
-(generated when the server is first run). The ./server/in file is read by the
-server for newline-delimited commands. The ./server/out file contains server
-messages to be read by clients. The ./server/worldstate file contains a
-serialized representation of the game world's data as it is to be visible to
-the player / the player's client.
+The game world is set up and made subject to player commands by
+./roguelike-server. It's controlled by commands explained in the file
+./SERVER_COMMANDS. The server usually reads these from the files ./server_run/in
+(written to by ./roguelike-client), ./confserver/world, ./record_save and
+./save.
+
+The ./roguelike-server executable can be run with a -v option for possibly
+helpful debugging info (mostly: what messages the client sends to the server).
+
+Server and client communicate via files in the ./server_run/ directory
+(generated when the server is first run). The ./server_run/in file is read by
+the server for newline-delimited commands. The ./server_run/out file contains
+server messages to be read by clients. The ./server/worldstate file contains a
+serialized representation of the game world's data as it is to be visible to the
+player / the player's client.