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

[Simon]

Rant.

When your lemmings die, play exits to postview, and you can't rewind. Many people have reported this bug, and it's still open 3.5 years after.

2020: WillLem, Simon, Proxima, Dullstar, mobius
2023: Crane, Simon, WillLem, Proxima, Dullstar

This is particularly nasty because you don't see it coming. Oh, split-second too late releasing the finger off timeskip? Tough luck, plow through the menu, start play from the beginning and fast-forward to where you want to go. Oh, you want to go to almost the end? Better take extra care to not run into the bug a second time!

Solution is to stay in play, but prevent further physics advances. It's only okay to exit here if I've already won, or if I've nuked.

I'll paypal 200 Euros to whoever fixes this (Edit 2024-05-15: WillLem got it and donated a share to namida), releases code and binaries, and prods namida to include it upstream (whether successfully or not). Never exit an unsolved unnuked level until I exit manually. Caveat: If namida gets the 200 Euros, 100 of them must go to LF hosting.

Every time:

• You promise people to play their levels.
  
• You finally find an hour of free time, and load the level in NL.
  
• You play for 3 minutes.
  
• You run into such a UI problem and resign.
  

It's beyond me how anybody can play under this bug without tearing all hair out. And this sounds familiar: I feel the same about the unfixed zoom bug. The workaround to the zoom bug is to never zoom, and instead play fullscreen on the biggest monitor you can buy. Yes, play fullscreen ... until you run into the exit-on-losing-lemmings bug.

There is also the slippery right-click scrolling, but that is hard to debug (happens under Windows or only under Linux) and hard to fix (freeze the OS cursor?). Again mitigated by big monitor. Not that big of a deal as the other two bugs (exit on losing all lemmings, and the zoom bug), but it aggravates the zoom bug because the zoom bug breaks the alternative scrolling via zoom-out-zoom-in.

Not sure what is 4th-most agonizing bug.

I've told Flopsy in IRC: NL has improved a lot since 2014. Yes, it has. It merely still has a few bugs that lead to dents in office furniture.

I understand that it's hard to make software bearable. I should write about and debug the laggy mouse cursor in Lix. Even the Allegro 5 example for endless mouse movement has that bug. Looks like it's worse on Linux than on Windows. I'm surprised nobody has ranted about that in Lix.

-- Simon

[Simon]

Forwarding all the way to the end is useful. I get to see by how many saved lemmings I fall short of the goal.

Again (as with the zoom bug) I assume that nobody else plays like I do because everybody is already conditioned to avoid running into these things. You can gain serious value here that isn't immediately obvious.

--  Simon

[WillLem]

N.B. I'm posting this with full acknowledgement of the fact that namida has repeatedly stated that he won't be updating NeoLemmix any further than has already been approved and planned. So, this post exists simply because I agree with Simon that this feature ought to be addressed, and I know of several possible fixes - I do not expect namida to act on this, and I'm sure he's more than capable of providing his own code/fixes should he wish to address it himself.

With that said, if namida does approve these changes, I'm happy to offer any help and support where necessary. And if not, he has stated that he's happy for NeoLemmix to be forked anyway, so it's possible that we can continue some sort of "Community Edition" of NeoLemmix using only Community-approved changes/updates such as this one.

I'll paypal 200 Euros to whoever fixes this

Happy to take you up on this! The following will prevent the level from ending when (the save requirement hasn't been met) and (there are no lems):

Code Select Expand


{ add to procedure TLemmingGame.CheckForGameFinished; }

  // Stops levels ending when no lemmings remain onscreen and the save requirement has not yet been met
  if (Level.Info.RescueCount > LemmingsIn) and (LemmingsOut = 0) then
      Exit;


Removing this from the existing code may also work:

Code Select Expand


{ remove from procedure TLemmingGame.CheckForGameFinished; }

  if ((Level.Info.LemmingsCount + LemmingsCloned - fSpawnedDead) - (LemmingsRemoved) = 0) and (DelayEndFrames = 0) then
  begin
    Finish(GM_FIN_LEMMINGS);
    Exit;
  end;


I'm happy to test this in NeoLemmix and work on the feature until it's bug-free and playing nicely, of course.



Meanwhile, SuperLemmix has code for preventing single-lemming levels from ending when that lemming dies. More than happy for this to be used as well. Here it is:

Code Select Expand


{ add to procedure TLemmingGame.CheckForGameFinished; }

  // Stops single-lemming levels ending when 1 lemming has been removed and 0 are saved
  if ((Level.Info.LemmingsCount = 1) and ((LemmingsRemoved) = 1))
  and not (LemmingsIn >= 1) then
      Exit;


(In SLX, this part also checks for Classic Mode, but obviously that's not needed in NL).

[namida]

If code for this is developed and tested by the community, I'm happy to merge it in. If there is significant divided opinion about whether this change is desirable, I will only merge it if it's implemented as an option rather than the sole behavior (being enabled by default is acceptable).

[WillLem]

I will only merge it if it's implemented as an option rather than the sole behavior

This shouldn't be a problem, I'd suggest passing a GameParams flag and checking for this alongside the above code example. Happy to implement this as well.

[WillLem]

(P.S. Assuming Simon is serious about the 200 Euros and I manage to find a fix, I'm happy to donate a portion of it to site running costs )

[namida]

Basically - if you can get a diff file or a git branch or something, or even just a copy of modified files compared to a specific NeoLemmix commit, I should be able to integrate it pretty easily from there.

Implementing an option would also mean making sure it's added in the Options menu and saved in the INI file.

[Simon]

Happy that this gains traction, and that namida is open to merging it back!

significant divided opinion [..] implemented as an option

At least for Lix, I haven't received any reports or any suggestions against this. It's standard and you can't turn it off (i.e., you can't make unsolved singleplayer exit without a keypress/nuke click).

But I display big fat text: "Rewind time (◀▮) or quit with [hotkey]." (Assuming you haven't turned tooltips off.) If you don't display such text, there is serious danger that the physics freeze looks like a bug. You'll have to user-test indeed.

Also, we might find NL edge cases that Lix never needed to consider. Make an option if you can't find a good rule.

Assuming Simon is serious about the 200 Euros

Yes, I'm serious about the 200 euros. I'd be happy if you donate a share to LF. To avoid converting currencies twice, I'll send that share directly to namida.

It's becoming important to specify exactly what's required for the money. Certainly, it's required that unnuked, unsolved levels don't exit. Is it required that nuked levels exit like before? Is it required that unsolved, unnuked, lemming-less levels freeze? Do we count neutrals as lemmings here (probably, unsure)? Do we count zombies as lemmings here (probably not)? Some of these are listed before I wrote "to whoever fixes this", but I repeated only a summary (technically incomplete) in the same paragraph as "to whoever fixes this". I'll post again on the weekend at latest.

-- Simon

[WillLem]

Attached is the relevant modified code for NL, originally taken from the latest commit (f3d92ea33). It will need to be tested for bugs and suitability, of course, but it seems pretty solid after a quick initial test.

it's required that unnuked, unsolved levels don't exit. Is it required that nuked levels exit like before? ... Do we count neutrals as lemmings here (probably, unsure)? Do we count zombies as lemmings here (probably not)?

The attached copy of LemGame will yield the following behaviour:

• If the save requirement is met and all lemmings have been removed*, gameplay ends as usual
• If the save requirement is not met and all lemmings have been removed, gameplay continues (unless the user has opted for gameplay to end when no lems remain, in which case gameplay ends)
• Nuke ends gameplay as usual

* Zombies count as removed lems in NeoLemmix, Neutrals do not - this means that gameplay will end if the save requirement is met and only Zombies remain onscreen, but will continue if any number of Neutral lems remains onscreen (even if the save requirement is met). Since Neutrals can be saved and we are soon to have the Deneutralizer object in NeoLemmix, this seems to be acceptable. However, this can be changed so that gameplay will end if only neutrals and/or zombies remain and the save requirement has been met. I'll await feedback on this first.

* Exited lems count as removed

Is it required that unsolved, unnuked, lemming-less levels freeze?
...
But I display big fat text: "Rewind time (◀▮) or quit with [hotkey]." (Assuming you haven't turned tooltips off.) If you don't display such text, there is serious danger that the physics freeze looks like a bug. You'll have to user-test indeed.

Although it can be achieved easily enough, I'm personally not in favour of a physics freeze; the lem count turns red when too few lems remain onscreen, and shows 0 when there are either no lems at all, or only zombies remaining. This, and the absence of assignable lems, is enough visual information IMHO. Players ought to wonder why gameplay hasn't ended in any scenario other than a pass.

With that said, if people would prefer the game to pause, it can be done.

At least for Lix, I haven't received any reports or any suggestions against this. It's standard and you can't turn it off (i.e., you can't make unsolved singleplayer exit without a keypress/nuke click).
...
Make an option if you can't find a good rule.

The attached copies of FNeoLemmixConfig and GameControl make the behaviour optional (and save the choice to user config) - this seems the best approach for now, and makes testing both behaviours easier.

[namida]

I wonder if the option to not auto-exit even when the save requirement is met, should be added?

In no way is accepting it conditional on any particular behavior here; I just thought it's worth raising.

[IchoTolot]

If the save requirement is met (and all my lems are gone), I personally 100% would like to auto-exit the level.

If I fail the save-req then it is debateable and there an option for exit/not exit would be very nice to have!

[namida]

This could also be an option with three settings: "Never auto exit", "Only auto exit if save requirement met", "Always auto exit".

[IchoTolot]

This could also be an option with three settings: "Never auto exit", "Only auto exit if save requirement met", "Always auto exit".

This sounds like good solution for the issue.

Maybe with the nuke as an exception for the "Only auto exit if save requirement met" setting, as that's a player initiated end.

[Simon]

If the save requirement is met and all lemmings have been removed*, gameplay ends
If the save requirement is not met and all lemmings have been removed, gameplay continues
Nuke ends gameplay as usual
Zombies count as removed lems in NeoLemmix, Neutrals do not
continue if any number of Neutral lems remains onscreen

All of this is good.

unsolved, unnuked, lemming-less levels freeze?

not in favour of a physics freeze
is enough visual information IMHO.
With that said, if people would prefer the game to pause, it can be done.

The freeze isn't only for feedback. It's a strong convenience feature.

The most common case is fast-forwarding into the failed lemming-less state. If NL doesn't freeze here, you'll overshoot. You don't necessarily realize the failed state immediately. If it takes 1-3 seconds of realization, you've overshot by a lot. Instead, freeze, to make it much quicker to rewind to a useful state.

Compare: 1. Web browsers don't let you scroll away from the page, not even half a screen worth past the end. 2. NL already doesn't allow you to rewind to 20 seconds before hatches open. 3. We'll have a button in Lix to quickly rewind to the previous skill assignment: That quickens the rewind to a common desired point. Similarly, 4., you should prevent moving into the useless clearly failed state any deeper than necessary, to quicken the rewind to a desired point.

If you believe that you want to continue into the useless state, I warmly recommend you to try it with the freeze first. If you still want more physics advances after trying the freeze, then it's time to make the freeze optional. Or have you played Lix and wanted the physics to continue?

Marginal use case (for continuing deep into failed lemming-less state): To observe zombie behavior. But even for this, the stars must align for the freeze to be annoying: 1. Zombie behavior must be nontrivial (hard to visualize), 2. zombie behavior must be important, 3. all lemmings have already died. Aligning all three stars sounds rare enough to ignore the use case, or to send the player to the options menu.

Consider to not tie the freeze to the pause button. The freeze can prevent further updates regardless of current speed. This is to avoid clashes with manual pausing. E.g., if NL paused on reaching the failed state, we might pause ourselves, and be a tad late. The two pause commands would then cancel each other.

option with three settings: "Never auto exit"

This sounds like good solution for the issue.

Considerable. But beware of adding options when nobody has wanted it another way yet. Ask Proxima or other challenge solvers. If it's handy for them, you can make a case for such an option.

-- Simon

[WillLem]

All of this is good.

Glad you approve! Testing will likely further discussion around the various specifics of this feature, but we definitely have a good starting point.

The freeze isn't only for feedback. It's a strong convenience feature.
...
The most common case is fast-forwarding into the failed lemming-less state. If NL doesn't freeze here, you'll overshoot. You don't necessarily realize the failed state immediately. If it takes 1-3 seconds of realization, you've overshot by a lot. Instead, freeze, to make it much quicker to rewind to a useful state.

It's possible to check for fast-forward game speed, so maybe we only freeze physics in the event of the player using fast-forward? Otherwise, it feels more natural to simply let gameplay continue (as is the case when Blockers remain, for example).

If you believe that you want to continue into the useless state, I warmly recommend you to try it with the freeze first. If you still want more physics advances after trying the freeze, then it's time to make the freeze optional.

Yes, there's no good reason not to give it a try. I like the idea of it being optional behaviour, as this reduces the need to show a message and allows fine tailoring of this feature by the player, which is important because it's purely a QOL. Incidentally, if we do show a message, a simple "no lemmings remain!" with an OK button should suffice, but a custom graphic could also be considered.

Consider to not tie the freeze to the pause button ... This is to avoid clashes with manual pausing.

I get the point here, but tbh it seems very unlikely that the double pause would happen often enough to warrant the hard physics freeze. A softer "game has paused itself" option seems more preferable, if only because pausing solves the "might look like a crash" problem; it's clear that player input will resume a normal gameplay state - the player can see that the game has paused itself, and simply unpauses to continue. Conversely, a freeze may be jarring enough to have the player quit out altogether on the assumption that the game has crashed.

EDIT: Admittedly, making the freeze behaviour optional and off by default also solves this problem

Happy to try it both ways and see what we think. Thoughts?

This could also be an option with three settings: "Never auto exit", "Only auto exit if save requirement met", "Always auto exit".

Yes, good idea. We could do this as a radio button group with the three mutually exclusive options, and a checkbox for "Pause/freeze game".

At this point, I probably agree with Simon that we should wait to see if it's needed first.



I'll get on adding the auto-pause / physics freeze over the weekend.