Handicap in Multiplayer

[Simon]

Done:

• Handicap merges properly in teams of more than one player. If A and B team up, A picks no handicap, B picks 10 % of initial lix, the team will start with 55 % of the initial lix (= (100 % + 10 %) / 2).
  
• Console tells you when another player in your room changes his handicap. The handicap in the player line is small and cryptic, it's only good as a reminder. The long console message explains the handicap much better.
  
• When you change your handicap, you unready.
  
• Fixed double overtime bell bug that came from physics changes.
  
• Fixed bug where the map wouldn't exit when all players were on the same team -- an unusual situation, but Lix has never explicitly disallowed it.
  

Curiously, this 1-team-map-exiting bug has been in Lix for many months. Icho and I merely found it because Handicap made it more likely to run into the bug. This bug was: Gameplay saw only 1 team, concluded that it had to be singleplayer, and only exited the map when that team satisfied the save requirement. Usually, the save requirement is 20 on multiplayer maps because 20 is the map editor's default, and you never need it in multiplayer. With a harsh handicap, you wouldn't reach 20 points, thus Lix didn't exit the map; instead, it froze physics at the end and told you to revert time.

I'll probably release a 0.9.48 before the 0.10 and include this fix already in 0.9.48.

Todo for 0.10.0:

• Server should tell 0.9 players that they can't see or can't enter 0.10 rooms.
  
• When you press ready, then enter the handicap dialog, then others press ready and start playing, you're stuck in the dialog. Fix this.
  
• Batter's forward range vs. blockers should be exactly as it has always been in 0.9. I believe 0.9 had same forward range as C++ Lix, but haven't investigated.
  
• Draw tipped scales (= the handicap icon) in all resolutions.
  
• Writing long release notes!
  

In later 0.10.x:

• Add replay support for handicap.
  
• File UX bug against the slowly-eating factory trap.
  

-- Simon

[Simon]

I had a productive Friday night and Saturday. Done:

• When you press ready, then enter the handicap dialog, then others press ready and start playing, you now successfully join play. You're not stuck in the handicap dialog anymore. Now, level browser and handicap dialog behave the same in this regard.
  
• Batter's forward range vs. blockers in 0.10 should be exactly as it has always been in 0.9. Ensured 100 % singleplayer coverage.
  
• Batter's backward range vs. blockers in 0.10 is exactly what I want, see spoiler section in this post for details.
  
• Unittested the handicap merging to guard against common int overflow. I compute sums of fractions with 64-bit ints, where each fraction has an 8-bit numerator and an 8-bit denominator. Anything with up to 8 merged fractions will not overflow. More than 8 fractions will also work fine when the fractions are sane (e.g., 1/2, 1/5, 1/7, 1/10) and not the awkward edge case stuff from the unittest (101/102 + 102/103 + 103/104 + ...) / n.
  

Backward range

Extend the batter's backwards range for 0.10 as far as possible so that this:
1. Faller falls onto a blocker.
2. Blocker turns faller away during faller's fall.
3. Assign batter to the lander.
... bats the blocker.

Still, this:
1. Walker walks towards a blocker.
2. Blocker turns walker.
3. Assign batter to walker immediately after turning.
... misses the blocker.

I believe that this feels best in multiplayer: When you fall onto a blocker, you can always bat the blocker, whether he turned you during the fall or not. To quote geoo: "Blocker müssen weg!"

Todo for 0.10.0:

• Server should tell 0.9 players that they can't see or can't enter 0.10 rooms.
  
• Draw tipped scales (= the handicap icon) in all resolutions.
  
• Writing long release notes!
  

In later 0.10.x:

• Add replay support for handicap.
  
• File UX bug against the slowly-eating factory trap: Icho wasn't sure whether the chimney was a wall or whether it was part of the trap.
  

-- Simon

[Simon]

All to-dos for 0.10.0 are done. All singleplayer levels are solvable. I expect to release what I have as 0.10.0 during the next weekend, Fri Oct 21st through Sun Oct 23rd.

Caveat: On the next few evenings, I'll test the multiplayer manually yet again. If I hit regression bugs or awkward new issues, I'll spend extra time, and possibly delay the 0.10.0 until November. But I don't think that will happen.



It's been a while for sure. When we played 0.8 on livestream, Icho said "The frog ate my cuber.", and that lead to a quick physics fix into the current 0.9 physics -- in Summer 2017.

-- Simon

[Simon]

And Lix 0.10.0 is released! Let's playtest the handicapping together next Saturday, October 29th.

-- Simon

[Simon]

From IRC today:

17:50 <SimonN> Handicap is popular, it gets more urgent now to support it in the replay format.
17:51 <SimonN> As it stands, replays will play as if there were no handicap. That's mostly okay unless we chose Spawn Delay, then it'll heavily desynch.
17:52 <Flopsy> yes, I support the replays getting support, I use this feature a lot and the replays from the last 2 sessions are no good
17:52 <SimonN> Right, I feel the same, we should fix that soon.

-- Simon

[Simon]

I have loading/saving the handicap from/to replays ready to ship in 0.10.2.

Question: What keyword should I write into the replays for the lix handicap? It's either initialLix or lixInHatch. This makes a difference if Lix ever gets preplaced lix.

Consider a map where you have 100 total lix, of which 2 are preplaced. There will be 98 spawning from your hatches. You choose a lix handicap of 1/2. How many lix do you have?

• 50 lix, because lix-at-start handicap applies to the total number of lix in hatch plus preplaced lix. 100 * 1/2 = 50, and 48 will come from the hatch.
  
• 51 lix, because lix-at-start handicap is really lix-in-hatch handicap. 98 * 1/2 = 49, making for a total of 51 with the 2 preplaced.
  

My first hunch was #1. Reason: If others start with 100, we should obviously start with 50, not 51, when we pick a lix handicap of 1/2. The number 51 would look odd. We then add a rule that the total handicapped number of lix will always be at least the number of preplaced lix. When a map has many preplaced lix, different small fractions for the lix handicap will all lead to equal handicaps with nothing spawning from the hatch, and we accept that as a degenerate case.

geoo considers #2 better than #1. His reason: You'll always have at least one lix to spawn from your hatches, matching the level author's assumption that some lix will spawn from the hatches. There is no need for an extra rule that we can't handicap below the number of preplaced lix; this already follows from #2. In maps where most lix are preplaced, you have finer control. All settings remain meaningful. It's okay if the number 51 looks odd.

I think geoo has the better reasoning here. For clarity, I'll choose lixInHatch as the keyword in replay files, not initialLix or totalLix.

Or does anybody want to convince me otherwise?

-- Simon

[Simon]

I've released Lix 0.10.2 which saves handicap to replays, and plays them back with handicap.

Flopsy: You asked whether it's possible to hand-edit old replays form 0.10.0 and 0.10.1 to add the missing handicap. Yes, here is the format.

First, the example:

+PLAYER 0 Orange Simon
+HANDICAP 0 LixInHatch 19/20
+HANDICAP 0 SkillsInPanel 1/2
+HANDICAP 0 SpawnDelayInPhyus 150
+HANDICAP 0 Score 2/3

Now the details. Look for the player number, 0 in the example. For each handicap type that you want to add to that player, add below the player a line of the form
+HANDICAP playernumber type value
... where playernumber is that player number.

The handicap type in each such line must be one of LixInHatch or SkillsInPanel or SpawnDelayInPhyus or Score, with that exact capitalization: Each word starts with a capital letter, other letters are lowercase, no spaces between words.

The value for most types is a fraction. Enter the fraction as x/y with integers x and y and a normal forward slash / in between.

For SpawnDelayInPhyus, the value is not of the form x/y; instead, it's just an integer. It's the number of physics updates -- not seconds, but physics updates -- of spawn delay beyond when a non-handicapped player spawns. Lix runs at 15 physics updates per second. In the example above, SpawnDelayInPhyus 150 means a spawn delay of 10 seconds. 75 would be 5 seconds. 300 would be 20 seconds. 1800 would be 2 minutes.

You don't have to put all 4 possible lines. You only have to put those lines for the handicap types that we didn't leave on the default non-handicapped value. In particular, when a player plays without handicap whatsoever, that player needs no HANDICAP lines at all.

-- Simon