[SUG][PLAYER] Tweak to jumper physics

[Proxima]

I asked namida over discord for permission to make this topic, in view of the decision about "no new physics suggestions". This is actually a suggestion I made a while back that got sidelined, so namida said it was okay to bring it up.

The attached level (requires proxima_greenhill style) shows a problem I have with the jumper: on rough terrain, if you assign it just before a step of at least 2 pixels, the jumper immediately stops, effectively wasting the skill. This is uncomfortable, and my suggestion is to relax terrain checks at the very start of the jump.

namida points out that any change could affect existing content, but I think this is such a small tweak that it would be unlikely to break anything, especially as it's very undesirable for backroutes to be blocked with single pixels.

Any support for this?

[Dullstar]

If we're concerned about breakage (I don't expect it would be severe), I think this would at least be worth trying out in an experimental build to properly analyze breakage.

[namida]

If we're concerned about breakage (I don't expect it would be severe), I think this would at least be worth trying out in an experimental build to properly analyze breakage.

The breakage would be in the form of "some things become possible that weren't before", which can be particularly tricky to spot.

[WillLem]

+1 for Proxima's suggestion.

Also support for the idea of an experimental to assess breakage, although I can see how "things are now possible that weren't before" is a much more difficult thing to spot and probably wouldn't be picked up via replay checks.

[namida]

and probably wouldn't be picked up via replay checks.

Replay checks would absolutely be unable to detect it. It would need to be done via manual examination, at which point the need for an experimental to test it is very little - sure, the exp could confirm 100% for sure whether there's an issue or not once a suspect location is identified, but it wouldn't help in spotting places where there's likely to be an issue.

If we can get a rough idea of how many rough-terrain or containing-steep-slopes levels use Jumpers, that might be a useful starting point. If this is very few, it may be the case that even if all of them were to be affected - keeping in mind "affected" would be "new backroute is introduced" rather than "intended solution breaks" - it wouldn't be an issue. On the flipside, if there's a lot, it might be safest to avoid making the change just in case.

I'm also somewhat inclined, seeing as this only really came up as an issue in theoretical discussions prior to the Jumper's release, to say that nothing needs to change because it's proving to be fine as-is.



There are basically three possibilities here regarding the overall outcome:

Option A - a special case for a pixel 2 above and 1 to the right (or left, if facing left) of the lemming's starting position, similar to the special cases for builder->jumper at 0,-1 or for dehoister at 0,0. Should have very little breakage, but introduces yet another special case.

Option B - explaining this requires understanding how the Jumper moves - each frame is divided into multiple 1px horizontal or vertical (not diagonal) movements. So for example, on the first frame, the Jumper moves (1px each step) up, up, forward, up, up, forward. The change would be - if a lemming's foot check detects a pixel, and the next movement would be an "up", the lemming only transitions to another state if the pixel 1px above his foot position is also solid. Current behavior remains if the next movement is forward or downwards. This could have wider breakage, but an advantage is that it removes the builder special case (as this new general rule would cover it).

Option C - leave it as is. My preference at this stage, simply because it hasn't proven to be a major issue.

[Simon]

I like B, a general rule that removes hacks elsewhere.

Jumper eagerly latching to ground, this feels odd and is worth investigating.

Extra breakage of B comes from how the jumper will latch less during the entire first half of the arc, i.e., whenever there is possibility to move up as a next single-pixel substep. Overall, B has greater breakage than A. This breakage, we can catch some of it with replay checks. But there is an argument that the fix worth it even here: Would you ever want to latch if the next 1-pixel-substep were upwards?

-- Simon

[Strato Incendus]

-1 for this. I'm for C, leave things as they are .

We already have enough new physics worries with the two final skills Laserer and Slider at this point, plus we've recently had a Swimmer physics change that lead to quite a few breakages. And then there was the Glider physics change a while before that.

Jumpers bumping against pixels of terrain and being cancelled as a result, while it may be annoying here and there, is in principle no different to me than being able to turn around a Builder on small protruding pixels, or to turn around a Platformer on a small gap resulting from such pixels. I simply think intended solutions shouldn't rely on such well-hidden opportunities to turn a lemming around.

But just like we won't be able to prevent this on a physics level for Builders and Platformers, I think we also shouldn't fiddle with the physics just to try to change this for Jumpers. Rough terrain will always be a problem when it comes to precise assignment of skills - also for destructive skills, for example, when making them pass through each other and doing other timing-based shenanigans.

Thus, the onus is on the level designer anyway to work around such accidental pixel precision. The proposed physics changes wouldn't solve this problem for good, it would just be an attempt to potentially solve a small part of it, and that attempt would come at the cost of further potential breakage of existing levels.

[IchoTolot]

I tend to agree with Strato here, even without considering possible breakage.

It's basically comparable to a builder being assigned before a 2 pixel step and in that case the builder hits it and reacts as with any other obstacle. Why should the jumper step out of the line here and gets special treatment?

Like the builder the jumper hit an obstacle here, even if it's small and the skill should act accordingly otherwise it's inconsistant.

Rough terrain just tends to get in the way with skill paths and I am against introducing special skill behaviors that step out of the line. There will always be points in a level with rough terrain where a builder/jumper/glider/.... gets stuck on a pice of terrain, even if it's just a few pixels or even a pixel in size.

You could even use those 2 pixel steps in order to make longer "jumper-save" stair-cases.

[WillLem]

Jumpers bumping against pixels of terrain and being cancelled as a result, while it may be annoying here and there, is in principle no different to me than being able to turn around a Builder on small protruding pixels, or to turn around a Platformer on a small gap resulting from such pixels

Good point, and certainly a strong argument for option C (leave as-is).

However, the Builder and Platformer are relatively static skills compared to the Jumper, which feels like it ought to be able to traverse whatever little bits of terrain are in front of it. Having it not able to do so makes it feel somewhat underpowered... then again, maybe being able to use the behaviour to turn a lemming is a power in itself.

[namida]

The lemming wouldn't turn. He simply treats it as a ledge to land on.

With that being said - ultimately, I'm going to go with "no change" here, primarily on the basis that it's how the Jumper has behaved since the stable release, and that issues raised with the existing behavior are primarily coming from the theoretical side of things rather than from actually encountering it as a problem in hands-on play. I'll also note that the absence of a skill shadow indicates when this will happen, and NeoLemmix does make it easy to reverse this. While if the Jumper hadn't gone stable yet, I could certianly see the balance leaning towards "change it", I feel that the argument isn't strong enough to justify a change post-stable.

So my final decision here is - no change to the Jumper in this regard. Definitely worth bringing up though - it's a close call here, so it's well worth having the various points on each side raised instead of just a blind "keep it as is".