It's too early for me to tell for sure. I might be able to make both or none of the dates, I suspect Saturday is more likely to work than Sunday, as I might be travelling on Sunday, but again, can't say for sure.
So I suggest you pick based on everyone else's preferences, and (as usual) I'll join if I can make it. Would love to try to the new handicap with more players.

Thinking of another possible approach (somewhat based on Simon's idea using planes) - let's suppose I can come up with a list of prerequisites (eg. face A must be rendered before face B, face B and C must both be rendered before face D) - what is generally the most efficient way to translate these requirements into an ordered list? Keeping in mind that two faces may be neutral with regards to each other, but a third face might need to be drawn inbetween them (eg: A and B have no order preference to each other, but A must be drawn before C while B must be drawn after C).

The next keyword to websearch from there is: Topological sort, or directly on wikipedia. (Starts to sounds like geoo or another computer scientist could have pointed us there much quicker. )

Yep, that's exactly what I suggested a couple of posts ago x_x

Anyway, if you do want to do face sorting properly, it seems to me if you're doing pairwise comparisons for intersection like Simon is suggesting, you can then piece it together into a linear order by building a graph (the nodes are the faces, the edges are when a face is partially obscured by another face), and then doing a topological sort. (Note that in practice you might encounter cycles in this graph, e.g. if you have 3 triangles where each one obscures but also is obscured by another one.)

But back to Z-buffering and the Z-fighting issues that you had when using that approach: Why don't you make the blocks a tiny bit smaller (not enough to be visible, but enough to avoid z-fighting due to rounding errors) than a full grid unit?

They need some polish before they can be released:

- Title
- Decision on how far to shift the exit from the start (unless you want to include all possible versions)
- Release rate that doesn't perfectly cluster the bunch
- Some mechanism to prevent plugging up other players' climber chutes
- Overtime

The main problem here is around determining the order to draw block faces and other 3D-space elements in. Due to how L3D levels can have multiple block faces in the same position, a Z buffer is not an option - this leads to an awful level of Z-fighting, and can also lead to lemmings' graphics disappearing inside blocks when they're close to a block face (especially deflectors). Instead, we need to determine what order to draw the block faces in. (Optionally, we can also work out which ones don't need to be drawn at all, due to being outside the viewing area. However, not doing this only results in a performance penalty, not glitches, so this is not critical.)

I want to have a look at this problem, but I think I need some clarification to understand the issues with using a Z buffer (which then also affect face sorting):

• How is block faces in the same position an issue? I can see that happening when there are two adjacent blocks, but then their touching faces are obscured by other faces of these blocks and therefore not visible, so this seems to be a non-issue (also, in that case you see the front of one of them and the back of the other, so if you're doing back-face culling, you'd only draw one of them anyway. Note: If you compute the normal vector of a face so that it points out of the front side rather than back, you can determine whether you see the front or back face of the triangle by computing the scalar product of the normal vector with the vector where the camera is pointing, and skip drawing the back faces. Are you doing back-face culling, and if not, maybe it improves your results already?).
  
• I assume, as Simon is suggesting, lemmings are simply a quadrangle with a texture (that has some transparency)? If you have Z-fighting between a lemming and a terrain surface, couldn't you just always prioritize the lemming whenever the difference between the distances is very small (i.e. possibly caused by a rounding error)?
• Are there other instances of Z-fighting to consider?
• If you do have instances of Z-fighting because of faces being in the same location, then it seems to me that moving from Z-buffer to face ordering just moves the issue from pixel-level to face-level, i.e. on one frame you might see texture A, and in the next texture B.

Anyway, if you do want to do face sorting properly, it seems to me if you're doing pairwise comparisons for intersection like Simon is suggesting, you can then piece it together into a linear order by building a graph (the nodes are the faces, the edges are when a face is partially obscured by another face), and then doing a topological sort. (Note that in practice you might encounter cycles in this graph, e.g. if you have 3 triangles where each one obscures but also is obscured by another one.)

As for the comparisons (of say a convex polygon P and Q), I think the following should work assuming no cycles and intersecting faces:

• Compute the projections of P and Q into the viewing plane. Then check if these 2D polygons intersect. (I had this for pairs of triangles as a programming exercise once, it's a pain. It's not hard, but just a lot of cases. You could probably find this for pairs of triangles somewhere on the internet, and reduce the quadrangles to triangles. Or just check the bounding rectangles and hope for the best...) If they don't intersect, you're done: Don't add an edge to the graph, you can draw them in either order.
• If they do intersect in 2D: take an arbitrary intersection point (in the interior), compute the original points in P and Q that they are projections of, check which one is closer to the camera, and add an edge accordingly.

If you do have intersecting polygons, then either of them could end up on top with this strategy. (And of course, you will still have issues with cycles as well.)

I was looking up how people resolve this, and found Newell's algorithm, outlined in the last comment here: https://stackoverflow.com/questions/58367851/how-to-sort-these-lines-with-painters-algorithm

Basically, it does the sorting in a smarter way to resolve cycles along the way, and replaces my second point with the following (technically it adds more checks, but these are just for optimization):

• Are all points of P on the same side of the Q-plane, or are all points of Q on the same side of the P-plane? If either is true, you can determine which one is closer to the camera: e.g. if the points of P are on the same side of the Q-plane, and the camera is on the same side as well, then P is closer to the camera than Q, and you have to draw it later. (Otherwise it's the other way around.)
• If neither of the above holds, split the polygons.

Interestingly, even after all the conditional checks in Newell's algorithm where it decides to split the polygons, we still cannot conclude that P and Q intersect in 3D (I found a counterexample, see attached GeoGebra file).
Hopefully this should be rare, so instead of implementing splitting, maybe you can hope it doesn't happen

If you're implementing multiple handicap options rather than a single score, and you're planning to implement a separate menu anyway, what is the purpose of using divisors rather than simply specifying the exact number of lix/skills/spawn delay in that menu? That seems much cleaner as you know exactly what you'll get, and the UI is the same.

Also, I hope "skill handicap" is configurable per skill and not a blanket handicap, as I think adjusting all skills with the same factor/addition is going to be pretty useless 99% of the time.

If you do implement such a dialog, I think it could actually be integrated quite nicely with the single-score handicap that is determined by the level author as I proposed above:
In the special menu, you can select a handicap level (say via a slider, and all the options that you see adjust accordingly), but you can also manually modify the individual handicap stats (then the slider displays '?').
The aggregated handicap level (or '?') could then be shown in the lobby. This offers the advantages from both approaches: Full customizability of all stats, but also level-author handicap levels which will be more convenient for players that are less familiar with a given map.

I've also thought about how Ultimate Chicken Horse does handicap: Players can only nerf themselves (i.e. no positive handicap), and the handicap is essentially a score multiplier. I'm not sure the former limitation is necessary in lix, but I think a score multiplier might even be more powerful than e.g. adjusting the number of lix or any of the other options individually, and probably the only one that could somewhat stand on its own in most maps.


One other remark: So are you prioritizing handicap over neutral/pre-placed lix? While I certainly think the former is useful, I think it's only relevant to some sessions, and there are various temporary workarounds, while I think the latter opens up a lot of new gameplay potential for any kind of session.

I played Outdoor and Beach (except for Beach 1, because for some reason there was a different level there): https://www.youtube.com/playlist?list=PLJNO01n86P6LXjn6NNxy1EYVWc9LtCYFu
A lot of backroutes again, I think.

As for comparing to QFK2, I think the execution is harder here, but finding the solutions is a bit easier because the levels tend to be a bit more open-ended. Then again, I'm mostly finding backroutes so far, so maybe once they are fixed, it'll be a bit harder.

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.

Here's a Lix-related logic puzzle (which I haven't solved yet):

You're building a N-player level where each player has M hatches.

The hatches are arranged into a grid of M rows and N columns. But the player order is wrong!
You need that in each column, all hatches belong to the same player, and in each row, the hatches spawn lixes at the same time.
You don't want to move the hatches around (error-prone), but you can fix this by changing the priority of a few of them.
How many hatches do you have to click to be guaranteed to be able to sort this out, regardless of the initial arrangement?

About priorities: If my hatches are ordered 1, 2, 3, 4, 5, and I decrease the priority of #4 down to 2, the priority of #2 and #3 gets increased by 1 each, giving 1, 3, 4, 2, 5.
If the players are A, B, C and the hatches per player are A1, A2, A3, then the hatches are ordered
A1, B1, C1, A2, B2, C2, A3, B3, C3
1   2   3   4   5   6   7   8   9

Example: N=2, M=2.
A2 B1    3 2
B2 A1 or 4 1
If I increase the priority of A1 to A2, I get
B1 A1    2 1
B2 A2 or 4 3
So clicking one hatch is sufficient. Is one hatch sufficient for every starting configuration for N=2, M=2?

Remark: This is from a real example where I was trying to build a level, and clicking hatches was expensive as they were buried under eraser terrain, which had to be removed first to access the hatch.