[MUD-Dev] Re: Bruce Sterling on Virtual Community goals

[Niklas Elmqvist]

On Wed, 21 Oct 1998, Darrin Hyrup wrote:
> First off, don't get me wrong, I really like the ColdC/Genesis approach.
> The main things I wanted were stuff that is pretty much personal preference
> for my own system, and the kinds of things we'll have to decide when we do
> this OpenMUD/PDMud project.

I'm starting to like the OpenMUD name... We'll have to hear what the
consensus is, but my vote is on that name. I must've just skipped your
earlier post where you mentioned that.

> When I initally reviewd the ColdC stuff (back in July I think), I wanted
> (off the top of my head):
> 
>   The whole environment should have a free-for-any-use license.
> 
>   A driver should act like the kernel of an OS.

Amen to that. Mirrors exactly my thinking. OS design is a good source of
inspiration.

>   o It should support multiple concurrent threads/processes of execution
>   o It should be written in C++
>   o It should support relational object oriented persistant store
>   o It should support plug-ins and/or dynamic loading for driver expansion

I would like to add this: not only should the server support this, *all*
mid-level (i.e. game logic, meaning not quite as low as engine code and
not quite as high as lib code) -- or virtually all -- functionality should
be added dynamically to the driver via plugins. 

>   o It should incorporate low level code (I/O, IPC, event management,
> plugin management, thread/process management, etc) directly in the driver,
> rather than implement it in the lib/core.

Aye! But, again making the distinction between driver code and
game-specific code, I would like to attribute such things as event
management, plugin management and inter-module/plugin communication to the
driver and I/O, parsing and maybe even the VM(s) to the dynamically loaded
plugins.

>   o It should have a simple object oriented internal programming language
> that non-programmer GMs can learn easily.

This is one reason why we should focus on an internal language which is
merely used for world programming, not for driver system programming. This
would allow us to tailor the language to this end (and thus make it
simpler). 

>   o It needs to be be efficient enough to support hundreds of simultaneous
> users without requiring a supercomputer. (If this means a compiler and
> dynamic loading for things written in the internal programming language,
> then fine.)

I have no objection towards compiling the internal programming language
separately (actually, the driver model becomes cleaner if you don't have
to have a compiler as part of it), but byte-code compilation should
suffice -- after all, we do want to have our DB objects
platform-independant. Or was this what you referred to when you talked
about dynamically loading things written in the internal language?

> Darrin

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
  "Nanny Ogg looked under her bed in case there was a man there. 
   Well, you never knew your luck."
		-- Terry Pratchett, Lords and Ladies