[DGD] Pet peeves for users in a MUD

bart at wotf.org bart at wotf.org
Mon Apr 13 00:37:29 CEST 2009


On Sun, 12 Apr 2009 07:35:21 -0700, Shentino wrote
> 
> That is the trouble.  You get a benefit every time your 
> disconnection would conveniently avoid danger that would otherwise 
> be experienced...particularly danger you caused yourself.

So the solution is to confront the player with the same or equivalent danger 
to the one they tried to escape?

> 
> Also, what about PvP?  If you go linkdead in the middle of a PvP 
> battle, you effectively rob the other player of victory if you quit 
> when things go sour...which could be considered griefing, as it's 
> against another player.

PvP has so many issues (often solvable ones) that I consider PvP an entirely 
seperare discussion.

> 
> Another abusable case is if (this happened on walraven once) you are 
> in a mine, and oh noes, you strike a water pocket and start a flood. 
>  Up until recently, you were able to quit out.  You wind up getting 
> stuck in the void when you log back in (the room is destroyed), but 
> you avoid dying.

So the problem here is the fact that you can avoid the danger. The obvious 
solution seems to be making sure you get the same danger when you return.

> 
> True.
> 
> However, letting a PC just go poof on a whim is abusable.

That is a statement that really needs some proof. This I am saying after 
some 15 years of administrating muds. It is abusable on many games, but it 
is not abusable by definition.


> 
> I think it's reasonable to allow insta-poof when the PC is in 
> relative safety.  I'm just not so sure about the optimal way to 
> handle it when things are fishy...i.e., a quit/linkdeath while the 
> PC has a high adrenaline level from combat or other potentially 
> dangerous activity.

Possibly that is a good solution for your game, I am not judging that. All I 
am saying is that it is a solution that would tick me off as a player, but 
then, nothing in your game requires that I play it I hope.

> 
> I would conceivably be very happy to only require the linkdeath AI 
> to be hired when the player needs to.  It's safer than letting the 
> character sit there and be abused, but fairer than letting him just 
> go poof.
> 
> It's a tricky issue to be sure.  On one hand, you must avoid dumping 
> a mega load of punishment upon an innocent flaker, but on the other, 
> you can't feasibly turn a blind eye to someone who disconnects on purpose.
> Particularly since once the "cheater" starts doing that to escape other
> players, it ceases to be mere cheating and crosses into griefing, which
> "must be dealt with" according to Skotos's articles.

See above, and please, that I don't like your solution doesn't mean that I 
don't see or understand the problem, that is really a big leap to make, and 
one bridge too far and such.


<snip>

> 
> Though come to think of it, I never mentioned any specifics of 
> quantity, just quality.
> 
> I was generally thinking that only a somewhat frequently 
> disconnecting player would ever burn out his grace and get a grumpy 
> linkdeath AI handling his PC while he was gone.
> 
> And if a PC's adrenaline level is low, the linkdeath AI would work 
> cheaply, or perhaps even for free if the PC isn't in danger.  I 
> would consider insta-poof or uber-smart retreat to be reasonable if 
> the PC is completely safe and "can't possibly be abusing things".

Bad assumptions here imho.
1. abuse and even more so griefing are a matter of perception that cannot 
ever be completely put into code.

2. Preventing all possible abuse tends to come at an extreme cost, finding a 
good balance between preventing abuse and not harming those who weren't 
abusing anything is paramount.

> 
> Which is to say, only linkdeaths or quits during high adrenaline 
> levels are viewed suspiciously at all.

Connection loss detection isn't instant or even near 100% reliable, so this 
always carries a risk for a player. Regardless, it is something that does 
need attention.
 

> 
> Again, expect me to spend time on character development? Then I 
> demand the
> > game does not endanger that when I am not in control, simple and, for me,
> > end
> > of story, end of discussion :)
> 
> And what if you happen to "not be in control" when your character is 
> in danger at the moment where your control ceases?  Supposing that 
> you just happen to disconnect right when things are going sour in a battle?

Until I disconnect, I am in control of the character with regards to choices 
made for that character. That my isp messes up shouldn't change that. A 
judgement call here is that imho no control is better then AI control.


> 
> The trick is, to distinguish a legitimate connection barf from a sly
> disconnect.

You can't.

> 
> I would prefer to delegate this to code rather than a bad-mooded wiz 
> being forced to make a judgement call that might go sour.

Code can't judge abuse, only detect possible indicators of abuse.

> 
> And I simply choose to use proneness to disconnect with high 
> adrenaline to measure this.

Ever played an intense game where you suddenly lost connection? I know what 
this does to your RL adrenaline level...

I agree that this is a potentially abusable situation (depending on game 
design), but..

> 
> Disconnects with high adrenaline are properly viewed with suspicion, 

That is just one bridge too far.

> and it is those moments where the linkdeath AI will start billing 
> the player for its paid-level services, which possibly could include 
> letting the character go poof, or letting his adrenaline go down 
> even when in the heat of combat.
> 
> Simply waiting for the adrenaline to go down naturally would be free
> though...unless the character was actually in danger at quit point,
>  at which point the AI would either be charging for an expeditious 
> retreat in spite of high adrenaline, or would keep you in combat for 
> free, being as skillful as history predicts you would have been had 
> you been online, fleeing as needed
> (again for free).
> 
> The AI's job would simply be to protect your character during
> high-adrenaline situations.  For free, it would do what you could 
> have done were you online.  For pay, it will "cheat" by voiding some 
> of the consequences...for a price.  A price that only habitual "bad 
quitters"
> wouldn't be able to afford.

Then the advantage that can be gotten from quitting isn't that big it seems..

Also, being able to pay for a 'cheating' AI does to me sound like somethiung 
abusable as well.

> 
> And of course, we all know that humans are creatures of habit.  So 
> sooner or later, someone who likes to quit abuseively like that will 
> wind up eventually getting his hand caught in the cookie jar, so to 
> speak, through the establishment of a trend, which would neatly 
> coincide with the moment where his buffer would run dry and make the 
> AI start going on strike and not doing anything special beyond the 
> basic "fight and flight" it does for free.
> 
> 
> Are you perhaps talking about players who like to suddenly idle 
> and/or chitchat and that shoudln't need to even bother with going 
> OOC?  Going ICly afk and outright quitting are pretty much the same 
> as far as character control is concerned.

This is true only for a mud that uses rather strictly enforced roleplay.
Also, going AFK isn't the same as having your character controlled by an AI.


> 
> Skotos's article mentioned a need for players to get their OOC 
> fix...but I still don't know how important it is to handle a need 
> for it "Right Now!" whenever the player feels like it.  Is it fair 
> to expect even a minimum of notice to the game (perhaps by tporting 
> to OOCland)?  Or should I simply treat the player as a short-
> tempered customer who may choose to go OOC at whimsy and it's up to 
> ME (the game) to accomodate them, starting with figuring it out in 
> the first place?

An important phone call, loo, someone at the door etc etc.
If playing means I can't deal with real time real life events that demand 
attention NOW, I can't play, its really that simple. 


> 
> My main problem is to prevent a character from making a habit of
> deliberately quitting while his character is in danger (measured by
> adrenaline levels).
> 
> Quitting, and having the PC go in stasis with a zero adrenaline 
> level: free Quitting with a nonzero adrenaline level, but being safe 
> enough for it to drain to zero and then put the PC in stasis: free
> 
> Quitting with a nonzero adrenaline level, but being in danger
> (combat/hazardous environment)...
> 
> That's the tricky part.
> 
> Having an AI fight for you until you win, lose, or flee: free
> 
> It's only when the AI "cheats"...

And personally, I believe that here you are getting to replace one abusable 
situation with another.

> - voiding adrenaline increases caused by dangerous actions, like 
> combat or mining - vanishing the PC when his adrenaline isn't 
> zero/neutralizing the adrenaline level at an accelerated rate. - 
> voiding successfully inflicted damage - voiding or deferring a 
> death. - "dead man walking" out of danger before keeling over and 
> leaving the corpse in a safe place. - anything else that couldn't 
> possibly happen if the player were online and could be assumed to be 
> paying attention
> 
> ...that the player gets billed at all.  And in cases where those situations
> are rare enough that the buffer is full enough to cover it, there is 
> no worry, because we can safely assume it was an accident.  Innocent 
> until proven guilty.
> 
> Hmm...maybe don't bump the adrenaline up much at all if the PC is 
> dodgy or beefy enough to either avoid or ignore damage...
> 
> Anyway, my assumption is that only an abusive player who made a 
> habit of it would be the able to exhaust his balance and start 
> making the linkdeath AI get grumpy enough not to cheat for him.
> 
> But doing stuff the player could have done anyway, that's free.
> 
> And if the PC is safe enough for its adrenaline to go to zero without
> incident, then the linkdeath AI isn't on the clock because it's just
> twiddling its thumbs.
> 
> What I want to do is:
> 
> 1.  Prevent players from cheating by using disconnection as a means 
> of escaping danger on a habitual basis.  (anti-cheating measure, possibly
> important, particularly if such cheaters also provoke envy from 
> other more honest players)

I agree this needs addressing, but imho the solution should be to ensure the 
danger (or equivalent) danger is there when the player returns, so that the 
whole 'escape' idea stops working.



> 2.  Perhaps more importantly, stopping griefers from doing so in PvP 
> situations (anti-griefing measure, probably VERY important)
> 



> If having the character hire a linkdeath AI and bill any special 
> stuff to the player is a good way, then great.  However, if there's 
> a better idea, I'm all ears.  Hiring mr linkdead to run your char 
> was just the best idea I could come up with at this point, other 
> than just ignoring the issue completely and letting players 
> disconnect at whimsy.
> 
> one idea that popped into my head just now as I was typing:  
> Publicize the incident and let peer pressure sort it out? 

Well, PvP is a special case here, and for that, your suggestion would 
probably work well.

I have used the publishing idea for a case that was very prone to quit 
abuse, and there it worked pretty well. However, quit and going linkdead 
were not at all considered equivalent there (quit will make the character go 
out of the game, linkdeath will freeze the char in place for a while)

We also had rent and dropping of equipment on quit.

However, for now I see more in a 'return players to where they quit and 
ensure they get back to the danger level that was there when they quit' kind 
of solution.

This all depends on your game, I don't think there is a best solution. For 
PvP your solution might work well, but it is a kind of solution that would 
make me not want to play. Since pet peeves was your original question...

Thanks for the interesting explanations tho. Good food for thought.

Bart.
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/




More information about the DGD mailing list