[MUD-Dev] Moving away from the level based system

[Travis Casey]

Sunday, December 24, 2000, 1:25:46 AM, Corey Crawford
<myrddin at seventh.net> wrote:

[snip lots about macroing and scripting]

> 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 ;)

> An example of this would be making a hammer.. you need wood (one
> process) then you would need iron (another process) then you'd have
> to shape the wood (another) and then shape/cure the iron/steel
> (another) and then finally put it all together (the last
> process). But this could be refined to the point where you get tons
> of wood (spammed/macroed) and tons of iron (spammed/macroed) then
> sat in a dark corner and spammed 'shape wood', 'shape iron', 'put it
> all together'.. and end up with 20 hammers.

> Anyone have any ideas in this area of skills?

Personally, I think this is simply a spot where the typical mud
structure breaks down.  Muds are essentially real-time games, but
doing something like making a a good arrow or sword from scratch takes
a considerable amount of time.

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 a 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
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.

A second method is to make a single long-term action consist of
multiple short-term actions.  This, however, is very subject to
macroing and/or scripting, and, even if it can't be macroed or
scripted, may be boring to the players.  It takes a lot of care to do
it successfully.

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
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?

--
       |\      _,,,---,,_    Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)   


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