[MUD-Dev] Curing skill spam (was: Moving away from the level based system)

[z032383 at students.niu.edu]

Corey wrote:

[snip]

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


With my mud that I go back to develop every once in awhile, I also
wondered what to do with players spamming skills to gain skill levels
quickly. There is a decay rate for lack of use, although once the
player has mastered a skill (very hard to do for all skills) the decay
rate goes away. This would allow a player to spend a few hours
spamming one skill to mastery, then never having the need to worry
about it decaying or anything. So I thought I needed some kind of spam
detection device. Of course, there's no way that a spam detection
device could be perfect, but it works.

Let's give an example of a teleportation spell. How often does a
player need to teleport in, say, 10 minutes? Generally, the teleport
spell is not used all that frequently, as it takes a lot of mana, and
you just don't need to be hopping all over the world all of the time.
Let's say the game keeps track of how many times player "Bubba" has
casted 'teleport' in the last 10 minutes. . . 25 times. In fact, the
mud realizes that those 25 times took up over 90% of the player's mana
pool in the last 10 minutes (this could be estimated, or you could
keep exact track of mana, etc). So now the mud says, "No, I don't
think so, you must be spamming!" (Not to the player, it's talking to
itself! ;)) So now the mud takes away most of the points earned in
teleport over the last 10 minutes, AND it puts a hold for two hours or
so on gaining any more skill points in 'teleport.'

This only works if the player keeps spamming the one skill over and
over. However, it could be tuned to check to see if they are simply
spamming any skill over and over.

Some mud administrators may think that this is cheating the player,
"Hey, they used the skill so they should get credit for that." Well,
for the people who actually play the game nicely, this isn't very
fair. If the mud's skill system is very good, skills that are used
less frequently should increase with less usage, and vice versa.  What
I mean is that although a mage may use teleport often, they do not use
it nearly as often as their favorite attack spell. However, if the
attack spell and the teleport spell were gotten at the same time, they
should both increase in skill on a relatively similar level. If this
is all spaced out correctly, there should be no need at all for
players to go spamming skills. During beta testing, heavy statistics
should be taken on all skills to see how long they take to level, and
whether or not that is within the desirable range.  As well,
statistics should be taken to see how often players use each skill
(hopefully spamming wouldn't weigh it though), and that can be used to
gauge when the spam detector should go off.

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