[DISCUSSION][PLAYER] Overlapping one-way walls.

[namida]

Currently, if you place two one-way wall objects such that they overlap, the overlap area gets a combined effect (subtractively). For example, if you overlap a one-way-right and one-way-down, it cannot be destroyed by bashers or fencers (due to the one-way-down) or left-facing miners (due to the one-way-right), but can by right-facing miners, diggers and bombers.

I wonder if this should remain the case - I don't believe there's any levels that have intentionally used this (but please correct me if I'm wrong), and it also looks very awkward. It would be far too much effort to actually hide one direction, but I wonder if I should at least block the physics, so that there's no reason to try this and end up with the confusing graphics.

I'd personally prefer this to have a priority by direction, so that a player who encounters a level that nonetheless does this just needs to know "left has priority" etc instead of figuring out "which object is first in the level data?" Of course - ideally players will not encounter any such levels, but yeah.

EDIT: Or perhaps an even stronger preference now that I've thought of it - overlapping one-way wall objects simply cancel out altogether; ie: if a single pixel is within the trigger area of two one-way wall objects, that pixel reverts to normal terrain.

What's everyone else's thoughts here?

[Proxima]

It could look okay if the arrows in one direction fit into the gaps in the other....

[namida]

It could look okay if the arrows in one direction fit into the gaps in the other....

This would be determined by the exact placement of the one-way arrow objects.

[Dullstar]

I don't currently have an opinion as to whether or not overlapping should be allowed, but if it were to be disallowed, I'd suggest that if a priority system is to be used, it should be reflected in the graphics; one-way-walls rendered inactive by the priority system should not be drawn to avoid requiring players to memorize a set of rules governing which receives priority. Furthermore, my suggestion would be to determine this based on the draw order rather than the direction, preferably granting priority to the most recently placed one-way-wall object, which I think is simpler for designers to remember than any directional hierarchy. Players would not have to worry about figuring out the object order with a system in which the inactive walls are not drawn. In any case, I would be strongly opposed to any system which requires users to memorize a priority list. These sorts of precedence systems should be avoided where possible, and the proposal to create one here, in my opinion, is significantly more convoluted than the current status quo regarding overlapping arrows.

I would further inquire if there are sensible graphics that could be produced for some of the situations. A one-way-horizontal overlapped with a one-way-verticle seems sensible enough, and could be drawn as diagonal arrows -  though making this a separate object might be cleaner than drawing the appropriate one based on direction. That said, this suggestion might make graphic set updates a pain.

[namida]

The problem with reflecting the exclusivity in display, is that it essentially means we need one layer per direction of one way wall. This would have a significant impact on performance and memory use, especially on larger levels.

There is one possibility here that's easy for designers to remember, unnecessary for players to be aware of, and easy to code: If multiple one-way walls overlap, they cancel out altogether, and the underlying terrain becomes normal. This is very easy to code, and performance impact would - at worst - be limited to a few extra milliseconds when doing the initial generation of the level's physics map. No further work on top of implementing the cancel-out-during-physics-map-generation would be needed - this would automatically translate to "no one-way arrow object gets rendered on the relevant pixel".

I would further inquire if there are sensible graphics that could be produced for some of the situations. A one-way-horizontal overlapped with a one-way-verticle seems sensible enough, and could be drawn as diagonal arrows -  though making this a separate object might be cleaner than drawing the appropriate one based on direction. That said, this suggestion might make graphic set updates a pain.

If this is seen as worthwhile, then diagonal one-way arrows could become a new object type altogether. Existing sets would need to add diagonal one-ways in order to be able to use them if those sets use custom one-way arrows in the first place; those that simply recolor the default ones will of course not need any changes. This in turn is not in any way mutually exclusive with the above idea.

[Crane]

To me, logically, the effects should be combined, but I avoid it because the overlapping graphics can be untidy or misleading.

[ccexplore]

So to be clear, with the proposal where overlap = normal, it means the areas where overlaps occur will be rendered normally without any kind of one-way arrows, correct?

Personally I'm with Crane and favor more towards having combined effects, but I can see the point of the overlapping graphics become hard enough to see that it could become difficult to tell which effects are being combined.  You are probably better off with adding new one-way-wall types if you want to represent one or more of those combination effects.

I guess the only question is, are there cases in NeoLemmix where overlapping is not for the combined effects, but because (for example) the one-way effects should not extend too far right nor left for the level, and so you're left with no choice but to position the objects overlapping, to precisely control the area of effect?  In such a case we would not want the overlap to become normal.

FWIW, in original Lemmings, due to the way trigger areas are handled, overlapping one-way-walls will have "last object wins" semantics, where the trigger area of the object that comes later in the level's list of objects, will overwrite whatever earlier objects might have placed into the areas of overlap.

[namida]

I guess the only question is, are there cases in NeoLemmix where overlapping is not for the combined effects, but because (for example) the one-way effects should not extend too far right nor left for the level, and so you're left with no choice but to position the objects overlapping, to precisely control the area of effect?  In such a case we would not want the overlap to become normal.

One-way wall objects in NeoLemmix can be arbitrarily resized (as can a few others such as updrafts and (horizontally only) water), so I suspect this situation would never arise. To be clear - this is a property of the individual object, not of object types as a whole, so perhaps an exception is if a style designer makes a non-resizable one-way-wall object in a custom style - but then the solution is "add the resizable property to it".

[Dullstar]

I like the idea of combined effects, but I think new one-way-wall objects would be the best way to handle this.

Suppose two different one-way-wall objects overlap for part, but not all of their area. To clarify, the proposal is that only the overlapping area is cancelled, correct?

Would this also apply if same-direction one-way-wall objects are overlapped, or would this be an exception? While resizable objects means it's always possible to arrange walls such that none overlap, it may be more work to cover certain areas: an area that could be represented as two overlapping identically sized rectangles, for instance, would require three one-way-wall objects to cover such that there is no overlap. These situations might also be common in older content predating resizable one way walls, assuming the conversion tools don't have some algorithm to automatically detect and merge such occurrences; certainly, without any such automated detector for these situations in the conversion tools, such a change would likely require much content to be manually fixed.

[namida]

Suppose two different one-way-wall objects overlap for part, but not all of their area. To clarify, the proposal is that only the overlapping area is cancelled, correct?

Correct.

Would this also apply if same-direction one-way-wall objects are overlapped, or would this be an exception?

I see no reason to make overlaps of the same direction cancel out. Same-direction overlaps would rarely cause visual issues, and never cause physics issues, so there's no reason not to just treat them as "it's still just that direction".



Here's an image to illustrate my proposal more precisely.

In this:
- Red marks the outline of one-way-left arrow objects. This should be interpreted as TWO objects that are half overlapping vertically, not three or more separate ones.
- Green marks the outline of one-way-right arrow objects. This is half overlapping horizontally with the one-way-left arrows.
- Blue background marks normal terrain
- Yellow marks one-way-left terrain
- Pink marks one-way-right terrain
- White is the actual graphics of the one-way arrow objects that would be displayed
- Black is one-way arrow object graphics that would not get displayed due to the cancelling-out

(To be clear - the blue in the top-right is simply because there's no one-way arrow object there in the first place.)

EDIT: Scaled the image up a bit.

[ccexplore]

I almost wonder if we should do more to actively discourage overlaps of different one-way-wall types, for example maybe popping a warning whenever a level is loaded in editor or when changes in positioning/size/etc. occurred on one or more one-way-wall objects, after checking and finding such overlaps.  Basically, are there cases where unintentional overlaps can be introduced and may escape visual notice by the level author?

Also, in the case where there are more than two objects involve in overlap, it's still going to consistently be normal, right?  We probably don't want a case where we handled things such that for example, two of the objects' overlap "cut out" an area of normal, and then we process the third object and wind up getting its one-way in the overlap area, because of the normal that resulted from overlap of first two objects.

[namida]

Also, in the case where there are more than two objects involve in overlap, it's still going to consistently be normal, right?  We probably don't want a case where we handled things such that for example, two of the objects' overlap "cut out" an area of normal, and then we process the third object and wind up getting its one-way in the overlap area, because of the normal that resulted from overlap of first two objects.

That won't happen.

NeoLemmix's physics map is basically a bitmap the size of the level, except that instead of storing a color, each pixel stores bitwise physics info. For example, a pixel's 32-bit "ARGB" value would have the 0x00000001 flag active to mark it as solid, or 0x00000002 to mark it as steel.

There are five flags relating to one-way arrows here. I don't remember the exact numeric values, but that isn't important here - there's a value for "one-way capable", as well as a value for each direction. Currently, the initial physics map generation code just marks pixels as "one-way capable" if the underlying terrain piece is (a) not steel and (b) has the "one way" flag. (How it figures this out in the case of partial transparency overlapping could be a whole post of its own, but that's irrelevant here - it collapses such cases into a final "yes" or "no" state before going on to this next step.)

After this, the one-way arrow's effects are applied. NL iterates through the level's one-way arrow objects, and will apply, based on their trigger area, the specific-direction one way flags only on pixels with the "one-way capable" flag. As such - applying the above proposal is a simple change here: When doing this, check "does a different direction's flag already exist on the pixel? If so, remove that flag, and remove the one-way capable flag." Any later one-way-arrow objects will then see this pixel as not-one-way-capable, and ignore it.

[namida]

I've implemented this proposal (in a separate branch, so if it's decided against, I can simply not merge it rather than having to explicitly undo it).

I've tested with two, three or four overlapping directions and it works correctly in every case - a full physics cancel-out where there's any number of different direction overlaps, but no cancelling when it's just multiple objects of the same direction. This in turn, as expected, automatically leads to a correct visual cancel-out. The segments that don't overlap don't get cancelled.

Should a directional priority be decided on, the code is easily enough modified to achieve that physics-wise, although a visual cancel-out here would be a nightmare to code (and probably cause a huge performance hit), so I'm actually quite against that idea now, unless it's on a "just worry about physics; visuals is handled by telling people not to do that" basis.