[SUG][PLAYER] Use a separate "looker" state instead of shrugger for throwers

[WillLem]

Walkers should have priority when in the thrower state, because you cannot assign a throwing skill to a lemming in that state
---
This is only a bug in regards to them having the priority over shruggers.

In that case, I'd suggest that:

a) the "shrugger" state be something different - maybe the lem could put their hand on their forehead as if to look at what they've thrown, before continuing walking (e.g. a "looker" state)

b) this state be activated as soon as the current projectile leaves their hands - or, maybe, no more than 2-3 frames later, allowing for a nicer animation

[namida]

a) the "shrugger" state be something different - maybe the lem could put their hand on their forehead as if to look at what they've thrown, before continuing walking (e.g. a "looker" state)

This was proposed before, when the idea was floated that maybe the thrower-shrugger should have minor physics differences from the builder-shrugger (as I didn't want the literal same state to have these differences, but a similar but unique state having them is okay). It didn't end up going anywhere.

Is there any situation where, despite all of skill queueing, directional select and highlight existing, you'd still need this priority change?

[WillLem]

(re: proposed "looker" state)
This was proposed before... It didn't end up going anywhere.

Maybe it could go somewhere now that it has been proposed again? Personally, if the projectile skills make it into stable I'd like to see a unique state for the post-throw anyway (i.e. regardless of priority), and I would strongly support any suggestions/ideas to that effect.

Is there any situation where, despite all of skill queueing, directional select and highlight existing, you'd still need this priority change?

I don't suppose there is given the existence of the tools you mentioned. And, it can sometimes be favourable to have 2 lems spearing from the same spot (bridge building and delay tactics spring to mind). So, perhaps this part of the suggestion can be ignored.

The "looker" state (or similar) is something I definitely think should happen though. Happy to re-post about it in the discussion topic if necessary.

[namida]

What will be different about it compared to Shrugger, physics-wise?

[WillLem]

Ideally, it would be reached more quickly and last longer.

So, at the moment the "thrower" state lasts for 6 frames, and the "shrugger" for 8. That's already a pretty good window as it is, to be fair, but it could be slightly better.

If the proposed "looker" state were to last, say, 12 frames, that's an extra 4 frames of repeat assignability from the same spot. And, if the "thrower" state were super quick (say, 4 {or even 3} frames), then the lem's unassignability window would be shorter.

This would have the effect of reducing the "wait" time between repeat assignments to the same lem, whilst extending the time spent on the initial throwing spot, and also meaning that passerby lems are potentially less of an issue when using the skill in realtime. All of this would make the throwables that much better in terms of their assignability and their usefulness as delay skills.

[namida]

How quickly the shrugger/looker state is reached is not a property of the shrugger / looker state; it's a property of the state leading to it (in this case, thrower).

Lasting longer is indeed a difference in the shrugger / looker themselves, but I'm not really sure that it's justified. It would mean a new state is being introduced, that (physics wise) is identical to an existing one except it lasts a few frames longer. The only reason for this state to be here is that it reduces the risk of assigning to the wrong lemming when spamming assignments. This is even further weakened in light of that I haven't yet seen a case where this problem arises and getting the exact right lemming(s) matters and none of the existing fine-control features (such as highlight or directional select) can deal with it. Not to mention - if a custom level that gave rise to such a situation were to be made, it would be too much of a frustrating-execution level for me to care much about; challenge solutions, while a more valid reason for such a situation to exist, should not be given too much weight when deciding physics.

Now perhaps a reason why a looker state could be justified, is if it went beyond just "a few frames more than the shrugger", such as "remained as a looker until the projectile impacted or went off-screen". However, in general, it seems the preference was for the lemming to only have a short delay after throwing, rather than waiting for impact.

[WillLem]

How quickly the shrugger/looker state is reached is not a property of the shrugger / looker state; it's a property of the state leading to it (in this case, thrower).

In that case, I suggest reducing the duration of the "thrower" state.

Now perhaps a reason why a looker state could be justified, is if it went beyond just "a few frames more than the shrugger", such as "remained as a looker until the projectile impacted or went off-screen"

+1 for this! I must have missed this vote - this is definitely what should happen! A unique state adds further definition to this skill, and waiting for actual impact/disappearance of projectile seems like a great idea.

[namida]

Keep in mind that that would make them very powerful as delay skills - and they, especially grenader, are already very powerful.

[Dullstar]

I think having a separate "looker" state instead of re-using shrugger is a good idea in terms of visuals, but I think it might be sufficient for it to just be a reskinned shrugger.

[Strato Incendus]

and they, especially grenader, are already very powerful.

Is that still true after the most recent update (V6), though? Have any Grenader backroutes been persisting since then?

[WillLem]

Keep in mind that that would make them very powerful as delay skills - and they, especially grenader, are already very powerful.

I'm not sure I agree that they're very powerful. Sure, they're instant-effect skills which also delay the lemming, and allow the lemming to remain in the same spot - that's powerful, no question.

However, they also have many limitations:

Spearers, by themselves, cannot be used to get the lemming that throws the spear off the ground (that is, from a small platform or pit area). They also require large quantities to be provided in order to build a sufficiently large bridge to cross, say, a water pool. Furthermore, whilst they can be used to make a "blocker", this requires ideal positioning and, sometimes, very fiddly execution - such as when 2 spears need to be placed perfectly side-by-side.

Grenaders, now that they have the smaller crater, again require large quantities to make it through a sizable chunk of terrain. They also, by themselves, cannot be used to remove terrain immediately beneath the thrower's feet (and are therefore not "replacement bombers", as such).

The range/arc element of the skills can also be limiting: if a platform is too near the top of a level, the projectile is useless since is simply disappears offscreen. They also require a navigable area that's at least the length and height of the full arc in order to be immediately useful; otherwise, other preparatory measures must be taken to ensure their usefulness.

A good example of this is in the attached solution to Crazy 4 Lemming Express for the 4-skills-only challenge. Note that, in order to throw a single spear to turn the worker lemming around at the end, it's necessary to blow many holes in the terrain above the lemmings to clear a path for that spear.

So, are they powerful? Sure! Are they very powerful? I would argue not so much. Are they too powerful? Definitely not.

Since the proposed state would change the length of time they remain on the spot, for better or worse (i.e. sometimes it would be shorter, sometimes longer, depending on the layout of the map and the location of the thrower), I'd say this would be a good move to a) add further definition and uniqueness to the skill, and b) enhance and refine its usefulness as a delaying skill.

[namida]

Added a poll.

[WillLem]

I voted for option 3, but 2 would be equally good.

Just to clarify something: does this mean the thrower would start walking immediately upon impact/disappearance of the projectile, or would there be some time (even 1 frame) to repeat-assign?

[namida]

Alright, there's not much preference for option #3. The only person who's voted for it has stated their position and said they'd also be fine with current behavior but longer window to assign.

I guess my next question is - to those of you who'd like a longer assignment window, what's the reason for this? Is it simply convenience, or do you have ideas that would benefit from it beyond this? Do you think the period in which assignment of a new skill should be possible, should start earlier than it currently does, or end later, or both? (And by how much?)

If there is any difference in the duration, it would need a unique state. Keeping the same duration but just shifting it to a bit earlier would not need a unique state, it could still use the shrugger - but that doesn't seem to be what the preference is.

The other thing that comes to mind is, if it's a "looker" state, should it end early if the projectile impacts before it would usually finish? There is also the option of a Looker falling down (either while remaining a looker, or - my preference - transitioning to a faller, and then upon landing, a walker) if the ground underneath him is removed - something a Shrugger does not do. Even if we keep the same duration, perhaps just to allow for this (which feels more natural to me, and the Shrugger's behavior is more kept to preserve existing content) we want to introduce a Looker state...

[Proxima]

Hard to put my finger on exactly why, but I feel the lemming becomes available for re-assignment too quickly. A longer delay would be beneficial from the gameplay point of view since when you spam several grenaders you could see more of the effects before you choose to assign, and it would be easier to avoid the very common mistake of assigning one too many. (Of course, spamming shouldn't be the most common use case and maybe we shouldn't be bothered too much about what it feels like.) Still, even in general it just feels quicker than I would expect it to be at the moment.