Don't exit on losing all lemmings (feature development)

[Simon]

was anything else happening besides the lemmings falling offscreen? Any trap animations it needed to wait for?

The level was your end-of-game test (some Crystal bars, 1 neutral, 1 zombie). No traps. The zombie was alive. The last dying lemming was regular (not the neutral; the neutral was already dead).

I'll need to add a check for the nuke specifically here.

Okay, cool, happy to re-test then.

-- Simon

[Simon]

Advantages for pause: it doesn't look like a bug
all advantages into one feature

The buggiest-looking behavior is now after unpausing in the dead state. During dead state, you're gimping the frameskips because that's the only way you can bring the pause to support real-life patterns (extrapolate current state to end of time and see by how many lemmings we come short).

There is a nasty long-term issue here: 5-10 years down the road, NL's maintainer X (neither you nor namida) gets a bug report from player Y: The frameskip after the pause is broken. This will be a perfectly nice bug report against what you've considered to look less like a bug. It's easy for X to fix, breaking the guarantees that you've added.

The pause itself looks well-defined. The freeze also looks correct with the message.

I'd even bet that anything with a message (pause or freeze) will look more intended than anything else without such a message (pause or freeze).

-- Simon

[WillLem]

The buggiest-looking behavior is now after unpausing in the dead state. During dead state, you're gimping the frameskips

Fair point.

anything with a message ... will look more intended than anything else without such a message.

Agreed; this does reduce the "looks like a crash" issue with the freeze, to the extent that from a programming point of view I'd actually much prefer to go with freeze rather than pause: much less potential for bugs, and it touches far less code. Pause, meanwhile, needs to have checks in a number of different places in order for it to behave well (and, as you've pointed out, it remains somewhat mischievous).

A majority of people seem to prefer pause, according to the poll results so far. As a player, I much prefer it.

I'll look for ways to streamline the Pause code, and try to remove the need to nerf the forward frameskips. There may even be a way to make use of both freeze and pause - freeze until the player has manually inputted something (so, no automatic overshooting with large/held skip hotkeys - keydown/keyup would help here), then pause - that could work.

[Simon]

people seem to prefer pause, according to the poll results so far.

Because you've framed the question.

"Pause - that way, I can decide" -- you can decide even if we implement the freeze, because the freeze is optional anyway. Also, tasty swizzle: Who wouldn't want to decide.

"Also, it looks less like a bug/crash" -- we've both realized today that the current designs (of freeze and pause) have bug-lookingness the other way around. Feels like you're straw-manning the current (2024-02-23) freeze implementation with an early idea of the freeze that had no message.

"Freeze - [...] I'll only ever need to" -- that's a powerful nudge away from this option. Who has had the time to try both experimental variants? If you haven't played both, why should you waive your rights (by picking this option) to instead of being allowed to "I can decide"?

Even I am not sure if I ever need to bypass! E.g., nuke and zombies.



There is more to write about zombies and nuke. Either later tonight or these days. Exciting design ahead!

There is more to write about false dichotomies. Across both experimentals, you already have a 7-way option here (3 radio buttons + 1 freeze radio button, and 3 out of those 4 listen to the checkmark), with at most 2-3 of the 7 useful in practice, and now you're making such polls based on two unfinished designs. Put them both into git as two branches and see.

There is more to drill out of you here because you like the pause even after all of this. Again, later.

-- Simon

[WillLem]

Because you've framed the question.

OK, I've removed the poll.

Ultimately, you've offered to pay for this feature so I'm happy to go ahead with whatever version of it you prefer.

You prefer freeze, so let's go with that; it's much easier to work with from a programming point of view anyway. I'll proceed with that version unless anybody else strongly wants pause, and cares enough to make a post specifically requesting it. Freeze is already better than exit anyway, and it's what people are used to from Lix.

Let's move on.

Ah, a nuked level in general freezes now (when everybody has exploded and even if no zombies exist), and doesn't exit. I believe it should exit, as it did in your pause experimental. Or do you have a new reason to freeze here?

I can't seem to reproduce this. Nuked levels exit as usual...

[Simon]

No worries with the poll; thanks for it, it helped me second-guess all this.

The poll said 4:1 in favor of the pause. I can't blame every single one of the 4 pause answers on the framing, and you preferred the pause before the poll.

My worry is now: If we make the freeze, but don't nail it perfectly, yes, we'll still be better than quitting, but we aren't as good as pausing (for a reason that I don't see yet). Are the pause wanters worried about a concrete reason? Are the pause wanters worried about a possible reason that might exist? Are you worried about this? What are the reasons?

Do you (or others) have time to hop on Mumble tomorrow, Monday, 19:00 UTC?

Ah, a nuked level in general freezes now (when everybody has exploded and even if no zombies exist), and doesn't exit.]

I can't seem to reproduce this. Nuked levels exit as usual...

You are right, I can't reproduce this either. Sorry, I don't remember why I wrote this, either. Consider it fine, and If I ever find anything like it, I'll post full instructions to reproduce it in the future.

There is more to write about zombies and nuke.

Regardless of freeze or pause, there is the decision if there is something of interest still happening. For this, we don't treat zombies as interesting.

Now I believe: Zombies become interesting once we are nuking. As a result, the nuke prevents the pause/freeze when only zombies remain. When everybody (regular, neutral, zombies) is dead, we quit. Reworded: In the decision if there is something of interest still happening, we test for regular lemmings alive, or neutrals alive, or traps eating, or nuke.

The fun part will then be: During the freeze with only zombies left alive, can we nuke? We won't advance to the tick in which the nuke is actively preventing the freeze. >_>;; In Lix, during the freeze, the nuke becomes a button to exit.

-- Simon

[WillLem]

My worry is now: If we make the freeze, but don't nail it perfectly, yes, we'll still be better than quitting, but we aren't as good as pausing (for a reason that I don't see yet)

To be honest, I'm at the point where I feel we just need to make a decision and run with it.

I failed to persuade you (i.e. the person who originally requested this feature and has offered to fund it!) that pause is better. I also now see that freeze is both easier to manage and (much) easier to debug.

So, I've pretty much done a 180 on wanting pause. I know I can do it if it's requested later, but for now I just want to get the "no lems" feature stable and ready for release.

After a lot of deliberation and testing of the new behaviour, I'm even beginning to think that the physics freeze shouldn't be optional. The choice should be: exit to postview, or freeze the game. Allowing gameplay to continue into an unplayable state has the potential to be very confusing. If I get no feedback on this, I'll likely run with it and remove the option.

Incidentally, we can also re-use the minimap message code for other "unplayable states": only Blockers remain (and no Walkers in skillset), only Neutrals remain, only Zombies remain (debateable), etc - obviously, game doesn't freeze in these examples, but the message can be displayed if we wish.

Do you (or others) have time to hop on Mumble tomorrow, Monday, 19:00 UTC?

Potentially, yes. I'll move a few things around and see you then.

Ah, a nuked level in general freezes now

I can't seem to reproduce this. Nuked levels exit as usual...

You are right, I can't reproduce this either. Sorry, I don't remember why I wrote this, either.

OK - wierdly, I can now reproduce this bug!

It's fixed; the end-of-level check now factors in nuke. However, I'm now seeing possibilities to streamline and simplify these checks further. It won't make a difference up front, but the whole thing should be easier to debug.

During the freeze with only zombies left alive, can we nuke?

At the moment, no. All controls except for backskip and restart have no effect.

Incidentally, in NL, nuking zombies causes the level to immediately exit to postview anyway: we don't get to see the zombies explode. I fixed this in SLX, happy to apply the fix in NL as well.

We won't advance to the tick in which the nuke is actively preventing the freeze

Correct - although, we can allow this by specifically calling the update procedure if the nuke is activated, thus cancelling the freeze state. Note: we could even cancel the freeze state with pause, thus achieving both freeze and pause in the same feature...?

In Lix, during the freeze, the nuke becomes a button to exit.

This is a good idea; I've added this by setting the nuke flag to true and calling the update procedure for nuke button/hotkey iff the unplayable state has been reached. Bit of a hack, maybe - there's probably a better way to achieve this same thing. Note: we can't call for Game.Finish because it needs a reason, which is undeclared in GBSP.

[Simon]

Do you (or others) have time to hop on Mumble tomorrow, Monday, 19:00 UTC?

Potentially, yes. I'll move a few things around and see you then.

All right, cool. If 19:00 UTC is hard, I can make 18:00 UTC or 20:00 UTC or 21:00 UTC. Let me know by the afternoon what's best, or hop on IRC tomorrow.

Everything else, I'll come back to it later, but it all sounds excellent and promising!

-- Simon

[WillLem]

I can make 18:00 UTC

Earlier is better

[Simon]

Minutes from the Mumble session.

Nobody has wished to continue into the dead state explicitly. Still, some people might want to do it (e.g., watch zombies walk?), but a prominent possibility to continue into dead state is confusing on its own. The freeze avoids this particular confusion, let's try it. If somebody really wants to continue into the dead state, we'll implement an option to neither freeze nor quit when no lemmings remain. The freeze is too useful to weaken it for the presumably rare wish to continue.

That means we choose the freeze over the pause to make a first PR against NL. That's because the pause would fiddle with too many assumptions of other speed controls. Nonetheless, neither of us wants to hammer any decision in stone here. NL can get additional solutions or improve on the freeze should the freeze suck.

Nuke will always prevent the freeze. Nuke will lead to quitting to postview. If you nuke with zombies, you'll see the zombies explode before exiting to postview. If you've already reached the freeze, the nuke will either exit to postview if no zombies exist, or unfreeze to show the zombies exploding, then exit to postview. (Technically: Activating the nuke forces NL to start another physics update despite the freeze. Without zombies, that extra frame of water/exit animation isn't shown then, not even during fade-out, nice.)

This design accepts that precise nuke solutions need manual pausing to prevent exiting to postview. It sounds practical because nuke levels are rare, and it doesn't worsen the user experience in nuke levels compared to 2023 NL. The fireworks take a few seconds, you have plenty of time to pause.

It would be nice if the freeze can work even if NL fails to load the graphic for the message on the minimap, e.g., when people update by putting only the NL executable into an existing NL tree. Our main worry is that the freeze will then look buggy. We have some ideas, possibly a once-per-NL-session dialog box, but no solution seems perfect. WillLem will ask namida what namida prefers for a PR here. Do others have a suggestion?

-- Simon

[WillLem]

I've now uploaded Version 4 of the NeoLemmix 12.13 Experimental, implementing changes discussed with Simon plus a few others.

Please do check it out and offer feedback as the features in this experimental are likely to make it into NeoLemmix, so it would be better if they've been fully tested and discussed prior to final implementation.

[namida]

I will also note that if we're still on 12.12 when this feature is ready, I'm quite happy to release it as a minor update if it merges (or cherry picks) fairly cleanly. If not it will need to wait for 12.13.

[Simon]

Thanks to both of you for pushing this!

I'll be busy until Monday. During that next week, I'll stream more contest levels with that experimental version 4, and I'll test offline in addition. Thus, expect detailed feedback in roughly a week.

-- Simon

[Simon]

Playtesting stream: This Wednesday, March 13, starting 18:00 UTC. https://www.twitch.tv/simonnaar

-- Simon

[Simon]

The stream will stay up for 14 days:
https://www.twitch.tv/videos/2089736199

00:01:00: I dumped the exp 3's config into the exp 4, then played without looking at the exp 4's options dialog. NL freezes both if won (wrong) and if lost (correct). But if we look into the options dialog, the middle option (Exit to Postwiew if Save Requirement Met) is selected. This doesn't match what we just saw in play. To make the game obey the middle option, I clicked the middle option (that was already chosen), then clicked OK. Now, play correctly froze after losing, and play correctly exited after winning.

00:04:40: It still overshoots by one frame.

Sometimes it doesn't overshoot. In particular: If it has already overshot once, then we rewound, and we haven't quit to menu since the overshooting, then it doesn't seem to overshoot.

00:05:00–00:10:00: The nuke works as designed: It always exits to postview, regardless of the 3-way option. Good.

Much later, in kaywhyn's Fun Teleportation Race in Space:

02:00:45: If you win with the final lemming that goes into the exit, and there are no more lemmings, and you don't run into the overshooting bug, NL tells you: No more lemmings, rewind or quit. NL won't quit here even though I've won; NL even shows 0 flagpole left to save. I've played this with the option: Exit to Postwiew if Save Requirement Met.

-- Simon