[MUD-Dev] Embedded languages, object persistance... ack.

[Kevin Littlejohn]

Hey, this stuff looks familiar ;)  Check www.bofh.net.au/mud/ for mine -
python-based, MySQL based, doing persistance and code objects and etc.

(Um - This post has a lot about my own little play area, Moebius, in it.
That's because I'm still trying to find other examples of this stuff.  My
apologies in advance if it sounds like I'm pushing what I've done - I'm
not, it's not nearly ready to run an honest-to-ghod mud yet, and is
probably badly coded to boot - but it's the only thing I know atm ;)

>>> "Joe Kingry" wrote
> I've been trying to figure this out lately. At first glance I generally
> thought I knew what it was about, but now I'm not so sure.
> 
> I mean, I know what the goals in general are. Persistance. You have a house
> say in some place in the world. It get's damaged, it stays damaged until it
> is repaird. So persistence is done through some kind of database, or
> multiple databases broken up to distribute categories/workload.

Databasing gives you a little more than that in terms of persistance, tho.
Because there's no load/save, things are committed immediately, there's no
potential loss of information in crash etc.  Also, if you're storing time,
you can either roll the database forward on restarting a mud, or split out
things like the event engine and run that seperately from the rest of the
mud - so it's "alive", even when the mud isn't.

> I want a mud server on which I can change the code online of say a skill, a
> spell or something else. I understand that this is the purpose of having an
> embedded language that runs "on top of" the mud's driver. i.e. MUF for MUQ,
> Python for AR3 etc.  So in general I know this code is to be compiled since
> you don't want to be executing "scripts", but is this code an object? and
> then is the byte-code stored? ack.. I'm confused.

In mine, yeah, bytecode is stored in the database.  You _can_ treat the
code as objects (as I'm about to play with doing), or you can re-build them
as methods on objects - so a door would be an object, the open and close
methods (which exist in the database, so you can hack them up whenever) are
methods on the object, and are re-attached when they're executed.

I suspect others have different ways of dealing with it, and I suspect
it'll be affected by the ease of doing certain things in certain languages.

> Here, I'll try to demonstrate what I little I think I know from MUSH type
> enviroments. A MUSH allows you to create an object. Great. This object is
> unique and persistent. Ie. it will be there when you get back if you so
> desire. You can assign code to execute based upon certain defined actions on
> the object, or you can create a new action for this object. Going by this
> model then, does that mean every single object in these "new" muds is a
> class and is inherited from a previous object? But then it's executed how?

That's not a problem.  (and yeah, every object can be considered a class
also).  Python at least offers you the ability to 'execute' classes - you
just give them a __call__ method, and you can call them.  Best used for:

class player:
  def attr1
  def attr1

normalPlayer = player()

normalPlayer.strength = normalPlayer.strength + 20

dwarfPlayer = normalPlayer()

If you've done good databasing in the backend, creating an instance of a
player, tweaking it, then using it as a class essentially means you created
a new 'type' of object.

Moebius starts with a bunch of pre-defined object types - player, object,
location - but they're completely arbitrary, and not at all needed.  They
make life easier for the creators - create a 'door' object, you
automatically get dest_location attributes and an open() and close()
function.

Why should you treat classes and instances seperately?

(Incidentally, there's a topic in there I'd love to pursue with other
like-minded souls - multiple inheritance vs. single inheritance, levels of
inheritance, and the possibility of a 'kit' approach on top of inheritance
- so you go "mageDwarf = mageKit(dwarfPlayer)" to extend things, then
optionally use _that_ as a prototype...)

> I think I have my object/class/code/driver concepts all muddled.

It does seem to get mixed up once you start playing with this stuff.
Objects are things that exist, classes are the things you create them from
(and can optionally be objects themselves, in some cases, maybe?), code is
executable stuff that belongs to objects (or floats free), the driver is
the underlying core that should not need changing(tm)...

ColdC looked like another interesting place to look for stuff like this.

> 
> All I want in a mud server is this:
> 
> -stores things in a database file(s). No more 4000 player files.
> -allows me to define objects online. Ie. I can decide I need an object that
> will act like a boat, and I can code and modify this online.

Part of the trick to that is being able to add new methods.  For example, I
wanted doors to work - so I coded 'close' and 'open' functions to toggle a
attribute 'open' in the object they're attached to, added that attribute
(and those functions) to something, re-coded the 'move' function to pay
attention to whether the door was open or not - and presto, closeable doors
;)  Should be doable, but you need to have access to change even the base
functions like move and look every so often...

> -doesn't have every object in memory, only when needed, otherwise on file.

Yup, although you'd be surprised what's "needed", when you've got complex
interactions happening.  Moebius handles this really badly atm  :(  Because
the top-level code pretends it's not using a database, it touches every
object when you do things like 'who' or 'list live creatures' or whatever.

> -doesn't require me to learn it's "own custom embedded language", this one
> really gets to me
> -somehow allows for security and access levels while coding

This is really interesting.  Moebius at the moment is dog-slow, because of
'bastioning' - protecting the internal classes from external view (python
doesn't have a concept of public vs. private attributes in objects).  That
has to be done for the sake of one variable - the 'self._db' - which gives
full access to the database :(

I'd love to find a solution to this, but it's an interesting exercise
creating objects that can talk to the database, and then creating a view of
those objects that can only use the defined methods.

> -somehow allows for an event type system

That's a whole 'nother kettle of fish ;)  Also another thing I've got to
read up on - what do people consider appropriate for event systems/what
needs to be supported?

> -allows code to be contained in packages and has appropriate management
> features. Ie. I can write the code offline in a file and then upload the
> file to the server

Upload?  Hrm.  I'm going to shortly write something that drags code from
the database, presents it in a flashy tk-based window, lets you edit it,
and commit the changes.  Would that be the sort of thing you're thinking
of?

Once you throw a db into the equation, your ability to tinker with things
_should_ increase dramatically - you open up a range of ways of dealing
with the data, from web pages (see below) to python/tk/C/C++/perl/insert
favourite language here, to the "stranger" (because I don't know anything
about 'em ;) things like ODBC...

(Hrm - forte as a mud building tool...)

> -will allow for http access to the database

If you've got a database, you've got that - um, again, check
www.bofh.net.au/mud/, in particular the 'live' section there.  I cheat -
Zope has beautiful database connectivity, so it's simply a case of writing
the sql to retrieve the info from the db, and wrapping that sql in basic
pages.

> 
> An added bonus would be, but hardly nessesary:
> -driver ported to both Win32 platform and *nix platforms and database is
> independent of platform.

Pick a platform-independant language, any platform-independant language ;)
python/java for your base code, pretty much any database, ODBC support and
you're there...

> Muq seems to have most of these except for MUF, I got tired of programming
> backwards ;).
> Then there is Momoko, it uses Java which would be great, but I'm not quite
> sure how to go about things and if it insists on having everything in memory
> or not and file management etc and i'm unclear if every unique object is
> it's own class on a persistent system.

Hrm - new things to look at ;)

It looks like the answers to your questions might be codebase specific, in
honesty.  I can say what' I've done in Moebius, others will be able to
explain the object/class model and inheritance system for their own
codebases - but those are not likely to be the same thing across muds.  In
fact, I suspect with the newer muds, they're being built specifically to
try out new and interesting ways of modelling objects, at least in part ;)

KevinL



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev