[SUG] New skill - Runner [Shelved until further notice]

[jkapp76]

I'm still following this. After reading more of your thoughts on it I agree with strato that it should hit traps. Maybe not those directly on the floor, but probably all others that you touch higher than the floor.

I think it'd be okay if it was a tempermental thing that is easily lost. Lost even when jumping maybe.

I'm the kind of person that the longer I look at my work the worse it looks to me, and input from others helps with that, good or bad. So, I just want to say I think the Hoverboarder video looked great. And I think it'd be good even if 15 of the skills cause it to be lost. I like the idea of getting ahead of the crowd and crossing waters above all else. Only the hoverboarder and magic carpet seem to do these. (the L2 magic carpet sinks in water for some reason)

[WillLem]

I’m even more convinced now that the Hoverboarder should not skip traps by default
---
if he’s hovering high enough to move over the trigger areas (instead of through them), he will ignore the traps automatically

We shouldn't have to take the trigger area into account at all - if any skill relies on knowledge of where a trap's trigger area is, then that means that designer and player also have to be aware of it in-game, which is not what we want - CPM should never be a requirement.

If we can agree that the Hoverboarder should bypass all triggered-traps regardless of trigger position, then players will always know that the Hoverboarder will safely bypass the trap regardless of where the trigger area is. Note that the visual example I gave above was to do with fire/water objects rather than triggered traps - they would need to pass fire/water objects the same way that they pass terrain if that object is raised. Conversely, if passing a triggered trap, the Hoverboarder wouldn't change vertical position at all, they'd simply glide past.

Does that distinction change how people feel about bypassing triggered traps?

if he’s hovering high enough to move over the trigger areas (instead of through them), he will ignore the traps automatically

How does the player know whether the Hoverboarder will make it over the trap's trigger area? If the only answer is CPM, then either all traps should always be bypassed, or none should.

what a skill would be used for is part of assessing whether it’s useful enough to warrant the effort of trying to implement it in the first place

I see what you mean, but skills can be used for a number of different things. I suppose each skill must have a primary purpose. If the primary purpose of the Hoverboarder is to move ahead quickly, then the "raised off the ground" thing doesn't need to apply, and it might as well be a Runner (to keep things simple).

After reading more of your thoughts on it I agree with strato that it should hit traps. Maybe not those directly on the floor, but probably all others that you touch higher than the floor

Again, since the player can't see the trigger area, the Hoverboarder's position relative to the trap's trigger needs to be irrelevant no matter which option we go with (i.e. bypass or don't bypass).


In fact, having thought about this a bit more, really the only reasonable solution is to allow the Hoverboarder to always bypass traps - if they sometimes don't due to the positioning of the trigger area (which the player can't see), then this is technically unfair to the player.

So, it's either always bypass, or the Hoverboarder can't be a float-above-ground skill. We then have to go with a Runner that's wearing special boots so they can run across Water objects. Not sure if I like that idea...


Actually, any triggered object will suddenly become a matter of "can the Hoverboarder reach it?" - I'm not sure I like the idea of that at all. It should always be clear - designers shouldn't have to mess around with object placement and players shouldn't need to use CPM to check if an object will or won't be bypassed by a Hoverboarder.

We need to decide whether Hoverboarders interact with triggers or not; it can't come down to pixel-perfect placement, it needs to be an over-arching rule. Personally, I'd say that they shouldn't interact with triggers of any kind, and then the purpose of the skill becomes a trigger-bypasser. If we don't like this, and the purpose of the skill should be a faster-moving lem, then let's stick with the Runner.

[jkapp76]

What if the hoverboarder just hits all the traps?

He can run ahead and go over waters but not outrun traps? Would that be terrible?

[Strato Incendus]

In a broader sense, if the Hoverboarder can skip traps, it might even be questionable why he should even be able to exit. That's basically how Ghosts used to work in NeoLemmix 1.43 (Very-Old Formats). Since Ghosts could never exit to begin with, that wasn't a problem. But I don't think we want the Hoverboarder to be unable to exit.

Of course, I don't think this should be a problem coding-wise, since the Disarmer already is a skill that responds differently to trap triggers while still responding the same way as any other lemming to pickup skills, buttons, and exits. So the distinction between how a given skill interacts with different types of triggers is already in place.

How does the player know whether the Hoverboarder will make it over the trap's trigger area? If the only answer is CPM, then either all traps should always be bypassed, or none should.

The other obvious answer would be skill shadows, which don't require the player to activate CPM. But I guess given your aspiration that levels in SuperLemmix should ideally also be solvable in classic mode, relying on skill shadows would probably be considered "just as bad" as relying on CPM?

Then again, without skill shadows, you can't be sure for any skill whether it will make it past a trap in the first attempt or not. Not just with regards to the size, but also the position of the trap trigger. Some traps have their trigger areas very far off to one side (e.g. the Frog trap from L2 Outdoor, or the Flower traps from L2 Highland). Even if you merely try to build over them, building one frame too late can make you build into the trap trigger area, whereas building one frame earlier would have gotten the lemming over the trigger area safely. Same for the Jumper or the Glider.

With that in mind, I don't see why this would be a problem for the Hoverboarder specifically. Much like players learn to anticipate the length and height of Builder staircases with increasing practice, they will also learn to judge whether a Hoverboarder will make it over an obstacle by himself, or whether he might need additional support, e.g., in form of a Jumper.

Yes, the trigger area is a property of each individual trap, not a property of the Hoverboarder skill. But again, the same is true for the Builder: Technically, the player has to memorise / develop an intuitive feeling for how high the trigger area of each trap is, and where in the sprite of the trap it is positioned, in order to reliably assign Builders in the correct spots to get over those traps safely in the first attempt, without relying on skill shadows and/or CPM.

The only way to avoid this - for the Builder, the Hoverboarder, the Jumper, as well as any destructive skill that can go underneath a trap - would be to standardise the trigger areas for all triggered traps. That's basically what they did in Lemmings 2: The Tribes, where all trap triggers are only 1 pixel large.

[WillLem]

What if the hoverboarder just hits all the traps?

He can run ahead and go over waters but not outrun traps? Would that be terrible?

Regarding water objects, please see my comment towards the end of this post.

Regarding traps - let's say we go with "the Hoverboarder hits traps, but only if they actually come into contact with the trigger area"...

This will almost certainly bring about a reliance on using CPM to check whether the Hoverboarder will make it over a particular trap's trigger, whether we like it or not, and whether we intend this to be the case or not. It would introduce another pixel-precise game element that style designers, level designers and players would all have to account for.

This is exactly the sort of thing I'm trying to prevent with a lot of SLX's design, so I'd rather give it a swerve. If we want the Hoverboarder to gain height, then it makes sense from a purely aesthetic/conceptual point of view that they would glide past traps without being affected.

If we go ahead with that, though, then - as Strato has pointed out - they should probably also glide past Exits as well. Since this is probably not something we want, we're back to allowing the Hoverboarder to interact with triggers, which brings back the pixel precision, which is something I want to avoid. So completes the circle that can only really be broken by disallowing the Hoverboarder's height advantage and returning to the Runner skill instead.

I guess given your aspiration that levels in SuperLemmix should ideally also be solvable in classic mode, relying on skill shadows would probably be considered "just as bad" as relying on CPM?

Correct!

With that in mind, I don't see why this would be a problem for the Hoverboarder specifically.
---
Much like players learn to anticipate the length and height of Builder staircases with increasing practice, they will also learn to judge whether a Hoverboarder will make it over an obstacle by himself

Yes, ideally, this is how it would play out. But, we're designing from a place where skill shadows and CPM already exist, making it difficult to implement game elements that aren't immediately ruined by the presence of these particular tools.

If the Hoverboarder ignores all triggers, then their placement becomes irrelevant - this is preferable, and the only way to ensure that CPM will never need to be used to complete a level featuring Hoverboarders.

The only way to avoid this ... would be to standardise the trigger areas for all triggered traps

This is a good idea, and one which I've given some thought. I concluded that it wouldn't be worth the effort of essentially re-making every existing trap (even in only the OG styles) just to account for one minor game feature which I'm not really sure is that great of an idea anyway.

And, such a measure could severely limit future style designs, which is again a sacrifice that the idea in question doesn't really warrant.


Regarding the current poll results (still open if you'd like to vote and have something else to add to the discussion):

I was the only "No" vote - all other votes so far have been in favour of the Hoverboarder interacting with triggers. The only fair, non-CPM-requiring way to meet this preference is to not allow the Hoverboarder the property of possibly missing trigger areas.

With all this said, the current Hoverboarder is only 2px above the position of a regular Walker lem, so they're likely to interact with the vast majority of existing trigger areas anyway. It's possible, then, that the very scenario I'm trying to avoid is unlikely to come up all that much - I do acknowledge this. However...


Regarding crossing of water objects:

...there is another angle to all of this which has occurred to me over the past few days as well:

Now that SLX has multiple water object types, a skill that can traverse all of them once again renders the Swimmer basically redundant. This isn't something I'm happy to do, especially since I'm hoping to increase the profile of the Swimmer skill in the game generally. Having different water types which interact differently with the Swimmer skill is a subtlety that I'm reticent to crash straight out of the game by implementing a skill that ignores them.

I'll add that this should be seen as pretty much a bottom line as far as the Hoverboarder, or any "all-water-crossing" skill is concerned.


Conclusion:

So, we should probably go back to the Runner skill instead. This still endows the lem with increased speed, which can be a way to get the lem ahead of the crowd whilst adding an interesting element for real-time play as well. Augmented Jumper arc is a given.

Having given the permanence-or-not aspect of this skill a lot of thought, it's my thoughts that the Runner should be Walker-cancellable - this further consolidates the purpose of the Walker as a "property/action-cancelling" skill, whilst also meaning that the Runner state can be more extensively managed by both player and designer.

To turn a Runner, I'd suggest that assigning another Runner to the same lem ought to do this. Again, reinforcing that Walkers only turn already-Walking lems. So, then, do Runners turn already-Running lems. Thoughts on this?

As for running-off-an-edge trajectory/action, I imagine that the lem ought to move at least a few pixels away-and-downwards from the platform's edge in a logarithmic arc before transitioning to Faller. This could potentially grant them a few extra pixels of fall distance - do we want this?

[jkapp76]

I'm happy with the runner idea. I can capture all the frames of the L2 runner if that helps at all.

I like reading all the debate over these. It's really caused my opinion to change back and forth. I
liked the idea of the hoverboarder crossing water, but I definitely now agree it deafeats the swimmer
a bit. It might be quite an interesting thing if a zombie could hit a button after crossing poison.

The runner seems to fit SLX better IMO. Run. Jump. Swim. Walk.

[WillLem]

I can capture all the frames of the L2 runner if that helps at all.

Yes, that would be great! I already have a hi-res Runner ready to go from my Lix re-skins, but we will need a low-res one.

Do we have access to the L2 sprites anywhere? We have the DOS ones in .DAT format - can these be extracted?

The runner seems to fit SLX better IMO. Run. Jump. Swim. Walk.

Yes, agreed. It would be a better fit. Ironically, the Hoverboarder would probably be better for NeoLemmix!

[jkapp76]

I can capture frames by slowing down the emulation and grabbing each frame. Then putting them all together in one image.
I don't know anything about extracting the game's data.

The runner seems to flip the lemming's green and blue colors.

[WillLem]

I can capture frames by slowing down the emulation and grabbing each frame

Great work, thanks for this! I think the colour-swap is due to the Runner being a permanent skill in L2.

[Strato Incendus]

I’m fine with the Runner, too — the part of my that is currently focused on designing Tribes-like levels prefers it over the Hoverboarder anyway.

Also, standing by my principle that I favour established skills over new ones, I’d rather not see the Hoverboarder become a thing in the first place than to see the Hoverboarder make the Swimmer redundant (up to the point of the Swimmer’s potential removal) one day.

Having given the permanence-or-not aspect of this skill a lot of thought, it's my thoughts that the Runner should be Walker-cancellable - this further consolidates the purpose of the Walker as a "property/action-cancelling" skill, whilst also meaning that the Runner state can be more extensively managed by both player and designer.

Yes — if the Runner is non-permanent, then the Walker should cancel it, just like it cancels the Shimmier.

To turn a Runner, I'd suggest that assigning another Runner to the same lem ought to do this. Again, reinforcing that Walkers only turn already-Walking lems. So, then, do Runners turn already-Running lems. Thoughts on this?

And interesting idea I had never even considered so far. My only concern here is consistency: Wouldn’t we then consequently also expect it to be possible to turn a Shimmier around by assigning another Shimmier to it? Or turn a Jumper mid-air by assigning another Jumper to it? If we’re talking about the broader category of “non-permanent movement skills”. This would probably also include the Ballooner.

As for running-off-an-edge trajectory/action, I imagine that the lem ought to move at least a few pixels away-and-downwards from the platform's edge in a logarithmic arc before transitioning to Faller. This could potentially grant them a few extra pixels of fall distance - do we want this?

Yes, please! That’s precisely the behaviour I’d expect, based on what most of us are probably used to from Lemmings 2: The Tribes.

On an unrelated note, it would simply look weird to me if the Runner had to come to a “hard stop” at the edge of a cliff and lose all of its forward momentum in an instant, only to transition to a regular faller right away.

[WillLem]

I’d rather not see the Hoverboarder become a thing in the first place than to see the Hoverboarder make the Swimmer redundant (up to the point of the Swimmer’s potential removal) one day.

I thought I might regret suggesting that we cull the Fencer...

OK, as of now, I won't put any more features up for a possible cull. I might suggest changes and improvements, but as for outright culling anything, I'll leave it to others to suggest that.

Wouldn’t we then consequently also expect it to be possible to turn a Shimmier around by assigning another Shimmier to it? Or turn a Jumper mid-air by assigning another Jumper to it? ... This would probably also include the Ballooner.

Jumper-to-midair-Jumper should result in a double-jump, if anything, surely? Turning Shimmiers with Shimmiers wouldn't be the worst thing... we could certainly look at that as a possibility if we also like the idea of turning Runners with Runners.

Ballooners-to-Ballooners resulting in turning, however, wouldn't make sense because the lem is already holding a Balloon and is already on a trajectory of sorts - there's nothing they can actively do to change direction, unlike with the other movement-based skills. I'd probably place the Ballooner more akin to the Floater and Glider than the movement skills which don't rely on some sort of "tool" (like an umbrella, a glider, or - a balloon)!

The consistency, then, is within the "lemming-driven action only" movement skills.

On an unrelated note

I've read your comment a few times, and I can't see how it's unrelated - it's exactly in relation to whether or not a Runner should hop a little bit, rather than falling immediately, when exiting a platform...

Still, glad to know you're in accord with the idea

[WillLem]

Updated the poll. It's been decided that this skill will take the form of Runner rather than Hoverboarder, so we need to shift focus to the particulars therein.


The previous poll closed out at 75% in favour of the Hoverboarder reacting to triggers, which means that they would also be able to possibly not interact with them depending on the trigger's position. Since this would likely result in pixel-precise trigger placement with regards to the Hoverboarder, it's been decided that this shouldn't go ahead at all.

[WillLem]

Gotta just be honest here, I'm really not liking this skill at all.

As well as presenting significant programming challenges and being (so far) extremely bug-prone, it just doesn't even seem worth the effort of adding all the sprites and everything. And, since that's coming from someone who created Lemminas and went to the trouble of implementing Freezer overlays, I assure you that's saying something.

Never say never, of course, but at least for now I'm going to call it a day on the Runner and concentrate on one of the other proposed new skills instead.