The Ubermud Monitor and User Input Interface
This document provides a brief description of the Uber-
mud player interface, or 'monitor'. The purpose of the moni-
tor is to dispatch user input, handling it as play input,
program text, or other types of commands. The monitor has a
simple command set that allows a user to toggle between pro-
gramming mode, game-playing mode, and any other modes that
may eventually be added.
1. Basic Monitor Modes
The monitor has three modes at present: login authenti-
cation mode, game-playing mode, and programming mode. Each
mode evaluates user input differently, and certain modes may
be inaccessible to a particular player at any given time.
Login authentication mode simply prompts the user for a
login and password, and refuses to perform any other opera-
tions until a valid login and password has been provided.
Game-playing mode takes a block of user input, reads it a
line at a time, and attempts to match the input to meaning-
ful options available to the player's "game self", depending
on the location of the "game self" and the current universe
rules. Programming mode accepts U-code program text, and
squirrels it away in a temporary file for later compilation
and execution.
Within each mode of the monitor, a player can switch to
any other without having to break connection or lose any
output that the game may be producing for them. Mode-
switching is done by sending a single line of input to the
server, with the first character being '@', followed by a
monitor mode command. The monitor may then perform a variety
of operations.
1.1. Monitor Switching Commands
The current monitor recognizes the following internal
commands:
@quit - Terminate the connection immediately. This option
can be entered from any monitor mode, at any time.
@login - Re-initialize the connection without disconnecting.
This option can be entered from any monitor mode, and causes
the current player to be "logged out", and the login prompt
to re-appear.
June 22, 1990
Ubermud Monitor
@play - Enter game-playing mode. This option causes all user
input to be treated as "player actions", and interpreted in
the context of whatever universe rules are in effect.
@program - Enter programming mode. This option causes all
player input to be stored in a temporary file for later com-
pilation. If there is already data in the temporary file, it
is left intact, but the player is warned how much program
text there is. Players can toggle freely between game-
playing and program modes, without the temporary file being
damaged. This is convenient in the case where something
interrupts a person who is programming, or a person who is
programming wishes to perform a quick player action in the
game.
@flush - Cleans out the temporary file of U-code and does
not in any other way change monitor modes.
@compile - Compiles the U-code in the temporary program
file, returning any error messages or output generated by
the compiler. After compilation, successful or otherwise,
the temporary file is flushed. Note that the compile direc-
tive can be issued when in any other mode, and does not
change monitor modes. It is perfectly feasible to enter some
U-code, switch to game-playing mode, play for a while, and
then compile the U-code. Each player's input code is stored
in a separate file, so there is no danger of players
interfering with each other's temporary code files.
The monitor commands are case-sensitive (as is most of
Ubermud) and can be abbreviated to significant characters
(EG: @pl for @play).
2. Operation of Ubermud in Each Mode
2.1. Programming Mode
For a detailed description of how to program in the U
programming language, see the reference guide, "The U Pro-
gramming Language". Some important non-language aspects of
programming mode are worth mentioning here, however.
Comments are not permitted in U. This may seem drastic,
but is for the simple reason that shipping masses of comment
text over the network is wasteful. U-code is only accepted
in 'raw' form by the compiler. This was a deliberate deci-
sion, because it enforces use of software development tools
on the player's host machine. Ubermud is distributed with a
simple U-code submitter called usubmit that handles the
dirty work of running a U-code file through the C pre-
processor, logging into the U-server, setting programming
mode, compiling the submitted code, and disconnecting. This
is to encourage users to maintain copies of their better
creations for re-use or to enable them to be "transported"
June 22, 1990
Copyright, Marcus J. Ranum, 1990
easily between U-servers. Remember that at this time there
is no U-code disassembler so it is impossible to regenerate
the source U-code for an object at the server end. Ideally
many people will use the C pre-processor, but it seems
unreasonable to enforce that in the environment. If you do
use the C pre-processor, ensure that all #line directives
are stripped out, as the U-compiler will treat them as syn-
tax errors.
2.2. Game-Playing Mode
In game-playing mode, the monitor functions only as a
simple parser that tokenizes user input, and tries to
resolve each line of text typed by a player into a call to a
U function. The functions that are defined are out of the
scope of this document, as they are not static, but are
defined in the universe rules that the particular server is
running under. There are a very few hard-coded rules in the
monitor - the rest are configured by the Creator of the U-
universe in question.
The first thing the monitor does is examine the text
line for various special initial characters, which are
'hot-wired' to certain functions in the universe. These are
'"', ':' and '>', which are intended to emulate to a degree
the functionality of TinyMUD and other MUDs. The '"' charac-
ter passes the remainder of the player's input line to what-
ever is defined as the current universe's say() command (in
U, designated as @.say()). Thus, typing:
"foo ? wa ?
Is exactly the same as calling the function:
@.say("foo ? wa ?");
Presumably, in most universes, the "say" command will result
in some form of player speech.
Similarly to the way in which the '"' leading character
generates a call to the universe's "say" command, the ':'
leading character generates a call to the universe "emote"
command. The '>' leading character is used as an abbrevia-
tion for "go", in the same manner. This is a departure from
TinyMUD for performance reasons, as a Ubermud universe has
to contend with disk accesses, and excessive searching and
matching is to be avoided. Thus, a player in a room typing:
>west
Will call the universe's "go" function (@.go() in U-code)
with a single string parameter, "west".
If the the leading character of the input line is not a
June 22, 1990
Ubermud Monitor
'hot-wired' special character that invokes an automatic
call, the monitor tokenizes the input line, chopping it up
into a list of words. Words in the input line can be
specifically grouped into strings by use of quotes. EG:
say "how's now" brown cow
Would be broken up as:
word #1: "say"
word #2: "how's now"
word #3: "brown"
word #4: "cow"
Strings quoted with either " or ' are treated as single
tokens. A quote will remain in effect until the matching
quote character is encountered, or the end of the line is
reached. In the example above, the apostrophe in "how's" was
preserved because it was surrounded by the double quotes. A
double quote can be placed in text by surrounding it with
single quotes, and so on.
Once the input is tokenized, the universe rules table
(in U-code object @) is searched for a function with the
same name as the first token. Note that this is case sensi-
tive.
A check is made to ensure that the leading character of
the function being called is not an underscore '_' charac-
ter. If the character is such, the system table, room, and
user are not scanned unless the effective user-id is that of
the Creator. This is intended to permit the Creator to
incorporate frequently used "utility" commands in the
universe rules table without their being directly callable
from within game-playing mode. Note that they are still
callable from within programs, or programming mode. This
provides a degree of control.
If a legal matching function is found, it is called
with all the remaining tokens passed as parameters. For
example:
take "the orange cat
Will search the universe rules table for a function named
"take" (in U-code, @.take()), and if it is found, it is
called as:
@.take("the orange cat");
Note that the quoted string was left unterminated. The moni-
tor assumes that the player wanted the entire line as a sin-
gle token. If no such function is found, an identical
search is performed within the room the player is currently
June 22, 1990
Copyright, Marcus J. Ranum, 1990
in (in U-code: #actor._loc). If a function matching the
first token exactly is found, it is called, just as in the
case where a match is made in the universe rules.
Thus, if the system table has a "look" function, but no
"hop" function, and the room the player is in does have a
"hop" function, the monitor resolves input as follows:
look Albert -calls> @.look("Albert");
hop around happily -calls> <room>.hop("around","happily");
hop "around happily" -calls> <room>.hop("around happily");
Note how the tokens are broken up differently based on quot-
ing. It is also important to note that case-sensitivity is
preserved.
If the monitor fails to successfully find a function in
either the universe rules or the current room, it checks the
object the player is using for an function whose name
matches the first token. The mechanism here is exactly like
that of within a room.
If a matching function is found, it is called with the
second and succeeding tokens passed as parameters. For a
programmer who is writing functions bound to objects, one
important distinction must be made: when the monitor gen-
erates a call to a function, all parameters are passed as
type string even if they are numeric. There are U-code
built-in functions for converting strings into numbers or
object numbers, to simplify interfacing with the monitor.
3. Universe Rules
It is impossible to predict what universe rules a U-
universe might be running under. It is perfectly possible
that the rules of a universe might be intentionally guarded
as secret by the Creator for some reason or another. Need-
less to say, this makes documenting things rather difficult
- especially since changing the rules of a universe is a
matter of seconds. Presumably users will become familiar
enough with the monitor that they can get about in even the
strangest set of universe rules. Creators are encouraged to
make the U-code for their universes available to people who
plan to program in them, and to provide at least rough docu-
mentation of the commands in the universe table (since they
are always searched, and could surprise a player rather
badly).
4. Funky Objects
Owners of rooms will have considerable powers to create
"funky objects", damaging objects, U-virusses, and so forth.
Ideally a Creator will only give programming access to peo-
ple who will not do such things lightly. As a deliberate
June 22, 1990
Ubermud Monitor
design decision there are no attempts other than the basic
permissions system to prevent such programming, since
correctly used in a spirit of fun, "funky objects" can be
extremely entertaining. Presumably each Creator will have
some published or arbitrary guidelines governing confusing
and damaging objects.
5. Conclusion
The Ubermud monitor is still somewhat rough, but pro-
vides a reasonable amount of flexibility. The basic trade-
off is between the desire for complex parsing in the moni-
tor, and the desire to make as few assumptions as possible
about the universe rules that the current U-server is run-
ning under. The monitor was deliberately designed with the
idea of a "mode switch" to allow easy adding and experiment-
ing with new user-input processors. Once the user's input
has been massaged into a set of calls to compiled U-code,
the universe rules, which are far more dynamic and easily
changed take effect.
June 22, 1990