[MUD-Dev] Re: PDMud thread summary

[Darrin Hyrup]

At 02:04 PM 10/22/98 +0200, Niklas Elmqvist wrote:
>On Thu, 22 Oct 1998, Jon Leonard wrote:
>
>> There's been enough discussion about collaboration on a MUD a that it's
>> starting to get tricky to follow, so I thought I'd try to provide a
summary.
>
>Good initiative! This thread was becoming hard to follow. Oh, and I must
>say that to me, this thread has easily been the most interesting on the
>list since I joined (which you could probably tell by the frequency of my
>earlier posts as compared to now).

I've found a lot of the threads on this list to be entertaining and
informative, but I agree, this is probably the most interesting thread I've
followed in the last 6 months. :)

>The way I see it, PDMud should just
>about cater to anyone on this list, be they interested in game or social
>issues, to more low-level development aspects, design viewpoints, and so
>on. This is a many-faceted project where anyone with spare time could
>contribute in their field of interest/knowledge.

I agree.  I am getting quite excited about this, since it will give me a
chance to work with so many talented people, with so many diverse
goals/interests.

>[Structure:]
>> It should be a collection of mix and match modules, reconfigurable
>> even at runtime via dynamic linking.  Many of the pieces should
>> behave like pieces of an OS.
>> 
>> This allows for lots of flexibility for individual MUDs, understandable
>> pieces, and answering the question "Do we hardcode or softcode this?"
>> with "Both".
>
>The dynamically loaded modules allow us to get kind of a softcode (since
>it can be added and removed to the server at run-time) but still with the
>efficiency and speed of native code.

Not to mention ease of modification and expandibility. :)

>I still like to keep the distinction
>between the internal MUD language which is used for world/quest/puzzle
>programming and the implementation language which is used to create the
>modules (native code).  This allows us to delimit the compiler design
>project (building a production-quality native compiler is a *lot* of work)
>and tailor the MUD language towards game-specific stuff (which also would
>make it easier for non-programmers to grasp). Is this something we can
>agree on? Anyone not in favor?

I totally agree.  The simpler the in-game language (i.e., more game-related
and less system related), the better.  Especially we design it such that
novice programmers (and non-programmer GMs) can easily do simple things in
the language.  (We can't expect miracles, I'd expect any really complex
code would have to be done by a programmer anyway.)

>Another valid question: Is the driver just a bare skeleton? That is, will
>all functionality be dynamically loaded via the modules? 
>
>IMHO, the driver should consist of a few primitives which provide the
>minimal functionality of any game server. One such thing is an event
>manager (c'mon! almost all games need one), a message hub/system/chain
>another, the module manager a third. Comments, please. 

I agree... the driver should basically be the building blocks of the
system, and would be responsible for the low-level game management
primitives as you mentioned above, the plug-in manager being the main one,
of course.  I think it should also handle most of the I/O subsystem and
task management as well.  We can do just about everything else via
plug-ins.  Perhaps making some of those plug-ins mandatory (mud-language
interpreter and client interface manager for example) such that the system
can run in bare-bones mode with just a minimal VM core/lib.

>> Project home(s), project maintainer(s):
>> 
>> I'm volunteering to be project maintainer, keeping track of source code,
>> releases and so forth.  If someone else wants to, thats fine too.
>
>Fine by me. This is one project which might become huge in scope. (Just a
>warning :)

That's true.  Although I don't always have a lot of time, I'll volunteer to
help coordinate the project.  I'll also definately be lending a hand in
both coding and design wise here and there.

>A tentative attempt at work division:
> a) Driver/Core/Server: the base core, specifications, design,
>	protocols, inter-module communication, etc. The foundation, in
>	other words.
> b) Modules: language VMs, DB handlers, on-line building, etc
> c) Lib: world, quests, puzzles, mobs, etc

That's a great start.  I suggest that people volunteer if they have the
skills appriate to the lead up any of these divisions.  If we can start
gathering the design teams and selecting leaders now, the team leaders can
begin the task of assessing goals and assigning tasks.

>Everything below item a) should be designed to be "easily" replacable to
>make a wholly different kind of game, meaning the driver should be
>flexible enough to support *any* kind of game, from a high fantasy
>text-based MUD to a cyberpunk 3D graphics MMPOG. The flavor and behavior
>of the MUD should reside in the modules. That is, the driver should serve
>as an OS upon which several programs (modules) can be built to constitute
>a whole system (world). The driver does not necessarily need to consist of
>a lot of code (actually, maybe it should contain as little and be as tight
>as possible to improve efficiency, etc?), but must be extremely carefully
>designed.  Most of the work is done by the modules, though.

That sounds like a good mission statement to me. :)

>Needless to say, development of these areas cannot start at the same time.
>The inter-module communication and standard calling conventions must be
>resolved before anyone can start building modules, for example.
>
>If this is something we can use as a starting point, allow me to
>immediately register my interest in the a) area (with the option of
>getting on b later on). I'm especially thrilled about the design of a
>flexible system like this. 

Sounds good!  Maybe you'd like to volunteer as a candidate for the driver
team leader?

Best,

Darrin