The MUDzilla Web Administrator
permits you, the
to create, test, and manage the objects which make up the core of the
MUDzilla Simulation System
From within this application, your ideas will be translated into simulated
reflections of your own thoughts, detailed in every way, according to
you are trying tell. And because the MUDzilla Web Administrator
requires only a web browser, your vision
can be implemented from
To make effective use of the MUDzilla Web Administrator, you would
be well-served if your wisdom included:
Who Are You?
Within a MUDzilla simulation, you are god, emporer, pharaoh, and king. You
wield absolute power over your creations, a responsibility not without
its hazards. For not only must you learn the interrelationships between
the various MUDzilla objects
which make up your works, you must also weave them together in a coherent
fashion, satisfying your vision of how these objects should interact
socially, economically, and politically within the larger simulation.
In MUDzilla, simulation participants, often called
are divided into two camps: administrators and seekers. Administrators,
like yourself, are typically few in number, and serve as the simulation's
designers, engineers, operators, and loremasters. Seekers represent the
bulk of a simulation's participant base, indeed, the very reason
administrators exist in the first place. Seekers serve to live out
the stories embedded within the scenarios created by administrators.
The interaction between administrators and seekers within the simulation
depends on the exact configuration of the simulation itself. By default,
seekers are not aware of the actions of administrators, at least not
directly, one avatar to another. This allows administrators to pass
unseen within the simulation, ammending plots, fixing bugs, and taking
on the roles of various static seekers, called non-player characters,
in order to fulfill the simulation's underlying story.
For additional information on simulation administration, see the
MUDzilla Design Overview.
What Do You Want?
All of your simulated creations, regardless of content or scope, share one
thing in common: it must first occur to you what it is,
exactly, you want to simulate. This Spark of Revelation marks the
beginning of your path to becoming an effective MUDzilla simulation
administrator. Once you have something in mind, you will use the
MUDzilla Web Administrator to turn your idea into a simulated
There are two, distinct approaches to MUDzilla from an
administrative point of view, and they reflect MUDzilla's
dual nature as both an engineering tool, and an instrument of
artistic creation. You will find that attention to detail,
regardless of which mode you are in, is a key to the success
of transforming your thoughts into simulation elements.
No matter how complex a simulated construct becomes, in MUDzilla,
it all boils down to manipulating the values
of the properties owned by
simulation objects. As
a simulation designer, you will manage your creations using special
objects called events,
generic data engines which manipulate other objects using a combination
of algebra, boolean logic, and the scientific method.
simulation will be intensly curious about itself, and any actions
it hosts, providing you with exacting detail as to What was done
to Who, Why they did it, When, and How. It is designed to be so flexible,
you need not worry about if something can be simulated,
but how long it will take you to design and implement it, given your understanding
of MUDzilla. In other words, the story
drives the shape and function its underlying objects, not the reverse.
Not only does MUDzilla provide you with a logical, ordered
representation of your ideas, it also allows you to interact with
your creations directly, inviting whomever you like to explore them
with you. One way you will manifest yourself within the simulation is
through the non-player characters you will create to
represent the living parts of the underlying story.
You can take up these roles at will, becoming
these individuals in an effort to expand the boundaries of the
plots you have created. Your own role-playing ability will become
the motivating force behind much of what you do. The tools embedded
within MUDzilla will help you to do it with style!
Throughout this and other MUDzilla help manuals, you will encounter punctuation
marks which provide meaning specific to the MUDzilla Simulation System.
What follows is a list of these punctuation marks, and their meaning:
1. Used in HTML and in MUDzilla responses
to identify tags within a web document. When the document is requested,
these tags are processed, resulting in a file whose exact format
and content is not known until the time of the request.
2. Used to identify required parameters within a formal
syntax declaration, such as a
simulation command. Consider:
TAKE <object name>
In this example, the parameter
is considered a required part of the
Square brackets are used to indicate optional parameters within
a formal syntax declaration, such as:
SMILE [ AT ] <object name>
In this case, the parameter
[ AT ]
is considered an optional part of the
A verticle bar separates possible options for a parameter
within a formal syntax declaration, as in:
TAKE <ALL | object name>
<ALL | object name>
indicates that either the word
an object name forms the first paramter of the
1.The period is used within a formal property reference to
separate the object part of the reference from the property portion.
Consider the following formal property reference:
In this exanple, the period divides the class name
from one of its properties, called
2.The period is also used to separate object names within
a contextual object reference, such as:
Hollywood and Vine.Hollywood.California.USA.Earth
Contextual object references begin with the least significant
object, and proceed from left to right to the most significant
object. In the example above, a
geographic context is used,
beginning with a room name (Hollywood and Vine), followed by the
geographic divisions which make up the room's context within the
||The Letter T
Whenever a name appears as though a capital letter T
has been added to the beginning of the name, as in
, it indicates the name
refers to a MUDzilla class.
Classes are used to describe each of the objects which constitute
a MUDzilla simulation. The letter T stands for
type, to let you know you are dealing with a
kind of thing, rather than the thing itself. It's
the difference between handling blueprints (classes), and the
actual building (an instance of a class).
Whenever a name appears in orange,
it represents the actual value of some property, as opposed to
the name of the property. It is the difference between, say,
a property called HairColor, and its value, which could be