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

[Darrin Hyrup]

At 09:03 AM 10/21/98 -0700, Bruce Mitchener, Jr. wrote:
>Good morning,
>
>>I think making it explicitly public domain would best serve the members of
>>the list.  That way nobody needs to be concerned about what happens with
>>the code.
>
>I am not a lawyer but .... I saw a reference on the linux-kernel list
>(http://www.linuxhq.com/lnxlists/linux-kernel/lk_9810_03/msg00806.html) to
>possible problems that can result from the laws surrounding public domain
>code in some countries, where the original author is still liable for
>anything that happens as a result of someone's use of that code.  An
>explicit license granting full permission and so on may be more appropriate?

Well, if needs be, we could put a license/disclaimer at the top of every
module saying that the code has been released into the public domain, and
insert the traditional blurb about how the authors accept no responsibility
for what you do with it, people you kill, etc.

>I'd be really interested in hearing what it was that it didn't do that you
>wanted. :)  If nothing else, it might help the current effort on this list
>to avoid some of the mistakes that we (Cold people) have made in the past
>(and continue to make today).  If thisn't on topic stuff, feel free to
>respond to me directly, or to drop by telnet://ice.cold.org:1138/ and chat
>with me there.

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.

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.
  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
  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.
  o It should have a simple object oriented internal programming language
that non-programmer GMs can learn easily.

  The core/lib should only determine the look/feel of the game.
  o It should allow a functional (yet spartan) game with a minimal lib.
  o It should to be flexible enough to be extended to support any type of
interface necessary without rewriting the whole I/O and command subsystem.
  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'm leaving out a lot of little things too.  ColdC/ColdCore has most of
that, but not all, (and I could live with that, but I thought it might be
more fun to do it from scratch.)  ColdC is rather powerful, but seems more
complex than it needs to be (of course, it also needs to be more powerful
being the low-level game engine is also built into the core, rather than
built into the driver as I would prefer.)

Best,

Darrin