The Power of Thought

The Genesis of MUDzilla
Database Model
Object Model
Power System
Our Destiny
 
Our Products
Our Services
Our Software
System Design
Product Support
Help System
Contacts
Sign Our Guestbook
Home Page



The MUDzilla Simulation System

MUDzilla Event Model

"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 Strength
A Reflection of Willpower

In order to present the underlying story of a simulation in a meaningful way, MUDzilla defines a special object called an event. 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.

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 Object Editor, a software application included with MUDzilla.

The Power of Ideas

Modifying the Multiverse

All actions within a simulation can be reduced to the modification of values associated with the properties 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 Multiverse 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 to Creation

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:

  1. Pose a question, called a condition.

  2. Predict a result, called a possibility.

  3. Obtain a result, called an effect.

  4. Compare the predicted result to the obtained result, called a perception.

  5. 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

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 underlying story.

Infinity

Logical Integrity

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.

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.

Click the Image for Additional Detail
Click on the image for additional detail.
  Next Topic: The Power System
 

[ System Design | Database Model | Object Model | Power System | Our Destiny ]

[ Products | Services | Software | Support | Help | Contacts | Sign In | Home ]


Please e-mail us your comments and inquiries.
© 1994-2001 Myne Corporation

Myne Corporation