Physics: Digger-digger cancelling, steel sensitivity

[Simon]

Hi,

C++ Lix through 0.7.12: A digger has 16 looping frames. She removes earth 12 frames after assignment during this loop. Earth is removed every (12 + (16*n))-th frame.

Proposed: Remove earth during the final frame of the loop instead. Then, a digger removes earth every (16*n)-th frame. For the animation, I'd design 4 frames of startup that run into the old 16-frame looping animation.

Reason: In 0.7.12, you can cancel an already-working digger by (assigning digger to a walker in the digger pit). The new digger removes earth sooner than the old digger, causing the old digger to fall. That leads to backroutes.

There are two interesting alternatives to 0.7.12: Give the digger 3 or 4 extra frames before entering the usual cycle. If we give 3 frames, then you can't cancel diggers by assigning new diggers, but you'll have a frame-perfect possibility to have the diggers moving in unison very close to each other. If we give 4 frames instead, we remove this overlapping assignment; the old digger will remove earth sooner than the new digger.

geoo is in favor of this change. This makes the digger even weaker in comparison to the miner, but not by much. It removes a backroutish digger-digger single-cancelling. Double cancelling (both diggers stop working) never happens, either with or without this proposal.

Damage to replays: Lemforum coverage down 236/240 -> 184/240, that's 52 levels to be covered anew. NepsterLix coverage down 107/107 -> 71/107, that's 36 levels.

geoo assumes that most levels' ideas remain intact, a select few need spawn interval 60 -> 64 or a small shift of terrain.

-- Simon

[Proxima]

The alternative solution (not really a backroute since it's harder to spot than the main solution) to It Takes Time to Build is possible without digger-cancelling, it just saves 39 in that case instead of 40.

And that's way too much damage to be considered for a change just to prevent a solution to one level.

[IchoTolot]

I always used digger canceling as a little trick: Get one digger going and then canceling him later with a lem facing the other direction to get a turned around digger. It also can create a ledge to stop climbers.

I think this adds to the design posibilities way more than it beeing a backroute potential at single cases.

Even if some will call the behavior a bit edgy: Don't cut away too many edges from the game or it can become too bland.

[geoo]

The purpose of the change is not just to prevent one single backroute. It's to prevent ugly behaviour that has potential to be exploited. I'd argue this potential is higher than for the builder backstep. And it's not like there's only one level affected by this. Go West is another example in the pack. Whenever you have to contain a crowd and you're short of builders/platformers this can be applicable.
Ideally this change should have come at the same time as all the other physics changes, but alas it went under the radar (we were discussing it at some point when we also changed the miner physics).

I still think now would be the best time to do this, as we don't really want any more physics changes after this release. I'd be happy to help covering levels with replays where they'd break due to the change, and with the minor adjustments some levels might need.

Even if some will call the behavior a bit edgy: Don't cut away too many edges from the game or it can become too bland.

Behaviour should either be easy, or impossible. This is neither. Maybe it's different in NeoLemmix, but this is Lix. If you actually want to make use of it, it's a bit of a pain to pull off because you need the lix to synchronize with the digger lix so that it's where you want it during those three frames where it works. I wouldn't be happy with a level requiring this behaviour. So really all that it leaves is backroute potential.

You can still create a ledge to stop climbers going out of a digger hole with a second digger.

[Nepster]

I agree that the proposed no-cancelling digger is cleaner. But Proxima's concern is valid: Do we want to rerecord 50 lemforum replays just for the sake of this change?

I always used digger canceling as a little trick.
I think this adds to the design posibilities way more than it beeing a backroute potential at single cases.

How many NeoLemmix-levels do you know that use this trick? I cannot name more than a hand full of them. So given the huge amount of NeoLemmix levels in total, level designers this don't seem to be overly fond of this trick.
On the other hand I agree with geoo, that this trick is at least as often used in backroutes as it is in intended solutions.

Behaviour should either be easy, or impossible. This is neither. Maybe it's different in NeoLemmix, but this is Lix.

This cancelling is far easier in NeoLemmix, because the terrain removal frame comes much earlier in the cycle than it does in Lix. So one has to be rather unlucky to fail cancelling in NeoLemmix (though the lemming still has to be positioned correctly within 3 pixels).

Go West is another example in the pack.

Actually all solutions to Go West that I am aware of use this cancelling trick. Without this trick I can still solve the level, if you give me 3 of each destructive skill, but it becomes extremely precise (especially given the fixed SI). I have no idea how to solve it with 2 of each skills, at least without lots of trial and error.

[IchoTolot]

How many NeoLemmix-levels do you know that use this trick? I cannot name more than a hand full of them. So given the huge amount of NeoLemmix levels in total, level designers this don't seem to be overly fond of this trick.

That's not the point. A trick doesn't need to be used in many levels to be good. But if you remove every trick that is only covered in a few levels you are just raising blandness. Culling everything what is not used very often can be a very bad thing.

This cancelling is far easier in NeoLemmix, because the terrain removal frame comes much earlier in the cycle than it does in Lix. So one has to be rather unlucky to fail cancelling in NeoLemmix (though the lemming still has to be positioned correctly within 3 pixels).

I have to admit, I did not counted in that it is easy to pull off in NL and difficult to pull off in Lix which makes this trick less viable and more annoying and I can understand the reason on why to remove it and this seems to be indeed the main point. In fact your post made me realized that as I did not fully understand the technical stuff in the first post, although I did not wanted to invest much time to think myself into the inner workings there.
To be honest all this mumbling about 12+X frames, animation loops and stuff in the first post I just skipped and focused on the thing that's pointed out in the title.
The first post should rather be like: Prevent digger-digger cancelling, as it is very hard to pull off in lix and introduces backroutes. Then point out the inner workings in detail for the people who want to actively think them out and propose an exact solution.
For the general players I think the fact what is up for culling (digger-digger canceling) and the general reason why (backroutes and it's hard to pull of) is what counts the most and not the exact code details.

[Simon]

Yeah, in 0.7.12, digger-digger cancelling requires an assignment during 3/16 of the old digger's frames. There's a chance that a passing walker, during his 9-11 frames of overlap with the old digger, won't be in the correct spot to cancel. I accept that the first post didn't describe this fiddliness.

With geoo offering to work on re-coverage, I'm leaning to accept the proposal. The main counter-argument was the workload.

Another idea would be to make digger-digger cancelling easier instead of impossible, but I'm not leaning as strongly towards that. I'll leave it open for 1-2 days.



I'm also considering to make the digger more lenient with steel. The mask is 9 lo-res pixels wide. 0.7.12 cancels when one of the 7 innermost lo-res pixels is steel. In particular, these diggers hits steel and won't remove anything:



Proposal for steel sensitivity: I'm considering to loosen the steel check. Instead of the 7 innermost lo-res pixels, check only the 5 innermost for steel.

Or maybe even the 3 innermost only, that would be closest to 0.6 physics. But Proxima suggests that would be too lenient, intuitively expecting the 3-innermost-checking digger to choke on the steel:



No replays would break from the more lenient steel check: I tested with both 5-innermost and 3-innermost. If there are possible backroutes in levels from this lenience, those backroutes would have already been possible in 0.6, which effectively had a 3-innermost steel check as long as all steel was to one side of the digger.

-- Simon

[ccexplore]

In Lemmings, digger canceling is something that you can probably rationalize once you see it happening and think carefully about the mechanics.  It is probably not something a yet-unaware user would intuitively expect to happen, though the same could probably be said of a lot of other edge-case behaviors.  It doesn't help that DOS version's mechanics are much more limited in how canceling can happen (though this doesn't apply to NeoLemmix?).  The analogy may also be slightly broken for Lix since I believe each dig stroke in Lix removes the equivalent of 2 dig-strokes in Lemmings and NeoLemmix, so maybe there is more of a case to expect the canceling behavior if it hadn't been so fiddly to achieve.

It's definitely not ideal to have it possible but troublesome to achieve due to timing.  It'd be helpful to get a sense of how many current levels explicitly rely on it.  It wouldn't be the first time we remove an "interesting" behavior in Lix that had actually been relatively well-known and were probably already in use by multiple levels, but overall still deemed not worth the problems the behavior brings to places where you don't want it exploited.  Basher staircase specifically comes to mind.

=================

Proposal for steel sensitivity: I'm considering to loosen the steel check. Instead of the 7 innermost lo-res pixels, check only the 5 innermost for steel.

Or maybe even the 3 innermost only, that would be closest to 0.6 physics.

Perhaps there are some details I'm not aware of, but seems like maybe we'd need to discuss or at least look at, the cases where there are steel on both sides, but terrain is still barely wide enough to not prevent digging?  All the pictures right now only have steel on one side.

Unless the level author was specifically forcing precision (which will likely be frowned upon anyway), I guess those would be cases where player is not supposed to dig through but instead use an imploder or similar.  They can likely be fixed by adjusting the steel positioning to further narrow the terrain portion.  So maybe not a big deal per se, but I want to bring it up since it isn't really being captured by the above post.

I think I do see the general idea behind making it more lenient wrt steel.  Namely for cases where digger absolutely must not leave any terrain adjacent to the steel (perhaps in order to make a climbable cliff), so you are unfortunately forced to be somewhat precise in where you start digging, and we want to make things a little more lenient for that case.  It is hard to tell though how much leniency is "good enough" for most.  Of course it also depends on how much this situation may come up in multiplayer, where framestepping is unavailable as a corrective measure compared to singleplayer.

[Proxima]

It'd be helpful to get a sense of how many current levels explicitly rely on it.

Pretty sure there aren't any, in the levels I've solved, which is nearly all of the first 5 ranks.

Perhaps there are some details I'm not aware of, but seems like maybe we'd need to discuss or at least look at, the cases where there are steel on both sides, but terrain is still barely wide enough to not prevent digging?  All the pictures right now only have steel on one side.

I've attached an image from the latest version of Cold Irons Bound. Both the digger and basher have to get between steel blocks that are 16 pixels apart -- a common situation given that Lix encourages designers to use multiples of 8, 16, 32. For the digger, there is only a single pixel where he can dig and get through. For the basher it's even worse -- there is only a single pixel, and you can't necessarily reach it because the digger goes down 2 at a time. This means, if the player starts the digger at the wrong height, they may give up without realising there is a correct height that will allow the basher to get through.

I propose that we adopt the 5-innermost digger (so, if I've understood rightly, in this situation the digger would have 3 positions he could start from) and also relax checks for the basher, so that it doesn't feel like the basher is much stricter than the digger.

[Simon]

I'd be happy with the 5-innermost digger. That's 1 lo-res pixel = 2 hi-res pixels more lenient to either side.

Basher: I understand your idea how, no matter the digger's vertical offset, a basher shall fit through a 16-pixel-high earth corridor with steel above and below. The digger removes 2 lo-res = 4 hi-res rows at once.

0.7.12: The topmost 2/18 basher rows ignore steel, leaving 16 sensitive rows.

Concrete idea for Proxima's proposal: Topmost 5/18 basher rows ignore steel, leaving 13 sensitive rows.

It's a sizeable cut on steel sensitivity. How do others feel?

Alternative idea: Instead of introducing the lenience all at the top, introduce some of it at the bottom. But then a basher could gain height. The basher can't gain height in 0.7.12, I'd prefer to keep this invariant.

Flying Squirrels (my LF contest 11 entry, picture in this post) becomes a tad more precise with a lenient basher, I've put a steel block above the ground to catch bashers of variable height. But that's not a main concern -- the level is possible either way.



-- Simon

[ccexplore]

It would seem logical that if we commit to increasing steel leniency for diggers, we should do the same for bashers as well.  Sounds reasonable to keep the leniency only at the top to avoid introducing a brand-new height-gaining behavior; doing so also IMHO "looks reasonable" with the bash stroke animation currently going from bottom to top.

It is interesting that some levels could end up requiring more precision due to increased steel leniency. (I imagine this is also theoretically possible with digger leniency and not just basher?)  I guess as long as those cases remain rare.

[geoo]

I don't see a big issue with the previous (less lenient) basher steel check. Level designers shouldn't (and as far as I'm aware, currently don't) require the player to go through a 16 px tunnel with a basher unless the basher starts on a wide platform which is already in the desired vertical position (and thus no precision is involved).
Unless a level author wants to seal a basher tunnel with a cuber, I don't even see much of a reason to use such tunnels. In the rare instances where a level does require such a tunnel, I think ensuring that there's no reason to try to enter it in a complicated way should be sufficient.

At the same time, I don't see any drawbacks from making the basher's steel check more lenient. So overall I'm indifferent to the change.

[Nepster]

While I like the slightly relaxed steel checks for diggers, I much prefer the old basher steel checks. The reason is, that the new steel checks break every single one-way gadget! Previously one could not get past in the wrong direction, even by placing one or two builder bricks in front and then bashing. Now this is possible! So if we keep the new basher steel checks, I would have to modify all my one-way gadgets.

[Simon]

0.7.15 had: Digger-digger-cancelling prevented (they dig later in their cycle). Basher sensitivity is bottom 8/9 hi-res pixels. Digger sensitivity is middle 5/9 lo-res pixels.

It would seem logical that if we commit to increasing steel leniency for diggers, we should do the same for bashers as well.

History is a wild back-and-forth. In 2006 to 2009, the L++ ground removers had 100 % steel sensitivity. That was straightforward. Pieces were shaped in multiples of 25 hi-res pixels. You can see the relics of this: matt/10tons.T and simon/water.W are 50 pixels long.

Then geoo popularized powers of 2, they became a big hit. The basher was 18 hi-res pixels high because of tradition with Lemmings 1, slightly too much for grid-16. He got his 2 insensitive pixels at the top. Unfortunately I don't remember anything for the digger. The digger hole is 18 hi-res pixels wide, I've likely introduced lenience quickly for the old 100-%-sensitivy diggers.

Late C++ Lix to D Lix 0.6 had a very lenient digger: Digger chokes iff both of the following areas have at least one steel pixel each: The leftmost 12/18 pixels, and the rightmost 12/18 pixels. This is effectively a 3/9 digger because steel on both sides is very rare. We increased the sensitivity it to 7/9 (= choke if central 14/18 hi-res pixels have any steel) for early 0.7, then lessened it to 5/9 for 0.7.15.

Now even considering to move to 9/9. Proxima doesn't like that 5/9 gives more lenience than the basher's 2 pixels. geoo doesn't like how a 16-pixel-fat cuber plugs a digger hole in one shot near steel. A 7/9 or 9/9 digger needs a fatter sprite, and probably blueprints (silhouettes, shadows) before assignment.

Can't blindly copy Neolemmix either, which has a 1/9-digger.

-- Simon

[ccexplore]

How important (and how common) is the case quoted by Proxima where there are steel on both sides of the tunnel?  The concern for that case is confusing the player on the viability of digging/bashing through the tight space.  Yet that case seems to be specifically exasperated by power-of-2 layout, which makes me wonder if those cases often have an acceptable alternative of just tweaking the steel positioning involved to intentionally break power-of-2, in order to allow the tunnel sizes to better match what the basher/digger takes out?

Then we are left with the case quoted by Simon where there is just steel on one side, but the solution requires you to dig exactly so that there are no leftover bits of terrain still adjacent to the steel after digging.  Those cases do require more precision if there is less leniency, but at the same time, unlike the steel-on-both-sides case, it doesn't seem like the player would get confused about viability of the precision digging.  There is clearly at least one position where digging/bashing can work as desired without also requiring any steel leniency, and so at least in singleplayer, the player can anticipate using precision controls like framestepping to handle that part.  The leniency then becomes more about convenience, or if the setup also appears often enough in multiplayer that we can't just fall back to framestepping.