Create an account


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

#1
UPDATE: Dynamic handicap was merged and it now available in git and autobuild.

Again, based on the discussion on the forums I've made another option to help new players. This mutator uses the difference from mean score to set the handicap.

Linear handicap value is calculated using the following formula:
Code:
linear_handicap = |(score - mean) * g_dynamic_handicap_scale| ^ g_dynamic_handicap_exponent
After that the sign is restored and final handicap if calculated using this formula:
Code:
if (linear_handicap >= 0)
{
   handicap = linear_handicap + 1;
}
else
{
   handicap = 1 / (|linear_handicap| + 1);
}

Server settings

Code:
g_dynamic_handicap 0 "Whether to enable dynamic handicap."
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."
g_dynamic_handicap_exponent 1 "The exponent used to calculate handicap. 1 means linear scale. Values more than 1 mean stronger non-linear handicap. Values less than 1 mean weaker non-linear handicap"
g_dynamic_handicap_min 0 "The minimum value of the handicap."
g_dynamic_handicap_max 0 "The maximum value of the handicap."
?️‍? <- that should be a rainbow flag emoji.
Reply

#2
But this will not used by new players? Is this mod client or server side?
Reply

#3
Handicaps have been built into Xonotic for a while. It's definitely in the 0.8.2 client and I think well before that.

The basic handicap code (current Xon default code) is entirely server side. The way it works is that the value is updated on the client, then passed from the client to the server, as this is the only way for the player to currently get the value to the server for that player.

The mutator change Lyberta has produced is server side, and it auto-scales the server side values for the handicap dynamically. Client side isn't involved.

Lyberta: Does this mod stop clients pushing the handicap cvar from the client to the server? Otherwise I can see people pushing their own values over the top of the dynamic handicap to get handicap bonuses (even if they're short lived due to regular updates of the handicap on the server side).
[Image: 21975.jpg]

Quote:“To summarize the summary of the summary: people are a problem.” - Douglas Adams
Reply

#4
(09-04-2017, 07:46 PM)cefiar Wrote: Lyberta: Does this mod stop clients pushing the handicap cvar from the client to the server? Otherwise I can see people pushing their own values over the top of the dynamic handicap to get handicap bonuses (even if they're short lived due to regular updates of the handicap on the server side).

No, client handicap right now is separate and is not really accessible to mutators in a clean way. My idea is too make handicap a core system that is customizable by mutators.
?️‍? <- that should be a rainbow flag emoji.
Reply

#5
Lyberta: No probs and thanks for the clarification. Only thing I'm wondering about is if people could use the client handicap to screw with the server side balance somehow, which would not be useful.
[Image: 21975.jpg]

Quote:“To summarize the summary of the summary: people are a problem.” - Douglas Adams
Reply

#6
If I understand correctly, you can't set client-side handicap to less than 1, which means you can't give yourself an advantage.
?️‍? <- that should be a rainbow flag emoji.
Reply

#7
Alright, I've added handicap API, if this mutator is merged, other people can create other handicap mutators and use clean interface.
?️‍? <- that should be a rainbow flag emoji.
Reply

#8
At what point does this kick in? I ask primarily because Vanilla can have rapidly fluctuating player performance, even at the beginning of the match. For instance a player used to insta or sniping in other games may grab a vortex and get a solid 5+ frags. He may then die and never get another chance to grab vortex.

It'd important to remember as well, that due to these sorts of circumstances, gaps of 5, 10 or even 20 frags between players of similar skill levels are actually perfectly normal, depending on the map and performance of each player. If we look at another extremely fast AFPS- CPM, one can find duels between players at the top of their game that can vary by thirty or even forty frags on popular maps like Aerowalk. While this is in duel, and between players who know how to exploit mistakes, they also dont have access to curving rockets, fast grenades, monstrously strong projectile shotguns and the strength powerup.

What should be avoided, above all else are scenarios where a new player feels as though they're being punished, and scenarios where people dont understand why their hits dont seem to really "count". In a game where we already have a high base armour reduction % we're already gonna have a hell of a time with the latter

edits due to my phone being a shit
Reply

#9
This is a mutator that must be explicitly enabled by server administrator. The main purpose is to make newbie-friendly config that will give them more chances to frag. Using this mutator I could win against godlike (skill 10) for the 1st time.
?️‍? <- that should be a rainbow flag emoji.
Reply

#10
Dynamic handicap was merged into master and is available in git and tomorrow's autobuild.
?️‍? <- that should be a rainbow flag emoji.
Reply

#11
(09-04-2017, 09:40 AM)Lyberta Wrote: Again, based on the discussion on the forums I've made another option to help new players. This mutator changes the damage of players based on their kill/death ratio. The handicap value of 1 means the damage in unchanged. The values higher than 1 mean players will deal less damage and get damaged more. The values lower than 1 mean players will deal more damage and get damaged less.
Hi.

I don't think this handicapping is constructive at all.
#1 This mutator changes the damage of players based on their kill/death ratio. Consider this scenario, an FFA DM match with 5 players (common mode for new players to be in).
Place       Name         Kills       Deaths     Suicides     Frags
1st           Player #1   30         27             1                29
....
5th           Player#5    7          1                0                7
...

In this scenario, Player#5 is the disadvantaged player from a natural score POV. With dynamic handicapping, he is also the most handicapped player because high k:d does not necessarily mean winning or dominating the match e.g the case of a large map wherein it is easy for a stray player to miss the party, which this is also common new player behavior to wander around the map. Where as FFA regulars of varying skills generally are trained to aggressively pursue frags.

Obviously the solution would be for him to die enough to remove the handicap, but that obstructs his goal to win explicitly e.g relinquish any items he's collected but also feed frags to other contestants who may have a lower k:d than him, but still have a higher score.

#2 New player may want frags, but they also want to learn the game and improve (which in previous posts, is something you have explicitly stated you are not interested in doing in your 3 years experience of playing the game). This obfuscates the latter where you punish positive behavior or improvement, and reward poor play, stagnation, or decay.

Add:

I almost forgot. Does this mean the flag carrier in CTF, can spam his kill bind, for massive damage reductions and carry flags all day (-> massive point rewards for capping the flag -> more elo points).
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

#12
A server admin can set maximum to 1 and good players will not be punished while bad players will be able to get advantage. The CTF scenario is solved by setting minimum to 1. Mario is working on a branch that will disable ELO when handicap is active.
?️‍? <- that should be a rainbow flag emoji.
Reply

#13
If that's the case, then increasing incoming damage based on k:d is agreed to be counter-intuitive.

If you set minimum for 1 regarding the CTF scenario, does it still mean a player dedicated to flag carries still gets a damage bonus (i.e better able to defend himself)?
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

#14
(09-17-2017, 03:01 PM)Antares* Wrote: If you set minimum for 1 regarding the CTF scenario, does it still mean a player dedicated to flag carries still gets a damage bonus (i.e better able to defend himself)?

A player who doesn't kill players and only goes to flag? That way they get vanilla damage.
?️‍? <- that should be a rainbow flag emoji.
Reply

#15
(09-18-2017, 01:09 PM)Lyberta Wrote:
(09-17-2017, 03:01 PM)Antares* Wrote: If you set minimum for 1 regarding the CTF scenario, does it still mean a player dedicated to flag carries still gets a damage bonus (i.e better able to defend himself)?

A player who doesn't kill players and only goes to flag? That way they get vanilla damage.

That will give them an advantage over people who get handicapped because they've done well at their role (defense, disruption), which means that you either have to rotate people awkwardly through roles (hard in pubs and less dedicated pugs, hard for new players, annoying for people who just want to have fun) or your frag-focused players will get worse at their job as they become more successful, but can still be crippled by a few shots from a flag carrier (who will generally not try to get frags). This will probably lead to something cheesy like defenders/attackers suiciding like CTS diehards to keep their damage up
Reply

#16
(09-18-2017, 01:09 PM)Lyberta Wrote:
(09-17-2017, 03:01 PM)Antares* Wrote: If you set minimum for 1 regarding the CTF scenario, does it still mean a player dedicated to flag carries still gets a damage bonus (i.e better able to defend himself)?

A player who doesn't kill players and only goes to flag? That way they get vanilla damage.

lol you tried to dodge the only important detail is that they (get themselves) killed intentionally.

A player who gets themselves killed would get a negative or low k:d on purpose would:
  • incur a incoming damage reduction so they're killed less
  • receive an outgoing damage boost so they can receive more kills
    You have described that in CTF you can set the minimum 1, so this is not abused by flag carriers so they not receive incoming damage reduction. However with the handicap in place, they would also receive a damage boost. Flag carriers or really any role in CTF do not really care about k:d and they can exploit this handicapping system to give themselves an advantage.Above all those conscious of the system will not be new players. So not only are potential newbies outmatched naturally, their opponents are also giving themselves unfair advantages over them.
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

#17
It's up to the server admin, why aren't you complaining that other mutators that may break the game? "Oh, killing flag carrier with running guns mutator is so hard".
?️‍? <- that should be a rainbow flag emoji.
Reply

#18
Feedback isn't complaining.  These are good points.  Kill/death ratio alone might work for ffa and duel but other information could be used to prevent a team from turning dynamic handicap into an adavantage and defeating the point of a handicap.  Handicapping by your score relative to other players might work without requiring game mode-specific code.

The other possible issue I can see is that the scaling of the dynamic handicap could be too heavy and make the game too easy for the down player or could be too little and not do enough to help that player.  You may have already found a good balance but I didn't see any mention of this in the thread.  If not, continued play testing should get you to reasonable handicap increments.
Reply

#19
(09-19-2017, 12:54 PM)Lyberta Wrote: It's up to the server admin, why aren't you complaining that other mutators that may break the game? "Oh, killing flag carrier with running guns mutator is so hard".

It's also the responsibility of the developer who placed an shortsighted, abuseable or counter-intuitive system in the game to begin with. Why should I be talking about other mutators in this thread?
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

#20
(09-19-2017, 03:19 PM)mini Wrote: Feedback isn't complaining.  These are good points.  Kill/death ratio alone might work for ffa and duel but other information could be used to prevent a team from turning dynamic handicap into an adavantage and defeating the point of a handicap.  Handicapping by your score relative to other players might work without requiring game mode-specific code.

Hmm, how would you scale the handicap using score? That would probably require checking the connection time and then calculating score/sec.

(09-19-2017, 03:19 PM)mini Wrote: The other possible issue I can see is that the scaling of the dynamic handicap could be too heavy and make the game too easy for the down player or could be too little and not do enough to help that player.  You may have already found a good balance but I didn't see any mention of this in the thread.  If not, continued play testing should get you to reasonable handicap increments.

That's exactly what g_dynamic_handicap scale is for.

(09-20-2017, 05:15 AM)Antares* Wrote: It's also the responsibility of the developer who placed an shortsighted, abuseable or counter-intuitive system in the game to begin with.

Pretty much every variable in the game can have tremendous effect. That responsibility is now of the server admins.
?️‍? <- that should be a rainbow flag emoji.
Reply

#21
(09-20-2017, 05:58 PM)Lyberta Wrote: Hmm, how would you scale the handicap using score? That would probably require checking the connection time and then calculating score/sec.
Polling scores every second sounds excessive.  Hooking into score changes would be nice if QuakeC allows it.  On kill or death also makes sense.  Regardless of how or when the handicap is set, the problem of confusing new/unaware players remains.

Factoring the time since joining the match sounds less useful if you're updating the handicap throughout the match.  Whether they catch up or die a few times, the handicap system will even things out as the match continues.

(09-20-2017, 05:58 PM)Lyberta Wrote: That's exactly what g_dynamic_handicap scale is for.
The point was that a sane default scale/recommended default scale would be valuable to server hosts looking to use your mutator.  I'm sure hosts would be willing to offer specific suggestions as time goes on.

(09-20-2017, 05:58 PM)Lyberta Wrote:
(09-20-2017, 05:15 AM)Antares* Wrote: It's also the responsibility of the developer who placed an shortsighted, abuseable or counter-intuitive system in the game to begin with.

Pretty much every variable in the game can have tremendous effect. That responsibility is now of the server admins.
You don't want to take ownership of your code?  I'm sincerely confused by this response.
Reply

#22
(09-21-2017, 03:17 PM)mini Wrote: Polling scores every second sounds excessive.  Hooking into score changes would be nice if QuakeC allows it.

I will hook into score changes.

(09-21-2017, 03:17 PM)mini Wrote: On kill or death also makes sense.  Regardless of how or when the handicap is set, the problem of confusing new/unaware players remains.

If done right, handicap should be unnoticeable. Players will simply have fun.

(09-21-2017, 03:17 PM)mini Wrote: Factoring the time since joining the match sounds less useful if you're updating the handicap throughout the match. Whether they catch up or die a few times, the handicap system will even things out as the match continues.

With kills/death formula there are deaths, with score what you will divide by? If I simply look at the score, the players with high score will be punished while players who just joined mid game will receive a huge buff. Dividing by playtime seems reasonable.

(09-21-2017, 03:17 PM)mini Wrote: The point was that a sane default scale/recommended default scale would be valuable to server hosts looking to use your mutator.  I'm sure hosts would be willing to offer specific suggestions as time goes on.

I don't have enough experience to say what scale is the best.

(09-21-2017, 03:17 PM)mini Wrote: You don't want to take ownership of your code?  I'm sincerely confused by this response.

I don't want to intentionally limit creativity of server owners. I give them tools, it's up to them to decide the balance and rules. Every variable can break the game, say you set blaster damage to 500, now blaster is instagib, but should we hardcode the range of values? I think not.
?️‍? <- that should be a rainbow flag emoji.
Reply

#23
How about this:
Code:
base_value = (score - mean) * scale;
if (base_value >= 0)
{
   handicap = base_value + 1;
}
else
{
   handicap = 1 / (fabs(base_value) + 1);
}
?️‍? <- that should be a rainbow flag emoji.
Reply

#24
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.
?️‍? <- that should be a rainbow flag emoji.
Reply

#25
(09-21-2017, 07:13 PM)Lyberta Wrote: I don't want to intentionally limit creativity of server owners. I give them tools, it's up to them to decide the balance and rules. Every variable can break the game, say you set blaster damage to 500, now blaster is instagib, but should we hardcode the range of values? I think not.


If you mean to say the server adminstrator as a creative position, then you're a little mistaken. Mainly server administration changes cvars and place what ones to execute in what contexts (vote calls and menus). That's roughly it in terms of the limits of working with the server console, it's not like you can write new game modes in it or make maps with it. And obviously those tasks aren't called server administration.

And for example, any player starting their local match can change numbers and later collect the changes to a cvar and give them to a server administrator who then is able to show them to server regulars. Obviously the session would be marked as modified to distinguish from the game itself. 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 don't say what I do as if I'm interested in enabling this on a server- I will never enable this setting on my server or any others I have influence over. I say because it conflicts at a fundamental concept with what new players generally want despite the intentions of being for new players, and will generally give a bad impression of Xonotic. I.e it doesn't matter if its up to the server admins, 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.
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



Possibly Related Threads...
Thread Author Replies Views Last Post
  More dynamic environment CuBe0wL 34 24,515 12-02-2011, 09:27 AM
Last Post: Sarge999
  Dynamic Lights Seperated? master[mind] 3 2,980 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-