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

[Adam J. Thornton]

On Wed, Oct 21, 1998 at 11:58:51AM -0400, Darrin Hyrup wrote:
> 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 plugin mechanism needs to be designed in from the start, and needs to
be extensible without being completely ridiculously inefficient.

> 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.

IOW, "Think, *then* code."

> 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.)

I recommend, with all the zeal of the recent convert, that pthreads be used
as the multithreading core.  Possibly to the exclusion of multiprocess
code.  I doubt that Win32's POSIX is good enough to handle pthreads yet,
but eventually it probably will be.  And pthreads are slightly more
portable than, say, Solaris native threads.

> 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.

If it's a vote, well, I dunno.  Compiled-to-native Java, if it existed in a
cross-platform fashion, would get my vote.  I never know just *what* the
C++ compiler is doing under the covers, which is one of the reasons I
prefer to use C.  OTOH, it gets uglier to do things like inheritance; you
lose a lot of the ease of doing an OO design in straight C.  Still, I
*understand* C in a way that I do not C++, and I don't think I'm alone.  I
don't understand Java as well either, but the networking and serialization
models are so nice to have that it'd be worth it--if, for example GJC
happens in a workable fashion soon--if performance can be made adequate.

> >> 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.

Here we run into a fundamental design problem.  The more abstract your
world-model, the less efficient any particular implementation, and
furthermore, the more hoops you have to jump through to get an actual
MUD--rather than a MUD development framework--out of it.  There exists a
tradeoff between flexibility and complexity that really needs to be
hammered out *before* coding starts.  My current project, I decided that
the fundamental scope of the world would be the room: there are rooms,
locations within rooms ((X,Y) plus Z modifier), and object trees rooted at
each location.  Each room maps to a process, each animate object to a
thread.  Each thread has its own socket to the controlling client.  This
greatly restricts my flexibility--for starters, because of the model I've
chosen, a true 3D representation is, if not impossible, at least
infeasible--but made actually designing a codebase much more
straightforward.

> 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.

If anyone wants to accept that mantle.  I sure don't; it's a lot of
responsibility and time, and I think most of us have other responsibilities
that preclude stepping into those shoes.  Still, this would be the right
way to do it if a volunteer could be found.

> 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.

Consider this a vote for keeping it very POSIXy so that ports to, at least,
different Unices and other systems with decent POSIX subsystems (e.g. OS/2)
remains pretty simple.

> >> 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, [GNUMud] 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.

I'm not sure I like Pure PD.  I'm all for allowing free hacking on the
code, adoption in commercial servers, and all that jazz, but pure PD looks
like a license to appropriate others' work without attribution.  Is there a
license that says "Do what you like to it, but accurately summarize the
changes you made and append your name to the list of developers in the
source you started with?"  What does the Artistic License look like?

Adam
--
adam at princeton.edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman