|"They washed their hands and arms, legs and feet, and then they washed their naughty bits." -- Three Men in a Tub, Monty Python|
A Reflection of Willpower
In order to present the underlying story of a simulation in a meaningful way, MUDzilla defines
object called an
Through the repeated execution of events, MUDzilla manipulates the simulation environment according
to your ideas. Once you have created the objects necessary to store the various aspects of your vision,
you will create events to manage these objects according to your plans. Events are the basis for
the expression of your will, a logical wrapper around your thoughts.
Modifying the Multiverse
Events are designed to replace the computer programming notion of coding, where lines
of text are written in some computer language, and then compiled or interpreted into some machine-readable form.
Designing, writing, and testing computer programs can be a long, tedious process, with the potential
for errors serious enough to halt a computer, or cause data corruption. Events insulate you from
coding, while providing many of the robust features of programming languages. Because events are
themselves simulation objects, they can be managed using the
a software application included with MUDzilla.
All actions within a simulation can be reduced to the modification of
associated with the
of simulation objects. The MUDzilla Event Model not only describes how events manage
other simulation objects, it also defines a method for remembering how these objects are modified. This knowledge,
called history, can be used later to refine the simulation's assessment of its current state.
As a simulation collects history, it will gain an increasingly detailed picture of itself, allowing the simulation
to continually improve its response to the actions of the simulation's participants.
Modifications to simulation objects can be divided into two groups:
1. Simple Changes. The Event Model allows you to make simple changes to objects
which require little or no thought on the part of the simulation. Such modifications are
geared toward system-level actions, or where the results of the changes are trivial, having
no distinct meaning within the context of the simulation. The target object is simply changed.
2. Complex Changes. During a complex object modification, the simulation uses
the target object's perspective of the
while it calculates the changes to be made. This allows the target object to influence
the modification, to become actively involved in the process of change. This two-sided
arrangement gives you minute control over how each modification proceeds.
A Scientific Approach
At the heart of every MUDzilla simulation lies the Event Driver,
one of the software components included with MUDzilla. The Event Driver implements a version of
the scientific method, allowing it to pose questions as to the state of the Multiverse.
The Event Model specifies a number objects to encapsulate this process, using the following steps:
- Pose a question, called a condition.
- Predict a result, called a possibility.
- Obtain a result, called an effect.
- Compare the predicted result to the obtained result, called a perception.
- Store all information gathered in steps 1-4, call it history.
The simulation uses history primarily in step 2, where it predicts some outcome, and
will seek to refine its predictions for greater accuracy the next time a similar question is posed.
All you have to do is create a list of possible outcomes associated with the application
of an effect. Should a result occur that is not in this list of possibilities, the
simulation will add it, thereby increasing its knowledge of how the Multiverse operates.
A Matter of Perspective
Each of us has a unique viewpoint of the universe in which we live. There are as many versions of the
story of our cosmos as there are humans to tell it, past, present, and future. The Event Model is
flexible enough to represent them all, choosing no one viewpoint above another, unless you
configure your events to do so. Each simulation object can possess so-called perspective
objects. They are linked to events through a common effect type. Effect types are
designed to capture the essence of a modification.
Touching a simulated hot stove, for example, might invoke
a participant's perspective of heat, allowing the simulation to indicate to the
participant exactly what happens when one touches a hot stove. In this case, heat is
the effect type. Bare-handed, the participant will likely be burned. But let us
suppose the participant is wearing a glove, which has a different perspective of heat, one which
it passes on to the participant by virtue of wearing the glove. Here, the participant
would be spared the fire, though it may singe the glove.
Each perspective usually has multiple outcomes associated with it, called possibilities.
Each possibility is rated by its likelyhood to occur. Once a possibility is selected, anything can happen.
The perspective may not alter an incoming effect at all. It may interrupt the effect, or modify it
before it is applied. Complex perspectives may even call other simulation events in order to
completely satisfy the chosen possibility. Once a perspective has been applied, the simulation
will create a history object, which transitions an event from the present into
the past. Any perspectives that were selected become perceptions of the original event, and any
chosen possibilities become lore, a unique viewpoint of the unfolding of the simulation's
We meet the burden imposed on us by the Nothing Unreal Exists
axiom because events can only modify other simulation objects, all of which we have determined are real.
Events are robust entities, capable of calling other simulation events. Events can even call themselves,
a process known as recursion, a powerful programming technique that allows a great deal
of work to be done using a small number objects. Recursion is not without its hazards, however. Imagine
a series of events trapped in a recursive loop with no exit strategy. The result would be a frozen
simulation, obsessed with a tiny part of the Multiverse, unable to move past some event.
We've all had days like that!
As a simulation designer, you will take as many precautions as you
can to guard against these so-called infinite loops by configuring your events with
some conditions under which the recursion will logically end. But there may be times, particularly as you test your events,
where you may have missed some key element within your events, and a recursive loop occurs anyway.
Armed with Gödel's Incompleteness Theorem,
the simulation limits the number of times any one event can be executed within a single execution chain.
This limit is configurable, depending upon your exact needs.
Click on the image for additional detail.
Below is a graphic which represents the MUDzilla Event Model. The red arrows indicate data flow, and
the vertical tiers link various related components together. You can click the diagram to obtain glossary definitions
for each component within the model.