[DISC.][PLAYER] Jumper physics

[WillLem]

The vanilla Jumper, by itself, can cancel another skill; get one lemming over a gap without using up a builder; get one lemming past a trap; get one lemming over a blocker/stacker (excellent for when your worker lemming needs to die or block and you need a second worker); get a lemming to a higher elevation; get a lemming to a lower elevation without floaters/gliders given a favourable terrain setup; get a lemming partway up a wall or close to a ceiling to bomb/stone there or collect a pickup skill. To all that, we've already agreed to add transitioning to a climber, allowing the climber to wall-jump, and gliding from the peak of the jump.
...
If you can look at all that and still think the Jumper needs more bells and whistles in order to pull its weight, then I guess we're not talking the same language any more.

Yeah, that is pretty good actually.

Still, I'm liking the idea of a Jumper-in-an-updraft demo. Seeing it in action might be the best way to evaluate its potential either way.

[namida]

Video / test build will come later if it still seems necessary, but for now, here's an image I constructed showing the actual path (which at some point slightly deviated from the earlier specs - it's 37px wide and 19px high, so 1px extra in each direction, but this feels "right" so unless there's significant objection I'm leaving it this way), vs my proposed path when an updraft is involved.

The rule being applied to figure out the updraft path is:
- If there would be downwards vertical movement this frame, the first downwards pixel movement does not occur.
- Otherwise, an extra one pixel of upwards movement is added at the start of each frame.

How this would apply if a lemming entered an updraft mid-frame is TBD. It's also likely I'll make deviations from the above specifics to make the path tidier (while retaining the overall concept of "one extra pixel of height gain / one less pixel of height loss per frame").

(The two halves of the attached image are identical, except for which path is in front of the other graphically.)

[Proxima]

Seems like a fairly mild change, then -- and it shouldn't be too confusing for new players since it would be visible in the skill shadow. I've changed my vote from "no" to "no preference", but that's as far as I'll go -- I don't think it's important we include this interaction.

[Strato Incendus]

I think this is a subtle but completely valid change. An updraft in this specific position would thus still allow the Jumper to cover the same width as before (no longitudinal extension of the leap), but the point at which he lands on the other side could be slightly (=4 pixels) higher if he jumps through an updraft, compared to a regular jump, where, if the full length of the jump is required to cover the distance, he would have to land at the same height as he started (if the wall were any higher, he'd instead bump against it and fall down).

So I would be completely on board with this, if this ends up being the difference between regular and updraft jumping!

Question: If a Jumper hits the side of a platform that's just slightly higher than his starting position, will he engage in "hoisting" behaviour, just like the Shimmier does when encountering a platform that's slightly higher than the current position of his feet under the ceiling?

[IchoTolot]

If the change is only this minor than the extra rule is even less justified.

This also leads to another danger that is that this difference is accidentally overlooked. Changes should not be too subtle.

An updraft in this specific position would thus still allow the Jumper to cover the same width as before (no longitudinal extension of the leap), but the point at which he lands on the other side could be slightly (=4 pixels) higher if he jumps through an updraft, compared to a regular jump, where, if the full length of the jump is required to cover the distance, he would have to land at the same height as he started (if the wall were any higher, he'd instead bump against it and fall down).

From a design standpoint you can also simply make the other side 4 pixels lower. Why introduce an extra rule when a very slight edit by the designer in the editor can achieve the same effect?

For this mild change I think an extra rule is even less justified and I would be even more on the no side.

[WillLem]

I'm not entirely sure what the picture is showing to be honest!

IchoTolot has a valid point; I'm starting to feel like if that updraft doesn't give extra jump distance as well as jump height, it might not be worth it after all... keeping my vote as a "yes" for now though.

Double jump, then?

[namida]

Okay so while the vote is only very slightly in favor of "no effect", the reasoning explained by some people is pushing me towards that side as well.

So - I'm going to say that this one is a "no", with the caveat that if opinion changes between now and V12.9.0-stable's release, I'm open to reconsidering this. But in any case, I won't discuss it again until an experimental or RC version of NL that includes the Jumper has been released.

On discussion alone, I'm going to rule out any kind of double-jump or other mid-air jump at this point.

[namida]

Let's think about the Jumper in connection with every other possible lemming state, to see if there's any edge case we've missed here. Let me know if there's anything you think I'm overlooking.


Walker - Assigning a Jumper to a Walker is of course the typical case. A jumper becomes a walker upon landing, or upon hitting a wall so short he can step up it without becoming a Hoister. In terms of the Walker skill, assigning it to a Jumper will not be allowed.
Ascender - Jumper and Ascender never directly transition to each other.
Faller - Jumper becomes a Faller upon hitting a wall (also turns around in this case) or ceiling (remains facing the same direction in this case). Jumper cannot be assigned to a Faller.
Shrugger - Assigning a Jumper to a Shrugger works as normal. Obviously, there is no case in which a Jumper becomes a Shrugger.

Reacher - Jumper cannot be assigned to a Reacher. A Jumper will never become a Reacher either, although there are cases in which a Jumper can directly become a Shimmier.
Shimmier - Jumper cannot be assigned to a Shimmier. A Shimmier can be assigned to a Jumper if he's close enough to a ceiling to grab it immediately (without a Reacher phase).

Climber - A jumper hitting a wall can climb it if he's a Climber. A lemming climbing a wall can be made a Jumper, and will jump away from the wall.
Hoister - A jumper hitting a wall very slightly further than the distance he can just step on to it, will become a Hoister. Jumper cannot be assigned to a Hoister (maybe it should be possible, as a "last-second wall jump"?).

Swimmer - A Jumper who hits water and is a Swimmer, begins swimming immediately (or drowns otherwise). Jumper cannot be assigned to a swimming lemming.

Disarmer - The normal universal rule for "transition to Disarmer" applies - the lemming must be standing on solid ground. Therefore, a Jumper could only become a Disarmer if he lands exactly on the trap trigger area and the trigger area does not stick out of the ground at all. (Perhaps this should be simplified: "Jumper will always be affected by a trap") A Jumper cannot be assigned to a lemming who is disarming.

Floater - Floater and Jumper never transition directly to each other. (Can't assign Jumper to a floating lemming; in the other direction, they'd go via Faller.)
Glider - Jumper cannot be assigned to a gliding lemming. Edge case: A Jumper transitions to a Glider at the peak of the jump, not the end.

Bomber
Stoner
- Jumper immediately performs these actions without Ohnoing first.

Blocker - Neither skill can be assigned while performing the other. A Jumper who encounters a Blocker will bounce off him and otherwise continue the normal trajectory.

Platformer
Builder
Stacker
Basher
Fencer
Miner
Digger
- Jumper can be assigned to all of these; none of these can be assigned to Jumper.

Cloner - Permitted and works as normal; the clone will face the opposite direction and otherwise continue the same trajectory as the original lemming.

Exiter - Jumper obviously cannot be assigned to an Exiter. A Jumper will become an Exiter only if it encounters the exit trigger area on solid ground (not in midair). I am open to "Jumpers never exit" instead if this is preferred; I'm not open to "Jumpers can exit in midair".
Death states - Jumper cannot be assigned to the lemming. A Jumper will transition to these states as per normal rules.

[Proxima]

The one thing I'm unsure about is the Hoister state. We agreed on the 36x18 trajectory because we felt a 32px gap should be crossable, and a 16px step ascendable, with a bit of leeway; but the Hoister would effectively increase the jumper's reach (certainly vertically, and maybe horizontally as well?). So I would think it should either be 36x18 with no hoisting, or a smaller trajectory (32x16 maybe) with hoisting. But maybe I'm overlooking something.

[namida]

The Hoister doesn't increase horizontal reach in any way.

For vertical reach, 0 to 2 pixels high transitions to a walker, while 3 to 5 (or 3 to 8, if the lemming is a climber - this is essentially just "he climbs it, but he's close enough to the top from the start to hoist immediately") becomes a hoister first. This would mean that:

- Up to 21px above the lemming's initial position can be reached directly
- Up to 24px above the lemming's initial position can be reached via hoister (though this needs to be quite precise if it's exactly 24px)

The result feels completely right, at least to me, when trying it out in-game. Although, it might be preferable to use an Ascender here instead, but this would pretty much just be a visual change (aside from the Hoister-Jumper wall jump possibility, I guess). I suspect any tweaking regarding the exact height is something that would be best left until there's an exp / RC build available.

[Strato Incendus]

Ascender - Jumper and Ascender never directly transition to each other.

Haha, the "old" Jumper to the "new" one! So I guess this means it's not possible to assign a Jumper to an Ascender (just like it's not possible to assign most other skills to Ascenders).

But couldn't a Jumper theoretically land on such a spot of terrain that he would have to ascend right away after landing (without ever being a regular Walker in between)? Or would he just "bump" against a "6-pixel wall" and turn around instead? What about altitudes lower than 6 pixels but higher than 1?

Hoister - A jumper hitting a wall very slightly further than the distance he can just step on to it, will become a Hoister. Jumper cannot be assigned to a Hoister (maybe it should be possible, as a "last-second wall jump"?).

Thanks, the first part answers what I was asking! So it will act just like the Shimmier in that case.

Regarding Hoister-to-Jumper transitions: If those are possible, I can already see WillLem create a pixel-precise level with a trap right at the top of a Climber's path, and a platform behind the Climber that you have to jump to, but the platform is placed at such a height that you can only reach it from the top of the wall (=where the trap is). In that case, you couldn't assign the Jumper while the lemming is still climbing (because he'd jump too low and miss the platform behind him), but you couldn't wait until he had finished climbing either, because then he'd go into the trap.

Or, alternatively, there wouldn't be a trap, but since the lemming would jump forward again once he is a Walker again, the Hoister state would be the last chance for him to turn around as part of the jump.

So I think, the main question should really be: If Jumpers can be assigned to Hoisters, do they jump forward (as soon-to-be-Walkers), or backwards (as still-Climbers)?

[namida]

I would see a Hoister as jumping the same way as a Climber if allowed, especially since for most of the hoist they're not quite at the top of the wall yet (try observing it frame-by-frame, in particular watching the position dot, in Clear Physics Mode).

Let's be careful about specifically accusing other users like that, especially when those users have shown that they're learning what is or isn't considered fair in a level and making efforts to improve (I'd probably be a bit less bothered if it was an accusation that someone has repeatedly, over many years, shown to be valid with no attempts to remedy it). With that being said, the general concept of what you're saying is valid - but I'm generally only going to rule out / cull a feature based on troll potential if the troll potential is the dominant aspect of it, or if the other features are relatively low importance. If it has lots of legitimate use with a few trollish edge cases (like how No Overwrite does), then I'd rather handle the troll potential via combination of discouragement, and where possible, features that reduce the effectiveness of the troll setup without breaking legitimate use cases (to use the same example, Clear Physics Mode would be the biggest counter-feature).

I'm not saying Hoister->Jumper is a definite. I'm very much open to not allowing it; I just don't see "troll potential" as a good reason at this stage.

[Strato Incendus]

I'm sorry, I didn't mean that to be an accusation - just something that would fit the level design philosophy he actively stated he enjoys personally, and thus, this would be completely fine in my book . I am aware he's actively trying to create levels that go along with the majority opinion in the NeoLemmix community.

I do think this might result in some pixel-precise levels - because otherwise it might rarely make a notable difference whether a regular Climber vs. a Hoister jumps, unless the level designer actively enforces it.

But fortunatly, the Hoister animation takes a couple of frames, so it should still be comparatively reasonable to assign any skill to a Hoister in general.

I just don't remember any particular other skill that you can assign to a Hoister?

[namida]

I just don't remember any particular other skill that you can assign to a Hoister?

Bomber, Stoner and permanent skills; that's it. (EDIT: Maybe Cloner too, not sure off-hand.)

[Strato Incendus]

Thanks for the overview! In other words: You can't assign a Shimmier to a Hoister.

Based on that, would it be reasonable for the player to assume that they can assign a Jumper to a Hoister?

Puzzle-wise, I think the most important gain of this mechanic would be allowing the Climber to turn around before looking forward again as a Walker.

Additionally, and easy to overlook, is the fact that Shimmiers and Jumpers can also become Hoisters now; iit would thus allow a Shimmier arriving on a platform slightly higher than his feet (causing him to hoist) to immediately jump into the other direction (same for a Jumper).

It would probably not be possible for a Shimmier traveling along a thin platform to immediately turn around through Hoist-Jumping after his arrival and jump on top of the platform he shimmied along before. He would most likely just bump his head on the ceiling he shimmied along and fall down looking in the opposite direction.

Unless you clone the Shimmier shortly before the original arrives, then bomb the clone to make space, so that the original can arrive, hoist-jump to turn around and jump over the Bomber gap created by the Shimmier clone, to then land on top of the platform he shimmied along before.

Do you understand what I mean? It's probably hard to explain without a RC build allowing hoist-jumping to demonstrate.