Author Topic: Handicap in Multiplayer  (Read 374 times)

0 Members and 1 Guest are viewing this topic.

Offline Simon

  • Administrator
  • Posts: 3283
    • View Profile
    • Lix
Handicap in Multiplayer
« on: May 16, 2022, 06:48:08 PM »
Hi,

(This has github issue #391: Handicaps in Multiplayer.)



If you're a brand-new player at golf, go, or chess, it's already an achievement when you beat a strong opponent at queen odds, or at nine stones, or at three more strokes per hole. Next time, can you do it at rook odds? You can easily see your personal progress in how the handicap shrinks over time. I'd like to have this in Lix.

Per game: In Lix's networking lobby, I'd like to offer handicap options next to the color picker. Between games, you can adjust the handicap. The default is no handicap for either side.

Choosing a handicap puts you at a disadvantage. The stronger side should handicap itself and thus start with a weaker position. I'd like the new player to start with the level's normal, unhandicapped-but-also-unimproved position; this makes it easier for him to learn how the map usually plays. Also, as I wrote in 2017: A strong player with 50 lix can beat a novice with 500, but a strong player with 5 lix must play enourmously well to beat a novice with 50 on a map with batters.



In IRC, geoo and I have considered some types of handicap.

Divisor handicap: You pick a number ≥ 1. Your initial number of lix is divided by it, and every skill count in your panel is divided by it. Options for divisor handicap could be 1 (= no handicap), 1.2, 1.5, 2, 3.3, 5, 7, and 10.

We'll always round up non-integer results. If the map gives 2 builders, you'll start with 2 builders at handicap 1.2 or 1.5, and you'll start with 1 builder at any bigger handicap.

Previously, I've expressed this as a multiplier handicap, and values were 100% (= no handicap), 70%, 50%, ..., but this design has a downside: Lower numbers mean stronger handicaps. It's nice when higher numbers mean stronger handicaps, to avoid confusion when people say "high handicap" or "you can lower it".

If you're in a team, the team's total divisor handicap can be the average of the team's players. Should "average" be the arithmetic mean or the harmonic mean? I'll have to ponder, and Proxima will be happy. Harmonic makes sense because it's a divisor handicap.



Delay handicap. You pick a number of seconds ≥ 0. Your first lix spawns later than other players' first lix, at this delay. Afterwards, your remaining lix continue to spawn at the normal spawn interval after each previous lix. Options for delay handicap could be 0, 5, 10, 20, 30 seconds. Anything more than 30 seconds is probably too boring for the experienced player.

Again, if you're in a team, the team's total delay is the average of the individual player's delay.

Asymmetric levels. If you choose a divisor and/or delay handicap, you always start in the first seat, and other players are randomly distributed amongst the remaining seats. This doesn't matter in a symmetric level, but if the author wants to build an asymmetric map, the author can put the seat-to-be-disadvantaged always in the first position. As long as we have any kind of handicap option, or even just a checkbox, we can add this seating rule at little exta UI cost in the lobby dialog -- it needs an explanation, but no extra pickers.

Level-specific handicap. Instead of offering concrete values to pick, you merely have a checkbox: Do you want to be handicapped or not? Or you have a choice of handicap strengths; which handicap strength do you want? It's the task of the level author to define the handicap in terms of delays or divisors or seats.

The downside of such level-specific handicap is that most authors won't bother to define handicaps for their levels. The few levels that have author-defined handicaps won't be consistent, e.g., you can play at strength 1 on this map, but it's hard to win against strength 3 on that other map. If it's not consistent anyway, I feel it's better to just offer concrete values, and let the players pick.

Ideas?

-- Simon
« Last Edit: May 16, 2022, 11:55:56 PM by Simon »

Offline Flopsy

  • Global Moderator
  • Posts: 885
  • Proud Lix player
    • View Profile
Re: Handicap in Multiplayer
« Reply #1 on: May 17, 2022, 01:17:01 AM »
I'm not sure if you're considering all these handicaps or just one of these but I'll discuss them anyway :)

Divisor Handicap

I read this as a handicap on both the Lix number and the number of skills at the same time, it feels like limiting skills doesn't really achieve much if the Lixes are already limited anyway, so having less say Walkers, Runners, Climbers, Floaters or Jumpers would not be that bad.
In fact if the same formula is used, if there was one walker for each Lix, it should still be one walker for each Lix.

The team formula is an interesting case however, because it feels like even the new players will be handicapped in this scenario which is not really something which should be encouraged.

Delay Handicap

I quite like the sound of this one but at the same time, I think level knowledge is required to make a decent handicap for this, some levels are over after 10 seconds pretty much.
Sometimes having delayed spawn could help the player rather than hinder them as well (eg. my Krypton Factor race map) so this can be very situational.

Asymmetric Levels

We don't have many of these levels and it's sometimes hard to know which is the hardest start position without play testing first. Otherwise this one is a good idea personally.

Level Specific

This one seems vague in description, are you saying the level author sets a single parameter which would occur if one says "yes" to being handicapped? If so, I don't see this getting much use also.

Offline geoo

  • Administrator
  • Posts: 1424
    • View Profile
Re: Handicap in Multiplayer
« Reply #2 on: May 17, 2022, 07:36:46 AM »
I've given this a bit of thought after the games with Rampoina. For the record, we played 3 maps:
  • Uphill battle. Rampoina was too strong for this map, and I didn't stand a chance. So we moved to
  • Ivory Tower: We played quite a few rounds, Rampoina won one and came very close to winning 3-4 times.
  • Stepping Stones: I handicapped myself by trapping my crowd and waiting for 1 minute before acting. Within 1 minute, building from the bottom middle block can almost reach to the opponent's starting platform, so this made it quite intense when my crowd was trapped there. If the spawn was simply delayed, the stakes would be lower, and even a delay of more than 1 minute could be considered. Rampoina almost won one round via the top route, but the crowd splatted right in front of the exit x_x
I believe handicap is extremely map specific. Quite often a delay and the reduction of the number of lix can serve the purpose. But many other maps will have specific skills which are rare, and adjusting their number might be a better means of handicap (e.g. floaters in Rescue Rangers, or diggers in Pancake Compression). The problem is, finding a good handicap needs knowledge of the map, and presumably the person who knows the map best is the level author.

I don't think putting the burden on the players via some complicated UI allowing to adjust delays, skills, number of lix etc is necessarily the best idea (it might be useful for experimenting though).

I would argue the best way would be to introduce handicap levels (both positive and negative), and the level author can specify various handicap levels in terms of delay, number of lix, spawn interval, skill numbers, etc.
Intermediate levels of handicap that are not specified would be done via linear interpolation (or maybe logarithmic for skills and/or lix amount, not sure). Of course, getting these levels consistent across different maps is difficult (and also subjective), but easy to tweak by changing the specific handicap level that is associated to a specific skill/lix parameter tweak.

I'm advocating for both positive and negative handicap because for some maps, it might be easier to provide positive handicap (e.g. add blockers, or add floaters to Rescue Rangers, while you wouldn't want to make these adjustments to the level itself). The aim would be that the handicap difference indicates the advantage, so +10 and 0 would be similar to 0 and -10.

Another advantage is that you can assign handicap values to spawns in asymmetric maps (and then possibly adjust them further via lix/skill parameter tweaks, to allow for a range of handicaps), incorporating these maps straightforwardly into the system.

From a player perspective, one would then simply adjust one's handicap level in the multiplayer UI, without needing knowledge of the specific map. Not every map would offer handicap levels, or some might only offer a limited range; the levels might not be 100% consistent across maps but one could make reasonable efforts towards that. I'd argue that all of this is fine, for example, the level browser could filter to only show maps where the min/max handicap is larger than a user provided value.

Offline Dullstar

  • Posts: 2032
    • View Profile
    • Leafwing Studios Website (EXTREMELY OUTDATED)
Re: Handicap in Multiplayer
« Reply #3 on: May 18, 2022, 12:07:08 AM »
With the Divisor Handicap, I think it would be important for skills and Lix to be two separate settings, with Lix being the most important.

Limiting the number of Lix available to a player forces them to go after other players in order to win, as the handicapped player will always lose a passive game. This is fine, because the players who we might handicap this way are the ones who are going to play like this anyway (because getting other players' Lix to come to your exit is generally how you win, but doing this requires a lot of skill because of keeping track of everything), so a reduction in the number of Lix offsets the advantage that players who are able to do this effectively have.

Limiting the number of skills could maybe make sense sometimes, but it's less fine-grained: if you observe a matchup is imbalanced, you can continually adjust the number of Lix handicap for quite a while before it reaches a point where it's unreasonable for the experienced player to overcome. But if you cut the number of skills, depending on what the limiting skill is, you can potentially reach a point where it's no longer possible to complete a path to the exit, and in levels with comparable amounts of constructive/destructive skills, the handicapped player will always lose any wars of attrition, which can happen a lot e.g. when there's a fragile builder/platformer staircase right next to an exit. I think for this reason, you'd want to handicap the number of Lix before the number of skills, and combining the two would place a hard limit on the amount by which you can divide before the matchup swings wildly in the other direction of imbalanced.

Since in a team game, all players share the same Lix and the same skills, I think it's sufficient to simply to assign the handicap to the team as a whole.



Assymetric levels, I think, would benefit from being able to choose arbitrary positions, though you may want some sort of mechanism to handle disputes in the event that talking to the other players fails to resolve it - a simple solution could be to try assigning everyone to their chosen hatch, and randomly select one of the people if multiple people chose it, then allowing remaining players to select from the remaining hatches until either all hatches are assigned, or there is only one hatch left to assign. Players could also choose to be assigned a random hatch, which would be applied after everyone who wants a specific hatch has chosen. Another solution could be to randomize the order of players (perhaps a handicap option to move certain players up or down the list?) and then go down the list and have people pick hatches, perhaps keeping the option to select a random hatch from the remaining hatches after all players have chosen.



The delay handicap is an interesting option, but I'd probably only consider it if we're okay with having multiple choices for handicaps.



A major weakness of level-specific handicaps is that there's not much room to adjust them on the fly. But one major use case could be defining the minimum amount of skills allowed. If a skill divisor handicap brings someone below that amount, they receive the minimum amount instead. This could be used to make sure that a player will always have at least the minimum number of skills required to reach their exit regardless of the skill divisor.
« Last Edit: May 18, 2022, 12:19:53 AM by Dullstar »

Offline Simon

  • Administrator
  • Posts: 3283
    • View Profile
    • Lix
Re: Handicap in Multiplayer
« Reply #4 on: May 19, 2022, 05:30:05 AM »
Thanks for the great replies! I'll come back to everything in 0-3 days.

-- Simon

Offline Simon

  • Administrator
  • Posts: 3283
    • View Profile
    • Lix
Re: Handicap in Multiplayer
« Reply #5 on: May 23, 2022, 09:10:11 PM »
Gist: Anything that touches the level format will wait until at least next year. 0.10 will have identical level format as 0.9, even if 0.10 has physics changes.

Anything that I can meaningfully implement as a player field is good for taking into 0.10's networking protocol. Lix 0.10 will already track client version per player, it's easy to add fields for handicap. Especially just adding some ints are are very easy these weeks during the design of 0.10, that's why I've made this thread.

I agree that no single handicap is the best on every map. If we offer handicap in the lobby, we may as well offer several types. This gives flexibility and is important for playtesting; then we'll be wiser in case we add something to the level format in the future.

Clones offered fully asymmetric starting positions for a still-balanced match. You were able to specify seat-dependent initial lemmings and seat-dependent skillsets. This goes in the same direction as handicap, might be worthwhile to keep in mind. Problem: It might also end orthogoal to handicap, forcing us to define all spots in a two-dimensional grid -- one axis handicap, second axis seat. I'd rather avoid too deep of such nesting. We'll see.

-- Simon

Offline Simon

  • Administrator
  • Posts: 3283
    • View Profile
    • Lix
Re: Handicap in Multiplayer
« Reply #6 on: June 27, 2022, 06:13:31 PM »
Hard to strike the balance between too many and too few options.

Benefits of many options:
  • You can fine-tune more. You can raise handicap of type X and lower type Y. Allows you to find something closer to 50:50 balancing.
  • As a community, we can experiment quicker and see what pulls its weight: which handicap types, which amounts.
Downsides:
  • Multi-valued handicap won't double as a ranking system. You're not 3 stones stronger than your opponent. You're hard-to-name-long-bla-bla stronger than your opponent.
  • Hard or impossible to squeeze the entire handicap selection into the player line in the lobby. Easy with one value, but hard with 3 or even more values. I don't want to reserve a huge space either for 3 values that will be empty in 90 % of the games.
  • Slightly more overwhelming UI, but this isn't a big downside with the following plan: I'll put all the details for handicap choice to a separate dialog anyway, where I can put ample explanation.
I'll heed Dullstar's warning (unplayability with too few skills), even though I don't believe it will manifest on too many maps. For 0.10, I'm thus aiming at:
  • Lix divisor handicap,
  • Skill divisor handicap (separate from the lix divisor),
  • Spawn delay handicap.
The underlying code will support geoo's beneficial handicap as well as the originally planned disadvantageous handicap, but I don't know if I want to expose beneficial handicap in the UI. I have written UI text that handicap will always put you at a disadvantage. I can revise the text if you feel strongly that Lix should offer beneficial handicap. But even with beneficial handicap, I'd still like to call the feature handicap -- and not mod or something similar unprecise.

In 0.10, I don't yet plan to put handicapped players on certain start positions. E.g., geoo's Uphill Battle will still require you to reset. If such deliberately imbalanced maps get popular, we can still add something in 0.11, 0.12, ...

-- Simon
« Last Edit: June 27, 2022, 07:11:05 PM by Simon »