basher/miner❤blocker interaction, desired behavior?

[geoo]

This is issue #47 on github: Basher/miner interact with blocker, pass through wall.

We're currently implementing physics changes in Lix, and there are two issues we need to come up with a solution for.


The first one is a glitch allowing a basher to pass through terrain without removing it. This also works for miners.

Have a wall to the left.
Basher standing in front of wall, facing right.
Basher bashes a swing, but doens't move yet.
To second lix in front of basher, assign blocker.
Blocker turns basher.
Basher walks through the wall on the left.

On first glance, moving the check that looks for terrain to determine if the basher continues into the same frame as the terrain removal looks like it might solve the issue. But if there's terrain on the other side of the blocker as well (i.e. blocker and basher are trapped between two walls), the glitch still works. It's a rather specific setup then though.

Another, move involved idea is not allowing the basher to move forward if it were to move into terrain. This however would allow to stall bashers using cubers.

Or only allow turning the basher in the frames after moving forward but before the stroke, and disallow moving forward when the basher is facing a blocker and is in its turning field? Then basher/blocker interaction becomes inconsistent and confusing.

None of these are really satisfying, so we were wondering if there were any other ideas.


The second issue is about lix trapped between two blockers. In this case we disallow any horizontal movement, and the lix turns around every single frame. Now imagine a basher trapped here. The basher cycle consists of an even number of frames, so the terrain check and terrain removal always occurs on the same side. So you can trap a basher between two blockers even if there's terrain on only one side. Same issue with the miner, but more visible (Imagine a miner on top of a cube where the cube is located between two blockers): It removes terrain always on the same side, leaving a pillar of cube on one side. Maybe less serious but same issue also with builder bricks, they are always on the same side.

Simplest fix would be having exactly one frame in their cycle where bashers/miner/diggers are unturnable. Then there's an odd number of turnable frames and so terrain checks and removal are alternatively executed on both sides. Introduces slightly inconsistent behaviour, but it's not that visible.

Other idea is: detecting if a lix is trapped between two blockers is already implemented. In that case just check for terrain/remove terrain on both sides. What about the builder though?


Any input and suggestions are welcome.

[ccexplore]

Another, move involved idea is not allowing the basher to move forward if it were to move into terrain. This however would allow to stall bashers using cubers.

IMHO I think it's acceptable (ie. stall bashers using cubers), since the only other alternative is that the basher moves ahead anyway into the cube and essentially winds up in the same situation as your "glitch" here, or maybe it stops bashing altogether which seems even less logical.  Are there any abuse in MP or SP that you feel is problematic with the stalling behavior?

The second issue is about lix trapped between two blockers. In this case we disallow any horizontal movement, and the lix turns around every single frame. Now imagine a basher trapped here. The basher cycle consists of an even number of frames, so the terrain check and terrain removal always occurs on the same side. So you can trap a basher between two blockers even if there's terrain on only one side. Same issue with the miner, but more visible (Imagine a miner on top of a cube where the cube is located between two blockers): It removes terrain always on the same side, leaving a pillar of cube on one side. Maybe less serious but same issue also with builder bricks, they are always on the same side.

The principle to consider here is that if the lix isn't perfectly trapped between two blockers (ie. there's some room for it to move back and forth a little between the two blockers), then I imagine you'd end up with alternating behavior for the skills in question.  With that in mind (assuming it's true), whatever solution you pursue should strive for resulting in the same alternation as well, since "perfectly trapped between two blockers" ideally should be just a special/limit case of imperfect trapping.

[ccexplore]

Since it was sort of mentioned in IRC:  if we're going with the stalling approach, the threshold between stall/move-ahead should probably be same as the current threshold between walking vs ascending.  I would go a step further and say that maybe the basher should step up whenever whatever's ahead is walkable like that, to keep symmetry with its ability (unless physics has recently changed around this) to move down small steps during the basher's forward movement.  But I'm not too adamant about that aspect; it's minor enough for me whether or not the basher can only go down and never up when it's moving forward.

I'd also say that while it's nice to try keep various consistencies amongst your skills, it's not always necessary or desirable.  So even if you decide to be very strict and always stall basher for all cases where any terrain at feet-level is present, that's probably acceptable too.  After all, the miner for example doesn't move forward exactly like the walker either, or else it would never terminate when mining on a 45-degree downward slope (or perhaps Lix has changed in that aspect as well?).

[Simon]

Thanks, cc, for treating two close-by blockers in scenario 2 (stuck between two blockers) as a special case. This is probably the correct approach.

Idea ♠ for the first scenario (basher moving through solid wall):

• The basher shall keep track of the encountered blocker field flags, instead of losing them before every physics update.
• The basher's bookkeeping of encountered blocker flags is only reset after finishing his walk when has removed earth.
• If the basher has been turned by blocker since his last swing, then walls at least as high as X shall prevent the basher from walking forward; it should walk on the spot instead.
• If the basher has not been turned, he will always walk forward normally, even if there is a wall of height X.
• In any case, the basher shall still be allowed to move into solid terrain.
• X should be at least 6, and at most 13, which is the normal wall height that turns walkers. Walkers will scale a wall of height 12, but nothing higher.

I believe that ♠ works for the miner, too. The blocking wall height X might be slightly higher for the miner. I'm thinking of X = 7 for the basher (walls <= 6 are okay then, half the walker's height) and X = 11 for the miner.

I haven't tested this at all. I haven't slept much at all. Here's a lovely picture, so everyone can enjoy the thread.



-- Simon

[ccexplore]

I'm not entirely convinced of the need for this difference in basher's walking behavior with and without blocker; again can one explain why stalling is so objectionable?  It feels like you're basically saying that yes, the basher can move through solid terrain anyway in some cases, but we'll make an exception to disallow it just when the blocker's involved, because...?  I'm basically suggesting "maybe let's not allow bashers and miners to move through sufficiently solid terrain, since it's not obvious that their ability to remove terrain also grants them the magical ability no other lix skills/actions seem to have of moving through solid terrain".

I'll grant you that the obvious difference is "well, with the blocker, the basher [while still swinging the shovel] wasn't looking/working at where he ends up moving towards".  It is a difference alright, even though it doesn't feel to me as natural a reason to affect forward movement as, say, the amount of in-the-way terrain.

It may well be that stalling based on amount of in-the-way terrain may end up rarely or never stalling in the no-blocker case anyway, since it's likely that you typically might not be able to re-add terrain in front of the basher fast enough to result in any appreciable amount of terrain to cause stalling.  I'm not as familiar with the details of lix's physics to tell which setups are feasible or not feasible.

I don't feel strongly enough to be upset or anything if you end up introducing this blocker-based difference.  With things like the miner canceling fix, we are already deliberately complicating the physics in ways that are not necessarily intuitive.  But at least the miner-canceling fix is aiming to solve real actual problematic behavior that impacts SP and MP levels.  It's not clear to me yet how stalling a basher could reach that level of "problematic".

Here's one other thought: instead of stalling outright, you could alternatively shorten the cycle, skipping the "trying to move forward part" and immediate make the basher start another stroke, whenever it gets into a situation where there's "sufficient" amount of terrain in front of where's he's moving into.  It's really still a form of stalling, but perhaps less exploitable?

[Nepster]

Instead of stalling outright, you could alternatively shorten the cycle, skipping the "trying to move forward part" and immediate make the basher start another stroke, whenever it gets into a situation where there's "sufficient" amount of terrain in front of where's he's moving into.

Good idea, but I would replace the "whenever" part by "whenever the basher was turned around by a blocker".

With Simon's mechanics, there might be some ways to exploit the ability to move into terrain:
- On a terrain which rises only very slightly, the basher usually stops after one stroke. However one could now use blockers to move the basher into terrain, which enables the player to start a permanent basher.
- Depending on the precise mechanics the following may work: Move the basher into the terrain and then change her to a digger. This might separate her from the rest of the Lix.
- Moving into terrain could be used to create deeper bomber holes, cuber-boxes that can be stepped upon by other Lix, ...

[ccexplore]

So again, it sounds like "moving into terrain" is the problematic aspect, yet apparently, people either feel so bad about stalling that they'd like to keep that to only special cases, or they actually feel "moving into terrain" is general acceptable except for the blocker-turned cases, where I guess the main difference is that the terrain being moved into is likely pristine (ie. never disturbed by the stroke that was just executed).

Neither point (badness of stalling or goodness of moving into terrain) feels self-evident to me, but I guess given time (or better explanations of those points by others), I can probably begrudgingly come around to it.

If the fix really must be special-cased to blocker-turned lixes, then I do think making them immediately start a new cycle seems more preferable to me, versus exceptionally disallowing it moving into terrain.  I think I feel that way because instead of the blocker somehow influencing an innate capability (ie. can move into terrain or not), it is a direct and immediate reaction (even if a special one) of the basher/miner to turning.  Granted, for the miner case, there may be some speed mining potential with that proposal that may prove too abusive for some levels?

[geoo]

IMHO I think it's acceptable (ie. stall bashers using cubers), since the only other alternative is that the basher moves ahead anyway into the cube and essentially winds up in the same situation as your "glitch" here, or maybe it stops bashing altogether which seems even less logical.  Are there any abuse in MP or SP that you feel is problematic with the stalling behavior?

I think the perceived difference here is that walking through terrain like that is exploitable, while the effect from walking into a cube can also be achieved by placing the cuber a little later (i.e. around the basher) instead.

As with the miner fix, accordingly the idea is to keep observable changes from before to a minimum, resulting in rather convoluted rules.

I'm not quite sure about this myself. I guess Occam's razor (and realism) dictates simply having the basher not move forward if a wall has appeared in the meantime. But where do you draw the line? Surely a builder shouldn't be able to stall a basher? With enough cubers it allows indefinite stalling, but I think in SP it's not so much of a concern as it's expensive, and in MP the best way to get through cubes is spamming miners anyway rather than having a single miner do all the work. So yeah, stalling feels like the cleanest option.

I'm not 100% happy with the miner fix myself either. It's a complicated workaround for a pretty cheap and powerful singleplayer trick that doesn't work consistently. Unless you meddle with the miner by removing terrain, everything will be as before, but unlike the basher's ability to move downards, it's a lot less predictable for the miner. I don't think there's a nice solution to this.

[namida]

But where do you draw the line? Surely a builder shouldn't be able to stall a basher?

Should the basher move up the builder's staircase as it moves forward, then?

[Simon]

The problem isn't the basher/miner moving inside the terrain.

The problem is how 1 basher + 1 blocker are used to let the basher work ahead, but will keep the crowd safely between the blocker and leftover wall. This result should need an extra blocker/cuber. It's a rather specific result we would like to counter, therefore the condition to trigger a fix needn't be simple at all costs.

With 1 basher + 1 cube, surely you can bash and then put the cube behind the basher. This will not contain the crowd safely however.

Instead of stalling outright, you could alternatively shorten the cycle, skipping the "trying to move forward part" and immediate make the basher start another stroke, whenever it gets into a situation where there's "sufficient" amount of terrain in front of where's he's moving into.

Good idea, but I would replace the "whenever" part by "whenever the basher was turned around by a blocker".

This sounds like it needs an extra case to handle getting stuck in between two opposing blocker fields. Will keep in mind nonetheless!

[About Simon's first proposal] - Depending on the precise mechanics the following may work: Move the basher into the terrain and then change her to a digger. This might separate her from the rest of the Lix.

Smart. This adds a 3rd skill to the mix and makes the setup more specific. My gut reaction was to shrug it off as too obscure, but it's not easy to ignore.

<SimonN> right now thinking about this fix:
<SimonN> let basher walk into terrain if not turned; but stall at the tiniest piece of terrain if she has been blocked since removing earth
<SimonN> (blocked == turned around, not only having been in a field)
<Proxima> that souds good
<SimonN> This will stop dead all blocker shenanigans, even if it looks a little strange on almost-flat slopes
<SimonN> But nobody in their right mind would bash the air there, and then block the basher

-- Simon

[ccexplore]

But where do you draw the line? Surely a builder shouldn't be able to stall a basher?

Should the basher move up the builder's staircase as it moves forward, then?

That's pretty much what I have in mind.  For the basher at least, it also results in symmetric behavior with regards to their ability to tolerate small downward steps as basher moves forward.  I proposed the walker/ascender height as the threshold for blocking forward movement since presumably we don't want or need the complexity of basher->ascender->basher transitions to actually match parity with a normal walker.

I did concede that I could probably live with not having the ability to step up as it moves forward, and only stipulate that it won't move forward when there's "too much terrain" ahead.  The idea is that, okay, so you're technically moving into terrain, but only when it's such a small amount of terrain that even a walker can step up to, so maybe not that big a deal?  (But definitely exploitable for specific terrain setups.)

I guess I do have to admit that if we allow moving up a builder's staircase, it does open up possibilities not currently possible, and therefore may well tilt things into the direction of "too exploitable".  Then again, bashers can already move down a builder's staircase, so I think this is less an issue of the behavior being inconsistent or unnatural, and more about whether the new behavior can become too exploitable especially wrt to existing levels.

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

Regarding the miner fix, it is complicated and feels unnatural to exist, but based on your arguments around how exploitable it is, it seems to be a necessary evil.  Moreover it seems like there's the real danger that if we apply the behavior change too generally (ie. too tolerant against canceling), it could potentially allow for currently unexpected possibilities like the ability to continue mining down 45-degree slope, which can wreak havoc in existing levels especially when such possibilities may not even require the player purposely setting things up for exploitation.  It seems less the case here that the ability to step up while moving forward has quite that degree of exploitability, since the basher/miner constantly removes terrain to counter against unchecked upward movement, making it such that the player needs to put real efforts into enabling prolonged upward movements when moving forward.

[ccexplore]

The problem isn't the basher/miner moving inside the terrain.

The problem is how 1 basher + 1 blocker are used to let the basher work ahead, but will keep the crowd safely between the blocker and leftover wall. This result should need an extra blocker/cuber. It's a rather specific result we would like to counter, therefore the condition to trigger a fix needn't be simple at all costs.

With 1 basher + 1 cube, surely you can bash and then put the cube behind the basher. This will not contain the crowd safely however.

I get that when the blocker is involved, there are much more exploitable behaviors.  I think for me it's just that I'm not generally in love with the idea of adding increasingly many one-off special cases to the physics.  It feels like it ultimately makes the player feels less confident about their ability to reason over general physics interactions if there are so many one-off special cases getting in the way.

So yes, by all means fix the basher+blocker exploit case.  I'm just less sure that the fix has to be so surgical here.

That's me speaking philosophically anyway.  From a pragmatist standpoint, yes, I suppose the more surgical the fix, the less we disturb the general physics and the less potential effects it would have against people's existing levels and replays, for the cost of more difficulty understanding it.

[ccexplore]

I can't really tell where this has currently landed on IRC, other than seeming to lean towards special casing blocker-turned bashers/miners.  If we end up special-casing, I'd like to throw in my vote for "immediately start the next stroke" in place of "stalling" (there'd still be a terrain check just as you would've checked with stalling).  The idea being that if we aren't going to promote stalling into a general behavior of the basher/miner, then rather than introducing it as a new special behavior not featured in any other cases, let's just use a variation of an existing behavior (terrain-removal stroke) instead.

[Simon]

Thanks for the vote. Walking on the spot seems odd anyway for the basher sprite.

Skipping the remaining walking frames is interesting. I would skip frames upon encountering solidness after being blocked, not immediately after being blocked.

-- Simon

[Forestidia86]

I encountered this issue with a miner in my Daunting "Hellfire" playthrough as well. (cf. issue 47) (v.0.9.8).
For my situation it was rather nasty I think since it just clipped the lix a bit in the direction of the turning and mined from there (a place where it couldn't succeed anymore).
I've attached in a zipfile a replay to show that off and a screenshot (spoilery).