[SUG][PLAYER] Fix misleading traps!

Started by Proxima, July 15, 2018, 05:02:03 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Dullstar

Quote from: Proxima on October 03, 2019, 10:38:36 PM
With all respect to namida as creator and maintainer of NL, I think it's abundantly clear we need more time to decide on this. We are as far from a consensus as ever, and several different ideas are being developed.

I have to agree here. I don't think requiring a consensus before [deadline] or [default option] becomes permanent is a good way to go about this decision. While I agree it's best we try to decide what the object should do before we take action so we don't have to make several potentially content-damaging changes to the same object in a row, I don't think it's necessary to declare that "All modifications to existing objects we make must be done at the same time." I think it's okay if we defer a few trigger areas for later versions so we know that we have a clear consensus regarding whatever decision gets made.

Maybe it's because I'm not really good enough to solve the really difficult custom levels, but I can't think of any I've played that are so dependent on the exact details of the trigger area that a reasonably small expansion of said area would break them, so I expect the content damage from these physics changes will be very small.

namida

Quote from: Proxima on October 03, 2019, 10:38:36 PM
With all respect to namida as creator and maintainer of NL, I think it's abundantly clear we need more time to decide on this. We are as far from a consensus as ever, and several different ideas are being developed.

I do understand where you're coming from, but official style triggers have already been modified a few times, and there's always the risk of content breaking when it happens. That's why I want to set this as an absolute final time for it to happen - if something, by this point, hasn't got universal agreement, it probably never will and it comes down to having to make an "executive decision" so to speak. Likewise, if something hasn't been raised throughout all of these sets of changes, it's probably not important enough to worry about and thus it can stay as it currently is.

And while "change some objects now, some later" may not raise issues on the same levels, it will mean that the same packs must be updated multiple times, for each of these changes. While sometimes, pack updates will become necessary due to changes, we have a very clear option to avoid it here, by making all changes to the official styles at the same time. I think if anything - the sensible alternative would be "hold off on all changes for now", but I'd really rather get this matter over and done with, rather than holding it up for the sake of a single object that (maybe due to the issue not being that big in practice, maybe due to the object not being used all that frequently) only came up at the last minute. I would also at this stage have to go and seperate the changes out again, as I've at this point started preparing for V12.7.0 RC's release and as such these have been merged into the main NL branch now. Not yet to the extent that there couldn't be further changes to the trap's trigger area, but to the extent that I'd rather not have to roll back these changes as a whole to delay them for a future release.

So I stand by what I've said - V12.7.0 RC will be the last release that may change trigger areas of official objects (the only exception being if a change that was supposed to go in got excluded by accident), and ideally (though not "no exceptions") I'd like animations to be finalized for V12.7.0 stable.
My 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)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

Dullstar

#62
It also seems to me that some of the reason for the lack of consensus is that there are essentially two issues at play: First, should the bottom pixel on this trap be deadly? If yes, then should this be done by changing the trigger area or the graphic? I suggest we should get a consensus on the first issue, then if we decide it should be deadly, only then should we move onto the second.

The bars seem to be creating some disagreement as to whether or not they should be deadly, which is why I will admit I don't think namida's proposed graphic change really solves the problem - to me, if I'm understanding it correctly, it looks like it shrinks the object around the trigger area, but it doesn't really resolve the conceptual disagreement surrounding whether this part of the object should, in fact, be deadly, which means the resulting object is no more clear, but it does have the potential to create situations where aesthetically guided object placements, such as multiple of the traps placed side-by-side, may break, which I suspect to be more common than situations relying on the pixel-precise details of the trigger area. Of course, if you've seen enough of my posts on these sorts of issues, you may have noticed I tend to oppose changes I believe will negatively impact the aesthetics of existing levels, valuing these sorts of levels over breaking precision levels.

Incidentally, I also think this object might be a good candidate to make resizable in the horizontal direction (depending on how exactly the graphics for resizable objects work, as I haven't worked much with them), although it may take some work to create a tiling animation for it.

IchoTolot

I was already pming with Willem to gather the animations (already got 2 but they have a different slightly widths as I forgot to mention that should stay constant :-[ - asked for an adaptation though) and we are at Step 1 again.

I agree with namida that this should soon come to a closure soon as having possible trigger and animation changes in the most used sets in the game every now and then is just a bad time to maintain. We all see things differently and there are bound to be things and objects that won't fit for every person. There needs to be an end point at some point.

I still stand with the following:

Quote- For a deadly frame would either have to change physics+animation or the size of the general visuals+animation which would alter the apperance of levels. So here we have either a visual or physics change for sure.
- For a non-deadly frame only a animation change would be needed. Like cold coal falling out of the sides of the pit over the frame. So no 100% need for a visual or physics change here.

In both cases we would need an animator for the fire and blue fire graphic though to make the case clearer.

And therefore I am still for a non-deadly frame with an animation change.

I will post the new animations from Willem when I get them (I already asked for the adaptation before I read the recent posts to clarify).

Simon

Icho, your position on the firepit condenses to (deadly frame is a physics change or a graphics change, therefore it's worse than a pure graphics change).

You make no statement on what feels correct with the fire pit re misleading. For consistency, this trap should be treated with the same rules as other traps.

Please go over other people's opinions and attack some specific ideas. I'd be really interested in your counterarguments to replies #52, #53, and #57.

-- Simon

namida

QuoteIncidentally, I also think this object might be a good candidate to make resizable in the horizontal direction (depending on how exactly the graphics for resizable objects work, as I haven't worked much with them), although it may take some work to create a tiling animation for it.

Resizable objects are simply tiled. Since V12.6.0, it has been possible to use "nine-slicing" (I've also seen this referred to as "nine-pieceing", "3x3 resizing" - I don't know if there is a single standard name for it; but basically, there's a center region that's tiled, then the borders are only tiled in one direction, while the corners don't get tiled at all - see attachment). So basically, what would be needed is some portion of the object in the middle that tiles nicely.

I agree - if animation suits, this object should become horizontally resizable.
My 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)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

IchoTolot

QuoteYou make no statement on what feels correct with the fire pit re misleading. For consistency, this trap should be treated with the same rules as other traps.

I have made the statement in past posts that I rather have my lemmings survive than die when something unexpected happens. I would be much more annoyed by a deadly frame in the current state. Also from the current state of the object I would assume it is non-deadly as there is no flame.
Therefore change the animation to make the frame look more harmless as it#s not part of the flame and don't make the frame deadly.

QuoteIcho, your position on the firepit condenses to (deadly frame is a physics change or a graphics change, therefore it's worse than a pure graphics change).

And that's my other point.

QuotePlease go over other people's opinions and attack some specific ideas. I'd be really interested in your counterarguments to replies #52, #53, and #57.

You just want more and more popcorn! I've got you, admit it. ;)

No, but seriously the 2 points above is my viewpoint on the topic and I agree with namida to draw a line under the topic soon and don't have it drag on for eternity and dug up again and again.

namida

As V12.7.0-RC has arrived with no consensus reached, the trigger area for this object will not be changing - case closed.

V12.7.0-RC has shipped with the shrunken frame animation, as demonstrated above. However, I am still open to changing the appearance of the object.

We can look at the horizontal resizability later. As such a change would not in any way harm existing content, not even in theory, I don't have nearly the same level of objection to making this change at a later date.
My 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)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

Simon

Quotetrigger area for this object will not be changing
still open to changing the appearance of the object.

Ah, we're in for the true popcorn. x_X

-- Simon

namida

Here's an idea that came up thanks to something Crane mentioned on Discord:

How do people feel about shrinking the existing object, as is currently the case, then creating a new object that has the old graphic, and an enlarged trigger area to suit? Levels that primarily want the visual aspect would switch to this object; those where physics is the main concern would keep using the existing one.

To be clear - the one that would be used for all existing levels (unless modified) would have the original trigger area, with the shrunk graphic. The new, alternative option would be the original graphic, with a larger trigger area. Since this would be adding a new object, not changing an existing one, I don't feel it violates the "no further changes to trigger areas" decision.
My 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)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

IchoTolot

#70
I think that would still cause a ton of confusion and checking and switching objects would also still be mandatory.
If we would go with 2 objects I think the new one should be the shrunken one, the visual breakage is much higher this time as the physical. I would rather take the trigger area change than the size change.

I still think a simple animation change is the way to go though.

namida

QuoteIf we would go with 2 objects I think the new one should be the shrunken one, the visual breakage is much higher this time as the physical. I would rather take the trigger area change than the size change.

Are there many examples of levels where the visual breaks that are not misleading? As far as I can see - almost any existing level either has the object placed such that it looks to be deadly but isn't; or has it buried enough that at worst, the new graphic will leave the firepit sitting on top of terrain instead of buried in it.

The only exception that comes to mind is Mayhem 2, as mentioned before.
My 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)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

IchoTolot

From the original levels not that much. I am referring to custom content here. And I also count visual breaks as those where pits are flying in mid air now.

Some examples that would need visual fixes due to either pits not standing on ground anymore or creating unwanted gaps in between objects:

Reunion: 

5 12, 4 19, 4 14, 4 04, 3 19, 3 15, 3 09, 2 24, 2 19, 2 15,  1 24,  1 02 , 1 01

This is Reunion alone.

Now the possible list for checking Reunion where the trigger extend could cause a break:

5 12, 4 02

I can expand the list for more packs if you want.

So you see that the trigger fix is much less work in content terms than the shrinking. Therefore if we have 2 objects the shrunken object should be the new one.


namida

If a pit is not standing on ground anymore, preserving that pit is not important, because it was misleading in that what looked like it should be either solid or deadly was not. As such - not only do I disagree that this breakage is important to consider, I disagree that this is actually breaking them at all - rather, it is fixing them, so the player is clearly aware that there is a safe space to pass under them.

I do notice that in some of your examples, for example, 0101 from Reunion, accuracy to physics isn't particularly critical - one fire object is impossible to reach, and the other two are simply a case of whether you fall into them and burn, or fall between them and drop out of the level; the lemming is dead either way. This would be less severe than a level that places such a fire pit along the intended path, or somewhere that could be reached during a failed attempt or backroute.

However, ultimately, this is an object with an effect, not a purely decorative piece. Concerns about decorative use come second to concerns about a good visual-physics correspondence.
My 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)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

IchoTolot

QuoteHowever, ultimately, this is an object with an effect, not a purely decorative piece. Concerns about decorative use come second to concerns about a good visual-physics correspondence.

Yes, but it's still a lot more extra work. I still consider a level with visual flaws a flawed level that critically needs fixing. It doesn't matter to me if it's only decorational it's still flawed.

QuoteAs such - not only do I disagree that this breakage is important to consider, I disagree that this is actually breaking them at all - rather, it is fixing them, so the player is clearly aware that there is a safe space to pass under them.

As the objects were unreachable this is anything but not a fix. The change did not affect the level gameplay (no fixing) and broke the visual aspect.

The workload is a critical thing to consider after all.

If the 2 object approach is chosen I would still consider to let the shrunken version be the new one superior as the possible workload is way smaller this way.