[MUD-Dev] A flamewar startingpoint.

[Marian Griffith]

On Tue 09 Dec, coder at ibm.net wrote:

> On 10/11/97 at 08:44 PM, cg at ami-cg.GraySage.Edmonton.AB.CA (Chris Gray)
> said:

> >Having a tedious requirement to 'eat food' is not hard to implement - it
> >would probably take an afternoon to add. I'm all for having atmosphere in
> >a game, but there are lots of players (often including me), that don't
> >care to spend a lot of time doing things that don't move my character
> >forward.

Of course this depends on the game, and what constitutes 'moving your cha-
racter forwards'.  I agree that on the typical mud or mush food is handled
in such a way that tedious is the only way to describe it. There is no re-
lation with the actual goal of the game  and there is no real game part in
it either.  Food is plentyfull once you are past level 3  and insisting on
characters to regularly buy and eat bread is pointless. It is easy to ima-
gine a game  where neither is the case though  and it being done in such a
way that it is neither tedious nor pointless.  The gathering and preparing
of food may be a valid sub game,  if you drop the linear advancement along
levels...

> >I wonder if it is feasible to have a "detail switch" in a game. Players
> >who want to go through the motions would turn it on, and so would have to
> >choose and buy food & supplies, and use them periodically as appropriate.
> >Other players could turn it off, and just have a small steady drain from
> >a "food counter", and would automatically stock up when they go into a
> >store. The former player would have to 'eat food' (or something possibly
> >a lot more detailed involving setting up camp, taking out utensils,
> >filling a pan with water, building a fire, choosing what to cook, paying
> >attention to the cooking, eating the result, washing the pan, putting
> >things away, etc.), while the latter would only have to occasionally
> >check their "food count" to make sure it doesn't get too low.

> You may have got something there.  Consider:

>   Eating food is not generally interesting.  Have a deafult configuration
> which debits your monies appropriately when needed, and otherwise ensures
> that your body is reasonably well fed without any interaction with or
> reports to the player.  Extremes will be brought to the player's attention
> (eg starvation, poisoning etc) for direct handling.

While in a city and in possession of sufficient funds  there should be no
real need to bother the player with food. For trips outside town food can
well be considered a critical matter.  A player should either pack enough
of it  before venturing into uninhabited lands,  or learn to live off the
land first.

>   The control can then be varied among a range of settings, possibly even
> subject to user programming.  It could for instance be set to be exactly
> as above, but to also ensure that the body is ideally fed, excercised, and
> cared for (with appropriate costs levied).  Or it could be set lower such
> that the player would have the ensure that his character body was
> approriatetely cared for in its minutae.

> Where this gets interesting is in the advantage that can be taken of such
> a system:

>   Bubba runs at the default "don't bug me" setting, but also has a case of
> food poisoning.  The poisoning isn't bad enough for the system to alert
> Bubba directly with a message, just bad enough to be gradually
> debilitating.  For Bubba to regain his health he will have to deduce the
> cause of his ill health (with the help of a medic/cleric/doctor?) and then
> handle appropriately.  This would likely enclude having to take over the
> absolute minutae of the care of his body until he has recovered, covering
> such details as ensuring that he drank/ate the various tonics at the right
> times and periods, ate the correct foods to help restore condition, etc.

[second example snipped]

Somebody else responds to the following, it seems to me to be extremely
relevant to both the people on the list discussing games  as well as to
the people coding games.

> This also has a more general scope:
>   We've discussed before the general case of the a player walking thru a
> scene being able to see more than the same character running at full tilt. 
> The perception level and chance of perception is higher.  The general MUD
> solution is to attempt to model this thru drowning the detail in spammy
> long descriptions.  The approach we discussed before was to instead
> register a "level of expectation" (LOE) value for the character's
> perception, and then report only those items which are either of enough
> instant impact to register above the LOE, or which trigger the LOE
> directly.
> 
>   Thus Bubba would be trailing Boffo at very high speed.  He would not
> notice a whole host of very good friends waving and screaming at him from
> the sidelines as they would fall below his tailored LOE.  However he would
> notice the fact that Boffo's trail now indicates that Boffo has a hurt
> right leg and is limping slightly...
> 
> The problem with this as we discussed before, is in determining what is
> expectable, and that what is the actual LOE function.  To a large extent
> this falls into the question of intent which is unanswerable (Is Bubba
> following Boffo, or merely going along the same route at speed?).  
>  
> I'm begining to suspect that this needn't be answered, and that this is an
> area where even a half-arsed attempt is good enough.  The following is
> something I have proposed before, and is what I currently do, if not quite
> to the level described:
> 
> Lets take the entire game and strip all default or automatioc descriptions
> or textual outputs.  There are no more long and short descriptions, or
> anything else of that type.  Instead, every single piece of data sent to
> the player is the product of the player's character determining that it is
> aware of said item, and that said item has enough import or noticability
> to be reported.  The result is that all touput is dynamically generated. 
> Nothing is pre-set or default -- it is all contextual.
> 
> This much I do currently.
> 
> Now have the character keep track of its own history, long and short term,
> and from that history attempt to deduce what the player's current
> intentions are.  
> 
> A lot of this can be resolved down to verb and command choice.  For
> instance if a recent fommand was "Follow Boffo", then that, at a micro
> level, can be assumed as a statement of intent (I'm not going to worry
> about the macro level).  Many other verb and command forms follow
> similarly.  
> 
> The character then keeps a mesh of these deduced intentions, resolving
> them as appropriate where they conflict, but also ressurecting older
> intentions when a short-lived one dies out.  eg:
> 
>   Current intent is deduced as "follow Boffo".
> 
>   Character is hungry, and side-tracks off to get food. and resolve the
> problems that raises including the intent of "follow deer."
> 
>   Character is now fed.  "Follow Boffo" intent is resurrected in stack-pop
> fashion, and compared to current player actions for a while for
> validation.
> 
> This intent web can then be used as the matrix to drive the LOE function
> in a fairly straight forward manner.


marian
--
Yes - at last - You. I Choose you. Out of all the world,
out of all the seeking, I have found you, young sister of
my heart! You are mine and I am yours - and never again
will there be loneliness ...

Rolan Choosing Talia,
Arrows of the Queen, by Mercedes Lackey