-The ./confserver/world file defines the map object types and the actions
-available to them. Each object type and action is defined by a multi-line block
-wherein each line sets one attribute of the object type or action.
-
-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 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
-
-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).
-
-All this definition block members must be present within a block, but only
-"ACTION" / "OBJECT" must be positioned at the respective blocks' first line,
-the others may appear in whatever order and even multiple times. If a block is
-finished, however, it cannot be re-defined by starting a new block wit 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.