[SUG] Level top and sides

[WillLem]

clear physics mode was added in response to artistic but difficult-to-interpret terrain and backgrounds, not primarily as a weapon against bad level design.

it's just too darn useful ... is also verging on necessary for some levels

That's what was meant by these comments; I originally elaborated on this to specifically mention its usefulness for unfamiliar terrain/objects/backgrounds, but must've edited it out without thinking.

[WillLem]

So, I was in the middle of fixing some skill shadow bugs (currently, Glider shadow disappears off the side of the level, and Shimmier shadow only works for Climbers* - both of these are now fixed, happily!) when I chanced upon something I'd ideally like a bit of feedback on.

Basically, the "Glider shadow disappearing" bug is caused by lemmings first turning around and then being transitioned to Walker when they reach the side of the level (to simulate solidity). This was done in order to cancel skills like Bashing, Mining and Fencing which would look a bit daft if they turned around and then carried on, but also Building and Platforming to keep them consistent with current wall-encountering behaviour.

Turns out, though, that I should've specified the transition-to-Walker behaviour for only these skills/actions. For most others, it doesn't make sense. In the case of Gliders, it means they then drop again as if walking off an edge, hence the disappearing skill shadow.

The only actions which become debateable, IMHO, are Shimmying and Jumping. When left out of the check, this is what happens:





Personally, I think this is great. So much so that I think it should actually be default behaviour for these actions when encountering any vertical terrain.

Main arguments for Shimmier:

1) Currently, other movement-based actions (Walker, Swimmer, Glider) turn when encountering a wall. So, applying this to Shimmiers would be more consistent

2) They still have Shimmyable overhead terrain

Main arguments for Jumper:

1) Jumping is a dynamic action which requires a quick burst of energy to complete. Applying the "equal and opposite" argument, it feels like they should bounce off the wall

2) Go outside, find a wall and jump towards it (I take no responsibility for any mishaps which may occur if you actually do this!). What do you do?

The third argument for each is the same:

3) Blockers and Forcefields cause this behaviour, so why not walls?

In the absence of any compelling counter-arguments, I'm at least 90% convinced that this is the way to go.



*For anyone interested, this is because Shimmiers can now be assigned to Climbers at any time, so I needed to make a small tweak to the Shimmier shadow handling which resulting in them only working for Climbers. An oversight that was thankfully easy enough to repair.

[jkapp76]

Well, I read the whole thing. I don't disagree.
The shimmier turning around is cool.
I don't think I have an opinion on the jumper bouncing. Seems okay.

If we don't want the jumper bouncing we can just move the walls further away when me make levels, right?
The glider seems good to just turn around if possible.

[Strato Incendus]

Well, there go my hopes of ever converting Lemmings Open Air to Super Lemmix. The water-object changes would have made it a lot of work already. But the pack has so many levels relying on Shimmiers that a bunch of new backroutes might be opened up by this change.

As the reigning "King of Shimmiers" (crowned by Flopsy), yes, I always wanted to be able to turn them around - however, since they didn't turn around on regular walls, I learned to live with that, and instead used one-way fields to turn them around on those select levels where it was needed. And by "learning to live with it", I mean that the way I designed my levels now of course relies on the assumption that Shimmiers will fall down when they hit a regular wall (or slide down if they happen to be a Slider).



I can understand all of your decisions and ideas to alter the physics, both from a flavour- and game-mechanic perspective. Also to set apart Super Lemmix even more from NeoLemmix, so that both engines can serve more and more different purposes, therefore feel less redundant to each other, and maybe encourage more and more players to use both engines in parallel.

However, the cost of this reduced overlap will also be less common content for NeoLemmix and Super Lemmix. The hurdles to convert a pack from NeoLemmix to Super Lemmix become larger and larger, the more physics / mechanics changes are implemented. NeoLemmix and Super Lemmix are indeed twins separated at birth, and the further apart they develop from each other, the wider the gap will become, and the harder it will become for anyone trying to bridge that gap again. Like when converting a pack to serve both "communities"

(Are there dedicated NeoLemmix and Super Lemmix communities yet? Perhaps not, but it might happen eventually. Which would pose a challenge, given how small the Lemmings community already seems to be.)

By itself, that's completely fine. I just thought it's something you might consider, especially since I just found out you made a converter tool, specifically for the purpose of converting NeoLemmix packs to Super Lemmix.



For hyperbole's sake, imagine somebody tried to convert original DMA Lemmings levels into Lemmings 2: The Tribes levels. Even if one only took the Pillar levels, there are enough minor differences in number, both in terms of terrain and object pieces AND in terms of how some of the skills work, to result in a huge hassle for anyone who actually wanted to do that.

The main appeal for me to use Super Lemmix, perhaps even create packs for it some day, are indeed the extra skills. Notably, the Spearer and the Grenader. I guess nobody who has known me for some time on this forum will be surprised by that. It was the same thing that eventually drew me to New Formats NeoLemmix, once its additional skills had been implemented. The culling of features like Radiation and Slowfreeze was something I was ultimately ready to accept for that.

General physics and skill-mechanics changes however are in a different ball park than merely culling an individual object like Radiation or Slowfreeze (especially given how rarely they had been used, even by people like myself, who did enjoy them when they sporadically popped up).

The Freezer already counts as a considerable physics change to the Stoner for me, as does the change of the Laserer's range, as do the changes made to the Shimmier (such as always being able to assign a Shimmier to a Climber). I don't really regard the Freezer as a "new" skill, merely a "different" one - just like the Cuber in Lix.



Just a thought. You probably shouldn't care too much about my opinion here, since I haven't really gotten into using Super Lemmix all that much yet. Which is a shame, because I really want to like it. Especially because it has a bunch of features my earlier self, in the first few years I was on this forum, would always have wanted: Timed bombers making a comeback, even more skills than New-Formats NeoLemmix etc. Super Lemmix should probably be the NeoLemmix version I've been waiting for, for all these years.

But by now, it feels like I've only been through this same thing a few years ago already, when making the shift from Old Formats to New Formats. I don't think I'm ready to make such a big shift again anytime soon.

Sure, if the entire NeoLemmix community effectively turns into the Super Lemmix community, then I might not have a choice in the end. Or people will simply stop playing my packs.
But so far, I doubt that every NeoLemmix player will shift to using Super Lemmix as their new engine. Which is not due to any "flaw" of Super Lemmix in and of itself. It's merely because Super Lemmix purposefully re-adds a few features (like timed Bombers) which the strict "puzzles only and no execution difficulty" faction of the community probably won't enjoy.

[Proxima]

Funny that you should post, Strato -- I was just going to say that WillLem's "consistency" argument reminds me of you!

I don't agree [replying to the OP], because the shimmier is not like the other skills you mention. The swimmer is a permanent skill. When the swimmer hits a wall, it turns around (obviously) and is still a swimmer, so it swims the other way. Similarly with the glider.

The shimmier is a single-action skill that tells the lemming "shimmy as far as you can, then stop and revert to walker or faller". It just makes sense that hitting a wall is something that makes it stop. I don't mean "makes sense" in a hard-and-fast "this is how it must be" way -- if I were new on the scene and the shimmier was already bouncy, I'd get used to it and accept it -- just that even if we were designing the skill from scratch with no existing content, that's the way I would argue for.

As for the jumper, you might have a look at the original jumper physics discussion to see what was said there about whether it should bounce or fall. For me, the main reason against bouncing is that it allows for some really fiddly design, particularly bouncing off a wall to reach a ledge above.

(And what I meant in the Discord when I said "You know what my answer is going to be"... the only behaviour that really makes sense and is consistent, as well as being what the community wants, is deadly edges. Solid edges either allow climbers/sliders to cling onto nothing, or else require those skills to be special-cased. So if you insist on solid edges... it's your project and you do what you want, but don't expect to be able to make everything make sense.)

[IchoTolot]

But by now, it feels like I've only been through this same thing a few years ago already, when making the shift from Old Formats to New Formats. I don't think I'm ready to make such a big shift again anytime soon.

Sure, if the entire NeoLemmix community effectively turns into the Super Lemmix community, then I might not have a choice in the end. Or people will simply stop playing my packs.
But so far, I doubt that every NeoLemmix player will shift to using Super Lemmix as their new engine. Which is not due to any "flaw" of Super Lemmix in and of itself. It's merely because Super Lemmix purposefully re-adds a few features (like timed Bombers) which the strict "puzzles only and no execution difficulty" faction of the community probably won't enjoy.

I think I can give you my vision of what will happen in that regard that mostly overlaps with yours:

- People preferring execution based gameplay will partly shift over to SuperLemmix or the Originals/(Super)Lemmini.
- People preferring puzzle based gameplay will mostly stick with NeoLemmix.

That is also the main reason I am mostly staying out of all SuperLemmix discussion apart from some advice from the sides - It is not an engine made for my preferences, so why should I bother interferring.
At this point I would never shift over again to an engine that forces me to timed bombers and other janky stuff.

The demand for it is there though and as (Super)Lemmini is kinda lacking in features, SuperLemmix has an audience.
That's why WillLem made the right call in my opinion with the project instead of desperate attempts to argue for such changes in NL!

For your packs you must make the call though on what kind of an audience you want to aim at.
I would advice maybe for your old packs (and maybe even other bigger packs in general) to stay with NL and for SuperLemmix make new dedicated ones with focus on using the features only SuperLemmix has!

[Turrican]

Personally, I have a concern, that this change on shimmier physics , may reduce design space for levels/puzzles including that skill!

Currently, there two main ways to stop a shimmier on a ceiling, without the use of a walker. Those are if the shimmier encounters 
a wall or a gap in the ceiling. If reduce them to one (shimmier encounter a gap), I think the puzzle potential of that skill, will be reduced significantly.

Imagine a designer, designing a level , where the terrain will have , several ceilings, so the player, will have to find which ones of these are the correct ones to use shimmiers. So now they will have to add small gaps , on the ceilings , that the shimmiers will be used , and in that way , revealing parts of the solution? And what , if the shape of the terrain doesn't allow something like that?

Also , I think the loss of the "shimmier on a ceiling, arrives to wall, then it slides down that wall" combo , will be a significant one too.

Also in the proposed change , the shimmier, will turn around, if it encounters a wall only , or this will apply , if it also , encounters small obstacles on a ceiling?

[WillLem]

Merged from Jumper & Climber turn & continue when encountering a wall/edge of level - this is because the discussion has ended up covering quite a range of topics, but can be mostly summed up as a discussion regarding level sides physics.



Wow, quite a lot to respond to here, I'll try to be concise in my responses, if not brief! TL;DR version here.

Well, there go my hopes of ever converting Lemmings Open Air to Super Lemmix

On the contrary, it's an opportunity to make a brand new port of that pack, which makes use of SuperLemmix's new features. I'll be converting my own packs (not all of them, but the main ones for sure) and will likely make small tweaks or even huge overhauls to many levels.

If you don't like the idea of having to go through all of that, I'm sure a few people wouldn't mind doing some of the work for you

With that said, this topic is asking if we should go ahead with this change, not stating that we are. I'm still somewhat convinced that this is the way to go, but perhaps less so after reading some of the comments.

I always wanted to be able to turn them around
---
I haven't really gotten into using Super Lemmix all that much yet. Which is a shame, because I really want to like it. Especially because it has a bunch of features my earlier self, in the first few years I was on this forum, would always have wanted:

Pretty much SuperLemmix's raison d'etre; it does the stuff it's better-behaved sibling doesn't want to do! EDIT - I jest here, because I actually would like SLX to be equally well-behaved, just in different ways.

Seriously though, we have an opportunity here to reopen discussions and reconsider some of the possible differences that could make it a full-fledged alternative engine. I personally think that's quite an exciting prospect, but then - as dev - I would!

The packs you've made for NeoLemmix will always be available for NeoLemmix - and, as others have said, I think the two will end up coexisting as alternatives. This gives you an opportunity to either remix your existing content to fit SuperLemmix or, better still, make some new content that leans into the platform-specific features.

set apart Super Lemmix even more from NeoLemmix, so that both engines can serve more and more different purposes, therefore feel less redundant to each other, and maybe encourage more and more players to use both engines in parallel.
---
iHowever, the cost of this reduced overlap will also be less common content for NeoLemmix and Super Lemmix

To the first part of this - yes, exactly! This is ideally what we want. Opportunities to make content for both engines is a good thing.

To the second part - my instinct here is that packs ought to be released for one engine or the other, rather than both. Then, we accept that there will be some cross-compatibility issues with some (but probably not all) levels; I think this is a small price to pay for the possibilities currently on the table. Or, of course, make ports for each engine if time/inclination allows. There are already several packs available for multiple engines, and it isn't really that much work to make it happen, from experience.

Then again, most of my packs are less than 100 levels long - I can imagine a pack as large in scope as one of yours or Flopsy's would be much more difficult to manage for both engines. For that, I would again honestly suggest that you ask someone from the "SuperLemmix community" (should one emerge) to help you out with the port.

I just found out you made a converter tool, specifically for the purpose of converting NeoLemmix packs to Super Lemmix.

Did I? That's news to me! It has its own Editor (which is also based on the NeoLemmix one, but makes several of its own divergences and will likely continue with that trend), but I'm not sure that's what you mean!

I don't really regard the Freezer as a "new" skill, merely a "different" one - just like the Cuber in Lix

Except that it can now be rescued!

I don't agree [replying to the OP], because the shimmier is not like the other skills you mention. The swimmer is a permanent skill. When the swimmer hits a wall, it turns around (obviously) and is still a swimmer, so it swims the other way
---
The shimmier is a single-action skill ... It just makes sense that hitting a wall is something that makes it stop

Yes, good point. This certainly counters the first of the main arguments in favour of turning & continuing.

How about this as a possibility - instead of falling straightaway, the lemming turns and transitions to Dangler. This would then give the player the opportunity to assign another Shimmier, should the need be to keep the lemming Shimmying rather than letting them fall... better, perhaps? I like it less, since it costs more skills, but it feels better than them just falling straightaway with no opportunity to perform another action.

And, to be clear, I still mostly prefer turn & continue despite the given counter-argument, which is certainly compelling. Any more thoughts on this?

For me, the main reason against bouncing is that it allows for some really fiddly design, particularly bouncing off a wall to reach a ledge above

As long as the designer doesn't make it so that the action is only possible on a single frame (maybe this will form part of "SuperLemmix philosophy" - if it can't be done in real-time, it's bad design), I can't personally see this being an issue. Even Save Me allows 2 frames for its infamously pixel-perfect ending. I'd say 3 frames is about right for this sort of thing, 2 is a bit mean but still OK, 1 is bad design.

Also, we have the opportunity to do something different here than what was decided for NeoLemmix. There would be little point in following through on the conclusion of old discussions unless the majority of us happen to think that the right decision was made. Wherever there's any room for doubt, we can try something else.

the only behaviour that really makes sense and is consistent, as well as being what the community wants, is deadly edges

I have to admit, having implemented this change, I can see why deadly edges does make more sense from a design point of view; it's harder to make an edge deadly than it is to make it solid. However, from a player perspective, I mostly prefer solid. There is room for improvement, though, so...

Solid edges either allow climbers/sliders to cling onto nothing, or else require those skills to be special-cased

OK, what if we instead think of the sides as being a "one-way forcefield" rather than a solid wall, then all of the behaviour being discussed in this topic actually becomes what's expected rather than a special case. Moreover, then, we'd let Builders turn & continue as well.

Personally, I'm now preferring this idea to "solid, but not really". Thoughts?

WillLem made the right call in my opinion with the project instead of desperate attempts to argue for such changes in NL!
---
I would advice maybe for your old packs ... to stay with NL and for SuperLemmix make new dedicated ones with focus on using the features only SuperLemmix has!

How ironic that Icho and I are agreeing now more than ever - all it took was the existence of SuperLemmix!

Yes, I echo this entirely. SuperLemmix is there for those of us who want the features that NeoLemmix didn't want*, and content should ideally be made specifically for it, and with its unique features in mind.

*With this said, it doesn't mean that SuperLemmix will bring back everything that was culled/rejected from NeoLemmix! It just means that some of those discussions can be had again, from a different perspective, so perhaps with different results.

Currently, there two main ways to stop a shimmier on a ceiling, without the use of a walker ... if the shimmier encounters a wall or a gap in the ceiling. If reduce them to one (shimmier encounter a gap), I think the puzzle potential of that skill, will be reduced significantly.

Perhaps, but the skill will in turn become more interesting to use from a real-time perspective; it can be used to potentially delay a lemming indefinitely, or have them go for a pickup and then return to where they were, or - now that the Laserer has (effectively) infinite range and we have the Grenader - it could then be necessary as part of the puzzle to create that gap to stop the Shimmier.

Imagine a designer, designing a level , where the terrain will have , several ceilings, so the player, will have to find which ones of these are the correct ones to use shimmiers. So now they will have to add small gaps , on the ceilings , that the shimmiers will be used , and in that way , revealing parts of the solution? And what , if the shape of the terrain doesn't allow something like that?

I might not necessarily be the best person to ask about level design specifics, since I'm the sort of designer that prefers multiple-solution levels and actually likes it when a level can be backrouted (as long as the backroute is still interesting, of course!). But, to offer my two cents on the concerns you've raised here:

- Have gaps on all the ceilings to disguise the intended one
- Use Laserers/Grenaders or send other destructives in from overhead so that the necessary gaps have to be created as part of the solution
- Group pieces to create the required shape if the existing terrain pieces don't quite create the shape you need
- Use a different tileset

EDIT: Also - as will be mentioned later in this post - a Shimmier encountering a vertical obstacle less than 6px in height (but more than 2px) would attempt to traverse it, fail, and fall - so we would still have that way of getting a Shimmier down.

Also , I think the loss of the "shimmier on a ceiling, arrives to wall, then it slides down that wall" combo , will be a significant one too

Agreed, and there's no reason/intention at all to lose this particular behaviour. We could simply make it "slide if they're a Slider, turn otherwise" in the same way that Climbers climb but non-climbers turn.

In fact, consider that pretty much confirmation that, if the proposed behaviour is implemented, Shimmiers will still always prefer to transition to Slider when encountering a wall (and, of course, if they're a Slider!).

The exception to this will be level edges, for which the proposal has now basically evolved into "let's make them into one-way-forcefields rather than solid edges".

Also in the proposed change , the shimmier, will turn around, if it encounters a wall only , or this will apply , if it also , encounters small obstacles on a ceiling?

Yes, this is significant. My instinct is that it should basically be the same as for Walkers - if the obstacle is vertical, and less than 6 pixels in height, then the Shimmier attempts to continue forward, fails, and falls (where they would ascend in the compared situation). If it's 7 or more pixels in height, they recognise it as non-traversable and turn around.

Wow, a nice juicy topic, this one!

Thoughts?

[WillLem]

TL;DR for the previous post:

- Since NeoLemmix and SuperLemmix have now diverged to the point of being very different "siblings", it's worth considering making unique content for each rather than attempting to manage a single pack for both platforms (although both are possible with a little bit of tweaking where necessary).

- Freezers are different from Stoners and Lix Cubers because they can be rescued - a very significant difference!

- "SuperLemmix philosophy" (the idea of which actually kind of gives me the ick, but I suppose is inevitable) is probably that if a level can't be solved in real-time, without the use of helpers/CPM/framestepping/etc, and without pressing pause too much, it's probably a bad level. In fact, many of the changes I've made so far have been geared somewhat towards reducing fiddliness - the Freezer, the Dangler, the extended Laserer range, Classic Mode (which basically renders overly-fiddly levels impossible), Shimmiers-always-assignable-to-Climbers, the list could go on. A notable exception would be direct drop, which even I can admit is sometimes a bit fiddly!

- SuperLemmix development gives us the opportunity to revive old discussions from a different perspective, and perhaps reach a different conclusion (but not necessarily!)

- The proposal is now that level sides be a one-way forcefield rather than a solid wall, with all lemming actions responding to them on this basis

- If the proposed "turn & continue" behaviour is implemented level sides, then Builders would also turn & continue as they would when encountering a Blocker or a one-way forcefield.

- See this new topic for specifically "Jumpers & Shimmiers hitting a wall" behaviour, as this is distinct enough from level sides behaviour to warrant its own topic.

[Strato Incendus]

Did I? That's news to me! It has its own Editor (which is also based on the NeoLemmix one, but makes several of its own divergences and will likely continue with that trend), but I'm not sure that's what you mean!

Well, that's how I first understood some messages I received from jkapp76, who has just taken the initiative to convert both Lemmings World Tour and Lemmings Open Air to Super Lemmix.

I now re-read the first message from him, and realised he only wrote that you "came up with a simple method to auto-update" the levels.
I guess I understood that as having developed a converting tool, but jkapp76 was referring to a solution via Notepad+++.

[WillLem]

Before I go ahead and implement this, does anyone have any specific objections to the sides being one-way-fields rather than simulated walls?

Note: the main difference is that skill actions will turn & continue rather than turn & cancel. The affected actions are Jumper, Shimmier, Builder and Miner. All other actions either turn & continue anyway (e.g. Swimmer, Glider), are cancelled by turning (e.g. Platformer, Fencer), or are static (e.g. Stacker, Laserer).

Note also: the proposal here is just for level sides, not for actual terrain walls. That discussion is still being had here.

[WillLem]

OK, since there have been no replies, I'll go ahead and implement "sides-are-one-way-forcefields".

We can trial it for now and see what we think. If we like it, then we'll keep it - if not, we can always change it back to either solid or deadly, depending on majority preference.

Implemented in Commit 1353eaa81 - note that this also removes the line "Transition(L, baWalking)" which is what caused the Glider shadow to disappear when the sides were simulated solid

[WillLem]

Revisiting this one again after a few top-of-level bugs have been found. Let's review what's going on with level-edge physics in SuperLemmix so far:

Bottom edge is a deadly void, as in all Lemmings games (if not most games in general). This is as expected and will not change in SLX.

Left and right sides are forcefields; a lemming encountering a side edge will respond to it the same way they would respond to a Blocker or a One-Way-Field. So far, I think this is working nicely and is actually the best of all possible behaviours, with horizontal wrap being a very close second. It's likely that SLX will keep "sides are forcefields" from now on.

So far so good. Only the top edge remains something of an issue:

Top edge is currently a pseudo-"forcefield", in that there isn't actually a horizontally-oriented forcefield in the game, and so SLX code must treat all lemming actions separately and decide what to do based on the action, the surrounding terrain layout, and various other factors. There are some inconsistencies (e.g. Jumpers can leap out of the top of the level, whereas Ballooners are nudged downwards by the "forcefield"), and despite my best efforts to nudge, turn and cancel any actions which result in a lemming accessing the topmost pixel of the level (and thus disappearing from view whilst remaining level-active), it is still possible to glitch one's way up there given enough skills and determination.

The code is also a mess; it's become necessary to factor in "Lem is at Y=0" when deciding whether or not to allow skill assignment, and the top-of-level checks are much more verbose than I'd like them to be.

So... I'd like to try the idea of always deleting the topmost row of pixels from the level. Effectively, the top of the level would then always be visible, and so it would be fine for lems to access it; we'd have no need for disallowing skill assignments (except Builders, Stackers and Freezers), and it would greatly simplify the "top is forcefield" behaviour generally. The aesthetic effect is also barely noticeable.

Let's give it a try in 2.8 and see what we think. Comments are welcome as always, and if people don't like the idea it's very easy to revert back to existing behaviour.

[namida]

Rather than deleting pixels that actually exist, consider expanding the level height by 1 pixel (a blank row at the top). You could even take this a step further and prevent this row from actually being displayed.

[WillLem]

Rather than deleting pixels that actually exist, consider expanding the level height by 1 pixel (a blank row at the top).

It's a good idea, and did occur to me initially as well, but it's much more cumbersome to achieve. Adding 1px to the height of the level is easy enough, but that pixel gets added to the bottom, not the top. It's then necessary to shunt every piece down 1px, and adjust the game window & internal height values to account for the added pixel (i.e. to prevent the need for vertical scrolling by 1px on 160px-tall levels). Even then, it's still necessary to delete the top pixel because pieces that extend above the level still fill that pixel after having been moved down.

Anyways, I did try doing this, but with limited success. I began to not like how much code had to be messed with to get it to behave and so opted instead for simply deleting the top pixel. It's much easier, touches less code, and achieves essentially the same thing.

You could even take this a step further and prevent this row from actually being displayed.

Perhaps I've misunderstood, but wouldn't that defeat the purpose of expanding the level by 1px? The point would be so that the blank row is visible, so you can see the lems' feet at the top of the level: