[MUD-Dev] Reputation & Trust Circles [was UO rants]

Dan Merillat harik at chaos.ao.net
Tue Aug 29 14:04:45 CEST 2000


Matt Chatterley writes:

> In a 'lawless' area: Bob and Jane both get away scot-free, unless friends 
> of Ned suspect them, and give pursuit. Or in a situation where Ned 
> returns from the dead, he chooses to exact his own revenge.

Well, if you're leaving in 'lawless' areas then you're back to B, having
it player enforced.   That would probably work the best.  Especially
since even if Ned dosn't come back, his "spirit" will ICQ his friends from
beyond the grave.

> I'm sure that a system which resists mild abuse can be designed. In my 
> mind, if the only way that you can deal with abusive players is to ensure 
> that your systems are 100% watertight (which, as you observe, is NOT 
> always possible), then you need to reassess how you run your game - abuse 
> is cheating, and I don't allow cheats to play a game which I am running 
> for longer than it takes me to notice them. Hmm. That sounds harsher than 
> I meant, but it does get the jist accross, I guess.

The problem isn't so much with cheats (selling item x is worth 200x more then
it's supposed to be.  Oops) but with systematic failures.  Although if you
keep your system loose and allow players to fill in the missing pieces it
would work well.   Players are a lot harder to use as an abuse tool then code.

> Or allow only a certain number of characters per player, block multiple 
> connections from 'registered' alternate characters, put an enforced wait 
> between your many characters in, etc. Lots of methods are in use all over 
> the place.

Account system.  Gotta make sure you know who is who.  Takes some effort on the
enforcement side, and slows your game (high barrier to entry.)   Usually mitigated
by giving characters some levels/play days before their registration is required.

--Dan




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



More information about the mud-dev-archive mailing list