[MUD-Dev] Embedded languages, object persistance... ack.
jkingry at uwaterloo.ca
Wed Dec 29 01:03:00 New Zealand Daylight Time 1999
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.
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.
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?
I think I have my object/class/code/driver concepts all muddled.
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.
-doesn't have every object in memory, only when needed, otherwise on file.
-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
-somehow allows for an event type system
-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
-will allow for http access to the database
An added bonus would be, but hardly nessesary:
-driver ported to both Win32 platform and *nix platforms and database is
independent of platform.
Muq seems to have most of these except for MUF, I got tired of programming
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.
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev