[MUD-Dev] An Idea... Mud Development Framework

[Jeremy Lowery]

<EdNote: Quote severely trimmed.>

----- Original Message -----
From: "Bruce" <bruce at puremagic.com>
To: <mud-dev at kanga.nu>
Sent: Sunday, January 14, 2001 3:32 AM
Subject: Re: [MUD-Dev] An Idea... Mud Development Framework

> Jeremy Lowery wrote:

> > The Object Factory
> >
> > The object factory manages all objects created in the
> > DE. The factory also includes built in support for object
> > serialization via standard C++ file streams. The factory
> > maintains the file structure of all game objects internally
> > in a special resource file named ofrdb.mlib (object factory
> > reference database). The factory also needs to keep track of
> > all objects created in the game. This is accomplished by a
> > unique virtual index number assigned to every single "thing"
> > created in game (all of which are objects).
>
> That sets an initial assumption that you'll be working in C++.
> Are these objects C++ objects, or some construction of your own?


C++ objects

> What happens when (not if) someone puts the wrong data into
> ofrdb.mlib?
>

All files will be put through a tokenizer/lexical analysier before
they are introduced into the system.

> What are the virtual index numbers used for? (Why are they
> virtual?)

The initial idea behind the virtual index numbers is a way to handle
dangling pointers. Since poiners are (in a way) a unique key.

> Can you have multiple object factories?

In a sense, yes. I haven't decided whether to have a set of base
objects definitions and have class factories associated with each base
class, or to make the object system completely dynamic, therefore all
objects would be created from the same object factory, based off of an
"object template" type mechanism.

> >   b.. System Snapshots
>
> How will you go about maintaining the integrity of the data and
> insuring that a snapshot is a fully consistent view of the data
> at that point in time?

All objects will have an independant saving mechanism based off of
file streams, there will be integrity tests for objects referenced in
more than one place, etc.

> > The Notifier
> >
> > The object notifier is a singleton object that processes
> > and dispatches object-based messages. Based on the message
> > scope and type, the notifier dispatches the message to the
> > corresponding target object(s). The notifier also has built
> > in security features that allow message destruction before
> > processing for invalid message usages. The notifier and
> > object factory work closely together to handle object-
> > creation and message dispatching. Indeed, they share the
> > same object pool.
>
> Why is there only one notifier?  What happens in the event of a
> distributed system or a cluster of servers?

Haven't thought of this :)

> > Game Messages
> >
> > Object interaction is achieved by using the notifier. All
> > objects must override member functions that parse system
> > messages directed to them by other objects.
>
> There is no way to have a message bound to a bit of code (like a
> method), or do I misunderstand what you mean when you say
> 'parse'?

A bad use of the word parse :) System message will be numeric
constants

> > In addition to simple object messages, the DE also
> > supports message scope resolution for message sending
> > objects. These specifiers can be used to send messages
> > at a certain game-level scope (More on this a little
> > later). All messages are identified by a unique integer
> > constant abbreviated MM_ (for mud message). Associated
> > with messages is a generic message handling data-type
> > identifying message specific data. Unlike most MUD systems,
> > the MDK does not explicitly bind client messages to
> > character objects. One of the main advantages this
> > approach exposes is the use of a common socket-polling
> > connection for every kind of game manipulation that is
> > possible. Aside from characters playing the game, this
> > also allows administrators, builders, and developers to
> > have parallel game access, but via different interfaces.
>
> I'm not sure that I understand much of the above paragraph.

A lot of the bases I have seen have builder ports. By not having
explicitit binding of conenctions to character objects, connections
can be bound to other "builder type" objects.

> > System Messages
> >
> > The framework can also send messages to game objects.
> > Unlike game message, system messages know no boundary.
> > Of course, it is the object's responsibility to actually
> > do something with the message. Common examples of system
> > message include time messages, shutdown messages, client
> > disconnection, and persistence messages (i.e. messages
> > that tell objects to save themselves on a regular basis
> > incase of system failure).
>
> Is there any default handling for some of the messages, like the
> one directing an object to save itself?  If not, wouldn't this
> have the negative effect of distributing the knowledge of
> handling data saves through out the code?

Yes, all objects would have default message handling abilities.
Ideally, all objects must implement functions to execute manditory
system messages (such as Save)


> > The Life of an Object
> >
> > Generally, all objects live the same life inside the
> > program. They are created by the Object Factory, load
> > their data from disk, sit around processing messages,
> > and eventually die. Of course, the most interesting
> > part is the message processing. All objects are inherently
>
> I don't know .. I think that the 'eventually die' part of the
> object lifetime is Very Interesting.  How do you know when an
> object can die?  How do you handle lingering references to
> it/dangling pointers?  Do you explicitly manage the lifecycle of
> objects?  Use refcounting?  Full blown garbage collection?

Well, generally objects "die" when they are destroyed inside the game,
or if a client has the object, when the client closes its connection.

> To solve this problem and others, I wanted a system that didn't have
> a 'driver' or a 'core'.  I didn't want to have to switch languages
> depending on which level I was working at.  I wanted to be able to
> soft-code things to prototype them out and then 'convert' them to
> 'hard code'.  I want to see a new type of server where you can work
> in the same language from the ground on up, accessing the same
> object model.  Ideally, I'd be working in an interpreter for that
> language to prototype while the server is running, and then have a
> mechanism for compiling code that native code to be linked into the
> server for greater speed.  Because there is no boundary between
> 'driver' and 'core', but only a set of libraries which comprise a
> server framework, there aren't arbitrary boundaries to work around
> in setting up low level elements of the system.  I'm on the path
> currently towards creating such a server.


One technology that I"ve been looking into can do something very
similar.  It's called Active Scripting. The idea would be to define a
a set of COM Servers that expose pragmatic interfaces to script. A
client would initialize base services, the loading sequence, and
instantaniate the runtime. Core system scripts (such as object
definition, command interfaces, etc) would be compiled into the
program on initialization for speed. Of course, scripts could be
compiled into the server during runtime as well.  The easy way out
would to add references to the scripts that are to be compiled into
the server at runtime. On loading, all compiled scripts with
references would be compiled into the server.  You could get a bit
fancier by actually extended the server with the scripts as "patches."
For other scripts, a script cache would be set up for speed.  The COM
Servers would expose objects static objects such as Server, Database,
Runtime, as well as building Servers such as ObjectBuilders and things
of this nature.

Scripts could be written in any language that has an ActiveX Script
Server Component Registered on the system.  Such as VBScript, Python,
JScript, Perl, and LISP, completely depending on the programmers
preference and the Interfaces that Language Components provide .

Jeremy
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev