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

If the server is to govern play and determine outcomes, P2P necessarily is  
restricted to things like OOC communication. If the server tries to share  
that burden with the clients, the clients will be hacked. Or so  
conventional wisdom has it.

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

The problem I have with that is merely that it adds another significant  
layer of complexity. What is 2A, then, and how does it facilitate 2b? I  
could sort of see it as--well, in the Interactive Fiction world, there are  
quite a few dedicated languages, most notably Inform and TADS. These are  
3GLs which have been designed around facilitating IF.

I'm just not sure what 2a would consist of. The only thing that comes to  
mind that might be spread across various different 2Bs is facilitating  
definitions of space and time.

> By the way, the
> GURPS license explicitly forbids computer implementations without SJG's
> permission (or did last time I saw it) - not seen D20.

Wizards of the Coast very cleverly made d20 "open source".

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

Well, if you're not going to provide them with a rule set, what ARE you  
going to provide them with? Nebraska?<s>

> Indeed.  Hence my interest in custom VMs.  Although I do think you need
> an *escape* to full Smalltalk.

The EToys model seems viable to me. Perhaps more layered.

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

Yes. But there you have the conflict between 2a, 2b and 3.

>> The obvious (not necessarily best) approach is a hierarchy:
>> users->content creators->framework creators->ruleset implementors.
>
> ... With some overlap between the levels.

I would say the levels are not so clearly defined rather than overlapping.  
By which I mean:

 From a technical standpoint, any content created by users would have to  
occur through the game rules (say, a mad wizard creating a horrible  
monster), just like any content that approached a framework level would  
have to be done with content tools (say content based on a medieval  
European-angled ruleset that moved play to an Oriental setting), etc.

Actually, i consider the idea of content coming from users to be the most  
interesting one. I'm not impressed by MMORPGs where you go slay the  
dragon--and half-an-hour later, someone else goes to slay the very same  
dragon. Pfeh.

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

You have to have an idea what the content is before you can know what kind  
of tools need to be created. Assuming I have the collaboration worked out,  
then I'm most likely to be the first to breach 2A. I may not be the best,  
I may not be the standard, but whatever I come up with would probably be  
bundled as part of the set as an example.

Other people, seeing that, do better versions of it than I do, and end up  
needing certain tools. Tools that, perhaps, I never saw the need for  
because I wasn't nearly as creative/clever/imaginative as they want to be  
in those areas.

Bootstraps.

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

Oh, 2D's no big deal. I would expect a certain amount of the effort to be  
pooled.

3D's a bigger deal, obviously, but the Croquet project is all about  
simplifying it. I have no urge to rebuild that wheel.

Anyway, my intent was to start with something heavily text driven, if not  
necessarily entirely text. And build from there.

> Who are they?  What do they want out of this system?  Are they
> achievers, explorers, socialisers or killers?

Yes! The group I have access to actually does message-based RPGing, not  
MUDing, but given a MUD, it was apparent we had all kinds.

> (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?

Hardly matters at this point. What matters, it seems to me, is getting to  
2A and providing a basic space or set of spaces where maybe there's  
nothing to do but chat. From there, you can at least take a stab at 2B.  
(Not that I don't have plenty of ideas and answers to the above questions,  
they're just premature, in my view. If we don't get to 2A, nothing else  
happens.)

>> 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*?

Aw, now, come on! I fell in love with Smalltalk precisely because it had  
this MVC concept: separation of interface from game rules. <s>

The way I see it working is this: The initial framework would provide  
text. Just a plain old, traditional MUD. If the time-and-space elements  
are the same (and I really think those are the key things that separate  
kinds of games) graphics, either 2 or 3D, can be added.

As a simple example, the classic text game "Adventure" can easily be  
ported to 2D or 3D, and could run simultaneously as all three. As long as  
turns (time) and locations (space) are discrete, this really isn't a big  
deal. Heck, I used to put 2D graphics on to the old text Basic games back  
when code listings were the standard method of software distribution.<s>

Now, at some point, you want to do positional based stuff--you don't want  
your space and time to be so conspicuously discrete--and text becomes  
unweildy. This works for text going to 2D, and from 2D going to 3D.  
Ideally this is up to the content providers. If they want to make a game  
that works as text, 2D or 3D, then they'd have to provide the appropriate  
content. (It's not hard to imagine, however, a 3D engine that also  
provides 2D support.)

Also, at some level, this goes back to the 2A. If your locations are truly  
discrete, as in "Player A is in the conservatory", then you can ignore the  
player's position within the conservatory: He can talk to anyone in the  
conservatory, or attack anyone in the conservatory, or grab any item in  
the conservatory. The framework need not care. But he might not, for  
example, be able to talk to someone in the foyer, since that's a separate  
location (even if the person he wants to talk to appears closer than  
someone on the farside of the conservatory to whom he can speak). If you  
want to build something more akin to a physics system, you have to abandon  
the discrete location system for something position based, which I think  
goes back to a rewrite of 2A.

Likewise, if you want the third dimension to actually matter, you need to  
code for it in the system. But it doesn't necessarily have to.

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

This goes back to finding a collaborative space and setting up some kind  
of canvas. A canvas which we might need to chuck later on because it's not  
flexible enough. But something on which a reality can be created and  
shared.