[MUD-Dev] Playing catch-up with levels

Kwon J. Ekstrom justice at softhome.net
Wed Apr 28 09:56:44 CEST 2004

Vincent Archer wrote:
> According to ext.Christer.Enfors at tietoenator.com:

>> I was thinking I should let players hire NPC trainers, and then
>> define which skills (not just one skill) this trainer would
>> teach.  The player (or guild) would then charge money from other
>> players (or guild members) for access to this trainer. Thus, the
>> player has in effect created his own class. If it's good, he'll
>> even be able to profit off of the access charges. A military
>> guild could boast "we give our members access to a Swordsman
>> trainer, a Spy trainer and a Healer trainer at a discount!". The
>> trainer would also incur costs for its owner, so in order for the
>> owner to make a profit, the skill set (read: template) he gives
>> his trainer has to be good enough for other players to want to
>> pay for).

> The problem with this approach is exclusive trainer access. Can
> you use different trainers? If you can use multiple trainers
> without penalty, then you're not accessing a "class", you're using
> "that trainer with skill X & Y, and that other with Z".

 From reading the original message, I think that's the goal of this
 system.  Players will need to "spend" their resources wisely,
 forcing them to choose a trainer that teaches the things they want
 to learn. Obviously, a player could choose to use multiple trainers
 to learn what they need for the role they intend to play.

> And you cannot afford to lock players with one trainer: if they
> can use only their original trainer, then griefers can set the
> trainer prices to X millions golds suddendly, and freeze
> completely your character progress without recourse (except
> dropping all skills and restarting at another trainer).

> The next obvious idea is to lock by skill: you can train at a
> trainer if and only if you do not have (yet) a skill that the
> trainer cannot teach. Since the obvious "marketing move" is then
> to advertise "we have a trainer that offers every skill", you need
> to defeat that, by making the maintenance costs of skills
> exponential. Class creators then have to select how wide the
> skills they place on the trainer: too wide and it's too
> expensive. Too small, and no one's interested.

I think locking the players in any way will cause the system to
fail. Honestly, it appears that the idea is for guilds to make money
off building trainers that teach meaningful skills.  Rather than
penalizing the players for poor choices in trainers, it should
become incrementally more expensive to advance a trainer.  The more
skills a trainer has, the more expensive it should be to add skills.
This would prevent guilds from creating uber-trainers and would
instead force them to make multiple trainers with different skill
sets.  An initial cost to build a trainer would prevent the game
from being flooded too rapidly, and would allow for specialization,
potentially increasing the trainer market.

> And, finally, there is the problem of the chicken and the egg. How
> do the characters initially get money to create the trainers? You
> need to create "basic trainers", who make essentially free
> classes.  Those free classes must not be competitive with
> player-designed classes (otherwise, people use the basic
> trainers), yet efficient enough that people can earn enough to
> create the first set of trainers.

Well, you could also ask "how do the players get the money to visit
trainers", obviously there are other sources of wealth.  Also, I'd
suggest making a couple of dummy guilds with basic trainers and
allowing the playtesters or event the morts of imms to run them.
This would reward people for playing the game, and prevent the need
to balance player-run vs basic trainers.  If you choose the players
to reward wisely, it would encourage a growing player-base.  Choose
poorly and they'll simply strangle what few players you have.
(smart players would encourage growth because it advances their
cause... more players = more
people using their trainers)

-- Kwon J. Ekstrom
MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the mud-dev-archive mailing list