> From: [...] Blake
> To simplify, I'd say no peer-to-peer. At least for now. And 
> I'm not sure  
> what the value of P2P would be in this context. Reduce server 
> load, maybe.

Reduce server load, reduce latency, reduce server bandwidth
requirements.

> > 2a. A way of writing the game framework.
> >
> > 2b. One or more game frameworks and rulesets.
> 
> For simplicity's sake, I see 2A being built-in. Maybe an 
> implementation of  
> D20 or GURPS or even something SIMS-like. Or a combination.

Ah.  Now, you see, to me these are game frameworks - my 2b.  The way of
*writing* the framework should be neutral to these.  By the way, the
GURPS license explicitly forbids computer implementations without SJG's
permission (or did last time I saw it) - not seen D20.

But why should I have to choose D20 or GURPS or...?  More interestingly,
if I choose to make this codebase available to others (cf. a typical MUD
driver), why should *they* have to be content with my choice?

> Yes. I'm not keen of giving people a full Smalltalk 
> implementation with  
> unfettered access to the entire server. It's both unwieldy 
> and insecure.

Indeed.  Hence my interest in custom VMs.  Although I do think you need
an *escape* to full Smalltalk.  I've spent 15 years running a
Tiny-derived MUD where the user language and the programming language
were the same; it's not powerful enough.  In my opinion, you need a
variety of languages and runtime systems for them, with at least one as
powerful as your implementation language.  Then you need to make all of
them so secure that a dedicated cracker can code effectively, but can't
break your game.  Even when s/he has characters walk into a location
that's trying its hardest.

> The obvious (not necessarily best) approach is a hierarchy: 
> users->content creators->framework creators->ruleset implementors.

... With some overlap between the levels.

> I'm not too worried about tools, since creating content 
> usually suggests the needed tools.

Sorry, I disagree.  How do you find your content creators - who are,
after all, users - without these tools?  And if you're going for 2D or
3D systems, these tools are neither quick nor simple to create.  Nor is
the content, as almost any 3D modeller will testify.

> > 4. Users.
> 
> I can supply some. Maybe a couple-hundred, maybe 5-10 at a 
> time, more or less depending on 1b.

Who are they?  What do they want out of this system?  Are they
achievers, explorers, socialisers or killers? (see
http://www.mud.co.uk/richard/hcds.htm - I don't necessarily agree with
the fine details of his taxonomy, but it's a useful overview and widely
used).  Remember that your content creators are users of your system...
How do you get them on board?  How do you keep them?  How do you ensure
that they create content that will attract others?  This isn't a ROM,
with a load of pre-built modules that you can simply load - or do you
make something that can import and run ROM areas?  How do you then make
that 3D?

> On the other side, I don't want to get =stuck= with a telnet-only  
> solution. (Text MUDS are so...1987...aren't they?)

<Chuckle>  January 1990, in my case - and it's been running pretty much
ever since.

> I'd like to be able to  
> (maybe) start with a text-based version then allow 2D and 3D stuff.

Sure.  But how do you migrate between these forms?  In a 3D world, it's
a bit awkward to have a page of text stuck in the middle of it.  And how
do you convey a texture on a telnet session?  Or do you start with text
and then move forward, *losing your old form of interaction*?

Sorry, far more questions than comments and answers.  To be clear, I'd
be very interested in collaborating in some way, if we could get to
views of what we wanted that had enough overlap that the collaboration
would work.  But my interest is much more at the engine level - how do
you get something that is very flexible, very extensible, and yet very
secure against attack?

		- Peter