Quote from: namida on May 28, 2026, 10:50:30 PMRather than just disregarding it for existing levels, could they be padded / shrunk accordingly?

Yes, but I see no reason to support this engine-side. It'll be up to level designers/maintainers to manually fix any affected levels, which I imagine will number very few anyway.

If it turns out that there are in fact a large number of affected levels, it may be possible to add Editor-side support, where levels would be automatically resized (and pieces moved) if necessary to accommodate the difference. However, there would have to be more than just a handful of affected levels to make it worth pursuing this.

Quote from: Nessy on May 30, 2026, 02:29:50 AMHey everyone!

I made a post under Destination a couple of days ago and wanted to make one here real quick. Thank you everyone once again for playing through my first pack and thank you for all the replays and comments I'll hopefully be checking them out soon.

It's pretty surreal to think that I made this level pack almost a decade ago. I remember being so nervous to share it.

There's probably a lot of backroutes, but honestly, these days I love seeing what crazy solutions other people are able to come up with on a level with the available skillset, instead of trying to force "one way" of doing it. I guess there are some exceptions, especially if a level is too overly broken, but it happens haha.

hi nessy I played your pack on RetroLemmini and really enjoyed it

I'm currently thinking about a possible progression system for Fizzles and would like to get some feedback.

The basic idea is to keep the core gameplay the same: each level still works like a classic Fizzles rescue level. Fizzles spawn, walk automatically, and the player assigns available abilities to individual Fizzles when needed.

The difference would be a new layer around the levels.

Instead of every level always giving the player a fixed set of abilities, the player would earn points by completing levels. These points could then be assigned to abilities before entering certain special levels, called instances.

For example:

* A normal level gives points depending on how many Fizzles were rescued.
* These points are not consumed.
* Before entering an instance, the player distributes the available points between abilities such as Digger, Climber, Floater, etc.
* The instance only shows the normal rescue goal at the beginning, for example: 10 Fizzles / rescue 5.
* The player does not know in advance which abilities are needed.
* While playing the instance, the player may discover that a Digger is needed to progress.
* If the current ability setup is wrong, the player can leave the instance without penalty, redistribute the points, and try again.
* Later in the same instance, the player might discover that several Climbers are also needed.
* The player can again leave, adjust the ability setup, and return.

So the gameplay loop would be:

Play levels → earn points → assign points to abilities → enter an instance → discover what is needed → adjust setup → solve the instance.

Normal levels and instances could both be replayed. A level would not give endless points, but could offer a limited number of points based on rescue performance. For example, rescuing the minimum number of Fizzles gives 1 point, rescuing more gives 2 points, and rescuing all Fizzles gives 3 points.

The goal is not to turn Fizzles into a complex RPG, but to add a light progression and preparation layer while keeping the actual level gameplay simple and familiar.

The main question is:

Would this kind of system make the game more interesting, or would it feel like unnecessary extra management between levels?

Nice to meet you too JawaJuice! Thanks for the kind words

It honestly fills me with a lot of joy to see a lot of new faces, and even some older ones, still enjoying the world of Lemmings even after 35 years!

Hey everyone!

I made a post under Destination a couple of days ago and wanted to make one here real quick. Thank you everyone once again for playing through my first pack and thank you for all the replays and comments I'll hopefully be checking them out soon.

It's pretty surreal to think that I made this level pack almost a decade ago. I remember being so nervous to share it.

There's probably a lot of backroutes, but honestly, these days I love seeing what crazy solutions other people are able to come up with on a level with the available skillset, instead of trying to force "one way" of doing it. I guess there are some exceptions, especially if a level is too overly broken, but it happens haha.

QuoteI've played a lot of these levels before but it was fun to play through them again and refresh my memory. The main stuff I hadn't played was the majority of 92Dexter11's Lock & Key levels and a few from LDC 32. Overall, lots of ingenious design and you can definitely see why everything has been nominated for LOTY 2025 - worthy contenders all! Good luck to everyone!

By and large, there's nothing particularly easy here! On the contrary, it makes for a challenging pack! I will say that aside from Armani's and Guigui's input, which I already knew, the levels from Lock & Key are comfortably the hardest ('No Looking Back' especially), occasionally utilizing quite obscure tricks but more often than not, just non-obvious solutions that take a very long time and lots of trial and error to figure out! 'kaywhyn's Organic National Park' gave them a good run for their money though; had me stumped for ages, that one!

Thank you for your kind words. I would also like to echo your statement about the lots of ingenious designs for all of the other contest finalists - there are some really amazing levels here, good luck everyone!

QuoteI'll attach all of my replays and maybe the respective authors can let me know if I've discovered any unacceptable backroutes!

For my levels, the 'Lemmings Faithful' have no intended solution, although I would have to commend you for saving all the neutrals in 'Diamond in the Rough' - that replay blew me away when I saw it!

As for the 'Lock and Key' levels, all the solutions are intended, except for 'The Split' and 'Epilogue'.

The Split

For 'The Split', the backroute is pretty major in context, although for the purposes of the contest, I suppose it's fine. (The gimmick behind 'Lock and Key' is that it's intended to be a narrative with continuity, e.g., if the lemming is assigned a glider in one level, he'll start as a glider in the next level, but this context isn't relevant for the contest so it's fine here.) I'll have to release an update for it at some point later.

Epilogue

For Epilogue, the solution is very impressive and uses all available skills. Backroutes aren't really as relevant for this one, since in context it's the final level of the pack. Either way, it's fine for the purposes of the LOTY contest too!

Rather than just disregarding it for existing levels, could they be padded / shrunk accordingly?

The next version of RetroLemmini (most likely 3.1) will no longer support variable level boundaries.

It's currently possible to set the boundaries to anything, but the default values are the only ones that actually make sense, at least from an engine maintenance point of view. Allowing them to be set to anything (particularly the top boundary, the physics for which is notoriously difficult to perfect) just causes unnecessary problems.

Furthermore, whilst variable boundaries might be a fun thing to experiment with, it's unlikely to produce any particularly good levels.

So, let's go ahead and set these values to defaults program-wide. Then, I can address the top-of-level physics properly and make sure there isn't anything unintended happening.

This topic is to provide users, creators and maintainers with an opportunity to voice any concerns or add to the discussion at this stage, before the next version is released.

Your silence = this will go ahead as planned, any levels affected by this change will be disregarded.

This bug has brought about the question of whether levels should be able to mess with the level boundaries. Personally, I see no good reason to allow this. It's most likely a hangover from support for some early level format or something, i.e. it seems unlikely to be a desired and intentional physics feature.

I'm tempted to strip variable level boundaries out of the code (the Editor doesn't support it directly anyway), and maintain the default boundaries for all levels. This will make it much easier to then tighten up top-of-level physics.

As it stands for now, I've gone ahead and committed the Builder fix (i.e. Builders now always stop building at Y=8, making it practically impossible for a lemming to reach Y<8), but will soon come back to the top-of-level stuff later, likely in a separate topic.

This one can be considered resolved, then.

Fixed in RLPlayer commit f142f69.

Confirmed.

This is happening because of a clash between these physics rules:

1a) The level must specify a top boundary of 0 or greater, with 8 being the default if none is specified
1b) In the level provided by hrb264 (attached here), the boundary is set to 0, so lems can build all the way to the top of the level
2) If a builder lemming is at or above the top boundary (usually 8, but 0 in this case), they will stop building
3) If a lemming encounters an obstacle that is too tall for them to step onto or their y-position is less than or equal to 8, they turn around - the latter of these conditions is symptomatic, which is the source of this bug

The first and foremost fix is to stop lemmings from building when they reach the default top position. This is easy, and fixes hrb264's example level/replay.

Preventing lemmings from repeatedly turning (which is what traps them at the top of the level if they reach a certain height) is harder: what should the condition be, and how can we make sure the fix doesn't create side effect bugs of its own?

It's too hot to think about this right now. I'll come back to it later.

---

P.S. I've also attached a level (Top of Level Test) which makes it possible to reproduce the bug:

1) Allow 1 lemming to walk up the stairs (contain the others with Blockers). They will turn around before reaching the thin platform and begin to walk back down the stairs
2) From the stairs, have them build up to the platform. The platform will stop them, they will turn around, step into the thin platform, and continuously turn around

If we can prevent this, the bug will be fixed for all levels, regardless of any other factors.