Hi,

while I composed today's main issue about about negatively-worded binary options, I thought about how namida and Nepster worded those options in the config file. Then I stumbled onto this bug on the side:

NeoLemmix 12.12.5.

The user options file settings/settings.ini does not persist the option "Don't Replay After Backwards Frameskips". If you check that option during your session, it will be forgotten after the end. settings/settings.ini contains no line for that option. When you run NL for the next time, the checkmark will be gone. During play, then, NL will replay your actions after you've rewound them.

Expected instead: NL writes that option to settings/settings.ini. NL restores this on next session.

(Other options save properly to settings/settings.ini and restore properly.)

Who needs the option to ditch actions from the replay on rewind? I haven't seen anybody ranting about this bug before. It looks like I'm the first to run into it, and I only ran into it during the naming research, not because I wanted to toggle that option. Lix offers a similar option ("Keep replay after rewind") and Forestidia and mobius prefer in Lix the rewind to be an undo. Forestidia feels strongly about this in Lix. Thus, it feels like it makes sense to keep the option. But stay tuned over Christmas for the popcorn on insert-into-replay in Lix.

-- Simon

Hi,

NeoLemmix player version 12.12.5. Here is a screenshot from the interface options. You reach these options from NL's main menu, click the gear icon, then click the interface tab at top of dialog.



I recommend the following rewordings:

Don't Replay After Backwards Frameskip -> Replay after Rewind or Preserve Replay after Rewind. Invert the meaning of the checkmark. Maybe "Keep" instead of "Preserve". Another wording: Cut Replay after Rewind and keep the meaning of the checkmark, but I feel this isn't as clear. I'm not 100 % sure if "rewind" is clear enough if the program calls it "backwards frameskip" elsewhere, but "rewind" is at least popular and short.

Disable Background Images -> Show backgrounds and invert the meaning of the checkmark. Maybe "display" instead of "show"?

Hide Skill Shadows -> Skill Shadows and invert the meaning of the checkmark. A verb doesn't feel as necessary as with "show backgrounds" because the skill shadows feel exactly in the middle between a tool and a graphics option.

Use Spawn Interval -> Show Spawn Interval Instead of Release Rate and keep the meanig of the checkmark as it is now. Or "Spawn rate" if NL prefers that term. I don't have a good short wording. The setting is really only for visuals and has no bearing on physics. Even better: Convert the box into a radio-button option. Reason: It's a choice between two meaningful different things, not a togging of a single thing.

Hide Advanced Options in Level Select -> Show Advanced Options in Level Select and invert the meaning of the checkmark.

This report is more about the UI than about what really ends in the config files. You can remove negative wording in the config files, too, and invert the setting under the hood, or you can merely invert the meaning of the checkbox.

-- Simon

All streams will be at:

https://www.twitch.tv/simonnaar

-- Simon

Hi Proxima,

while streaming lemforum on twitch, Ramond found this backroute 2nd intended route in Rumble to the Bottom.

Spoiler

Idea how to change

Not necessary because Proxima deems it the 2nd intended route.

Lower the floor on which the exit sits.

The cost is that the level will look less than Smile if you love Lemmings. At least you can lower the floor uniformly, not merely dent it where the exit is.

-- Simon

Hi,

Proxima has laid down maintainership of Lix's lemforum level pack.

As long as we don't have a designated maintainer, we'll still work together on the levels, but nobody's word trumps others. I'll glean from the discussions what might be best, and implement that in Lix. Everybody, please speak up if I make odd decisions, and I'll happily do something else in the next version of Lix. Also, if you know lemforum well, you can step up to be maintainer and call the shots!

Lix lemforum is the flagship pack. One possibility is to stabilize lemforum, which means that we'll mostly fix backroutes, but avoid larger level swaps. This is best for speedruns, and it preserves the spirit of the contributions. If Lix gets fancy new features or new levels, we can put those separately from lemforum.

The alternative is to keep cutting weaker levels every now and then, and let lemforum slowly adapt to Lix when Lix gets new features like neutral lix, or new tilesets. This allows us to recommend lemforum to new players as a sample of the state of the art, and still have the vast majority of the content from 2010 to 2012, although not necessarily all of it.

You can mix the two ways to a degree, but they're fundamentally incompatible. I'd like to recommend to new players at least some cross-section of Lix's features and level designers' work. Proxima prefers a stable lemforum that we still recommend to new players as first pack, as we've always envisioned.

It's an amicable parting. I'm sure geoo's and Proxima's handwriting will stay visible on lemforum. Thanks for your contributions! Proxima, you're busy in life, about to get a foot into the door of the software industry. And in Deadly Rooms of Death, you've got a big project on the brink of release. I wish you the best of luck with both projects!

And barge in if we ever screw it up.

-- Simon

Ramond's list of episodes down here in this thread.

All video are preserved for 14 days on his main stream page:
https://www.twitch.tv/paramondox

-- Simon

Hi,

darkshoxx joind our recent Lix session on Saturday, November 26th. I streamed the session to twitch, and darkshoxx also streamed the session to twitch. To familiarize himself with Lix, darkshoxx played Lix singleplayer for an hour before the multiplayer session.

darkshoxx's Lix stream from 2022-11-26
(twitch will delete this on Dec ~10th)

Thanks for the stream! Here's my feedback:

Button caption: darkshoxx played the first level Any Way You Want and reached the end-of-singleplayer screen. The button at the bottom says "Back to the browser". darkshoxx reads the button, and says: "What? It's not a browser. Whatever."

Indeed, the level browser is a level selection first and foremost, and it only happens to be also implemented as a file browser that can browse to every level. I'll recaption the button to "Back to Level Browser" or maybe "Back to Level Selection".



Feedback on winning/losing: darkshoxx played Let's Block and Blow?, which has a save requirement of 19/20. First attempt, he flings several lix to death. Obviously this is wrong, and he resets.

Second attempt, he carefully assigns the exploder to not fling any lix to death. And he succeeds in this goal. This second attempt saves 18/20, it doesn't save the exploder and the blocker. This comes short of the save requirement of 19/20. Since he didn't fling anybody to death, he believes that he's won, nukes the blocker, reaches the end-of-singleplayer screen, and happily moves to the next level.

The end-of-singleplayer screen always presents the next level, even if you've lost. I like this, but it makes winning and loosing look nearly alike on that screen. The only difference are the small numbers at the top left, and the caption "Congratulations! You solved:" vs. "Try again:" over the solved level in the top right. We're all conditioned to not look much at the solved level in the top right.

During play, I'd still like the nuke to exit regardless of winning/losing. I think it would be awkward to pause after nuking a losing attempt.

As annoying as it is to admit: Winning and losing is central to every game, and Lix fails to present it properly. We need better feedback about winning/losing, both during play and during the end-of-singleplayer screen. I have loose ideas, but nothing ready to discuss yet.

---

This third finding is feedback for darkshoxx, it's not for Lix.

You had us in Mumble. At first, your viewers considered us too quiet. You raised the audio output in Mumble, but that didn't affect the loudness of Mumble in your stream. I think you should lower the Mumble audio output back to 100 %, to reduce the chance of audio clipping.

Then you put gain on the Mumble output. We were pretty loud already then, at least as loud as yourself. Then you put gain on the Mumble output a second time. Now, we were very loud, far louder than yourself. When I spoke, we got audio clipping in your stream. Maybe it's the mix of more than 100 % on the audio output, maybe it was from my side, but it ended loud in the stream.

I think a good amount of gain was how much you put on us the first time, before you raised it for the second time, together with Mumble at 100 %.

Or perhaps even slightly less gain than the first time (but still more than nothing)? Then you're at least as loud as anybody on Mumble, and your viewers want to hear you after all.

-- Simon

Hi Proxima,

in 2017, you suggested the following, which is also github issue #376:

Quote from: ProximaIn the replay browser, display the full replay filename under the level name on the right, so that it's easier to distinguish multiple replays in the common case when the default filename does not display in full in the list on the left.

I've come around to implement this. Look at the attached images; they differ in the bottom two lines of the nameplate (= the text between level preview image and the big buttons). I assume that you're still running Lix in 640x480, it's a rather tall resolution at 4:3, leading to cramped horizontal space.

The nameplate abbreviates the beginning of the replay filename, so you can always see the last part of the filename. Compare this with the file browser's listing at the left-hand side of the screen: It abbreviates the end of the filename, as is customary for abbreviating text in general.

Implemented in 0.10.1 is the first attached image: It says "Replay:" in line 3 and has a big arrow for the pointed-to level in line 4.

• Is the first image clear enough about what's the replay file and what's the pointed-to level? Captions are up for discussion.
  
• Does the nameplate show enough of the replay filename? The idea is that for really long filenames, you'll have the browser listing for the beginning, and you'll have this nameplate for the end.
  
• Do you still run Lix at 640x480?
  
• The second image is an alternative idea: Shorten the "Replay:" in line 3 to some single symbol and shorten the pointed-to arrow in line 4 to match the symbol in line 3. Is that better or worse?
  
• Or do both solutions suck and you need something else?
  

-- Simon

Hi,

everybody is busy near the end of the year, therefore I don't want to plan a big multiplayer session on short notice. Instead, let's meet in Mumble for loose discussion ("campfire" or "fireside chat") this Saturday, December 3rd, starting 17:00 UTC. Who's up?



Ideas for the discussion:

• I'm working on writing handicaps into replays, and playing back multiplayer games from replays with the correct handicap. We can test this together before I'll release 0.10.2.
  
• Level reorderings in our flagship pack, lemforum.
  
• Game modes involving neutral lix. Which good ideas can we copy from NeoLemmix? What should be a level option, what should be a property of the goals/exits? At the September 2022 campfire, I discussed this with geoo, but haven't written anything on the forums about it.
  
• Solving levels together on livestream is fun. I had a great time with Flopsy, mobius, and Ramond this past Sunday. Let's do it more often?
  
• Anything you like. Bring your own topics!
  

If you don't have time, no worries: I'd like to have campfire every couple weeks/months. We don't set in stone any plans for development. Important things should go through the forum in any case, giving everybody a chance to comment on plans.

See you in Mumble!

-- Simon

Hi,

namida said in the closed topic Any changes / additions needed in replay?:

Quote from: namida on December 31, 2021, 12:15:26 AM
last-minute idea come up on Discord - saving the frame on which the replay is expected to complete.

Quote from: namida on November 06, 2022, 11:54:13 PM
Commit 6b1bca2 implements this.

Mass replay check will make use of this too. Currently, a replay check will give up and return "undetermined" if 5 in-game minutes have passed since the last action and the save requirement is not yet met. It will now only do this if it's also been at least 5 in-game minutes since the expected completion time, if one is set in the replay file.

What moment will the game choose to write into the replay as completion time?

Sensible candidates:
* When the replay satisfies the save requirement,
* when the replay wins a talisman,
* when the replay wins all talismans,
* when you lose all lemmings.

At the game moment we save the replay, some replays satisfy none of the above. Will the game extrapolate to find a completion time, or will it write nothing? I assume you don't extrapolate. The completion time dosen't seem important enough to compute it at all costs.

-- Simon

Hi,

Consider the following two-player map.

This isn't an exact map from Lix, but the rough shape is common enough in two-player Lix: Player A goes from top-left to bottom-right, and player B goes from top-right to bottom-left.



Let's assume:

• You start at the red hatch, and you're planning a route to the red exit.
  
• You have reasonably many builders, platformers, bashers, miners, and diggers.
  
• Both hatches have steel. You can still attack the opponent's hatch, but that won't decide the match at once.
  
• Your route will cross the opponent's route somewhere.
  

What will be the shape of your route?

Straight Line

You can mine straight from the hatch to the exit. This produces a linear path.

The problem is that your opponent can sabotage this path: He can send lone saboteurs to the !-marked area, destroy the terrain, and drown your lix. It's always easier to destroy terrain than to rebuild it, and you'll lose several lix here. You'll have to invest a lot of attention to the defense of this single area.

It would be even worse to dig near your hatch, then bash across near the water. Your crowd would have to pass close by the opponent's exit, that's a risk in itself, and the sabotagable area over the water will be even wider than in the direct straight line.

Arc

A better approach is this arc-shaped route. You start to go across horizontally. For even more resilience, you can try to get your crowd on top of the trees.

High routes are strong routes: Your opponent has a harder time getting to you. But you yourself can still get down easily enough. If your opponent bashes through your stairs, you fall back to the grassy surface. Even the grassy surface is still higher and safer than the linear diagonal route from the previous example.

Near the exit, the arc bends downward. You approach the exit in a steep slope -- considerably steeper than a miner's slope. This steep slope is resilient:

• You won't splat anywhere.
  
• When your opponent removes some terrain around you, it's okay.
  
• He can't bat you into oblivion, you're well away from the edge of the map.
  

Don't approach your exit perfectly vertically, that will risk splatting. High arcs are good, but if your arc is too high and stretches too far rightward, you'll risk overshooting the exit, and must turn your lix. Whenever your crowd must turn -- be it at a blocker, at a cuber's cube, or at other diggable terrain -- you're vulnerable to sabotage.

As a bonus, the arc allows good access to the opponent's hatch for your saboteurs, but you don't have to send your entire crowd to his hatch.

Most of our custom maps are more complicated than this example. You'll find steel or hazards in the way of your ideal arc, or the level offers only a reduced skillset. You'll have to be flexible, accept some risks, choose tradeoffs -- and that's what multiplayer Lix is all about.

-- Simon

Get the newest Lix:

Download Lix -- for Windows, pick 64-bit version
Source code
Changelog
Issue tracker

Lix 0.10.0 released:





The big new feature: Lix 0.10 offers handicapping in multiplayer games. If you're too strong for your group, consider to click the handicap icon with the unbalanced scales in the game room. You can choose fewer initial lix, fewer skills, a spawn delay, fewer points per lix saved, or any combination of these four handicap types.

It's up to our sessions to fine-tune the options! Let's see what's reasonable and what's less exciting.

Networking:

• The server allows 0.9 and 0.10 in separate rooms. Decide with your friends whether and when to update as a group to Lix 0.10.
  
• Both 0.9 and 0.10 players can chat with each other in the server's lobby. The 0.10 client will see both 0.9 and 0.10 rooms, and print a console error when you attempt to join a 0.9 room. Since 0.9 has no such functionality, the server will not show 0.10 rooms to 0.9 players at all; instead, the server will write a chat message to those 0.9 players in the lobby if any 0.10 rooms exist, suggesting to update to 0.10.
  
• Renamed the server executable from server to lixserv.
  

The networking fixes are the silent star of the show this year. The server will now continue to support older Lix versions (0.9.x) in separate rooms from Lix 0.10. I won't have to force everybody to adopt a new physics release (this 0.10, or a future 0.11, 0.12, ...)

Let's give the 0.10 physics a good shot. Besides handicapping, many small physics fixes made it into 0.10:

Physics:

• Fix #265: Allow simultaneous exiting. When you're playing a race map and reach the exit at the same time as one or more different teams, all teams will score. Before, only the red team would score.
  
• Fix #311: Top and bottom of maps are hollow. Terrain checks beyond those edges will not behave as if the edge row's terrain extended infinitely. Now, only the left and right edges of the level extend terrain in this way, not all four edges. Staircases built to the deadly ceiling will kill the builder as before, but now all following walkers will also leave the level and die.
  
• Allow ability assignments (climber, floater, runner) to blockers. For now, these assignments have low priority; we can raise the priority after playtesting as a UI change without changing physics.
  
• Fix blocker dancing: Now, walkers (and other non-blockers) don't move when they're both in a left-forcing blocker field and in a (different blocker's) right-forcing blocker field. Before, walkers would move sideways through the fields, turning each phyu. This looked like dancing.
  
• Fix #266: Grant batters extra backwards range against blockers. We keep forward batter range vs. blockers as in 0.9, even though it's a lot of forward range so the batter sprite needn't overlap the blocker to still bat the blocker. Nobody has complained so far, and it's nice to bat blockers without awkward precision. We keep the batter range against other activities.
  
• Half-fixed #397: The faller's distance in pixels fallen will not overflow the 32-bit int anymore. I didn't fix the overflow for physics updates yet, you can still play longer than what fits into the 32-bit int that counts physics updates (4.5 years at normal speed, or 46 days at turbo-fast-forward).
  
• Moved the frogs' trigger areas downward by 1 pixel, so that the coordinates are divisble by 2. No levels broke from this, not even geoo's Las Ranas Hermanas in Hopeless.
  
• Fix #410: Removed spike at top of both matt/beach/04 tiles (day and night). Before, both tiles had identical masks; now, both tiles still have identical masks, although the mask is different than before. There is no odd prong at the top right of those tiles anymore.
  
• Fix #414: Fixed transparency/air pixels in earth.png from the Oriental set. The top row of pixels was not fully transparent (that would be 0 % alpha); it had an estimated 5 % alpha. Lix treats that as solid. Walkers were walking over solid, nearly invisible pixels. Now, earth.png has full transparency above the earth. No levels broke from this change.
  
• Fixed #322: Don't wrap during tile group construction: Now, when you load a tile group on a small torus map, Lix will construct the group without wrongly wrapping the group's elements before grouping. Only when Lix has fully constructed the group tile, Lix will insert the group into the torus level.
  

Other:

• Adapted the singleplayer levels Cry for Me (from lemforum), Baywatch (by RubiX), and Walking in a Winter Wonderland (also by RubiX) to work well with the always-hollow ceiling.
  

All levels are proven solvable in 0.10.

-- Simon

Hi,

Flopsy and I have time to playtest Lix 0.10 (it's now released) on Saturday, October 29th, 2022. We can have a big session or a small one, it's no problem.

I still prefer to start at 16:00 UTC, but Icho prefers to later in general. What time of day suits you all? 16:00, 17:00, or 18:00 UTC seem to be reasonable candidates.

-- Simon

NeoLemmix 12.4.4 in Wine 7.15 on x86_64 Arch Linux.

1. I had NL 12.4.4 already set up, it wasn't a fresh installation.
2. I put Armani's pack Lemmings Uncharted inside NL.
3. I played some levels from Lemmings Uncharted, having NL download missing tiles successfully per level.

Then:

4. Run NeoLemmix (or have it already running).
5. In the main menu, click Settings.
6. In the settings dialog, click Style Manager.
7. Optional: In the style manager, click one of the styles to select.
8. Click Update All.

We get an error box: "Division by zero."

9. Click OK (the only button) on that error box.

Now, Download Selected and Update All are greyed out in the style manager. I can only click Cancel. I have not received any new styles that I didn't have in the list before.

See attached video for a demo of this.

---

Expected instead: The goal of the whole operation was to avoid getting the prompt to download missing tiles before every level. NL should fetch all styles from namida's central style collection, or at least everything from that collection that I need for my installed packs.

I have no idea what exactly you want to happen on Update All.

Per-level style download works fine. When I preview a level with missing tiles, NL offers me to downloads missing tiles from the net. When I accept, NL downloads the tiles, then reloads the map. Now, I see the map with all intended tiles correctly.

Fresh installation: The bug doesn't reproduce (or is different?) on a fresh extract of NL 12.4.4 from the big download button on neolemmix.com: Here, when I attempt step 8 in the repro above, I can't click Update All because it's greyed out. All lines (one line per style) are already green in the style manager. But I don't seem to have every style yet in a fresh installation.

I don't see how I can download all styles on a fresh NL installation. What is the intended way to download all styles (from your central style collection) in one shot?

-- Simon

Hi,

this Sunday will be too short a notice for an organized multiplayer Lix session. Instead, let's meet on Mumble for a loose discussion, without playing. I'll call it a campfire discussion.

Possible topics to discuss:

• Physics on 0.10,
  
• user interface for handicap,
  
• neutral Lix, experimental physics to try in December,
  
• really long-term concerns, e.g., level maintenance N years after an author leaves,
  
• general Lemmings culture,
  
• ...anything you like. Bring your own topics!
  

This Sunday, September 25th, I'll sit in Mumble from 16:00 UTC onwards. Join me anytime on Mumble voicechat, very much like you would for a Lix session. (If you don't know my server, send me a private message on the forum here, I'll tell you.)

-- Simon

Hi,

this is the next suitable weekend that suits both Flopsy and me: Saturday or Sunday, October 15th or 16th.

I can play either Saturday or Sunday. What's everybody else's preferred day for that weekend? I recommend to start again at 16:00 UTC, you can join later.

There's a chance that Lix 0.10.0 is released by then. But I'll play it safe and say that we'll be using Lix 0.9.x one more time for this session. (Current is 0.9.47, but any 0.9.x will do.) I'm still aiming to release 0.10.0 before November 2022.

-- Simon

These are the C++-only posts from Simon blogs.

---

Apropos uniform initialization syntax.

I've used C++ for 16 years now and I still don't know every case of where the language guarantees a zero initialization and when it may leave something uninitialized.

Everybody learns early on that this int is uninitialized:

void foo() {
    int a1;
}

And that's about as far as "everybody knows" goes, I'd wager. Only many people, including me, know that these two are zero-initialized (although I'd still add the explicit = 0):

int a2; // at global scope
void bar() {
    static int a3;
}

The design reason behind this is that these ints live in "static land" instead of going on the stack where the zero initialization would cost runtime: The BSS section is a memory region that comes preinitialized for free when the operating system loads your executable and has to copy all of the executable code into memory anyway.

But I have no clue of the following, although I see this occasionaly in the day job, usually in C code that somebody renamed to .cpp later:

void baz() {
    int arr1[5] = {}; // Is anything zero?
    int arr2[5] = {0}; // Are the subsequent four ints also zero?
}

And do those initializations mean something different in C and in C++? Does it depend on the version of the C standard?

Here are some fun ways to initialize a single int, most of which only arise in theory. This is perfectly legal code that compiles. Are they all zero, are only some zero, are they all possibly uninitialized? I don't know.

void blub() {
    int a4{};
    int a5 = {};
    int a6 = int{};
    int a7 = int();
    int a8{int()};
    int a9 = {int()};
    int* p1 = new int;
    int* p2 = new int{};
    int* p3 = new int();
}

The two cases I should look up for definitive clarification are a4{}; and a5 = {};. The others might also be enlightening eventually, but expressions such as int() come up rarely enough that you can deem those esoteric.

And it doesn't end with ints where you have a chance at initializing them explicitly with zero. Occasionally useful in real life: You have std::vector<int> and you want to enlarge it by calling resize(). Does it zero-initialize the new values?

---

I have dark memories of possible nonequivalence of the following. It might be a false memory from early learner days in 2006, but I've never clarified it. Assume X is a class with a custom default constructor, and no other constructors (in particular, X doesn't define a constructor that takes a std::initializer_list). Do all of these run the default constructor? Quick reality check with g++ --std=c++17 tells me: Yes, all of them run the default constructor. But does the language really guarantee it, ever since C++98? I assume so, then...

void blip() {
    X x1;
    X x2{};
    X x3 = {};
    X x4 = X();
    X x5 = X{};
    X* x6 = new X;
    X* x7 = new X();
}

I should really read the standard directly more.

-- Simon

Hi,

On Saturdays or Sundays, what would be the best time of day for you to start a Lix session? Sessions usually run for 2-4 hours after this starting time.

Rampoina suggested: Our current time of 17:00 UTC (European evening) was suitable for him, but he prefers an earlier time of day, possibly right in the middle of European afternoon. For me, it's fine to play in the afternoon instead of the evening, but maybe the afternoon won't work for others?

The poll offers only the hours possible for myself. Happily complain in a post if sometime else is even better.

-- Simon

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

Hi,

Rampoina asked on IRC: Are there replays of two-player Lix games between strong players? How can we learn more about multiplayer strategy?

I've attached two replays:

• Stepping Stones 2v2. It shows a common principle in multiplayer: Higher and faster routes are better. Even though the purple team loses, pay attention to purple's initial relentless attacking of the orange bunch. The orange bunch is weakest while the top route is nearly prepared, but not completely done, and the bunch hasn't yet ascended to the top level.
• A close and eventually drawn endgame at the bottom of the towers: Both geoo and I want to fight for a win in a drawn position. This shows micromanagement of single lixes that have to attack a bunched enemy crowd.

To watch replays:

• Either put them into your replay directory, then navigate there from Lix's replay browser.
  
• Or, on Windows, drag them on the Lix icon.
  
• Or, on all OSes, run Lix with the replay filename as a command-line argument.
  

Ah, if you watch these replays: Lix versions since mid-2021 have a bug: Lix will re-save a watched multiplayer replay, even though you haven't changed it. This is a regression of the new end-of-game dialog. I'll fix this in the next version, 0.9.44.

-- Simon