[SUG] Level top and sides

[WillLem]

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" (pun intended) 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?

[jkapp76]

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.

[Simon]

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

[WillLem]

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).

[WillLem]

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.

[kaywhyn]

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!  

[Proxima]

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.

[WillLem]

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

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. It would mean directly modifying the level, but it may be the best way to allow top-of-level access whilst keeping the lems in sight and assignable. Maybe something to try another time.

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

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!)

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.

[WillLem]

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???

[namida]

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?

[WillLem]

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.

[jkapp76]

I like the sound of all this myself. I have nothing negative to add.

[mobius]

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.

[WillLem]

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.

[Proxima]

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.