On Thu, 10 Mar 2005 19:56:28 -0000, Peter Crowther <Peter at ozzard.org>  
wrote:

>> From: [...] Blake
>> Sent: 09 March 2005 10:17
>
> Sorry for the delayed response - life has been... Interesting.

I hope not in the Chinese curse sense.

>> 1. A collaborative space (some way for clients to share the common
>> experience and communicate with each other, as well as affect
>> the space).
>
> 1a. The server component of this.

There's a lot of freedom there.

> 1b. The client component of this.  This has some important consequences,
> especially if a user needs some custom client in order to connect.

This is the kicker.

> 1c. The protocol used between client and server, and whether any
> communication is provided between client and client.  This has other
> important consequences, especially if it needs mods to firewalls,
> secondary ports opening, standard client ports, incoming connections, or
> other nasties.

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.

But I'd like to get something usable before worrying about load killing  
it.<s>

>> 2. A game framework/ruleset/etc. (This could be broken down a
>> bunch of ways.)
>
> 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.

2b gets into content. One such ruleset needs to exist, of course.

> 2c. (Assuming user extensibility, my main interest) A way of preventing
> user-created frameworks and rulesets from interfering with one another,
> accidentally or deliberately, unless such interference is desired.

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.

>> 3. Content.
>
> 3a. Users or admins with sufficient skills to create the content.  The
> more complex the content, the more skilled these people need to be.
>
> 3b. Tools to create the content.  The more complex the content, the more
> complex these tools need to be.

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

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

> 4. Users.

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

> What collaborative space do you want?  At one end of the scale, I've got
> a multi-user telnet server for a Squeak image...

That's what I'm trying to figure out. I do want to hit the low-end. I  
don't want to be shufflng mega-data around if it's not necessary. The  
notes on Nebraska sort of concern me.

On the other side, I don't want to get =stuck= with a telnet-only  
solution. (Text MUDS are so...1987...aren't they?) I'd like t be able to  
(maybe) start with a text-based version then allow 2D and 3D stuff.