[MUD-Dev] Re: PDMud (was Re: Bruce Sterling on Virtual Community goals)

[Darrin Hyrup]

At 09:58 AM 10/21/98 +0200, Niklas Elmqvist wrote:

>I am not entirely sure about the focus for the virtual machine (and it's
>language). As I see it, we basically have two options:
>
>1) Use the VM (and language) to implement game systems as well as a "quest
>and world programming language" (ala LPC or ColdC).
>
>2) Use the VM (and language) as a "quest and world programming language".
>Period.
>
>One way to look at it is to ask ourselves this question: "Do we want to be
>able to implement stuff like network code, DB handlers and event managers
>with our VM?" If no, we'd go for option 2) and stick to putting this kind
>of low-level/engine-specific code into dynamically loaded (there's that
>word again :) modules. If yes, go for 1) and design an all-out .
>
>Personally, I am all in favor of # 2. I believe that an internal language
>for a MUD should be tailored for use when programming the behavior of the
>MUD world, not the MUD engine. The engine is "nothing" more than a sandbox
>for the VM (cf JVM in browsers) which provides engine primitives such as
>event managing, data channels, security, etc.

I've always been a fan of #2 myself.  Thats what I've done in my commercial
projects.  Its much more efficient, and better lends itself to massively
multiplayer projects (supporting 1000+ simultaneous players.)

If we need to change the handlers for the low level stuff, we can always
implement a 'plugin' mechanism for such things without having to make our
VM handle that.

>> The issues for these buzzwords as I see them:
>> 
>> Efficient:  May make the VM harder to understand.
>
>Right. Could maybe be done later. The optimizing step is "just" a filter
>through which you pass the bytecodes before emitting them, after all.

True... however, we should also think about the design in terms making the
code more efficient, such that when we do wish to go back to clean things
up, we don't have to rewrite whole sections because of inefficient design.

>> 	Being able to run multiple threads of the bytecode is a must.
>> 	This can be implemented using something like cooperative multitasking,
>> 	or even just forcing each bytecode operation to complete before
>> 	doing something else (interrupt, other thread, etc.).
>
>Right. Cooperative multitasking is IMHO a little dated, and I (if I did
>this myself) would allow each bytecode operation to finish before
>switching to another Thread.

If the kernel for our driver/bytecode interpreter is set up properly, we
should be able to do real time/work-sliced multi-tasking within the VM,
without the need for cooperative multi-tasking.  Making the system force
bytecode operations to complete before switching to another task would be
fairly easy to accomplish in that environment (with some caveats, of course.)

>> If there are good workarounds for these kinds of problems (and the
consensus
>> is that people want to use C++), then I'll ignore my distaste for C++
>> (I've been burned more than once by C++isms on large projects) and use it.

I've migrated my development base to C++ over the last year or two.  I only
have 1 legacy application that I regulary work with that is still pure C,
and thats mainly because there would be no benefit to converting it to C++
at this stage (not to mention I don't relish converting ~1 million lines of
C code to C++.)  My programming team at work has developed our own C++
based API's for simplifying all our new development, and everything is C++
based now.

However, that doesn't mean we should do this in C++.  I think we should
seriously examine what our options are, compare the pros and cons (C is
usually easier for new people to understand, for example) and then select
one of them based on which one wins out the most.  My personal preference
is C++ if its a vote, but I think we'd be better served with a decision
based on the project, not on whim.

>Maybe this is a good time to survey how many people on this list are ready
>to pitch in on a project like this and contribute? Oh, and the list will
>be the perfect forum to tell our war stories as well as bounce some ideas
>and design issues before implementing them. 
>
>Btw, I've been with the list for a while and am surprised nothing like
>this has happened before(?). It seems like an almost logical step. 

I'd been lurking on the list for 6 months before I posted, and the second
thing I posted included a suggestion for an OpenMUD project. :)  It is
indeed something that is long overdue... with all the talented people we
have on this list, we could create the 'ultimate mud' and use it as a
tutorial for new people trying to get into MUD development themselves.

>> In-game entities involved:
>> 	A player
>> 	A room
>> 	A script
>> 
>> Sound feasable?
>
>Yes, very.

The 'entities' might be better described as:
	A connection
	A location
	A process

That way we don't get too tied down into a particular 'interface' to the
game.  That is, say I wanted to create a 3D game using this driver?  I
wouldn't want 'rooms' per se, I'd want locations (which might be 3d
coordinates on a map, for example.)  What if I wanted to make a game where
players had no 'bodies' per se, but stole those of others (ala JC's
Murkle), I wouldn't want a defined physical presense.  Etc, etc.  Most of
that kind of stuff can be worried about from the lib's point of view, the
driver need not know about it unless we have a good reason for it.

>> I'm not sure about the need for default handlers, and I can think of cases
>> where more than one thing needs to get notified when something happens.
>
>Okay, my thought was on having the default handlers take care of requests
>which are not captured by any of the modules attached to the message
>chain. That is, if no one took care of a "MegaBoom Spell" Command request
>(due to some glitch in the ParserModule versus the MagicModule), the
>default handler would silently take dispose of the request and emit an
>error message in the log or something. 

Ideally, if we set up some kind of inheritance in our design (this is going
to be O-O, right?), events/requests that are not serviced by a particular
node will pass the request to its parents, and its parents to their
parents, and so forth, until it is serviced, or discarded (with an error
message) if the root node discards it (having no parent to pass it off to.)

>> I'll happily contribute a website, server space, accounts, etc. on
>> frost.slimy.com.  (160 Kbit network connection, 600 MHz Alpha)
>> Somewhere else might be better.  (Kanga.nu would be easiest to find,
>> for example.)  There's nothing stopping us from having different modules
>> living on different servers, with links and mirroring to make it easy to
>> find stuff. 
>
>Yes, but the main server/core/driver (maybe a convention would be in order
>here) should reside somewhere nice. Slimy sounds just like what we need
>(SlimyMUD? :). 

We all have places we could do the development I'm sure... but I agree that
a central repository for the code-in-progress (perhaps set up as a RCS tree
like the Cold project folks do, with read-only access for the world and
full r/w access only for those authorized for modifying the project.  Might
be easier if we elect one person to be 'keeper of the source' and let that
person be responsible for any changes made to it, integration of
modifications, backups, etc.

However, it would be nice to have a 'test server' running that we could use
to prototype our versions for the list to test.  The frost site might be a
good place to host that.

>> I prefer having everything on my machine, but it really doesn't matter
much.
>
>Fine by me. My own server (486DX-100) is not anywhere powerful enough :)
>(Although I do have a T1 to the net -- in Sweden). 

Ideally we'll be doing work on our own development machines, testing
changes, debugging, etc. before we update the master source tree and
integrate the updates.  So, we'll all need to have access to some kind of
development machine.  Probably best to concentrate on the UNIX platform
(Linux perhaps?) to begin with and then worry about porting to other
platforms later.

>> > GNU Mud anyone?
>> 
>> Naming it GNU Mud is at least misleading if it's not GPL'd, and as much
>> as I like the Gnu Public License, it doesn't fit this project.
>> 
>> I want code that I or anyone else can modify, experiment with, and even
>> build commercial servers out of, without having to worry about what's
>> permitted.  GPL may not necessarily prohibit running commercial services,
>> but it might wind up forcing release of client source code (including
>> signatures to prevent cheating clients?) and be otherwise unpalatable
>> to commercial interests.
>
>Ahh, you're right. Well, it sounded neat and official. 

No GPL.  I love the GNU concept, but it is too restrictive for our use.
Pure PD is best for this, since that way people can use the code (in part
or whole) as they see fit, without having to worry about licenses or
conventions of use.

Best,

Darrin