[MUD-Dev] PvP Systems

msew msew at ev1.net
Fri Feb 23 00:13:50 CET 2001


At 07:55 02/22/2001 -0800, Koster, Raph wrote:

> How does this prevent the exploit that John cited?
>
> Bubba kills Buffy. Buffy places bounty on Bubba.
> Bubba gets his buddy Boffo to kill him, they split the bounty.

:-)

So my current thinking is this:

  The player with the bounty on them is penalized:

     -P + ( .5 * bounty ) or even just: -P + bounty (I get one of my
     own characters to collect bounty from another account)

  instead of:

     -P

now, for this specific exploit, this is only "really" bad when:

     time to recover P < time to get ( .5 * bounty ) for the friend
     kill exploit

  and

     time to recover P < time to get ( bounty ) for the self kill
     exploit

We will only really care about the self kill exploit as that one
encompasses the friend kill exploit.  Why we care about this is
because I could be doing less work to get ( bounty ) than I should, in
terms of the game design.

We can now calculate the difference in time and have that be the real
penalty here.  Only the amount of time matters (right?).  Time is the
common denominator for all people.  Some people may have more time on
their hand than others and that will be addressed below, as it is very
important.


  statement A: as (time to recover P) + ( -( time to get ( bounty )) )
  gets larger and larger we will have a system which the punishment
  far out strips the worth of the bounty.

So:

  we make P be a function of bounty!!  ( this can be especially harsh
  as the ENTIRE community can pitch in a small portion of their wealth
  and make the bounty absolutely HUGE and thusly make the P almost
  character crippling :( tho this may be a good thing for dealing with
  the scourges of the virtual world)*

*assumption being that we want to have a world where killing someone
actually is a thought out process and not just the afternoon fun of
the day.  It has REAL penalties that can be VERY VERY harsh.

  P >= ( f( bounty ) * k ) + f( bounty )

Where f() is the time that it takes the killer to get (bounty).  We
add f( bounty ) as we have to assume that the killer will get the
entire bounty himself for doing the killing (ie self kill exploit).  k
is just a scaling factor we can adjust to hopefully make pking more or
less rampant in the world (ie making it large will make the penalties
larger ) (recall statement A from above)

As we are basing everything on time, P should really be f(E) so that
whatever experience (E) penalty we give the Killer that amount of time
is greater than or equal to the amount of time it would take to gather
the bounty.

  f(E) >=  ( f( bounty ) * k ) + f( bounty )

The big problem is: figuring out what f( bounty )/f(E) is for various
ranges for characters (ie the lvl 1 will take 10 hours to get 1 pp
while the lvl 50 will take 10 seconds to get 10pp).  And player Boffa
will take 1 hour to get 1 million exp while player Bubba will take 2
days to get 1 million.  Further, we possibly need to understand the
victim's utility(time) and the killer's utility(time).  We need to
know these as a casual player losing an hour's worth of time due to PK
could be really really valuable to them and to the killer losing an
hour of time is just another grain of sand in the sahara to them.*

  * if this is added it makes the PKers want to avoid killing casual
  players and kill the people that play along the same play times as
  the killer (seems to be good as the casual player really loses much
  more than a non casual player when they are pk'd)


Possible ways for f(bounty) and f(E)

     -past empirical data on character's money gathering time  ( muahahha )

     -past empirical data on character's exp per minute  ( muahahha )

gives us a true amount of time that that character takes to gather
(bounty) and gain exp :-) (yet two more bytes to keep around tho which
imo is a small price to pay for what you gain)


I don't think that doing some sort of statistical guess based on
class/level/playtime/etc/etc is going to work, as the people that will
be doing the killing will not be correctly represented, and it should
be a punishment fit for that character not some general punishment
(one shoe does NOT fit all and it provides for exploits in that f()
assumes something that is probably not true for the uber killer (ie
f() with statistical data leaves open the possibility that: f(E) < f (
bounty ) and this is BAD BAD BAD).

Possible ways for utility(time):

      -average time played and total time played  in some function.

The (sadly) implicit assumption here is that people that spend less
time online have a higher utility(time) than those that spend large
amounts of time.  (I don't know if this is true or not but it seem to
be partially true.)

So we need a way to relate the utility(time) of the killer and
utility(time) of the killee such that: we can calculate the actual
"harm" that was done in terms of each party's view of "the value of
time".  We will call this f'(), it maps the harm amount to some value
in a table that can be modified to make the P bigger or smaller based
on what type of player is PK'd.

  killeeUtility() is using the original person killed by the killer

  killerUtility() is the killer that did the killing of the killee

so now our function looks like:


  f(E) >= ( f( bounty ) * k ) + f( bounty ) + f'( (
  killeeUtility(time) - killerUtility(time) ) )

If you kill someone that is a casual gamer compared to you, you get
some biggish penalty, if you kill someone like you, you get basically
no penalty.  you can do all sort of stuff with the utility(time) where
you make certain classes of people (ie casual gamer is average play
time < 10 hours a week)

Some loopholes with this are that if you have a PKer that just logs on
to kill infrequently as a secondary character made just to kill casual
gamers.  So we need to keep track of how many PKs this guy has done.
f''() is a scaling function we use to determine based on the number of
kills this killer has done, how to scale his utility value.


  f(E) >= ( f( bounty ) * k ) + f( bounty ) + f'( (
  killeeUtility(time) - ( killerUtility(time) * f''(killerNumPKs )) )
  )

or in english:

  the amount of time that it takes this specific killer to gain E
  experience pts must be GREATER THAN OR EQUAL TO the amount of time
  it would take this specific killer to gather the bounty that is
  offered for killing him, scaled by the world's view of PKing (ie PK
  is an accepted thing or a really frowned on thing), with an
  additional penalty for killing people whom being killed really
  really harms them (ie causal gamers)

So now when the bounty kill occurs, the amount of exp the killer loses
is calculated instead of just being the normal exp lost to a death.*

  * it seems that there are two types of kills.  PK kill and Bounty
  Kill.  The player BEFORE attacking needs to decide which type of
  attack he is going for.  A normal PK kill attempt does NOT allow him
  to claim the bounty if he succeeds in the killing.  A Bounty Kill
  DOES allow him to claim the bounty if he succeeds in the killing.


One could consider k to be the "pk" factor in the game.  Make k really
large and you will have no PKs.  Make k close to zero and you will be
actively encouraging PKing.  Make K 1 and you will have only the f'()
(killing casual gamers) penalty be the only real Penalty for killing
someone (ie you get rid of the f'() then a k == 1 basically means
PKing for free when they do the self kill exploit ).  (NOTE: * k
should really be a function so we can do other things like have a min
exp loss and such but *k made it clearer in regards to what it was
doing.)

The goal of any punishment system is to make P a strong enough deterant, 
that trading the Penalty for the bounty is NEVER worth it.  Relating the 
penalty to the bounty seems to work in terms of that statement.  Adding the 
utility f''() conceivably makes the penalty function better for protecting 
casual gamers.

msew







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



More information about the mud-dev-archive mailing list