[MUD-Dev] RP=MUSH/PG=MUD

[clawrenc at cup.hp.com]

In <33bb270e.27883839 at relay.mnsinc.com>, on 06/26/97 
   at 08:58 AM, caliban at darklock.com (Caliban Tiresias Darklock) said:

>On Wed, 25 Jun 1997 19:22:51 PST8PDT, clawrenc at cup.hp.com wrote:

>>In <33ad0a65.1847835 at relay.mnsinc.com>, on 06/20/97 
>>   at 07:29 PM, caliban at darklock.com (Caliban Tiresias Darklock) said:
>>
>>>This illustration is slightly flawed as I present it, in that the
>>>game system and game world are rarely a clearly defined pair of
>>>separate entities, and on many occasions the programming language and
>>>user command set are subject to significant crossover. 
>>
>>It also avoids the various forms of hardcoded games (cf DGD, Diku)
>>where there is no internal programming language:  changing the game
>>requires recompiling the game kernel.  Such servers are surprisingly
>>common.

>Since the aim here is to create a flexible server which does NOT
>require recompilation to effect changes, this option is completely
>unacceptable by definition. 

Depending on your "here", that's not necessarily a shared goal. 
You're presuming a commonality here that doesn't exist.  Its my goal,
but its not Nathan's, or Chris Gray's that I know of.  

>>You can try and build a system which is leveragable into different
>>systems, but the result is that you don't define the current system
>>with sufficient detail to actually define the precise behaviours with
>>the result...

> [snip]

>>...that you end up here (from my last para).

>Are you saying there is no middle ground here which would be an
>acceptable compromise? I find that a dubious claim. On the other
>hand, no one out there seems to have many ideas.

I believe so, yes.  Its a question not of design or middle grounds,
but of implicit interdependancies in any sytem which explicitly
prevent that from being easily leveraged to another system with
different dependancies.

>>Not a lot I disagree with so far.  Most of it is largely unarguable --
>>essentially a reporting of what you have observed and your conclusions
>>there from.  What is missing is a proposed interpretation and
>>addressing of your observations.
>
>I'm being deliberately cagey on the matter, because I've been rather
>quickly pounced on as a codebase bigot and/or someone who doesn't
>know what he's talking about every time I've tried to discuss it
>previously. I still haven't heard more than two or three people
>express an interest in participating in the discussion, and all of
>them seem to be of the opinion that the concept has merit but it will
>never work. I really don't feel like laying out a lot of work only to
>be told by two or three people that I'm just dreaming and a server
>like this can't even be written. The end result of such a thing is
>likely to be either I write a server that everyone hates, because the
>opinions of two or three people are not statistically valid, or I
>don't write a server and people smirk and say 'yeah, right, *sure* it
>can be done'. 

You're at the edge fo the cliff.  You can either jump, or go back and
ever after wonder what would have happened had you jumped.  I can't
fairly encourage you.  I don't see that the field is in a state where
it can support this sort of effort.  It will be, but the standards
support, or possible support, is not there yet.  To create the sort of
commonality, or shared base that you are describing you need
standards, or at least a field which is capable of supporting a
standard.  Those standards don't exist, and won't exist until the
field has matured significantly further than it has now.  Sure the
FTN/FIDO-style FOSSIL driver is a great model -- but they had a
simpler problem to resolve, with the prior knowledge that the system
only needed to run on single-tasking, non-re-entrant, non-threading,
interrupt driven architectures.  They had a simple shared problem with
precise boundaries.  MUD's don't have that level of simplicity yet. 
Sure, they might if the stock MUD convergence goes much futher, but
the automatic safe assumptions aren't there yet to support a standards
effort.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...