[SUG] Steel is always steel, even if it's partially behind terrain

[WillLem]

I really can't decide on this one...

I made a very silly video a few years ago (back when my beard was huge!) which more or less sums up the problem I have with "steel is only steel when it's visible" - basically, despite it being a much more consistent way to handle steel areas in a level (I can fully admit that it removes the need for CPM in all but the most trollish and/or visually unclear levels), it's also very unintuitive to anyone who isn't yet familiar with this particular steel behaviour.

Moreover, it also doesn't prevent steel from being used in a trolly way; it's still possible to make steel pieces that don't look like steel, terrain pieces that do, and it's even possible to do this using the official styles (group a steel block with a bunch of erasers so that only 1px of not-metal-coloured steel is visible, and then use that pixel to build a steel area, etc). So, whilst it might be a tad more cumbersome to troll a player with hidden/disguised steel, it is still possible. Here's an example (from the Crystal set) - see if you can guess which is the steel piece:



What we have now is better than the OGs either way: no longer do we have those problematic "steel areas" that need to be managed separately: a steel piece is simply labelled as steel and that's that. Much better!

The question then becomes: should it always be steel, or sometimes not be steel if it's overlapped with destructible terrain? The answer is, really - "it depends", which means that it's very difficult to make a decision on this.

If we keep it the way it is, then steel can sometimes be seemingly destroyed, which to me doesn't feel right even though I'm familiar with the behaviour and understand its implementation and purpose. It feels better to have the steel behave as expected and not be destructible at all, wherever it may exist in the level, and whatever is overlapping it.

However, if we change it to "always steel" behaviour, then suddenly it becomes necessary to use CPM to see exactly where the boundaries are, and this isn't something that feels right either. Even if CPM were removed from the game (which Classic Mode does), it becomes a possible source of unnecessary frustration again to the "picture puzzlers", who prefer everything to be exactly as it seems right from the beginning.

It could absolutely be argued, though, that a partially-obscured steel block being destructible in only that obscured area gets more and more "not as it seems" the smaller the obscuring area is - especially if it's a 1px-wide thread cutting through the centre of the steel block, for example.

Ultimately, it's a chase-the-tail argument which doesn't really have a way to keep both points of view satisfied.

What might be worth looking into is whether the terrain-over-steel can be destroyed, revealing the previously-obscured steel block underneath (for example if a bomber or basher is assigned close enough for the destruction mask to make contact with the overlapping terrain). This would certainly look a lot better, but doesn't completely address the associated concerns. I'm also not 100% sure how to handle this; it perhaps becomes necessary to draw the steel onto another layer (or maybe draw it twice - once as destructible terrain, and again on a deeper layer as actual steel...?)

Basically, I need help with this one; it's not a clear cut case either way from my point of view, and so feedback is going to make a big difference on which way this one swings. All I'd ask is that you think of this from a fresh, conceptual, aesthetic and gameplay-oriented perspective rather than tying the argument up with concerns about existing content or sameness with any other Lemmings clone, port or engine.

---

NOTE: Programming-wise, this change comes down to a single word in the entire code - so, it wouldn't be out of the question to trial the proposed "steel is always steel" behaviour for a while and see how we like it. Changing it back would take seconds.

[Simon]

It's not necessarily a binary problem, even though your two solutions are the simplest.

An attempt at an alternative rule: A pixel of a steel tile remains steel unless { it is covered by earth pixels in such a way that it isn't anymore in the convex hull of { other uncovered steel pixels of the same steel tile }}.

This sounds costly to compute and depends on rounding decisions when we compute the lines (the convex combinations of uncovered steel pixels) that aren't necessarily horizontal or vertical. But sounds like it does roughly what you want.

Or, to avoid computing convex combination lines that aren't vertical or horizontal, we can define: A pixel of a steel tile remains steel if it remains in the smallest possible rectangle (with vertical and horizontal borders) that still encompasses all uncovered pixels of the same steel tile.

Examples:

• Both ideas resolve the video's banana to keep the steel block fully intact.
  
• Your white thin diagonal line keeps the steel block fully intact.
  
• Mesh can't dent the steel under the smallest-rectangle rule.
  
• Mesh may dent a corner under the convex-hull rule.
  
• Sticking a steel block halfway into a large earth clump cancels half of the steel.
  
• Outright hiding an entire steel block cancels all the steel.
  

I'm not sure if either is so much more intuitive. Certainly both are more complex than always/never turn earth-overlapped steel into earth. I have a weak preference to stick with one of your two solutions.

-- Simon

[Crane]

This is a difficult one.  There are cases where one or the other is ideal.  For example, on the dirt tileset especially, one might want to put moss over the steel plates for decoration, but have the steel take priority (I also do a similar thing in "Deep Freeze" with non-steel terrain looking like ice over the steel, but is still clearly steel plating).  Other times, I may only want the visible steel to be treated as such, like if I've bisected it with, say, a diagonal piece of terrain in the crystal tileset.  I would personally say it should be a per-level setting (e.g. the old "simple autosteel" option).

[WillLem]

A pixel of a steel tile remains steel if it remains in the smallest possible rectangle (with vertical and horizontal borders) that still encompasses all uncovered pixels of the same steel tile.

Yes, I like this - especially if doing so will delete steel that's completely covered, and partially delete steel that's partially covered in a comprehensive enough way, such as in Crane's bisection example.

With it being a rectangular check, would this also work for diagonal coverage? Any chance you wouldn't mind helping me to figure out how to do this with the existing code structure (maybe we can look at it at the same time as the zooming bug!)?

I may only want the visible steel to be treated as such, like if I've bisected it with, say, a diagonal piece of terrain in the crystal tileset

You could still achieve this by first erasing the steel, then overlaying the terrain. I personally think this is an acceptable enough workaround, but others may feel this constitutes unfair design... it seems better, then, to give Simon's idea a try and see if it can allow for this type of steel coverage.

I would personally say it should be a per-level setting (e.g. the old "simple autosteel" option).

I agree to some extent, but ultimately this needs to be a game-wide thing or it will become way too difficult to manage - not just from a programming perspective, but a gameplay perspective as well. Players would never know what to expect from steel on any given level, which is not a good thing; this is something I think NeoLemmix's autosteel behaviour absolutely gets right, in that at least steel always behaves exactly the same on every level.

We want SuperLemmix steel to be as predictable as possible game-wide, whilst allowing for a more aesthetically-pleasing and intuitive solution to the problems presented in the OP.

Let's give Simon's idea a try; maybe it can calculate overlap to a decent enough pixel margin.

[Turrican]

In any , case , I would personally like, for steel , to still properly be able , to be combined with eraser pieces, so level designers , can still give steel pieces the shape they want , by simply combining steel pieces , with eraser pieces, and also , by grouping steel pieces and eraser pieces, using the group function.

[Floyd Brannon]

I'm pretty much a player exclusively, not a level designer. But I chose that last option. Cutting through steel seems like a gimmick to me.
But I could have chose the second to last just as easily. I'm not very into the super hard levels and don't like surprise steel, but I like backward-compatibility too and I watch my share of replays that help with tricky levels.

But I'd say I'm somewhere in the 4-5 zone here.

I look forward to each new release. Also, Neolemmix takes my PC about 15 seconds to load and Super Lemmix loads in about 3. I've noticed alot of polish on things like that and the little graphics updates and the level menu. [vinetrapper too!] Looks and feel very clean.

[WillLem]

I would personally like, for steel , to still properly be able , to be combined with eraser pieces ... using the group function.

Yes, don't worry - piece grouping will always be available.

Neolemmix takes my PC about 15 seconds to load and Super Lemmix loads in about 3

Thanks for your vote and kind comments!

A question regarding this particular comment, though: how many level packs do you have loaded into SuperLemmix compared to NeoLemmix? I find that, with NeoLemmix, loading times get longer and longer the more packs I load in (and the more level completion data there is to load). Since we don't have many packs yet for SuperLemmix, I wonder if it will eventually start to suffer from the same drag when loading a lot of packs into the player...

[jkapp76]

I can help verify... at least with my equipment that SLX loads considerably faster than Neolemmix.

I have every available pack installed in Neo, and I have converted every available pack for SLX and installed them there too.
My computer should be a pretty good test for this load-speed thing. However, I will say that Neo loads at an acceptable speed
for me. It probably takes 8-10 seconds, but after loading it's fine. SLX loads in about 2-3 seconds. I sometimes wish Neo could
share some of the level selector improvements.

[Turrican]

Yes, don't worry - piece grouping will always be available.

Ok! That's nice! Also, will this also apply , to normal steel - eraser combinations ?

[Dullstar]

I've already stated my reasoning in more detail in Discord, but summarizing here:

While the NeoLemmix behavior may not neccesarily be what newcomers would expect, it only needs to be learned once. After that, it is completely unambiguous: there is no guesswork as to exactly what is and is not steel, and thus no nasty surprises once the player has learned the rules. Any other reasonable behavior means that every instance of overlapping terrain + steel must be assessed individually and/or that CPM must be used to ascertain the steel boundaries.

Thus, the existing NeoLemmix behavior is the best solution.



That said, I get the desire to be able to decorate steel. Simon's proposed solution is a good general solution, I think, though presumably two adjacent steel tiles should be treated as one for this purpose.

A simpler alternative might be to allow styles to mark some pieces as being primarily decorative, such as moss pieces in orig_dirt. These pieces could be overlaid on steel and wouldn't turn it into non-steel, while normal terrain pieces would. It would be less consistent, however... but presumably there wouldn't be particularly many pieces marked as such and it would be obvious something weird is going on if someone tries to abuse it (this assumes that standard styles get vetted to make sure the choices they make are reasonable, of course, but new styles aren't super frequent so I don't think that will be an issue).

[mobius]

An even better solution imo is to have decorative terrain specifically made for and only for steel. This should look at least subtly different from ordinary terrain.

Or to take this idea even further except this is outside the scope of this topic sort of; you could have a class of terrain that's entirely decorative and can or doesn't necessarily have to be used over steel. So that it essentially has no physical effect in game; is purely decorative. Outside of steel Lemmings would pass right through it.

[everybody's angry response at this idea so they don't have to]:
That would lead to lots of confusion and angry ranting; what's walk-able terrain and what's not??? I don't want to play guessing games! The game should be always clear what's terrain and what's not. This would just add clutter and unnecessary complexity.

Just as an aside; NL currently has lots of graphical content, imo that is VERY confusing, to the point of me completely losing interest in playing. When I see certain tilesets or graphics used I simply pass without even attempting said level. And this is with the "optimal" steel features NL has and all the other stuff "true physics mode" and what not.

IMO steel should always be on top of terrain or else clear that it's steel somehow. If I was making a game I might just be tempted to enforce that steel is always on top at the sacrifice of being able to make "misshapen steel".

[WillLem]

I can help verify... at least with my equipment that SLX loads considerably faster than Neolemmix.

It could be the online features, then...? SLX has generally added stuff rather than removed stuff, so it's strange that the loading times would be faster. Obviously great to hear, but it would be good to be able to find out the reasons for this so that I can potentially optimise it even further.

Also, will this also apply , to normal steel - eraser combinations ?

Yes, all current grouping behaviour will be kept exactly as it is now with no changes (unless someone specifically requests a change, and then that request will be addressed community-wide before anything happens).

A simpler alternative might be to allow styles to mark some pieces as being primarily decorative, such as moss pieces in orig_dirt

It's not a bad idea in theory, and I can absolutely see how this would solve the particular use case of decorative terrain on steel. However, beyond that, the layer of complexity this would add to an already fairly cumbersome style management system cannot be ignored.

For instance, how would any player, not just new players, know which pieces were meant to be decorative and which were meant to be actual terrain? What if those pieces get used elsewhere, not just on steel (that already happens with moss in orig_dirt before we even start factoring in custom levels/styles)? If they behave the same there, why not on steel?

Whilst I can agree that this idea does succeed in tackling the issue head-on, it also raises more questions than it answers. It's a move towards a more complex system, and therefore I'm not particularly sold on it.

Does anyone else have any thoughts on this?

you could have a class of terrain that's entirely decorative and can or doesn't necessarily have to be used over steel. So that it essentially has no physical effect in game; is purely decorative. Outside of steel Lemmings would pass right through it.

We already have this: marking an object as "backround" means it has no effect. Then, displaying it "only on terrain" or even using "no overwrite" will make it always display in the foreground (whilst still having no effect).

Also, did we ever get "stickers" in NeoLemmix? I seem to remember that being a suggested feature at one point...? From what I recall, the idea was similar to what's being proposed here: a foreground object with no effect other than to be decorative.

But yes, all the rebuttals you then typed stand fairly firm, particularly the "clutter and unnecessary complexity" one. We don't want to have to hit CPM every time we play a level.

I might just be tempted to enforce that steel is always on top at the sacrifice of being able to make "misshapen steel".

I'm not sure how shape relates to layer/position...? You can make steel whatever shape you like... the level End of an ERa from God Save The Queen is a huge steel picture of Queen Elizabeth II!

Meanwhile, I have considered the idea of separating out steel from terrain and painting it on a higher layer to terrain - this would mean that it could never be decorated with regular terrain though, which seems a bit too drastic a move. Therefore, this would only be done as an absolute last resort if all other ideas (including the ones presented by yourself and Dullstar here) fail.



I'm even more convinced now that we should look at trying Simon's idea of an intelligent system which sorts this out automatically. Here's what I propose...

SuperLemmix looks for the boundary of a steel piece, and checks how much of the boundary is obscured. We'd need a formula that could detect the following:


Example 1, 2 and 3

The dark blue squares are steel, with the light blue boundary being what SuperLemmix "searches" to see where the steel area is defined. The terrain shapes return steel wherever they are yellow or orange, and terrain wherever they are teal green.

In the first example, the terrain circle is entirely within the light blue steel boundary, so the entire area is steel.

In the second example, the terrain line cuts across the steel boundary (note that the boundary is orange where the terrain cuts across it). SuperLemmix searches along this orange boundary for, let's say, 5 pixels. If it finds blue boundary again, then nothing happens - and again, the entire area within the steel boundary is steel (the orange part of the boundary is also steel).

In the third example, the terrain obscures an entire corner of the steel block. SuperLemmix searches along the orange boundary and doesn't find blue boundary again after 5 pixels, so it draws its own boundary between the two points at which the "boundary search" failed to find blue steel boundary. In the example given, it draws a red straight line. I would suggest that this line, the orange part of the boundary, and the yellow part of the terrain block should all be steel. The teal green part of the terrain is terrain, and a large chunk of the steel block is rendered not-steel due to being obscured.

Here's another example, with a more complex variety of steel intersections:


Example 4

So here, wherever the boundary check fails at each end of a straight line, the red boundary will be drawn along that line anyway, so the steel will be preserved as-is in spite of the thickness of the terrain in these area. However, the part of the block that is fully obscured in one corner would be dissected in a straight line, similar to the third example above.

I really think this could work, and it's predictable because the steel intersection would always follow a straight line along the terrain/steel boundary wherever a fully-obscuring intersection occurs.

If there's a formula to achieve this, I'll be amazed!

[WillLem]

Apologies for the double-post, but since that previous one is bordering on being a textbook, I didn't want this particular message to get lost!:

For the next SuperLemmix update (2.4, coming very soon), steel is always steel, even when behind terrain. Let's live with it for a bit whilst we try to work on a solution, and see what happens. If we don't like it, and no solution is found, we can always revert to NeoLemmix behaviour.

[Simon]

Here are two counterexamples where the boundary-following idea fails to detect a large chunk of visible steel block pixels as steel.

Are all steel tiles convex? If you apply either of these new ideas to concave steel tlies (your boundary-following idea, or my smallest-rectangle idea, or my convex-hull idea), you'll produce more convex shapes. This accepts the risk of inverse-banana-style problems where the banana covers a dent in a concave steel tile, and the algorithm fills the dent with steel.

It sounds dangerous to define this arbitrary extension of the visible boundary by 5 pixels. What if the piece sticks in the earthen ground by only 1 pixel not by 5? Your area would overshoot the real steel piece by 4 rows into the ground. At the very least, consider to intersect the detected pixels with the original steel tile (how it's loaded from disk, not how it's partially covered in the level) to prune such overshooting.

The boundary of a diagonal side is really a staircase. When a diagonal side begins to overlap earth, you'll have to extend by 5 pixels in a random horizontal or vertical direction, depending pixel-precisely on how exactly the level designer covered the side with earth.

A steel piece, even if it's a connected lump, can have holes. Holes will increase the number of boundary circles of the tile. A steel piece can be a disjoint union of several lumps, and every such connected component will have one or more boundaries.

-- Simon

[WillLem]

Here are two counterexamples where the boundary-following idea fails to detect a large chunk of visible steel block pixels as steel
...
It sounds dangerous to define this arbitrary extension of the visible boundary by 5 pixels. What if the piece sticks in the earthen ground by only 1 pixel not by 5? Your area would overshoot the real steel piece by 4 rows

Yeah, I see the problem.

How possible would it be to just detect whether the entire block is covered, and if so then remove it as steel? Then, if even 1px is visible, the entire block becomes steel again.

If we can start with just that, then it seems easier to branch out from there and make better and more sophisticated checks. For now though, a "let's not allow designers to completely hide steel" algorithm seems like a good way to start; even if we end there and do nothing else, it's solved perhaps the biggest problem with allowing terrain-on-steel.

Another thing I'd like to try and do is draw all non-erasing steel pixels twice. Once on the terrain layer, where they'll be combined as usual (and probably left as destructible terrain), and again - in the exact same place - on a new steel layer, one layer below. Here, it will always be steel, in whatever shape the pieces are before being covered with anything.

This would allow 2 things, as far as I can imagine:

1) Any overlapping terrain will be destroyed, revealing the steel beneath and making it clear why the action has stopped (if, for example, the lem is Bashing or Digging). So, no more wierdness where the lem hits a subterranean steel block but the terrain itself seems to remain intact. It feels like the terrain still ought be be destroyed by nearby bombers/bashers, etc, at least as far as it can be, to reveal the steel pixels which have actually caused the cancelling.

2) It might be easier to check over the steel map and see if any pieces are completely covered by stuff on the terrain map. Then again, this could possibly be done even before the pieces are combined to draw the terrain layer, I suppose.

In any case, I've had a look at the rendering and it should be possible to achieve this in theory, but I'd have to get a much better understanding of exactly what's going on first. The physics rendering is one of the more impenetrable areas of the code (changing steel to always steel may have only been a single word, but it took a while to find that word!)

Are all steel tiles convex? If you apply either of these new ideas to concave steel tlies (your boundary-following idea, or my smallest-rectangle idea, or my convex-hull idea), you'll produce more convex shapes

I'm not sure I understand what you mean by "convex", in this context...?