[MUD-Dev] A flamewar startingpoint.

JC Lawrence claw at under.Eng.Sun.COM
Wed Dec 24 10:50:10 CET 1997


On Fri, 19 Dec 1997 00:33:48 PST8PDT 
Jon A Lambert<jlsysinc at ix.netcom.com> wrote:
> On 18 Dec 97 at 22:39, Matt Chatterley wrote: [snippy snip]

> Full agreement with this critical use of food.  I'd call it
> adventuring logistics.  Now it does pose some interesting
> difficulties in a mud that has the following feature/lack of
> features:

As discussed before there is a wary line that has to be tread here.
On one side collecting the necessary resources for an endeavour can be
"fun" and can become an adventure in its own right.  On the other,
always ensuring that you have the appropriate resources for your next
activity, when you full well know exactly what they area and how to
obtain them, can easily become drudgery and thus"boring".

...deletia...

> Now the example scenario.

> An adventuring party is attempting to traval from Libya to the
> African interior and decide to make the journey across the Saharan
> desert, ignoring the wiser option of Egypt and southward via the
> Nile.  The party has a limited but they think adequate supply of
> provisions for the two week(?)  journey.  About halfway into their
> journey they realize the consumption of provisions using the
> auto-debit has been much too high or their progress too slow.  I
> would assume the owner of an animal could turn off this feature for
> the animal.  The journey continues with the supplies as they are
> causing some animals to die, and perhaps converted into supplies and
> eaten, debilitating health effects on the famished adventurers, etc.
> Supplies completely run out and more severe effects occur on the
> adventuring party members including hallucinations and quite
> possibly deaths.  (reminiscent of the Oregon Trail and the Donner
> party) Eventually about half the party makes it across the desert.

The difficult as always would be to retain the players for the
gradually expiring party.  Many/some may (I have no experience in the
RP values used here) bow out early rather than continue with an
apparently doomed campaign.

> Personally I like the idea that this _could_ happen within a mud
> world and find it interesting.  

Agreed.  The problem is in retaining this in a game context such that
it is enjoyable at the micro minute to minute level, as well the macro
character-life/game-life level.

> Some problems in implementation
> appear in the area of travel time and character logout.  What range
> of real time in travel is playable in such a situation?  1 hour?
> more? less?  What happens to characters that are part of this party
> that must logout either due to personal reasons (RL calls) or
> through network problems?  Do they continue the journey?  Attempt a
> automated solo return if before mid-point?  How are they fed if
> auto-debit is turned off?  How does a logged out character continue
> to engage in maintenance of pack or transport animals that they own?
> If something like the "Donner" situation arises, do they find
> themselves at a severe disadvantage?  Is it possible and/or
> desireable for characters to have the ability to choose or "will"
> character control over to another player should such a logout event
> occur?

<ouch>

My gut reaction is that any designed and enforced solution will be
unacceptable to many.  Provide all the possible ways you can think of
to skin the cat, and let the users decide and select which applies or
is preferred ad hoc.  Note however that for an RP game, this has the
added characteristic that selection of appropriate game mechanic for
the current scenario can become very important in the character's
life, and can determine that character's future.  Some RP'ers will not
appreciate that heavy an intrusion of game mechanics.

--
J C Lawrence                               Internet: claw at null.net
                                           Internet: coder at ibm.net
----------(*)                        Internet: jc.lawrence at sun.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...



More information about the mud-dev-archive mailing list