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> .hop("around","happily"); hop "around happily" -calls> .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