[MUD-Dev] Time debt (keywords: automation, contract systems)

[Eric Random]

I've read the posts on time-debt so far, and I think it should be
pointed out that it seems Steve's original post was attempting to
solve the problem of managing excessive downtime, or perhaps even
mundane time (given its reference to training and repetitive
crafting), by shifting it off-line. My initial understanding is that
I don't think he's necessarily attempting to manage excessive
character progress, although that's what could ultimately occur with
his sytem. As Cruise and Lai point out, perhaps the best way of
handling excessive character progress (as opposed to excessive
on-line time) is with a long-term endurance attribute. I would
agree, and I have a specific implementation I could discuss, but it
may be diverging from the original idea.

When I read Steve's post, I saw mainly two points: off-line
automation and a contract system.

Many actions in an RPG have time costs associated with them. Some of
these actions are mundane and repetitive. One could take these
actions off-line or automate them on-line. If taken off-line, the
character can continue the automation, or if the game engine has no
automation capability, log-off in a particular location which
converts off-line time into the desired action, had it been
automated (for example, log off in a school to accrue learning a new
skill). I think on- and off-line automation is a discussion of it's
own. I think this is what Steve is getting at. Automated or not
automated, it's a mundane action that takes time to accomplish. This
time cost, is, ultimately, what Steve views as a time debt, but
instead of actually doing the action, it's time cost is abstracted
down into an absolute duration of the action which is implemented as
a time-debt.

I've explored this before, and as a design element, I would agree
with aspects of Steve's time-debt in games where automation does not
exist.  For example, a character wants to learn a new skill. Like
learning all things, it requires time for instruction, instead of
simply saying I want this or that skill, spending some abstract
skill points, and "acquiring" a skill, which is, perhaps, less
fictionally consistent.  Exploring fictional consistency in learning
new skills is actually how I wound up at this example. There is a
reasonably simple skill I want to learn which requires 1 hr of
instruction and I could accrue an hour of instruction in one of two
ways: I could sit in the instruction room for one hour, chatting
away with other people, or I could log off in that room for one
hour.  Although Steve was more focused specifically on off-line
accrual, I don't know if he meant online as well.  Concerning this
specific example, do you think players will spend that time on-line
in some mundane activity, or choose to off-line it? How will this
affect fundamental design goals, like fostering socialization? I'm
just trying to clarify here so I won't get into this aspect because
that's a post in itself!

Further, Steve discusses not just learning, or crafting, but
training as well. I see this as pick a skill, pick a skill level,
log off for x amount of time, and ding! character's ready for
go-go-go! In my perspective, the go-go-go -is- the training. Getting
from one skill level, or simply gaining experience (ie. training) is
often the driving force of go-go-go. Spending your time crafting
something for experience is the same as heading out to the forest
and slaying orcs. I think perhaps the issue here is that crafting is
seen as more mundane than battle. Perhaps the solution is not
avoiding mundane forms of training, but perhaps making it more
engaging. Avoidance is certainly an option, as some RPG's get rid of
crafting altogether and push the workload onto NPC's, which I think,
is continuing along the lines of fictional inconsistency, but that's
my opinion. That's not a "bad" thing, though, as you focus on what
your are attempting to achieve, and in some RPG's, crafting is not
apart of the overall design goal.

The contract system, on the other hand, is perhaps from an
extrapolation of the automation, and this is where I see Steve's
post discuss more, perhaps, towards on-line automation. For example,
one type of simple on-line automation is a store clerk. I need
someone to stand here in this same spot and sell my wares. Pretty
mundane. Easily automated. But it's work, and I'll pay that person
for their service (in comes a contract system). This same thing
could be applied to non-interactive off-line "automation" such as
construction, as is Steve's example. I've explored contract systems
and they can get quite complex. I'd love to discuss contract systems
more, but that's another post.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev