[MUD-Dev] "short" Introductory Message (fwd)

clawrenc at cup.hp.com clawrenc at cup.hp.com
Thu Jun 19 13:25:29 CEST 1997


In <199705172042.5025153.8 at shadow.null.net>, on 06/17/97 
   at 08:42 PM, Martin Keegan <martin at cam.sri.com> said:

>On Sun, 8 Jun 1997 coder at ibm.net wrote:

>> Will Island ever arise again?  It would be a great loss to have it
>> dissappear.  It did too may things far too well to lose, (and enough
>> things far too stupidly to tolerate its loss as an example).

>"Oh no, not this chestnut again". I've already been swayed into
>bringing it back - just trying to find a stable site for it. You
>probably underestimate the amount of flak I *still* get from people
>who hated that poor old game.

I caught some of the flammage during its life.  I'm not surprised. 
What are the hardware requirements?

Re: Quests

>> And were for the uninitiated, utterly superb.  <I bow in their general
>> direction>

>They were not too much fun if you were doing them for the second
>time.

This is a fault of the quest system in general as implemented in MUDs.
not of Island.  It is *rare* to find a quest on any MUD which isn't
trite once you've done it the first time.  Cf my recent description of
the Fortress Fract, King Mandel, and Princess Julia for a "quest"
which was non-repeatable, just incredibly bloody annoying.  it is
possible to do reset-less quests, and even to do non-trite,
non-repeatable, non-automatable  quests, but they have to be designed
that way from the start.  cf the recent thread on this area, and my
comments on automatic systems to create conditions, not states.

>> >Eventually, it became apparent that the quest-oriented nature of the
>> >game was driving players away. Crucially, it was driving away the
>> >idiots and powerlevellers. "Strong in Spades", is how Island was
>> >described in the light of Bartle's HCDS paper. (Spades being the
>> >"Explorer" types). Every year or so, the quests would be updated, and
>> >made more numerous, and (we hoped) more intellectually challenging.
>> 
>> <cheers>

>Well, the truth is that the majority of people does not want to be
>intellectually challenged, and the majority of people did not enjoy
>Island. I don't share the pessimism of other Islanders who extended
>this to "Most people crave badness with religious fervour", despite
>the compelling statistical evidence.

This is one of the reasons I am not a fan of democracies.  Equally I
don't accept the "Most people..." assertion, (this is straying into
philosophical areas not not meant for this list much tho I delight in
them).  I profess the view that discrimination and exacting selection
have now been falsely equated with intellectual snobbery and a generic
denigration of all those not practicing it.  Its a cheap half-arsed
equation which doesn't stand up, but the media like it, and it sells
newspapers almost as well as the Sun's page 3, so it must be good.

>> >At the moment I'm writing a mud (from scratch, unsurprisingly) which
>> >allows building at a proportional cost to the player, rather than
>> >being based on rank. (Or letting everyone build, or no-one at all).

>> How do you intend to scale the cost of construction?  I've been
>> thinking about this one a lot and have yet to arrive at a decent
>> model.  Best idea to date:

>This is tricky and I haven't really worked it out yet. Basically,
>entities will have a number of properties and values which will have
>associated costs.

>This system seems like a thought experiment but it's actually a
>reaction against what I call "higher order imbalance" in many muds.
>In some muds, powerful players can promote lowly players to high
>ranks, as much as they want - they have limitless power. In a mud
>with levels, a level 100 player could promote a level 10 player to
>level 80 - as many times as she wanted. Really, she ought to use up
>sufficient power to *drop* 70 levels.

No.  What is missing is feedback.  Consider the case of a mayor of a
city:

  Excluding bugetary considerations (another, different feedback
loop), he can promote as many beat cops as he wants to Sheriff or
whatever other tin badge value he wants.  The reason he doesn't do
this is that should those promoted not live up to the expectations
engendered in their new positions the mayor will lose his job.  (And
thus we get the idiocies of popularity-driven politics)  It is
essentially a time-delayed feedback loop.  He can spend as much power
as he wants on the beat cops -- but should the beat cops squander that
power, the mayor loses it.

  Perhaps investment economics would make a decent model?

>The rationale is of not getting "something for nothing". The more
>powerful/valuable the object/mobile/room you're creating, desto it's
>gonna set you back.

How about, "The more capable the object, the more the creator is
personally at risk for it?"  Then a "good" creator can create as much
as he wants, but a "bad" creator gets negative investment feedback and
zeros out.

>> >To the end of making sure the text is not repetitive, I've designed a
>> >system for randomised generation of non-boring text, which got an
>> >airing in rec.games.mud.admin in a thread about creating consistent
>> >names for newborn NPCs. 
>> 
>> Descriptions, definitions, or just names?

>Such strong typing, Chris! :) 

I know.  I wear out keyboards at an alarming rate.  <hang head>

>The system isn't really aware of any
>distinction between words and sentences. 

<ponder>

Ahh. I see.  You use the same/similar macro form with the same
replaceable parameters yada yada and then merely post parse the
results for acceptability.  Should work too.  But, how do you key this
off a scene with given artifacts to generate a suitable description?

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




More information about the mud-dev-archive mailing list