[MUD-Dev] (fwd) Temporality and user actions in MUDs

[J C Lawrence]

From: hilarion at heave.to (Hilarion)
Newsgroups: alt.mud.programming,alt.mud,rec.games.mud,rec.games.mud.admin
Subject: Temporality and user actions in MUDs
Date: 11 Jun 1998 14:49:45 GMT

I've got a few issues dealing with this sort of thing that I'd love
to brainstorm on.  Assuming an absolutely fresh start on the code,
and a conjunctive parser (ie, "do this and this and that"):

1) Let's say that two (or more) users are competing on some skill use:

If you allow multiple actions on one command line, conjuncted, and
let them be queued by the machine before another user picks up, you
only have the timing issue of who's the quicker typer (or who types
the most) to see you through.  This is a nice implicit solution, and
would be acceptable but for 'bots.

The other thing that could work would be to queue them all, and let
the MUD take care of the users sequentially as usual, but with one
"phrase" at a time as opposed to a conjunction of them.  Instituting
different speeds for skills as a semi-objective temporal reference.
For most MUDs, which usually only compete and combat and other things
are disallowed, this boils down to weapon speed.  But I'd rather
generalize because you could use different skills in conjuctive phrases
that might end up messing any combat-only explicit ordering.  Do you
just stick the guy who doesn't type and assume he misses his turn?
This kind of "competition time" might be horrendous for larger groups,
waiting for the slowest guy, or hard to sync for general reporting
to the inhabitants of two or more groups that are having separate
competitions.  It just sounds real scary trying to debug and might
be a heavy hand on the players to boot.

2) You want to know how long an object was there in game-time.

I've seen some MUDs where the corpse literally decomposes within a
minute, and day and night strobe in the time it takes you to walk
a few blocks. I'd hate to come out of a dungeon crawl and find I'd
done a Rip Van Winkle and that Night Vision was the only skill that
hadn't, therefore, atrophied from comparative lack of use over the
"years."

I've also seen MUDs where time doesn't seem to be an issue at all,
with no observable qualities, traits or reactive interest on the part
of the character of its gamer.

Most of the rationale for either decision in game time seems to be
completely dependent on their conception and definiton of what 
hitpoint recovery should be like, or a similar teleology.  While this
need not be, I think there must be an intrinsic reason for temporality
as a device for roleplaying and not chained to some other set of
criteria to bypass this criticism on hitpoints owning game time.
(Even though it seems that on many MUDs, this is largely _the_
activity that all partake in most of the time.)

For one part, I would like to see a character age as his viewpoint
in the game world advances.  This would mean that for each day, he
would age a day.  Clearly, a rapid temporality needs to be slowed
to a more respectable (and reasonable) rate, regardless of the need
for hitpoints, which should be considered arbitrary to the individual
and his situation, or at worst, to some other scale of time, or both.

My particular issue in this is that if time marches on, then there might
be a skew large enough to disorient players coming out of an extended
combat or contest of skills.  This would suggest a near real-time game-time,
much out of the ordinary for many.

My question:

Is real-time for game-time an acceptable thing for most gamers?

It solves a good deal of problems related to "when" an object got picked up,
or measuring skill atrophy, or what-have-you.  (Otherwise, a long contest,
for instance, might wither away your needlepoint, even though you were
practicing but seconds before matching rapiers with Rudolf over there.)

I might not of thought of all the implications this might bring about in
a game world, and I certainly haven't set them all out here.  (One is
the dreaded spectre of downtime.  This might be alleviated by just counting
time boostrapped instead of raw polling the system clock at need.)

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...