[MUD-DEV] Moving away from the skill system

[Inq Admin]

[Sorry about the delay here - apparently my local mailserver decided
to go belly up]

On Fri, 29 Dec 2000, Travis Casey wrote:

>> But this is still a problem when it comes to trade skills.. how do
>> you prevent ANY type of trade skills (arrow fletching, cooking,
>> whatever) from being macroed and/or spammed? The above system
>> doesn't help that situation at all and may even promote it (since
>> you have to be doing hard stuff to gain exp, then why not have your
>> guy trying to do the hardest thing he knows how to do for 2-3
>> hours?). One of my thoughts was to make sure the process was a bit
>> more complex than a simple command (a few at least) but these could
>> still be macroed, and probably WOULD promote macroing because
>> people are lazy ;)

  [snip some extraneous information]

> In a paper RPG, it's simple to switch time scales as needed -- the
> player makes the skill rolls, and the GM says, "Ok, it takes you
> four days, but you now have the six swords you wanted to make.  What
> are the rest of you doing in those four days?"  Unless a player in
> the group decides to be obnoxious about it, it's not a problem.
>

> In mud, however, that can't be done so simply -- other players are
> off doing unrelated things, and aren't going to take kindly to the
> idea that what they can do is going to be limited because some other
> player they don't even know is doing something that collapses time.
>

> How else can long-term actions be handled, then?  One method is to
> have timed actions -- the action takes a certain amount of time, and
> until that time has gone by, the character can't do anything else
> until that time has gone by, the character can't do anything else
> without losing the progress that's been made.  This is done
> sometimes in paper RPGs, when long- and short-term actions have to
> coincide -- e.g., if a thief is trying to pick a lock in the middle
> of a fight.
>
> Unfortunately, this can be very frustrating for players, and for very
> long-term actions, would be even more so.  Imagine:
>
>   > forge sword
>   You begin forging a sword.
>   > e
>   Are you sure you want to quit forging the sword?  You have 1 hour,
>   59 minutes, 54 seconds left to go on it.  (y/n): n
>
> Not something anyone probably wants to subject a player to.

   [snipped some more - sorry for quoting so much]

> A third method is to have such long-term actions happen "offstage"
> -- that is, the character does them while the player is logged off.
> This can work nicely, but requires some sort of interface for
> players to can work nicely, but requires some sort of interface for
> players to specify what they want their characters to do while
> they're logged off, and a reporting mechanism so that a player can
> find out what a character actually got done when he/she logs on.
>
> Any other ideas on how to implement long-term actions?

Our solution is a mixture of the above.  As a frequent writer of
triggers for other MUDs before I started the one I'm with now, I was
well aware of the potential ease to macro skill-development and even
levelling.  Trigger writing is a feature found in most of the clients
available, and fairly easy to learn to write at least simple scripts.
(..."You are thirsty.....drink water").  The avid gamer will macro
everything from that to picking up their weapon when disarmed.

The first aspect is relatively simple to fix - use a table of text
messages for the various returns on skills and combat.  Have the code
poll the table when it needs to send a message to the client.  With
two or three messages, its still fairly easy to macro, but when you
get it up to ten or more, it not only increases the variety of the
game for the player, but begins to make script writing have little or
no effect.  Too, with tables it is easy to change the syntax of the
script, making the time invested in writing it a loss.

So, for simple skill-gains, by polling a table you are working to
decrease the chances a player will macro something.  Will they still
do it?  Yes, likely.  But the net effect is decreased significantly,
as they will need to still pay attention to what they are doing.  You
can further compound this by having multiple messages - they are
disarmed, and run the 'get sword' trigger.  Their syntax is correct,
and the trigger works properly.  But, alas, the sword has fallen
beyond their immediate range (we have ranged rooms, but you could do
the same with some creative ingenuity in a non-ranged room system.  So
a second list of messages is polled for sending to the player
indicating to them that the weapon is too far away for them to pick
up.

The real gist of this message lies in addressing long-term skillgain,
and prevention of spamming.  I like the ideas of using a total-time
value to determine some of the stuff they gain.  But, at least on the
MUD for which I work, our goal is to keep them ON the game, not just
an inactive pfile.  We're currently in the process of transferring the
skills model as outlined in ROM to a tree system, with prerequisites
and all.  So again, they need to interact with the code to some extent
to determine where their character wants to go next.

For long-term skills, the act is passed to an event handling system:
Zorphius the Armorer is making a breastplate for another player.  He
has the ore (currently bought in a shop, planned to be mined at some
point in the future, using the same model outlined here) in sufficient
quantity to make the item, and he is at his forge (or anothers).  So
he initiates the event with the forge command, indicating in the
command what he is making, and with which ore (or it defaults if he's
got only one).  Over time, his actions progress through a series of
events, ranging from heating the ore, to hammering it into shape,
annealing it, and putting some finishing touches on it.

Once done, Zorphius has a very plain, unadorned breastplate.
Functional, yes, but not very nice to look at.  Its values are
determined upon both his total skill in manufacturing and the type of
ore he used.  In the future this will expand to also include his
experience with making a particular type of item and the quality of
the ore (once its mined).  A master-wrought breastplate of iron may
very well be better than one made by an apprentice of steel.  Anyhow,
he's got the plain item, which he can sell, or which he can work to
improve further, either by getting it adorned with etchings (which he
can do) or taking it to a jeweller for more lavish designs.  Although
the value intrinsic to the item remains the same, he can command a
greater price for those which he improves more.

Can his actions be macroed? Yes, but by polling a table-list, it makes
it somewhat more difficult for him to do successfully.  To, with the
command being spanned over a period of time, it offsets the
instant-gratification cycle of do_command, get_reward which is
prevalent on many servers.

Ultimately, however, the end result is that Zorphius takes _pride_ in
being able to make something, and wants to show off his ability to
others.  He has to spend money to gain the raw materials, and may not
necessarily see an immediate return on that investment.  Even if he
macros, his total ability to do so is limited to the amount of funds
at his disposal - and then is tied up until he can liquidate them once
more.

Our end goal is to make not only Zorphius pass thru the event handler,
but to have all the persons involved within the creation process do
the same.  The miner will do such with finding the ores, and he or the
smelter will have to do the same with the refining process.  And, the
time spent doing this task also ensures that they are suitably
occupied to preclude their doing other mundane tasks which would raise
their other skills.

With a skill-deprecation model in place, it works to ensure that if a
player wants to be _truly_ good in something, he or she spends time
devoting themselves to it.  With varying return messages, the rote and
boredom of repetitive taskings is somewhat offset.  In having them
input time to developing a skill, they know that they can take pride
in it when it is mastered.  If they choose to devote time to another
skill, they will lose some of their gains in others, because they are
not able to devote the requisite time to maintain them.

Robbert 

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev