Create an account


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Dynamic handicap

#26
(09-22-2017, 11:12 PM)Antares* Wrote: A dynamic handicap cvar for a system built into a git version of the game- isn't so clear as to whether or not the server is flagged as modified i.e balance changes, or Official e.g g_warmup changes does not tag servers as modified.

I'm pretty sure you have to explicitly mark it is pure to be allowed officially.

(09-22-2017, 11:12 PM)Antares* Wrote: if new players perceive that unfairness is part of the game ("why does my sniper only deal 80 damage and yours does more?"), there's a good chance they'll see it as a bad game and not waste any more time with it.

For new player sniper will deal more damage if they play badly. This system is designed to help new players, not to punish them. If a player can actually remember what weapon does what damage (I'm playing the game since 2013 and still don't know damage of half of the weapons), they are not newbies by any stretch and most likely will not be interested to newbie-friendly servers.
?️‍? <- that should be a rainbow flag emoji.
Reply

#27
(09-23-2017, 12:06 AM)Lyberta Wrote: I'm pretty sure you have to explicitly mark it is pure to be allowed officially.
You don't. To be marked as Official, certain cvars can't be touched. Some cvars are allowed to be changed.
(09-23-2017, 12:06 AM)Lyberta Wrote: For new player sniper will deal more damage if they play badly. This system is designed to help new players, not to punish them
You seem to be confused. A new player doesn't necessarily play badly e.g they play other FPS games and there's some carry over in skill or there's other new players on the server and one in particular is doing well.
This system may have the intentions of helping new players, but it rewards poor play, intentionally dying (if k:d) or stalling the game (if you're doing points per playtime e.g this is also easily done in CTF and frustrates both teams), and penalizes new players if they were to improve over their peers.
Damage is now observable since the damage text feature has been added.
Xonotic exists for a long time and low player count is the proof that nobody wants to play Xonotic since it is a bad game by default.
- Lyberta, 2017
Reply

#28
(09-23-2017, 12:19 AM)Antares* Wrote: You don't. To be marked as Official, certain cvars can't be touched. Some cvars are allowed to be changed.

I'm saying that you explicitly mark variable "official friendly" in code. This is the usual policy of "default deny".

(09-23-2017, 12:19 AM)Antares* Wrote: You seem to be confused. A new player doesn't necessarily play badly e.g they play other FPS games and there's some carry over in skill or there's other new players on the server and one in particular is doing well.

A new player doesn't know the weapons, doesn't know where are their spawns. Most new players will be walking with shotguns and getting other weapons by pure chance. It's not likely that they will dominate the score.

(09-23-2017, 12:19 AM)Antares* Wrote: This system may have the intentions of helping new players, but it rewards poor play,  intentionally dying (if k:d) or stalling the game (if you're doing points per playtime e.g this is also easily done in CTF and frustrates both teams), and penalizes new players if they were to improve over their peers.

Those behaviors require a lot of thought on the part of the player and will need the majority of players to break the game. Something that is extremely unlikely.

(09-23-2017, 12:19 AM)Antares* Wrote: Damage is now observable since the damage text feature has been added.

Yes, but if you can remember the numbers, you are already very skilled or experienced.
?️‍? <- that should be a rainbow flag emoji.
Reply

#29
(09-23-2017, 12:34 AM)Lyberta Wrote: A new player doesn't know the weapons, doesn't know where are their spawns. Most new players will be walking with shotguns and getting other weapons by pure chance. It's not likely that they will dominate the score.
Or they've played FPS games before and have some pre-existing aiming skill that benefits them over others without necessarily being conscious of Xonotic specific weapon strategies. And they find the weapons via hitting the weapon key of the weapon they don't already have.


(09-23-2017, 12:34 AM)Lyberta Wrote: Those behaviors require a lot of thought on the part of the player and will need the majority of players to break the game. Something that is extremely unlikely.
Players aren't exactly idiots and (ab)using systems for an advantage is generally part of gaming.


(09-23-2017, 12:34 AM)Lyberta Wrote: Yes, but if you can remember the numbers, you are already very skilled or experienced.
No, there's more to the game than memorizing numbers, and recognizing a 2 or 3 digit number is something nearly anyone can do.
Xonotic exists for a long time and low player count is the proof that nobody wants to play Xonotic since it is a bad game by default.
- Lyberta, 2017
Reply

#30
(09-23-2017, 12:52 AM)Antares* Wrote: And they find the weapons via hitting the weapon key of the weapon they don't already have.

How the hell are they supposed to know that? I was playing for 4 years without knowing it.
?️‍? <- that should be a rainbow flag emoji.
Reply

#31
(09-23-2017, 01:52 AM)Lyberta Wrote:
(09-23-2017, 12:52 AM)Antares* Wrote: And they find the weapons via hitting the weapon key of the weapon they don't already have.

How the hell are they supposed to know that? I was playing for 4 years without knowing it.
By hitting the key when they don't have the weapon, either accidentally or just trying out the weapon binds. lol
Played only one year, but found the feature within a few matches.
Xonotic exists for a long time and low player count is the proof that nobody wants to play Xonotic since it is a bad game by default.
- Lyberta, 2017
Reply

#32
(09-22-2017, 09:57 PM)Lyberta Wrote: I have implemented that formula and added exponent for more fine tuning. Unfortunately, score difference varies wildly between gamemodes so g_dynamic_handicap_scale should be set per mode. 0.2 seems fine for DM, 0.05 seems fine for CTF. Dunno about other gamemodes.

Looks good.  Should mitigate the described abuses in the main modes (CTF seems like a tricky mode to dynamically handicap).  Nice looking ahead with the different scale for modes with drastically different point gain.  Won't require a code change every time a game mode is added.
Reply

#33
Thanks again.
Code:
g_dynamic_handicap_scale 0.2 "The scale of the handicap. Larger values mean more penalties for strong players and more buffs for weak players."
I might have misunderstood buffs -- I thought buffs are for anyone to get so how can they show up only for some?
Also, what's a set of good settings for servers? (And does the server setting take priority over voluntary client setting, or do the two settings aggregate?)
Thanks!
Reply

#34
Lyberta, have you tried doing player_score / mean_score instead of player_score - mean_score to avoid having different factors and exponents for different modes?
BFG, in this case buff means bonus or advantage, unfortunately certain game items are also called buffs, might be better to change the description.
[Image: 30381.jpg]

<packer> when i see martin-t's name my blood pressure increases

<[BOT]Hоtdоg> anyone here lives near martin?
<[BOT]Hоtdоg> will pay monies for shooting him
Reply

#35
(09-24-2017, 11:35 PM)martin-t Wrote: Lyberta, have you tried doing player_score / mean_score instead of player_score - mean_score to avoid having different factors and exponents for different modes?
BFG, in this case buff means bonus or advantage, unfortunately certain game items are also called buffs, might be better to change the description.

I would calculate the handicap directly and eliminate the absolute value and the exponent but would keep the scale because modes like CTF have much larger differences in score than most modes.  

According to Halogene,  in another thread, only handicap values greater than 1 are applied, so any value less than that is the same as 0.  From speaking with other players, it seems that small handicap values make a big difference so exponents are likely overkill.  Something as simple as the following preserves the sign and can be applied directly because players leading in score have a value less than one set to cl_handicap.  It also doesn't grow out of control because it's not exponential.  I'd liked to have eliminate the if-else but this function needs to not apply a handicap when the difference is 0.
Code:
difference = mean - score;
if (difference != 0)
    linear_handicap  = difference * g_dynamic_handicap_scale  + 1;
else
    linear_handicap = 0;

The scale would be different than it was for the original function, but values could be chosen that restrict handicap between 1 and 2 in most cases, and just a little beyond in extreme cases.
Reply

#36
(09-24-2017, 11:35 PM)martin-t Wrote: Lyberta, have you tried doing player_score / mean_score instead of player_score - mean_score to avoid having different factors and exponents for different modes?

Maybe (player_score - mean_score) / mean_score. Remember that score can be negative. But this would mean that when mean becomes larger, handicap deviation will be very little. Say, a DM game with 100 frag limit. In that mode 10 frag difference can mean a lot.

(09-25-2017, 08:21 AM)mini Wrote: According to Halogene, in another thread, only handicap values greater than 1 are applied, so any value less than that is the same as 0.

Forced handicap can be less than 1 and cl_handicap is multiplied by forced handicap when calculating damage.

(09-25-2017, 08:21 AM)mini Wrote: From speaking with other players, it seems that small handicap values make a big difference so exponents are likely overkill.

Exponent can be less than 1 in which case deviation will grow less than linearly.
?️‍? <- that should be a rainbow flag emoji.
Reply

#37
(09-25-2017, 08:06 PM)Lyberta Wrote:
(09-24-2017, 11:35 PM)martin-t Wrote: Lyberta, have you tried doing player_score / mean_score instead of player_score - mean_score to avoid having different factors and exponents for different modes?

Maybe (player_score - mean_score) / mean_score. Remember that score can be negative. But this would mean that when mean becomes larger, handicap deviation will be very little. Say, a DM game with 100 frag limit. In that mode 10 frag difference can mean a lot.

(09-25-2017, 08:21 AM)mini Wrote: According to Halogene,  in another thread, only handicap values greater than 1 are applied, so any value less than that is the same as 0.

Forced handicap can be less than 1 and cl_handicap is multiplied by forced handicap when calculating damage.

(09-25-2017, 08:21 AM)mini Wrote: From speaking with other players, it seems that small handicap values make a big difference so exponents are likely overkill.

Exponent can be less than 1 in which case deviation will grow less than linearly.
My point was that this approach is needlessly complex.  Taking the absolute value and exponentiation are costly and give you nothing a simpler function wouldn't.

Switch mean and player score and you have a function that gets you directly to a useful, but very strong cl_handicap value.  Scaling this down may be the way to go because it avoids complex computations.
Code:
if (score != 0)
    cl_handicap = 1 + ((mean - score) / score)  * scale
 
What makes this all work is the hint Halogene gave us. cl_handicap of anything less than one is zero.  cl_handicap of anything greater than one is itself.  Here's some sample values if scale is set to 1.


f (m, p) = 1 + (m - p) / p,  if p != 0
             = 0, if p = 0

CTF player leading 
f (70, 150) = 7/15  (effectively 0)

CTF player is well behind
f (70, 30) =  7/3

DM player is very far ahead
f (1, 20) = 1/20  (effectively 0)

DM player is very far behind
f (20, 1) = 20

DM player is a little ahead
f (5, 10) = 1/2  (effectively 0)

DM player is a little behind
f (10, 5) = 3/2

Close game, ahead by one
f (2, 3) = 2/3  (effectively 0)

Close game, behind by one
f (3, 2) = 3/2

Haven't scored any points yet (don't div/0)
f (4, 0) = 0
Reply

#38
(09-26-2017, 12:19 AM)mini Wrote: What makes this all work is the hint Halogene gave us. cl_handicap of anything less than one is zero.  cl_handicap of anything greater than one is itself.  Here's some sample values if scale is set to 1.

I don't mess with cl_handicap at all. cl_handicap is up to the client.

cl_handicap of anything less than 1 is 1.
?️‍? <- that should be a rainbow flag emoji.
Reply

#39
(09-26-2017, 03:06 AM)Lyberta Wrote:
(09-26-2017, 12:19 AM)mini Wrote: What makes this all work is the hint Halogene gave us. cl_handicap of anything less than one is zero.  cl_handicap of anything greater than one is itself.  Here's some sample values if scale is set to 1.

I don't mess with cl_handicap at all. cl_handicap is up to the client.

cl_handicap of anything less than 1 is 1.

Ok, so cl_handicap itself defaults to one because it is applied to damage and damage taken.  My previous suggestions can be simplified even further with that domain.  If you had already bound the range between 1.0 and 10.0, then why use such a costly function?
Reply

#40
Because I don't use cl_handicap. I use another, forced handicap value that can be anything greater than zero (i.e. linear value can be (-inf;+inf) ).

My first idea was to use normal distribution but exponent is faster and more flexible.
?️‍? <- that should be a rainbow flag emoji.
Reply

#41
(09-26-2017, 08:25 PM)Lyberta Wrote: Because I don't use cl_handicap. I use another, forced handicap value that can be anything greater than zero (i.e. linear value can be (-inf;+inf) ).

My first idea was to use normal distribution but exponent is faster and more flexible.
You still seem to misunderstand my points so I'll be blunt.  cl_handicap is completely irrelevant to the choice of mathematical function.  The given domain, desired range, and how the function dictates the design of your code is what matters.  If you had taken the time to choose a decent function, you wouldn't have had to store the sign, take the absolute value in two places, or restore the sign.  It's the difference between

Code:
Code:
difference = score - mean;
linear_handicap = | difference * g_dynamic_handicap_scale| ^ g_dynamic_handicap_exponent

if (difference < 0 && linear_handicap > 0)
{
    linear_handicap *= -1;
}

if (linear_handicap >= 0)
{
   handicap = linear_handicap + 1;
}
else
{
   handicap = 1 / (|linear_handicap| + 1);
}

and
Code:
if (score != 0)
    handicap = 1 + ((mean - score) / score)
or
Code:
handicap  = difference * g_dynamic_handicap_scale  + 1;

You could also figure out an exponential function that calculates the desired handicap directly for the same design improvement but with your desired growth rate.  That is, if you really need to give admins the option of having handicaps that are wildly explosive or too weak to make a difference.
Reply

#42
(09-27-2017, 09:15 PM)mini Wrote:
Code:
if (score != 0)
    handicap = 1 + ((mean - score) / score)

What if score is 0? What if score is between -1 and 1?

(09-27-2017, 09:15 PM)mini Wrote:
Code:
handicap  = difference * g_dynamic_handicap_scale  + 1;

What if difference is negative and multiplied by g_dynamic_handicap_scale gives less than or equal to -1?
?️‍? <- that should be a rainbow flag emoji.
Reply

#43
(09-28-2017, 11:29 AM)Lyberta Wrote:
(09-27-2017, 09:15 PM)mini Wrote:
Code:
if (score != 0)
    handicap = 1 + ((mean - score) / score)

What if score is 0? What if score is between -1 and 1?

(09-27-2017, 09:15 PM)mini Wrote:
Code:
handicap  = difference * g_dynamic_handicap_scale  + 1;

What if difference is negative and multiplied by g_dynamic_handicap_scale gives less than or equal to -1?
This is how I know you weren't reading my previous posts.  Please read them rather than replying without.

The first one is probably best because it can't be misused.  Thanks @martin-t.  Inputs are all integers but are float types so epsilon comparison or bound would work where appropriate.  Since this assignment happens in an event loop, set it to 1 in the case where score is 0 (did you really need me to spell that out for you?).
Code:
if (score != 0)
   handicap = 1 + ((mean - score) / score)
else
    handicap = 1;

For the second one,
mini Wrote: The scale would be different than it was for the original function, but values could be chosen that restrict handicap between 1 and 2 in most cases, and just a little beyond in extreme cases.

and restrict the values scale can assume or use bound() so that admins can't shoot themselves in the foot.  

Once again, all of this is beside the main point, which is better mathematical functions can simplify your code, be kind to admins, and be kind to future maintainers.
Reply

#44
Score is float and I use fractional score. There is no point in restricting it to integers. Bounding is already implemented.
?️‍? <- that should be a rainbow flag emoji.
Reply



Possibly Related Threads...
Thread Author Replies Views Last Post
  More dynamic environment CuBe0wL 34 24,510 12-02-2011, 09:27 AM
Last Post: Sarge999
  Dynamic Lights Seperated? master[mind] 3 2,979 11-12-2010, 08:19 PM
Last Post: tZork

Forum Jump:


Users browsing this thread:
1 Guest(s)

Forum software by © MyBB original theme © iAndrew 2016, remixed by -z-