Author Topic: [SUG] Level top and sides  (Read 2749 times)

0 Members and 1 Guest are viewing this topic.

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
[SUG] Level top and sides
« on: May 12, 2023, 03:10:43 PM »
Cheshire Cat and I are becoming very familiar recently, what with all these rabbit holes I keep going down...

Found this old thread discussing whether the sides of levels should be solid or deadly. It seems that opinion was very divided, but deadly sides "edged it" in the end and that's what we have now.

Personally, I think neither are that great. If there's an opportunity to do something different with the physics, then all options ought to be considered (for example, ccexlore mentioned wrap physics being a better option, and I agree at least as far as the horizontal sides are concerned).

I don't want to go over everything that was mentioned in that topic (have a read of it, it's interesting), but to summarise my own thoughts: sides shouldn't be solid, because we can't see what's making them solid and it seems a bit odd and unexpected. But, neither should they necessarily be a deadly void into which the lems can vanish. Ideally, the only way to leave a level should be through the exit. IMHO, this is definitely true for the sides, somewhat true for the top, and perhaps less true for the bottom.

The top edge is a tricky one: it shouldn't be inexplicably deadly, but nor should it be solid. Lems should be able to exist where they can perceptibly exist - but then, that means allowing them to walk across the top of a level. I've had a look into this and done some tests, and actually, allowing lems to exist at Y = 0 isn't as much of a travesty as you might think; the cursor finds them, and we can tweak things so that only relevant skills are assignable (it can of course also be that all skills are assignable); at the absolute least, we want Jumpers and Projectiles to be able to complete their arc and return into the level, even if we were to keep the top edge inaccessible in all other cases. This needs much more thought/testing, but I'm generally in favour of allowing this particular mechanic rather than having lems inexplicably turn around, or just disappear.

The sides is easier - these should wrap around; my own preferred depiction of this would be out one side, in the other rather than infinite scrolling, but neither is out of the question. I can already get lemmings to continue skills across the boundary when going from the right side and coming back in to the left side (the other way around doesn't work for some reason). However, the program crashes, which means that there are probably a lot of internal "no lemmings outside of the level" checks that are preventing the behaviour from being implemented in the way that seems to make most sense to me. Hopefully, these checks can be either relaxed or removed entirely, this remains to be seen.

The bottom edge is the one I'm least sure about; if we leave it deadly, then it's a contradiction of everything I've said in this post, but it also definitely shouldn't be inexplicably solid. Maybe it should wrap around to the top...? Not sure about that - wrap actually seems to make less sense vertically.

So, this conundrum sparked another idea: what if the lemmings who leave the sides of the level simply return to the entrance hatch, and re-spawn from there? This reinforces the "exit is the only way out" logic, but is perhaps less immediately intuitive and has the potential to cause confusion. It could also cause indexing issues (I've already had problem with non-assignable lems when attempting to do this), so it wouldn't be a walk in the park from a programming POV either. But, it's an idea which could work.

Thoughts?
« Last Edit: July 21, 2023, 10:44:18 PM by WillLem »

Offline jkapp76

  • Posts: 373
    • View Profile
Re: [SUG] Level top and sides
« Reply #1 on: May 12, 2023, 04:09:45 PM »
I always thought of the lemmings world like a rectangular fish tank. If they slip through a crack or fall out the top they are lost, out of the game.

But, I have always thought the ceiling should be raised. This would fix projectiles and allow builders to do more. I'm personally not a fan of wraparounds.
« Last Edit: May 14, 2023, 12:34:43 AM by WillLem »
...Jeremy Kapp

Offline Simon

  • Administrator
  • Posts: 3860
    • View Profile
    • Lix
Re: [SUG] Level top and sides
« Reply #2 on: May 12, 2023, 04:22:00 PM »
Teleporting to the hatch sounds unnatural, and it raises several design questions about the queue of lemmings that await spawning.

From which hatch do you respawn? Presumably hatches continue to spawn in round-robin order? Does the lemming respawn as a separate event (immediately, thus in addition to what spawns according to release rate) or does it respawn according to release rate? If according to rate, do you insert the teleported lemming as next-to-spawn, or queue it at the end? Should puzzle designers rely on this? I'll have to lure this climber to the edge of the map exactly between physics updates x and y, or after this other floater reaches the edge of the map, otherwise the climber will respawn from the wrong hatch.

Will lemmings respawn even while we're nuking? The nuke normally sets lemmings-still-in-hatch to zero.

Wrapping left/right is more natural, but that doesn't say much because the hatch-teleporting feels unnatural. Forced wrapping introduces backroutes similar to how direct drop has lured designers into leaving backroutes. Use with care.

You might extend the level dynamically once you get close to the sides or the top. Expensive to implement on top of existing engines, but sounds quite natural. What kind of terrain should appear during the extension? Always air? Or always a duplicate of the outermost row/column? Raises subtle design questions, e.g., what to do when people extend so far as to overflow the integers.

-- Simon
« Last Edit: May 14, 2023, 12:34:51 AM by WillLem »

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides
« Reply #3 on: May 12, 2023, 05:18:11 PM »
I have always thought the ceiling should be raised. This would fix projectiles and allow builders to do more.

You might extend the level dynamically once you get close to the sides or the top. Expensive to implement on top of existing engines, but sounds quite natural

Interestingly, I've just been out for a walk and thought of this exact same thing; why not just increase the height & width of the level dynamically as a lemming gets close to it...! I actually really like this idea.

If there's a way to get the theme background colour and apply it to the surrounding border, then that would prevent the appearance of awkward bump-ups as the level size increases. It also avoids the various pitfalls of horizontal wrap (although, I do still like this idea - maybe it could be designer-side optional).
« Last Edit: May 14, 2023, 12:56:20 AM by WillLem »

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides
« Reply #4 on: May 13, 2023, 04:23:16 AM »
Still investigating the possibility of dynamically increasing the level size when a lem reaches the edge...

For now, the top is simply no longer deadly. Jumpers and Projectiles can complete their arc, and it's possible to walk across the top of a level and assign certain skills (any skills which have a completely invisible effect - such as Laserers, Bashers, Builders, Stackers or any other upward-only skill, cannot be assigned).

Meanwhile, the sides are solid for the time being. I slightly prefer it to them being deadly, and if I can find a way to make wrap do-able, I'll likely implement it as an editor-side feature.

It's a work in progress. Watch this space.
« Last Edit: May 14, 2023, 01:31:09 AM by WillLem »

Offline kaywhyn

  • Global Moderator
  • Posts: 1846
    • View Profile
Re: [SUG] Level top and sides
« Reply #5 on: May 13, 2023, 06:26:58 AM »
It's tough, because there's a lot of inconsistency with whether the level boundaries are solid or deadly among the engines/platforms, and even between the various formats of NL, with the exception of the bottom, as that's deadly in any engine, except if the wrap gimmick was active. For example,

Very Old Formats NL (v1.43n-F or earlier)

- All level sides are solid, and the bottom was only non-deadly if the wrap gimmick was active. For examples, see Strato's Lemmicks pack, third rank IIRC for wrap

Old Formats NL (v10.13.18 or earlier, but after v1.43n-F)

- Left and right boundaries are deadly, but the ceiling is solid. I remember one level from Pit Lems I got stuck on because I forgot about this.

New Formats NL (v12 players)

- All level boundaries are deadly


For Lemmini and SuperLemmini, they're both just like very Old Formats NL in that all level boundaries except the bottom are solid.

I grew up with the Dos version, and the ceiling and left boundary are solid. I'm not certain about the right boundary, though I want to say it's solid just because the ceiling and the left boundary are, but one can't automatically assume this just from that.

I'm not certain about the other ports, such as Genesis, Amiga, etc.

I'm indifferent as to whether any boundary other than the bottom are solid or deadly, though I think I more prefer boundaries are solid. For them to be deadly seems more of an inconvenience and annoyance as another way for lemmings to die, though them being solid can result in really bad backroutes even if the intended route doesn't use them. However, because of the inconsistencies among the engines as to whether the boundaries are deadly or not, I too would simply avoid dependency on the boundaries when designing by simply putting stuff in the way so that they cannot be reached and therefore one doesn't have to wonder whether they're solid or deadly.

Keep up the great work on this, WillLem! All the work you've poured on SuperLemmix looks great and ace! :thumbsup: 
« Last Edit: May 14, 2023, 12:35:35 AM by WillLem »
https://www.youtube.com/channel/UCPMqwuqZ206rBWJrUC6wkrA - My YouTube channel and you can also find my playlists of Lemmings level packs that I have LPed
kaywhyn's blog: https://www.lemmingsforums.net/index.php?topic=5363.0

Offline Proxima

  • Posts: 4562
    • View Profile
Re: [SUG] Level top and sides
« Reply #6 on: May 13, 2023, 11:19:17 AM »
I grew up with the Dos version, and the ceiling and left boundary are solid. I'm not certain about the right boundary, though I want to say it's solid just because the ceiling and the left boundary are, but one can't automatically assume this just from that.

I'm not certain about the other ports, such as Genesis, Amiga, etc.

DOS and Mac have a solid left boundary and deadly right boundary. Since the Mac version is pretty close to Amiga mechanics, in cases like this where DOS and Mac are the same then I'd guess Amiga is also the same.

This behaviour is almost certainly unintended, but I don't remember if we ever determined for certain what it was intended to be. Since the manual states that lemmings die if they fall into the "miasma" outside the level area, I would guess that the intention was for all sides to be deadly.

Genesis infamously has a solid ceiling, forcing quite a few terrain adjustments in NL conversions of the levels (including Redux). Not sure about the sides though.
« Last Edit: May 14, 2023, 12:35:42 AM by WillLem »

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides
« Reply #7 on: May 13, 2023, 11:52:07 PM »
Quote from: kaywhyn
I'm not certain about the other ports, such as Genesis, Amiga, etc.

Quote from: Proxima
Since the Mac version is pretty close to Amiga mechanics, in cases like this where DOS and Mac are the same then I'd guess Amiga is also the same.

On the Amiga, the left and right sides are both solid. I wonder whether that's why the level designers made the levels with loads of space either side; it's possible that there wasn't a way to make the sides deadly, or maybe it was buggy to do so, so they opted instead to just place the level stuff in the centre so that the edges would never be reachable (effectively making the sides deadly)?

The top is interesting: it stops Builders about 4px from the top, and they transition to forwards walkers (so, no turning around). From that point, it's not possible to assign Builders at all, whilst Bashers and Miners can be assigned but have no effect on the surrounding terrain (all other skills remain assignable and effective).

It isn't possible on the Amiga to walk across the top of a level either; climbing to the top of the posts in Fun 17 / Taxing 6 results in the Climber stopping at the top and falling back down (facing in the opposite direction, incidentally).

At the moment, I've made the sides solid in SuperLemmix because I simply prefer it to them being deadly, and in the absence of a non-buggy way to dynamically increase the width of a level (which is looking more and more unlikely the more I look into it), I'll probably keep it this way.

The top I'm less sure about. I did actually consider the idea of stopping all upwardly-oriented skills 1 or 2px from the top (and make them unassignable from that point, similar to the Amiga version). The problem is that it leads to inconsistencies with Jumpers* & Projectiles, which is what led on to experimenting with the idea of allowing lems to exist at Y = 0.

I actually quite like the idea of allowing lems to walk across the top of a level if it happens to be accessible, but I can absolutely see how it could cause all sorts of issues backroutes and/or badly-designed levels which require action to take place above the level, so I've mitigated it by limiting skill functionality to downwards-oriented skills only (Jumpers and Projectiles count because of gravity).

I also started to think that a better way to manage it would be for the engine to remove 1px of terrain from the top of all levels, so that the lems walking across it are at least partially visible. Then I thought... no, that's not a great idea because it's the engine modifying people's levels, which is a route I'd rather not go down.

Does anyone know which ports allow above-level access? I know there is at least one, I just don't know which it is.

Quote from: kaywhyn
because of the inconsistencies among the engines as to whether the boundaries are deadly or not, I too would simply avoid dependency on the boundaries when designing by simply putting stuff in the way so that they cannot be reached and therefore one doesn't have to wonder whether they're solid or deadly

Yes, this is a better way to think about it from a level design point of view, definitely. We have multiple ways of making sides behave however you want them to behave (even ceiling water is a thing now!)

Quote from: Proxima
the manual states that lemmings die if they fall into the "miasma" outside the level area

Which manual? I'd like to see that!



*It is possible to stop Jumpers in the case that they have a terrain pixel at their X position, and are themselves positioned at Y = (0 or less); this effectively prevents Jumpers from accessing the top of the level (they fall vertically back down at this point, as if they've hit a vertical wall above the level), and is a decent enough fallback if we decide not to go ahead with "lems can access the top of the level" behaviour.
« Last Edit: May 14, 2023, 12:38:54 AM by WillLem »

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides
« Reply #8 on: May 13, 2023, 11:57:46 PM »
I did think of one other idea regarding all this today, not sure how popular it will be though...

What if the sides become exits???
« Last Edit: May 14, 2023, 12:36:10 AM by WillLem »

Offline namida

  • Administrator
  • Posts: 12398
    • View Profile
    • NeoLemmix Website
Re: [SUG] Level top and sides
« Reply #9 on: May 14, 2023, 11:55:18 PM »
Quote
On the Amiga, the left and right sides are both solid. I wonder whether that's why the level designers made the levels with loads of space either side; it's possible that there wasn't a way to make the sides deadly, or maybe it was buggy to do so, so they opted instead to just place the level stuff in the centre so that the edges would never be reachable (effectively making the sides deadly)?

On DOS (and presumably Mac), the right side of the level gets cut off by 16px compared to Amiga - resulting in levels being 1584px wide on DOS but 1600px on Amiga. Perhaps the physics still expects the right boundary at 1600, but the pixels beyond 1584 become non-solid? This is purely guessing, though.

I also vaguely recall the sides acting solid for a walker but deadly for a climber in some port. I don't think DOS has this behavior; possibly Master System?
My Lemmings projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides
« Reply #10 on: May 16, 2023, 02:25:00 AM »
OK, after a few days pondering this, I've reached some decisions about what should happen at the top and the edges.

Essentially, I'm going to try to emulate the behaviour of the Amiga version as closely as possible, since I've aimed to do that elsewhere in the engine and it makes sense to follow suit here. This is at least until I can figure out how to dynamically resize levels, which I can't see happening anytime soon.

So, the sides are now solid - simple, and the DMA levels can be resized slightly to make reaching the edges impossible wherever necessary.

The top is different: it's open, but access to the top is restricted as much as possible. It took many cups of tea, several walks and a couple of long baths for me to reach this decision, but in the end I think it's the right way to go. I'm generally not in favour of the engine itself backroute-fixing levels for the designer, so that isn't actually what swung it.

The eventual decision is based on 3 factors:

1) Lems are not visible when walking across the top of the level, so even though they are accessible, the gameplay no longer feels intended - it really does feel like an overlooked engine bug, and one which detracts from the game's aesthetic considerably.
2) Classic Mode's deactivation of skill shadows would make this scenario basically unplayable, and I don't really want to implement anything that would ruin the experience of playing in Classic Mode.
3) It's not possible to access the top of the level on the Amiga version. This last reason holds less weight than the others, but is good enough as reassurance that I've made the right decision.

So, here's how it works:



This image shows the top-of-level checks that are needed in order to prevent lems from accessing the top of the level (but without killing them, and without turning Builder lems around). The green blocks represent terrain, the blue line represents the starting position of the lemmings.

The red line is Y = 0. Any lemmings whose Y positions reach this line will turn around to come back the way they came. The first terrain block shows an edge case where the terrain is arranged in such a way that ascenders are able to reach Y = 0. If this happens, the lem simply walks back along the 1px-high platform and drops back into the level. For the duration of them being at this position, no skills are assignable to that lem except permanent skills (which have no immediate effect anyway).

The Builder bridge shows the lem's position when they place the final allowed brick - from here, they walk forwards from the end of the bridge, as per Amiga behaviour. Platformers, Stackers and Freezers can be assigned from this point, but Builders can not. The reasoning here is that Freezers and Stackers are generally meant to turn lems around anyway, so expected behaviour is upheld by the terrain checks mentioned above, whilst Platformers will simply continue forward at the same pixel as the top Builder brick.

The vertical green block to the right of the above image shows where Climbers check the top of the level. Any higher than this allows Climbers to transition to Hoisters, which is generally unproblematic in itself but I think that simply Falling is better, and mimics Amiga behaviour anyway. If the lemming is also a Slider, they will slide back down as expected.

Meanwhile, here's the special case of Jumpers at the top of the level:



I've always thought that Jumpers (and Projectiles) should continue their arc and land back into the level if there is no perceptible obstacle in the way. So, that's what now happens!

The first arc is self-explanatory enough, whilst the second arc is only slightly more complicated; the Jumper will land on top of the terrain, but since it's now at Y = 0 the above check will kick in, turning the lem around - they will then fall back down facing away from the wall unless they're a Slider, in which case they'll slide their way back down.



Unfortunately, the only ways to completely guarantee no above-level access are to make the top deadly or to have the engine always remove the topmost row of pixels at Y=0 so that there is never terrain at this point to be walked over. Both are heavy-handed and undesirable solutions to the problem. I personally prefer the approach of fixing it as far as is sensibly possible, and letting level design deal with the rest.

Thoughts, comments and suggestions welcome. SuperLemmix is in very much a state of fluctuation at present, and my mind has been changing a lot on things over the past week, so it's a good time to speak up if you have any thoughts to share on this.
« Last Edit: May 16, 2023, 02:33:54 AM by WillLem »

Offline jkapp76

  • Posts: 373
    • View Profile
Re: [SUG] Level top and sides
« Reply #11 on: May 16, 2023, 04:06:10 AM »
I like the sound of all this myself. I have nothing negative to add.
...Jeremy Kapp

Offline mobius

  • Posts: 2747
  • relax.
    • View Profile
Re: [SUG] Level top and sides
« Reply #12 on: May 17, 2023, 12:43:43 AM »
imo this is a decision up to the game designer. Good arguments could be (and have been) made for all cases. Particularly with the jumpers and throwers, this is a case imo where the ceiling being open or deadly makes equal sense to me, so I would have no strong opinion in the matter at present.

Also Idk if I ever said this elsewhere but I always found the "lets design our game in such a way to discourage bad level design" frankly a bit of a weak argument for anything. Only to a point does this work. People will and can always find a way to make bad content. People aren't forced to play their content. Content makers should not be the major deciding factor for how the game is designed imo.
everything by me: https://www.lemmingsforums.net/index.php?topic=5982.msg96035#msg96035

"Not knowing how near the truth is, we seek it far away."
-Hakuin Ekaku

"I have seen a heap of trouble in my life, and most of it has never come to pass" - Mark Twain


Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides
« Reply #13 on: May 17, 2023, 02:51:07 AM »
Content makers should not be the major deciding factor for how the game is designed imo.

I agree, but more from the angle that the game shouldn't try to fix backroutes. What might seem helpful to one user ends up being inhibitive to another.

Meanwhile, I do think bad level design ought to be discouraged, but not to the point that it's made outright impossible (or even pointless - aka Clear Physics*). Newcomers should be given the opportunity to explore different ideas and find out what works and what doesn't for themselves.

*I've seriously considered removing Clear Physics from SuperLemmix, but it's just too darn useful. It reveals all, and so is the ultimate spoiler, but is also verging on necessary for some levels. The best I can do for now is relegate it to hotkey-only.
« Last Edit: May 17, 2023, 02:56:13 AM by WillLem »

Offline Proxima

  • Posts: 4562
    • View Profile
Re: [SUG] Level top and sides
« Reply #14 on: May 17, 2023, 03:43:09 AM »
It's worth remembering that 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.

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides
« Reply #15 on: May 17, 2023, 05:18:57 AM »
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.

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides
« Reply #16 on: June 03, 2023, 03:22:07 AM »
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.
« Last Edit: March 10, 2024, 12:22:11 AM by WillLem »

Offline jkapp76

  • Posts: 373
    • View Profile
Re: [SUG] Level top and sides
« Reply #17 on: June 03, 2023, 03:46:12 AM »
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.
...Jeremy Kapp

Offline Strato Incendus

  • The King of Shimmiers (crowned by Flopsy ;D )
  • Posts: 1747
  • #RIP Spearer/Grenader (2020 - 2021)
    • View Profile
Re: [SUG] Level top and sides
« Reply #18 on: June 03, 2023, 11:26:57 AM »
Well, there go my hopes of ever converting Lemmings Open Air to Super Lemmix. :evil: 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. :crylaugh:

Sure, if the entire NeoLemmix community effectively turns into the Super Lemmix community, then I might not have a choice in the end. :evil: 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. :P
My packs so far:
Lemmings World Tour (New & Old Formats), my music-themed flagship pack, 320 levels - Let's Played by Colorful Arty
Lemmings Open Air, my newest release and follow-up to World Tour, 120 levels
Paralems (Old Formats), a more flavour-driven one, 150 levels
Pit Lems (Old Formats), a more puzzly one, 100 levels - Let's Played by nin10doadict
Lemmicks, a pack for (very old) NeoLemmix 1.43 full of gimmicks, 170 levels

Offline Proxima

  • Posts: 4562
    • View Profile
Re: [SUG] Level top and sides
« Reply #19 on: June 03, 2023, 01:36:59 PM »
Funny that you should post, Strato -- I was just going to say that WillLem's "consistency" argument reminds me of you! :P

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.)
« Last Edit: June 03, 2023, 01:48:24 PM by Proxima »

Offline IchoTolot

  • Global Moderator
  • Posts: 3608
    • View Profile
Re: [SUG] Level top and sides
« Reply #20 on: June 03, 2023, 01:38:41 PM »
Quote
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. :crylaugh:

Sure, if the entire NeoLemmix community effectively turns into the Super Lemmix community, then I might not have a choice in the end. :evil: 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. :P

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!


Offline Turrican

  • Posts: 339
    • View Profile
Re: [SUG] Level top and sides
« Reply #21 on: June 03, 2023, 02:46:35 PM »
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?
« Last Edit: June 03, 2023, 03:30:18 PM by Turrican »
My Youtube channel ( Turrican Lemm )  :
https://www.youtube.com/channel/UCYGFBOHdYITHlsqa203Tu8Q

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides
« Reply #22 on: June 04, 2023, 01:35:16 AM »
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! ;P 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! ;P

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! :crylaugh:

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! :lemcat:

Thoughts?
« Last Edit: June 05, 2023, 03:53:01 PM by WillLem »

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides (plus Jumper & Shimmier behaviour)
« Reply #23 on: June 04, 2023, 04:13:48 PM »
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.

Offline Strato Incendus

  • The King of Shimmiers (crowned by Flopsy ;D )
  • Posts: 1747
  • #RIP Spearer/Grenader (2020 - 2021)
    • View Profile
Re: [SUG] Level top and sides (plus Jumper & Shimmier behaviour)
« Reply #24 on: June 06, 2023, 05:38:16 PM »
Quote
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+++. ;)
My packs so far:
Lemmings World Tour (New & Old Formats), my music-themed flagship pack, 320 levels - Let's Played by Colorful Arty
Lemmings Open Air, my newest release and follow-up to World Tour, 120 levels
Paralems (Old Formats), a more flavour-driven one, 150 levels
Pit Lems (Old Formats), a more puzzly one, 100 levels - Let's Played by nin10doadict
Lemmicks, a pack for (very old) NeoLemmix 1.43 full of gimmicks, 170 levels

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides (plus Jumper & Shimmier behaviour)
« Reply #25 on: June 06, 2023, 05:45:45 PM »
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.
« Last Edit: June 09, 2023, 08:03:32 PM by WillLem »

Offline WillLem

  • Moderator
  • Posts: 3348
  • Unity isn't sameness, it's togetherness
    • View Profile
Re: [SUG] Level top and sides (One-Way-Fields for level sides)
« Reply #26 on: June 09, 2023, 08:05:14 PM »
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
« Last Edit: June 09, 2023, 09:07:35 PM by WillLem »