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

[WillLem]

From this topic:

The Runner: It already exists in Lix, and the only reason it doesn’t in NeoLemmix is that it tends to add execution difficulty where the NeoLemmix player wants none. For SuperLemmix, though? It seems tailor-made!
---
should be comparatively easy to implement

Having one lemming run ahead to perform skills seems great. And having a runner perform a higher jump would replace
the vaulter for sure.

[WillLem]

I agree that this one's a no-brainer for SuperLemmix. The Runner would be a bit more of a challenge to code than you might think, though.

For one thing, even before delving into the code, we have the question of which skills ought to be affected by its speed, and how so? Jumpers are obvious, but what about Climbers? Swimmers? Even Gliders might be affected.

A Jump would likely become a "Super-Jump", like in Lix, with the lem balling up like Sonic The Hedgehog and covering a greater range (this state could also be employed for the Trampolene object as well).

Support for this idea? Thoughts? Suggestions?

[Strato Incendus]

Before we wonder what other skills should be affected by the Runner: Didn’t you already implement a Superlemming mode?
Sure, that speeds up the entire game, including the time counter, rather than accelerating an individual lemming relative to the speed of everything else. But Superlemming certainly has the property of affecting every skill execution. I’m not sure whether that should be the case for the Runner.

What would make sense to me are the following interactions:
- Runner + Jumper = wider jump
- Runner + Spearer = wider throw
- Runner + Grenader = wider throw

The latter two alone make the Runner a lot more valuable in SuperLemmix than it ever would have been in NeoLemmix!
Unless of course if NeoLemmix had retained the Spearer and Grenader, too.

With Shimmiers and Walkers, I’m already on the fence about whether these should be sped up by Runners.
Same for Swimmers, Climbers, Floaters, and Gliders.
The reason being that all of these motions cannot be carried out concurrently with running.
Nor can any of the destructive skills.

Perhaps there is potential in making a running Builder or Platformer lay his bricks faster.
However, since one version of New Formats NeoLemmix, the Platformer has been using a novel sprite (compared to the old one, which was identical to that of the Builder), for which he actively kneels down to lay the bricks. So the Platformer makes less sense as an interaction with the Runner. A running Builder could be more easily imagined dropping the bricks behind himself as he charges forward.

But from a game-mechanics perspective, if either the Builder or the Platformer are accelerated by the Runner, then both of them should be.
By extension, the same thing would apply to the Stacker, though — and this makes even less sense to me, flavour-wise, since the lemming has to come to a standstill to stack, and is therefore by definition not running at this point.

Hence, the Runner as a permanent skill would usually be a state lemmings transition back into, once they’re done performing other tasks.
At least that’s the way it works in Lemmings 2: The Tribes, if I remember correctly?



PS: One noteworthy idea: What happens when you assign a Laserer to a Runner? Will it still stop while shooting?
If not, the Runner could be used to blast away a wider tunnel with the laser beam than usual.

[Floyd Brannon]

I like the runner. I was trying to keep my faves down to 3, but this is at least top 4 for me.

[WillLem]

Superlemming certainly has the property of affecting every skill execution. I’m not sure whether that should be the case for the Runner.

Superlemming mode and the Runner skill would be two totally separate, different things which depend on different mechanics. The Runner wouldn't so much be a "sped up lem" as a singular action which has a greater range of movement over a shorter number of physics updates. By contrast, the physics updates themselves are made to happen at a faster rate (3x, to be exact) in Superlemming mode.

What this means is that every one of it's interactions with any other lemming state may (or may not) need to be individually modified, hence the need for some decisions around it.

With ... Walkers, I’m already on the fence about whether these should be sped up by Runners.

Maybe I've misunderstood here. The Walker state itself would be replaced by the Runner. I imagine that assigning a Walker to a Runner would cancel the running state.

Hence, the Runner as a permanent skill would usually be a state lemmings transition back into, once they’re done performing other tasks.
At least that’s the way it works in Lemmings 2: The Tribes, if I remember correctly?

I don't think Runner should be permanent. Perhaps semi-permanent, cancellable with a Walker, makes most sense?

But yes, L2 does indeed maintain the running state between other normal-speed actions. From very quick testing, the only state that appears to be directly affected by running is jumping!

If anyone plays more L2 than me and happens to have knowledge of exactly which other skills/states are affected by the Runner, this would help massively! Also, it would be interesting to know which states are affected in Lix.

Ultimately, we need a list of all interactions, whether we want each to be affected by the Runner, and if so then how.

[Proxima]

I don't think Runner should be permanent. Perhaps semi-permanent, cancellable with a Walker, makes most sense?

It would still be a "permanent skill" in the Lemmings sense: gives the lemming the ability to perform an action rather than the skill and action being the same thing; the lemming retains that ability even when not currently performing the action; a lemming can have multiple permanent skills but only one non-permanent skill at a time.

Or when you say "I don't think Runner should be permanent", do you mean something other than making it cancellable? This is not clear.

[Floyd Brannon]

I recommend to have the runner only replace the walker skill. Then extend that to jumper only.
Keep it permanent until the lemming enters the exit. I wouldn't recommend doing anything else faster. His name only implies that he runs, not that he lays bricks and can hurl a spear to the moon.

I think the runner is usable enough if it can run ahead and maybe jump farther.

[WillLem]

when you say "I don't think Runner should be permanent", do you mean something other than making it cancellable?

You understood right, I mainly mean in the sense that the skill is cancellable. It feels right that assigning a Walker to a Runner ought to cancel the running ability.

Having said that, we then don't have a way to turn a Runner around... hmm. Maybe it should be a permanent skill, then, like in Lix. @Lix users - does this generally work well as a game mechanic? The Lix Walker seems to be explicitly a "turning" skill, then. Maybe it makes more sense to refer to the Walker skill as the "Turner" - and, from that point of view, it definitely should also turn Swimmers, possibly even Builders, and maybe even midair Gliders...

I wouldn't recommend doing anything else faster. His name only implies that he runs, not that he lays bricks and can hurl a spear to the moon. I think the runner is usable enough if it can run ahead and maybe jump farther.

Yes, agreed. Simplicity is also a goal here, so maybe walking and jumping ought to be the only actions affected by the Runner skill (if implemented).

[Strato Incendus]

Having said that, we then don't have a way to turn a Runner around... hmm. Maybe it should be a permanent skill, then, like in Lix. @Lix users - does this generally work well as a game mechanic? The Lix Walker seems to be explicitly a "turning" skill, then. Maybe it makes more sense to refer to the Walker skill as the "Turner" - and, from that point of view, it definitely should also turn Swimmers, possibly even Builders, and maybe even midair Gliders...

I’m always gonna call a loud “stop!” whenever propositions come up to fundamentally change the behaviour of any long-established skill.

The Walker also can’t turn Shimmiers around — it cancels them. If you want to turn the lemming around again afterwards, assign another Walker.
Your “non-permanent” version of the Runner would essentially be closest to the Shimmier, as far as I can tell: A movement skill that can be performed for one iteration, until the requirement is no longer fulfilled, and/or the lemming is assigned another skill. This distinguishes the Shimmier and Runner from the Swimmer, which, much like Climber or Floater, is a permanent skill that the lemming reassumes whenever the requirement is met (a vertical wall / falling / being in water).

Aside from assigning two Walkers to a Runner to turn him around, obviously you could turn around a Runner by having him run into a Blocker.

But generally speaking, the question of how to turn a lemming around just one more time is one of the primary ways that difficult puzzles use to make themselves more challenging. :PWhich is why you typically won’t see a lot of Walkers in the level packs with higher difficulty, since the turning-around function is often more powerful than the cancelling function. Builders, Bashers etc. can all cancel other skills in various ways, but they can’t just turn around a lemming anywhere in the level: Bashers need to hit steel, Builders need to build into terrain. The Walker can turn lemmings without any external requirements.

Hence, I don’t think the Walker should be powered up in that regard even further.

Especially when it comes to the idea of renaming the Walker into a “Turner”: The Turner is already a skill in L3D. And it functions more like a Blocker. So guess what the primary way of turning other lemmings around has always been? A Blocker.

And as someone who notoriously struggles finding the solution when lots of Blockers are involved (in non-conventional ways), I’d say they provide the far more interesting challenge, in terms of how to turn lemmings around, than to just provide the player with some overpowered Walkers.



PS: You’re right that I wasn’t thinking properly when talking about the Runner “speeding up Walkers” .
PPS: I finally feel compelled to dredge this excerpt from a post of mine in the “joke skills” thread, now that we’re seriously discussing the potential introduction of the Runner:

The Skateboarder.

This one is inspired by Speedy Eggbert (the game which Jaimie's Techno and House tileset are taken from): The lemming gets on top of a skateboard, putting him at a slightly higher position than regular Walkers, as well as moving slightly faster. He can thus get over trigger areas of traps (or buttons you don't want to push yet, teleporters or splitters you want to avoid, etc.) that regular Walkers would walk into. In contrast to the Shimmier, he doesn't require a ceiling above his head to do this, plus he can be assigned more skills (Shimmiers can only be assigned the same skills as Fallers or Swimmers). For example, he could start bashing or fencing while still standing on his skateboard, creating a tunnel only he can reach (if the skateboard places him higher than 6 pixels above the ground; otherwise, he could get over traps and still create a tunnel accessible to regular Walkers). Admittedly, this might be difficult, because the assignment of the Basher or Fencer would stop him from being a Skateborder, therefore falling down.

What would definitely work though would be assigning a Builder or Platformer to a Skateborder, since those skills don't actually require terrain beneath the lemming's feet. He could thus start building or platforming in what would be mid-air for all the other lemmings, which can be a great way to isolate him from the crowd!

Also, most prominently, you could assign a Jumper to a Skateboarder, who would consequently jump a little further than regular Jumpers.
In contrast to Speedy Eggbert, the Skateboarder would only bypass traps by not even hitting them in the first place; if Speedy Eggbert hits a (one-use) trap in his game, those get destroyed instead, while Eggbert remains on the skateboard and survives.
All in all, this skill would have all the properties of the Runner (increased moving speed + wider jumps), while still offering some additional applications.

So if anyone ever seriously contemplates adding the Runner to NeoLemmix, maybe consider the Skateboarder first...

[WillLem]

I’m always gonna call a loud “stop!” whenever propositions come up to fundamentally change the behaviour of any long-established skill.

Yes, rightly so. I've addressed this here. Also see the Upcoming Features topic for SuperLemmix, which comprises all proposed features and accepted suggestions.

With that stated clearly, we can surely get back to discussing things without concern that anything I randomly say during a theoretical discussion ought to be taken as a proposed change (unless I explicitly state that this is the case)!


From what you've said, I understand that you're more interested in the idea of having to figure out how to turn a lem, so we don't want the Walker to be a generic "Turner". I definitely agree there, but had to ask the question because it just seemed to be presenting itself via the current discussion re: the Runner.

To re-focus things, then, I need to be entirely clear on which people prefer here, out of these two options:

1) Assigning a Walker to a Runner cancels the running behaviour and returns the lem to a normal walking lem, without turning them around (semi-permanent Runner)
2) Assigning a Walker to a Runner turns the lem around, and the lem then continues with the running behaviour (permanent Runner)

The Skateboarder.
---
at a slightly higher position than regular Walkers, as well as moving slightly faster. He can thus get over trigger areas

This obviously depends on how tall the trigger area is. A skateboard probably shouldn't be any higher than about 4px (3 for the wheels, 1 for the board). We can probably get away with setting the lem's foot position a bit higher whilst they're a skateboarder, but not too much so or it might start making things very wonky!

What would definitely work though would be assigning a Builder or Platformer to a Skateborder, since those skills don't actually require terrain beneath the lemming's feet. He could thus start building or platforming in what would be mid-air for all the other lemmings, which can be a great way to isolate him from the crowd!

Haha, this is a neat idea. He'd have to leave the skateboard behind, though, surely - maybe it could evaporate

[Simon]

Next fork in the design: L2 runners have forward momentum when they fall off ledges. Effectively, they jump. Kieran used that to create courses for runners that walkers couldn't traverse.

Lix runners don't have that forward momentum. Hard to say what's the better design. I believe I've grown a soft spot for the forward hop in the past years.

This design decision is orthogonal to the skill permanence (all 2x2 designs are possible).

-- Simon

[jkapp76]

Here my video of the Lemmings 2 runner.

His body is at a nice running angle.

[WillLem]

Next fork in the design: L2 runners have forward momentum when they fall off ledges. Effectively, they jump. Kieran used that to create courses for runners that walkers couldn't traverse

We could merge this idea with Strato's Skateboarder idea, and create The Hoverboarder.

This lem drifts along at twice the speed of a regular lem, and slightly higher so it can potentially traverse trap triggers. It could also traverse Water, removing the need for the proposed Surfer skill.

When reaching a wall, the Hoverboarder could either turn around and continue, or the board could become a terrain piece, and the lem is no longer a Hoverboarder. I probably prefer the former.

When reaching a cliff/edge, the Hoverboarder continues at the same speed and trajectory, but begins to descend - the arc is probably steeper than a Glider, so we get Simon's L2 "hop". If the lem is a Glider, then... well, I'm not sure tbh. Thoughts?

Maybe certain actions ought not to be possible whilst Hoverboarding, since it seems like quite an overpowered skill so far. Jumping, we take for granted, Shimmying could detach the lem from the board - it continues on its trajectory to become a terrain piece (if we like the "can also be terrain" idea, that is. I'm not sure if I do at the moment). Floating, Swimming, Disarming, Sliding and potentially Climbing are all bypassed.

The explosion-based skills are all as-is. Destructive skills probably shouldn't be possible, and neither should constructive skills. This is, of course, very debatable.

Walker feels like it should either cancel the Hoverboard state, turn them around, or do nothing (Walkers don't have to have a function - Swimmer, Climber, Slider, Floater and Glider currently don't respond, so why should the Hoverboarder?).

I've updated the title because I currently much prefer this idea to a standard "Runner", but of course it can change back at any time. This is one we probably need to discuss significantly, since there are a lot of potential complications when it comes to behaviour and skill interaction.

Feedback very welcome.

[Strato Incendus]

We could merge this idea with Strato's Skateboarder idea, and create The Hoverboarder.

This lem drifts along at twice the speed of a regular lem, and slightly higher so it can potentially traverse trap triggers. It could also traverse Water, removing the need for the proposed Surfer skill.

Believe it or not, these were exactly the thoughts going through my head recently, too!

The Hoverboarder originally came from the Spearer, whereas the Skateboarder came from the Runner, and the Surfer from the Swimmer.
But the similarities are obviously similar, just like with the various Pourer skills, where we also agreed we might at best need one of them that accomplishes all of these purposes.

The flipside of that, of course, is that it goes against the principle "a skill always does one thing" that we recently discussed with regards to the Walker?
Since the Walker does two things: cancelling skills and turning lemmings around, depending on context.



Now, of course, the speed of the Hoverboarder could be seen as a secondary trait - much like the Basher, Miner etc. also have different speeds at which they move, while their main purpose is something else. In the Hoverboarder's case, the main purpose would probably be the "lifting it slightly off the ground" part?

This would probably also eliminate the need for a "horizontal flier" skill, as we considered it for the Magic Carpet / Jet Pack / Hang Glider etc.

Maybe certain actions ought not to be possible whilst Hoverboarding, since it seems like quite an overpowered skill so far. Jumping, we take for granted, Shimmying could detach the lem from the board - it continues on its trajectory to become a terrain piece (if we like the "can also be terrain" idea, that is. I'm not sure if I do at the moment). Floating, Swimming, Disarming, Sliding and potentially Climbing are all bypassed.

In my quote about the Skateboarder, I proposed that it might be possible to build / platform / stack while standing on the board.
Builders and Platformers don't require terrain under their feet to begin with, which normally doesn't make sense flavour-wise.

With the hoverboard, however, it actually would make sense, since the lemming does have something to stand on.
So it would be weird if, in the one instance where the lemming does have a board under his feet while being in mid-air, that he would suddenly no longer be able to build / platform / stack. ^^

This would also be an interesting way of creating terrain in mid-air, without always having to resort to the Freezer.

[WillLem]

the speed of the Hoverboarder could be seen as a secondary trait - much like the Basher, Miner etc. also have different speeds at which they move, while their main purpose is something else. In the Hoverboarder's case, the main purpose would probably be the "lifting it slightly off the ground" part?

The "slightly off ground" feature definitely fixes this as a worthwhile skill, since it's completely unique in that regard. The idea that it can bypass triggers (we'll make sure of that in the code rather than relying on the actual sizes of the triggers themselves), cross water, and (probably) ascend a 7px wall make it a good way to get a worker around a level quickly.

We do need an answer to the "should the Hoverboard itself be terrain?" question. I'd probably rather not, so any "Hoverboard becomes Spearer" interactions can probably be ruled out in favour of the Hoverboard instead trying to ascend, and turning around if it fails. Movement seems the better way to go with this, particularly since it's being considered as a Runner alternative.

This would probably also eliminate the need for a "horizontal flier" skill, as we considered it for the Magic Carpet / Jet Pack / Hang Glider etc.

And the Surfer, which probably won't be happening anyway; I'd rather upgrade the Swimmer instead, and look to the Hoverboarder as a "can cross water" skill.

It becomes even more important then, whether this skill is permanent (always applies once assigned), semi-permanent (applies until cancelled by user input), non-permanent (applies until cancelled by a game mechanic beyond the user's control) or single-use (applies for a set duration/length).

I'm probably more in favour of semi-permanent or non-permanent for the Hoverboarder, and semi-permanent for the Runner (it definitely feels like a Walker should cancel a Runner, not turn them).

Builders and Platformers don't require terrain under their feet to begin with, which normally doesn't make sense flavour-wise.

With the hoverboard, however, it actually would make sense, since the lemming does have something to stand on

I agree for the most part, but if we allow construction skills then it feels wierd to disallow destruction skills, all of which would make much less sense with a Hoverboarder. What do others think about this?

[jkapp76]

I think it's weird to talk about building from the hoverboard. I think it would be fine to just move quickly and
pass over water... even dangerous water.

Like a fast walker that can go over things. small things.

I think the graphic itself would look like its hovering just by putting a black shadow under it.

This would be a fun skill to see in action.

[Strato Incendus]

And the Surfer, which probably won't be happening anyway; I'd rather upgrade the Swimmer instead, and look to the Hoverboarder as a "can cross water" skill.

Didn't they tell Marty McFly in "Back to the Future" that the Hoverboards don't work above water?

But in all seriousness, I agree the Hoverboarder should be able to cross water objects. And yes, of course that would eliminate any and all need for the Surfer. The Surfer is nested within the Hoverboarder, because the Hoverboarder could do everything the Surfer can, and then some.

I'm probably more in favour of semi-permanent or non-permanent for the Hoverboarder, and semi-permanent for the Runner (it definitely feels like a Walker should cancel a Runner, not turn them).

Yes, I agree that Walker cancelling Runner seems more intuitive. And that would fix the Runner as a non-permanent skill, since it's not possible to unassign any other permanent skills, like Climber / Floater etc., by assigning a Walker to that lemming.

Then again, at this point, it sounds like the Runner won't be happening to begin with, so we won't have to worry about it anymore?
The Hoverboarder, I agree, should be a semi-permanent skill.

I agree for the most part, but if we allow construction skills then it feels wierd to disallow destruction skills, all of which would make much less sense with a Hoverboarder. What do others think about this?

If the hoverboard is terrain, then ranged skills (both destructive and constructive) would work from the top of the hoverboard: A lemming could stand on it and throw a spear, a grenade, or shoot a laser.

Then again, I do agree with the potential danger of redundancy with the Spearer, if the hoverboard is also terrain.
Therefore, I can see the hoverboard being a non-solid object, much like the Floater's or Glider's parachute.

For comparison, the Ballooner's balloon is kind of in between - since lemmings can't land on top of the balloon, but the balloon can pop when hitting solid terrain.

[jkapp76]

I like everything about this, but the Flying Carpet seems equally a good choice for all this.

The Hoverboard is cool and modern.
The Flying Carpet is cool and ancient. (and already an established L2 skill)

Strato saying hoverboards can't cross water in back to the future was a good shout.

[Strato Incendus]

Just out of curiosity: How fast is the Magic Carpet, compared to the Runner, in Lemmings 2: The Tribes?

[jkapp76]

Which is faster you ask?

Let's race!

[WillLem]

Didn't they tell Marty McFly in "Back to the Future" that the Hoverboards don't work above water?

"Unless you got power!"

We got power

If the hoverboard is terrain

Let's rule this out, we want to keep things as simple as possible.

ranged skills (both destructive and constructive) would work from the top of the hoverboard: A lemming could stand on it and throw a spear, a grenade, or shoot a laser.

I'll probably throw skill interaction out to a vote when the time comes. Let's start with increased speed, slightly elevated position, and extended jump range, and add other skill interactions as and if they feel right.

I like everything about this, but the Flying Carpet seems equally a good choice for all this.

I probably prefer Hoverboard tbh. As well as being potentially easier to animate, "Hoverboarder" is a snappier skill title than "Flying Carpeter" or even just "Carpeter". Also, the extended jump range doesn't feel quite right for the Flying Carpet.

Happy to put it out to a vote, though, if it ends up being a purely cosmetic thing.

[Strato Incendus]

You're right, the Magic Carpet doesn't feel like it would need to jump in the first place - it could just fly anywhere.

So I agree, let's stick with the (non-terrain) Hoverboarder. Especially as a more versatile version of the Runner, I also agree the Runner-like features are the ones we should start with.
Everything else would just be a potential bonus.

[WillLem]

OK, so I've made a start with the Hoverboarder, and it's nowhere near as simple as I originally thought it would be - and I don't mean programming-wise, I mean conceptually!

The main concerns I'm running into with it (no pun indended) are to do with assignability, and permanent-ness (or not).

The code itself is relatively straightforward, except that we're doing something with the Hoverboarder that hasn't been done yet, namely a semi-permanent skill. That is, the skill needs to exist in the permanent skill set in order for it to replace the Walker action wherever it would otherwise take place, however it also needs to take immediate effect and cancel other actions, whilst being cancellable itself. If cancellable, then perhaps all skill-cancelling actions (such as Builder, Basher, Ballooner) should also cancel the state? If only cancellable with Walker, then...why? And, if not cancellable, then it's a permanent skill.

Then, there's the assignability in general. At the moment, movement-based skills, permanent skills, explosion-based skills and the Cloner can all be assigned, but nothing else can - I'm not 100% sure how I feel about that. I think if we do go ahead with "other skills can cancel the Hoverboarder", then we can allow pretty much anything to be assignable. Otherwise, we need to be a bit more careful.

Here's a demo video showing the Hoverboarder as it is now. Note that the sound is a placeholder, and it is in fact possible to play the sound continuously by cueing it on a particular frame, and then making the sound the exact length it needs to be to loop back to that frame. But, it's not as easy to then stop the sound, so it will need to be kept relatively short anyway. I'll worry about that if we end up keeping this skill (at the moment, I'm about 50/50 on it).

Some questions:

1) Should Hoverboarders Climb/Slide when Jumping against a wall (assuming they're also Climbers/Sliders)?

I think that not transitioning to Climber/Slider when Jumping against a wall makes more sense, due to the skill's speed and movement. But, I don't feel too strongly about it. Also, its Jumper interaction (and even its Ascender interaction) will probably need completely new sprites as well as their own "larger-jump" method - this is on its way, if we decide to go ahead.

2) Should they descend more quickly, or steeply, when exiting a platform? The movement is currently similar to that of the Glider...

3) Should it be
   (a) cancellable with all skill-cancelling actions (Shimmiers, Bashers, Builders, Ballooners, Walkers)? Note that Jumpers won't count here - it's a given that the Jumper will be integrated into the Hoverboarder's overall action
   (b) cancellable only with Walkers? If so, why?
   (c) permanent, non-cancellable skill? If so, then it would become the first permanent skill in SLX that takes immediate effect.

4) What do you think, generally? Does it seem too OP? Does it "fit in" with the other skills and the game in general?

Everything is up for grabs at the moment; I don't feel too strongly either way about a lot of this, and I'm not as keen on this as I have been on the Ballooner whilst developing that skill. So, now's the time to make suggestions if you have any!

[Strato Incendus]

Great job, WillLem!

Using the Blocker as a sprite for standing on top of the board might indeed be a good starting point - much like the Disarmer used to look like a Digger for the longest time, and the Platformer looked exactly like the Builder.

1) Should Hoverboarders Climb/Slide when Jumping against a wall (assuming they're also Climbers/Sliders)?

Keeping in mind that the Hoverboarder is planned to be our Runner replacement, how does a Runner behave in Lemmings 2: The Tribes when jumping against a wall, if that Runner is also a Climber or Slider?

With Jumpers and Runners also existing in Lix, how do Runners in Lix behave when they jump against a wall, in case they're also Climbers?

I do agree that not transitioning to Climber / Slider does seem to make sense flavour-wise; however, there's also the game mechanics perspective, and if the Runner turns into a Climber or Slider, perhaps the Hoverboarder should do so, too. Especially if the Runner / Hoverboarder is used to go ahead of the crowd, which probably sends him on a more parkour-like path. In such cases, the ability to climb and slide might be vital for the solution.

Transitioning to a Climber or Slider should probably make the lemming lose the hoverboard, of course. Meaning, once they stop climbing or sliding, the lemming won't have a hoverboard anymore, but will continue walking normally. Flavour-wise, the lemming would drop his hoverboard so that he can hold on to the wall instead.

2) Should they descend more quickly, or steeply, when exiting a platform? The movement is currently similar to that of the Glider...

I'm fine with the angle, I'm just wondering whether this actually breaks falls of any height? It looks like it at the moment, but perhaps that's because the lemming in the video is also a Glider?
If the Runner jumps from a certain height, he will certainly still be able to splat. This of course makes less sense with the Hoverboarder, conceptually - it would make more sense with a Skateboarder, though.

3) Should it be
   (a) cancellable with all skill-cancelling actions (Shimmiers, Bashers, Builders, Ballooners, Walkers)? Note that Jumpers won't count here - it's a given that the Jumper will be integrated into the Hoverboarder's overall action
   (b) cancellable only with Walkers? If so, why?
   (c) permanent, non-cancellable skill? If so, then it would become the first permanent skill in SLX that takes immediate effect.

a) would make the most sense to me
b) seems arbitary
c) would make it more similar to the Runner, which does remain a permanent property of the lemming (which might become less of a problem with skill deassigner objects; in L2, it can certainly increase execution difficulty at some points, if a lemming you had to turn into a Runner at an earlier point in the level has to perform some more precise action near the end)

The difference is of course that running, from a flavour perspective, doesn't require the lemming to have access to any tools. Therefore, a Shimmier can logically transition back to running, once there is ground under his feet again. But where would a Shimmier place the hoverboard in the meantime? (Granted, probably in the same place where lemmings also stow away their parachutes... )

4) What do you think, generally? Does it seem too OP? Does it "fit in" with the other skills and the game in general?

The part where it seems to break falls of any height (see above) is what looks OP to me - it also makes the skill conceptually more similar to a Glider (we've already discussed the overlap with the Magic Carpet before).

As said above, perhaps this is where the conceptual difference between a hoverboard and a skateboard becomes vital.

The original idea for a Skateboarder skill on my part was inspired by Speedy Eggbert, who can also jump further with the board if he gains some speed, and can ignore (=destroy) one-use traps by skating over them. The difference is that there is no splat height in Speedy Eggbert - you can fall as far as you want. So while splat height would make more sense with a skateboard than with a hoverboard, the game that inspired the Skateboarder in the first place doesn't actually feature any lethal falls itself.



Finally, I'm uncertain about the horizontal moving speed. In the video, at least to me, the Hoverboarder still seems slower than the Runner? But I might be mistaken.

[WillLem]

how does a Runner behave in Lemmings 2: The Tribes when jumping against a wall, if that Runner is also a Climber or Slider?
---
With Jumpers and Runners also existing in Lix, how do Runners in Lix behave when they jump against a wall, in case they're also Climbers?

In both L2 and Lix, Climbers stick to the wall (Lixes do so with a nice "squelch" sound!), then proceed to climb.

However, this probably makes me think: we should do something else with SLX. Neither L2 nor Lix allow wall-jumping, which I was surprised to discover. So, we don't necessarily have to follow existing patterns.

if the Runner turns into a Climber or Slider, perhaps the Hoverboarder should do so, too

Why?

Especially if the Runner / Hoverboarder is used to go ahead of the crowd, which probably sends him on a more parkour-like path

In this case, I'd probably say - let's just have done with it and have Runner instead of Hoverboarder.

Transitioning to a Climber or Slider should probably make the lemming lose the hoverboard, of course. Meaning, once they stop climbing or sliding, the lemming won't have a hoverboard anymore, but will continue walking normally

Interesting. If we go with "most or all skill actions cancel the Hoverboarder", this would certainly make more sense. The Hoverboarder, then, becomes more like the Surfer or Kayaker - a short/single-use skill that can be used to get a lem quickly from A to B. Quite honestly, my current instinct here says "don't bother, go with the Runner instead and make it permanent." But, there may actually be more to gain by having a more dynamic and versatile* single-use skill, so... decisions!

*Hoverboarder can cross water, and if we make it single-use and cancellable, then the "off-ground Builder" seems that bit more likely to happen.

I'm fine with the angle, I'm just wondering whether this actually breaks falls of any height?

Yes, at present the Hoverboarder never transitions to Faller, and so no height is a threat. If we keep Hoverboarder, this will most likely remain the case, but I might make the angle steeper and the drop speed a bit faster so it's less comparable to the Glider.

If the Runner jumps from a certain height, he will certainly still be able to splat

Agreed, if we go with Runner, then falls are a threat again.

a) would make the most sense to me
b) seems arbitary
c) would make it more similar to the Runner, which does remain a permanent property of the lemming (which might become less of a problem with skill deassigner objects; in L2, it can certainly increase execution difficulty at some points, if a lemming you had to turn into a Runner at an earlier point in the level has to perform some more precise action near the end)

Agreed on all points.

Hoverboarder, then, should probably not be a permanent skill, and instead be a single action akin to the Shimmier, which can be cancelled by most skills and which does result in the lem Climbing when they meet a wall (but probably not Sliding if they meet an edge - they should probably still fly off)

If we want permanence to be a thing with this skill, then Runner seems the better flavour.

Finally, I'm uncertain about the horizontal moving speed. In the video, at least to me, the Hoverboarder still seems slower than the Runner? But I might be mistaken.

I've doubled the distance a lem covers in the same time. Tripling it might be too much, especially since it's probably that the Hoverboarding action i]seems[/i] slower because there is less movement in the actual sprite.


After reading Strato's comments and giving it some more thought, my current feeling is that the semi-permanent thing probably isn't a good idea anyway (if you think semi-permanent could work, please do speak up, because it probably won't happen unless the idea gets some support). So, the question really becomes:

Do we want this to be a permanent skill, or a single-use skill?

[Strato Incendus]

If we think of the application of the Hoverboarder as a Surfer (i.e., a one-time Swimmer), then it also shouldn't be a permanent skill that allows to survive all falls.
Rather, to the extent that it resembles a Glider when falling, the Hoverboarder could be a "one-time Floater / Glider", too.

Much like a Shimmier can only get you across a water pond once (provided there is a ceiling above it), the Hoverboarder would only allow you to

• cross a water / fire object once (single-use Kayaker / Surfer application)
• survive a fall once (single-use Floater / Glider application)
• get the lemming ahead of the crowd, extending Jumper arcs in the process, due to the increased speed (Runner application)

The crucial question here is whether the Hoverboarder would then consequently also be cancelled after having performed a single jump.
As far as I currently understand it, this will be the exception? Meaning, a single Hoverboarder could perform multiple jumps (=the Jumper would be the only skill that doesn't cancel the Hoverboarder), until he is assigned some other skill that does result in the Hoverboarder being cancelled.

Hoverboarder, then, should probably not be a permanent skill, and instead be a single action akin to the Shimmier, which can be cancelled by most skills and which does result in the lem Climbing when they meet a wall (but probably not Sliding if they meet an edge - they should probably still fly off)

See above, I also see the Shimmier as the closest comparison right now.
And yes, "flying off" the edge is the similarity to the Runner, which we would need in order to extend the jumps.

Basically, a Hoverboarder that's also a Slider never gets the opportunity to hold on to the edge, because, due to the hoverboard, he's actually floating above the edge already.
The Slider only holds on to an edge or a corner when transitioning to that state from Walker, Shimmier, or Climber.

[Floyd Brannon]

About being the only semi-permanent skill. You could make this a pick-up skill only. Then the lemming must pick up the board to fly on it. and only the lemming that grabs it can fly?

I like the runner better in every way, except the ability to hover over dangerous water. (like a kayaker) I think simpler is better. The hoverboarder should fall to his death after an extended jump, just like gravity and velocity would do.
I like it being permanent, but I also think many other skills should permanently cancel it. Just not jumpers.

I saw the hoverboard video. It looks better and more usable than I would have expected.

[Strato Incendus]

The pickup-skill only idea would make it more similar to Speedy Eggbert again. For NeoLemmix / SuperLemmix, though, it woudl be a first.
This is not Lemmings Chronicles / An All New World of Lemmings, where all skills except movement skills are pickups.

The use for crossing water objects with a Hoverboarder would be higher in SuperLemmix, since we now also have lava / acid / poison - water objects that Swimmers cannot cross, but a skill that can hover over the trigger area without ever touching it can.

[WillLem]

If we think of the application of the Hoverboarder as a Surfer (i.e., a one-time Swimmer)

I don't think the Hoverboarder should be relegated to a one-time Swimmer - it's unlikely that the Surfer will be implemented due to this limitation, so I'm hesitant to place it onto the Hoverboarder.

Rather, to the extent that it resembles a Glider when falling, the Hoverboarder could be a "one-time Floater / Glider", too

It would make sense for the Hoverboarder to survive one fall, but no falls thereafter. What's the reason for this limitation? And, what if the first fall is much larger than the second?

I think at this point I should rule out any notions of single-use actions for this skill, if only from a POV of personal preference. I don't mind the Hoverboarder being non-permanent, but its effect should be continuous, and predictable, until the action is finished.

Meanwhile, there does need to be something besides player-driven-cancelling which terminates the skill's effect - in the same way that Shimmiers stop when there is no more Shimmyable terrain. The problem with the Hoverboarder is that there is nothing that would obviously stop the skill, other than maybe crashing into a wall? That could work...

The crucial question here is whether the Hoverboarder would then consequently also be cancelled after having performed a single jump. As far as I currently understand it, this will be the exception?

I imagine that the Hoverboarder/Runner will have an extended jump range, and the action will continue thereafter. Since SLX will eventually be getting the Trampolene, it's necessary to implement the Super-Jump, which will take place when a lem lands on a Trampolene from a great height; the Hoverboarder/Runner would use this same action.

a Hoverboarder that's also a Slider never gets the opportunity to hold on to the edge, because, due to the hoverboard, he's actually floating above the edge already

I guess this can be seen as a caveat of the increased speed - it's one of the reasons I don't think construction or destruction skills should be assignable - the lem is simply moving too fast to perform them.

You could make this a pick-up skill only. Then the lemming must pick up the board to fly on it. and only the lemming that grabs it can fly?

Not a bad idea, actually. I was thinking the same thing for the SuperLem.

The hoverboarder should fall to his death after an extended jump, just like gravity and velocity would do.

This seems contractictory to the premise of a "Hoverboard", which would surely cushion the lem's fall. Unfortunately, we don't really have any real-world examples, and even Back To The Future Part II doesn't show what would happen if hoverboarding down from a height. However, if we assume that the hoverboards as depicted in the film use the same technology as flying cars, then they probably would descend gradually, particurly if they're able to take the weight of two full-grown adults (BTTF Part III shows this in action).

The use for crossing water objects with a Hoverboarder would be higher in SuperLemmix, since we now also have lava / acid / poison - water objects that Swimmers cannot cross, but a skill that can hover over the trigger area without ever touching it can.

Yes, exactly. This is the main reason I haven't reverted to the Runner.


OK, let's make some decisions regarding the Hoverboarder.

The skill shouldn't be permanent. That feels right, especially since it's quite overpowered (ignores water, traps, and falls).

The skill should be cancellable by more than just the Walker - OK, but which other skills? Shimmier is an easy yes, Jumpers we've decided should be integrated into the action itself, explosion-based skills are obvious, but most other skills honestly don't feel quite right. Speaking of which...

I think we should rule out any action that can't begin unless there is terrain under the lem's feet - so that would be all destruction and construction skills. We can't count the hoverboard as terrain, since - by Lemmings-world-logic, it would no longer be there once the new action has started.

And, I'd like to rule out single-use actions for the Hoverboarder. Any of its properties (fall-surviving, water-crossing, etc) should be active throughout the skill's duration; let's keep it simple.


Next question, then:

Since it's not permanent, we need some in-game logic that auto-cancels the skill. I propose hitting a wall; since the lem approaches at speed, they bounce away and fall off the board (but stay facing the same way). Then, they get up and do whatever they would do when reaching the wall as a Walker. So, effectively, we get our Climber transition back.

Thoughts?

[Strato Incendus]

I like the "crashing into a wall and transitioning into a Climber / Slider" bit!

I don't think the Hoverboarder should be relegated to a one-time Swimmer - it's unlikely that the Surfer will be implemented due to this limitation, so I'm hesitant to place it onto the Hoverboarder.

To be clear here: I didn't want to "relegate" the Hoverboarder to just that; rather, I was pointing out that being a one-time stand in for various permanent skills (swimmers, floaters, and gliders) is one of several possible uses the Hoverboarder can fulfil. Of course, it still also acts as a runner / jumper extender, and as a skill that can circumvent traps (including fire traps).

[jkapp76]

I think crashing into a wall fixes things well.
You could have him casually jump from the board instead of crash. Or even pick it up, never to be used again.

Or go full bugs bunny and splat him on the wall and get back up.

[WillLem]

You could have him casually jump from the board instead of crash. Or even pick it up, never to be used again.

Or go full bugs bunny and splat him on the wall and get back up.

I think we all know which of these ideas we'll be going with

[WillLem]

OK, well... due to the way that jump mechanics are handled, implementing a longer/higher jump is far from trivial. The Jumper state is locked in to 13 frames - I've tried increasing this with no luck, since it seems that a lot of the Jumper code is intertwined with other checks and procedures elsewhere. When I try to increase the number of frames, even if I account for the increase everywhere obvious, the game simply crashes.

So, since we only have 13 frames to play with, and every step of the Jumper arc has to be accounted for (no blank pixels), that doesn't give much room for increasing the size of the Jumper's arc, especially not for Runner/Hoverboarder/Trampolener purposes.

I have 4 choices, then:

1) Continue to try and work out how to increase the number of frames that the Jumper uses - not a tempting prospect, since the game crashes with no explanation of what's gone wrong or where the crash has occurred.

2) Stretch the 13 frames as far as I can - I've tried this, and we do get an extra few pixels of horizontal movement out of the arc, but it feels more like a slight tweak than an actual gameplay feature.

3) Create brand new Jumping methods for a longer jump (for the Hoverboarder/Runner), and a higher jump (for the Trampolene, when/if it happens) - far from trivial, since Jumper code is everywhere in the project. This would be a lot of work and take many hours, and would mean at least 2 different, independent jumping methods to bugfix and maintain throughout the project - a lot of which would be near-duplicate code. Thinking about it, since it's possible to change the arc easily enough I could probably get Hoverboarder and Trampolener into a single method. But even so, it's still way more work than I honestly think this feature is worth.

4) Abandon the idea entirely - always my least favourite option, but sometimes you do have to know when to quit.

[jkapp76]

I would say option 2. But I don't know exactly what your results are so far.
Would it be possible to have the first frame off the edge a few pixels? So it
Looks like it sped up? Then use the majority of the frames for the end.

[Strato Incendus]

Thanks for the detailed explanation, WillLem, and all the effort you've already put into trying to make this happen.
It also gives the players some perspective on why the Jumper needed so much time to make it into NeoLemmix in the first place.

What about the way the Hoverboarder currently works? That already comes with the feature of "leaping off cliffs" with that gradual diagonal fall, which the Runner has, too. Then the difference would be a change of falling behaviour (without removing splat height entirely, as discussed before), rather than a change of jumping behaviour.

Second idea: I just took a look at how this works in Lix. The Runner does indeed increase the Jumper arc here, with the Lix coiling in the air like the L2 Roller.

I don't know how much similarity there is in the code for Lix vs. for SuperLemmix. Perhaps the code referring to the Jumper in NeoLemmix is more spread-out over the project, making it harder to spot all the parts that will lead to errors, compared to how the Jumper was implemented in Lix.

[WillLem]

Would it be possible to have the first frame off the edge a few pixels?

If you move a lemming by several pixels at once, the problem is then that this lemming can potentially "phase" through terrain platforms that are less than the number of pixels that the lem has been moved. You then have to implement all sorts of clunky collision detection checks that can and do go very wrong.

You should've seen the state of the Dangler's collision detection before Master88 reported the phasing bug. It's now much, much tidier, but it took a bit more work to smooth out the transition and make sure that the lem never moves more than 1px at a time whilst it's looking for terrain. And that's just the Dangler, which is a relatively unseen state. The Jumper code is extensive, and with it being a very popular skill it's particularly important to make sure it's all correct.

What about the way the Hoverboarder currently works? That already comes with the feature of "leaping off cliffs" with that gradual diagonal fall, which the Runner has, too. Then the difference would be a change of falling behaviour (without removing splat height entirely, as discussed before), rather than a change of jumping behaviour.

Yes, this is definitely a consideration: we simply keep the same Jumper arc, and the skill is then distilled down to faster movement and the slight height advantage. It seems a shame not to gain the larger jump, though, especially since I'm considering the Trampolene object, which would also require a different jump pattern.

Perhaps the code referring to the Jumper in NeoLemmix is more spread-out over the project, making it harder to spot all the parts that will lead to errors, compared to how the Jumper was implemented in Lix.

Not sure how it's implemented in Lix, Simon will be able to provide more insight here. I'd be very interested to see how it's done there, i.e. whether it's the same Jumper method but overlayed and slightly tweaked, or whether the Runner-Jumper has its own method.

At present, I'm thinking... take a few days away from it, come back to it with a fresh pair of eyes, see if Simon and/or namida have any wisdom to impart in the meantime. It's possible that the crashes I was experiencing when trying to give the Jumper more frames came down to a simple oversight due to tiredness. I sometimes find with programming that when I try the same thing a few days later, it just works.

[Simon]

On a high level, it's ballistic flight, but with the usual Lemmings low-level particularities.

The job class (BallisticFlyer in Lix) tracks a speed. Speed consists of two numbers: a forward speed and a vertical speed. Forward speed is mostly constant. Vertical speed is subject to gravity and changes each physics update.

Jumper and Tumbler subclass BallisticFlyer. Jumper covers both running and non-running jumpers, they differ only in the initial speeds and the shown frames.

Each physics update, from this speed, we construct the line segment that the lix shall travel during this physics update. (Thus, it's not a perfect parabola, it's piecewise linear and only resembles a ballistic arc.) That physics update, we travel the line segment in small steps, each only one pixel either forward, up, or down. Each step, we check for collisions. We stop travelling on first collision or when we've finished the line segment.


There are several nasty problems hiding below the surface.

I recommend to write a class just to compute the line segment. Take as input the speed, and the class gives you the finite sequence of small steps (forward, up, down). This class doesn't compute collisions; we collide elsewhere and stop early taking steps from this class.

You want the collision code to behave nice with angles. Suppose there is a 45-degree upwards hill and we fall onto it diagonally, perpendicular to the hill slope:

. v . . . #
. > v . # #
. . > # # #
. . # # # #
. # # # # #
# # # # # #

There's a 50:50 chance to hit the slope during a downwards step or during a forward step. We want identical behavior in both cases. Probably, we want to land here. In my image, it looks like we've hit it during a forward step. Naively, when we hit terrain while going forward, we might assume that it's a wall, and turn. To conclude that it's a slope, examine the surroundings.

geoo recommended me to treat even a steep 1:2 slope as a floor. I'd have to check even more surrounding pixels.

Similarly, maybe you want identical behavior for 45-degree ceilings. It's lots of work to define the cases, decide, and then write several skills with minimal code duplication and without spaghetti.

I'm not happy with the current bug-fixing patchwork in D Lix over the 2007 tumber code. I want to ditch it entirely and write it anew, starting with test cases for common slopes. That's a project for the future (not 2023) and will get a separate thread.

-- Simon

[Simon]

game crashes with no explanation of what's gone wrong or where the crash has occurred.

That's odd. Build it with debugging symbols enabled, and run it with a debugger attached.

Delphi suites probably come with their own debugger. Quick websearch makes it look like GDB (a popular debugger) doesn't understand Delphi debugging symbols.

-- Simon

[Floyd Brannon]

Could the jumper arc be done in two different animations? Maybe arc 1 is several frames and arc 2 completes it?
Maybe there could even be an advantage to doing it in two parts. There could be more than one arc 2's depending on the situation. If the hoverboard collides with something that is not traversible terrain it could continue descending in a wobbling state. [or the lemming could come off the board and enter the standard falling animation]

I'm only pondering the problem, I'm no programmer.

[WillLem]

OK, as predicted, a few days away from this helped!

When approaching the problem again today, I did everything in small increments, testing as I went, to make sure there were no issues.

We now have 2 separate Jumper arcs, one for regular jumping, and a "Super Jump", which will be employed by Hoverboarder and horizontally-approached Trampolene.

Each has their own number of frames, and their own frame offset for displaying the Jumper animation (the Hoverboarder will also have a replacement Jumper sprite anyway). Having looked at the code afresh, it's actually perfectly set up for this sort of dynamic tweaking of the parabolic arc, as well as how many frames the jumper devotes to each pattern - it's not immediately obvious, but it's all there.

So, only the one Jumper method ! (Meaning, no need to duplicate checks and Jumper code elsewhere in the project).

I'll also implement a third arc for landing on a Trampolene from a height, but that's for another topic.


Moving forward, then, I could do with devoting some time to the question of what to do about moving over corners. See video demonstration:



Current options:

A - Leave it as it is
B - Create a "Hover-Ascender" state which mimics the Ascender - it would need to move more quickly, though, otherwise it slows the lem down significantly
C - An option yet to be suggested...!


And, some more Hoverboarder questions:

2) The Hoverboarder can traverse water, but... can they also bypass traps (since they hover above the trap's trigger, effectively)? If so, what about buttons, pickups, teleporters, exits, etc...?

3) How should the Hoverboarder stop? Cancel-only? Bump into a wall? Not stop, and be a permanent skill? (Could do with a bit more input on this before making a decision)

4) Should the Hoverboarder have a skill shadow? Currently, it shows about 50 frames of movement (and, I wouldn't want to display any more than that) - I feel this could be confusing, though, since players may expect it to stop)

5) Anything else you'd like to suggest at this point?

[jkapp76]

1. I like how it currently handles corners.

2. I'd say only dodge traps... but I'm not completely sure.

3. probably cancel only.

4. doesn't need a skill shadow

5. You could do something like the ballooner and have other skills that cancel the hoverboarder. Maybe builder and such.

[Strato Incendus]

Great job on the Jumper arcs, WillLem! Sometimes, a few days away from a problem do help indeed, rather than cancelling the attempt immediately.

1. The corner handling looks fine to me in principle - it might just be a little confusing, depending on the extent to which the Hoverboarder seems to pass through terrain while doing so.

2. The Hoverboarder should be able to pass any kind of water object. That includes lava and poison. Now, lava is of course identical to any other fire object (as it was already the case in NeoLemmix with the green acid in namida's Lab tileset). So the question really is how many pixels above water the Hoverboarder will move. Because while that may get him across a lava pond, it probably won't lift him high enough to get over other "on land" fire traps, like the fire pits from orig_fire, or the slashers from orig_marble.

Regarding triggered traps: Here it would feel inconsistent to me if he can bypass traps, but still collect pickups, hit buttons etc. ("only the good stuff").
Then again, such is the use of the Skateboard in Speedy Eggbert, which is where the "skipping over traps" idea came from:
Eggbert can ignore all the traps (actually destroy one-use traps) while on the Skateboard, but still collect treasures, eggs, ammunition etc.

In SuperLemmix, we don't have a way to deactivate one-use traps without triggering them (unless of course you use the Disarmer, but that skill can disable any kind of triggered trap).
Hence, I think the Hoverboarder merely bypassing traps (not disabling them safely like in Speedy Eggbert) is more useful.

One problem with the Disarmer is indeed, as restricted as it is, that it immediately makes a given trap harmless to the entire crowd.
That's too powerful on the one hand, and at the same time, disabling traps is the only thing the Disarmer can do in the first place - and this combination of "too powerful" and "too restrictive" limit the potential for the practical application of the skill even more.


Now the question is: What if the Hoverboarder can't ignore traps (and would therefore also collect pickups, hit buttons etc. like any regular Walker)? This would make him more akin to the Runner again. But what would it change for level design if the purpose is to get one lemming ahead of the crowd, or onto a path the others cannot take?

Because that's the primary use of having one lemming that can get past a trap, but not the rest of the crowd. Much like Climbers and other athletic skills are often applied to a few worker lemmings, who then need to create a path for the rest of the crowd, who do not have that skill. The Disarmer, however, is the one permanent skill where this doesn't apply, since once a Disarmer has walked along a path, everyone else can take that same path. Not so much with the Hoverboarder: He can get over trap triggers, but the rest of the crowd can't.

In contrast, if the Hoverboarder himself can't ignore trap triggers either, then all this would change for the level designer is that they would probably have to provide a lot more Jumpers, to get the Hoverboarder / Runner over the trap triggers as a one-time only thing. This might create more challenges if the Hoverboarder turns around, of course, because then, he would require additional Jumpers to make it back across the trap trigger - whereas if the Hoverboarder can get past them anyway, no additional Jumpers are needed.

The trade-off here is: Ignoring trap triggers will make the Hoverboarder more powerful (potentially too powerful), but having to provide additional Jumpers can create backroutes elsewhere.
Especially since Jumpers can also be used to cancel any other skill mid-performance.

Speaking of which: Another thing to consider is what skills would typically be used to cancel the Hoverboarder - and what the terrain would have to look like if the level designer wants to force the player to cancel the Hoverboarder at a given point: If the Hoverboarder can go across water, fire objects, trap triggers, and gaps / pits (bottomless ones and those with terrain), then it may become hard to stop the Hoverboarder at all. (This also feeds into your question 3.)
Except of course with a chunk of terrain in his path. The latter would also include making the walls of a water pit (or any other pit) too high for the Hoverboarder to jump out of, in order to force the player to e.g. use a Shimmier instead. But apart from that, it's much easier to force a Shimmier to stop (just two pixels of height gain or loss on a ceiling) than to stop a Hoverboarder.


In short: I'm still torn about whether or not the Hoverboarder should skip trap triggers. However, I'm actually a little more inclined to say: No, he shouldn't.
If we decide he should, then just like with fire objects, the difference in height of the trigger areas of various different traps becomes crucial.
I think the "skipping traps" part only makes sense if the Hoverboarder visibly hovers above the trigger area - not if he passes through it and simply remains unaffected.
The explanation should be "the Hoverboarder flies over the trigger" - not "the Hoverboarder is simply too fast for the trap to affect him". The latter would require an animation that shows the trap "trying" to affect the lemming, but failing to do so. And that would be a whole lot of effort for anyone maintaining a graphic set.

With that in mind, if we decide the Hoverboarder can't skip traps by default, then there will still be some triggered traps he will get to ignore - depending on how low their trigger area is, and/or how deep the level designer flushes them into the ground. This would enable the level designer to build around the powers of the Hoverboarder, by deliberately either making traps low enough for the Hoverboarder to get over them (while those traps would still pose a threat to Walkers), or by placing them high enough that e.g. only Gliders, Shimmiers, or Jumpers can get over them - but neither Hoverboarders, nor regular Walkers.


3. see above: How easy it is to stop a Hoverboarder will depend on what types of obstacles he can pass. However, slamming into a wall should probably cancel him (where it wouldn't cancel a Runner), simply because this means he falls off his board.

4. Skill shadows on a Hoverboarder sound reminiscent of projection shadows; then again, Gliders have skill shadows, too. What's of potential interest is whether the Hoverboarder can get over a given obstacle or not (be that terrain, a trap trigger, or a water object). In other words, the skill shadow is more relevant with regards to height. Secondly, of course being a Hoverboarder also alters the Jumper arc now - just like being a Glider does, actually . In that interaction, the skill shadow is relevant in the horizontal dimension, too.
With Gliders, this is less of a problem, because the lemming transitions back into a walker state once has landed - so that's where the Glider skill shadow naturally stops. The Hoverboarder, meanwhile, does not transition back into a walker state when merely landing on even terrain.
So the skill shadow would potentially have to extend up to the next vertical obstacle - one that's high enough for the Hoverboarder to stop (see point 3). If that's too long of a skill shadow, I guess a fixed range for the skill shadow makes the most sense.

5. You could do something like the ballooner and have other skills that cancel the hoverboarder. Maybe builder and such.

Yes, any kind of constructive or destructive skill should definitely cancel the Hoverboarder - otherwise, getting a lemming ahead of the crowd will prove pretty useless, if he can't actually do anything once he arrives at his destination.

Since we have already decided (I think?) that the Hoverboarder shouldn't start building "from the top of the board" (this is relevant because Builders and Platformers don't require terrain under their own feet to be assigned), assigning a Builder to a Hoverboarder would have to make him fall first. And then, I don't see why he should automatically start building after that.

Could one of the sneakiest ways to stop a Hoverboarder actually be to assign a Blocker to him? That would be the same method of cancelling as when assigning a Blocker to a Digger on the edge of a piece of terrain (where there is actually no terrain under the Digger himself, so that he turns into a faller right away).

[WillLem]

1. I like how it currently handles corners.

2. I'd say only dodge traps... but I'm not completely sure.

3. probably cancel only.

4. doesn't need a skill shadow

I agree with all of this. The Hoverboarder is shaping up to be something of a wild card, maybe the further we lean into that, the better.

lava is of course identical to any other fire object ... So the question really is how many pixels above water the Hoverboarder will move. Because while that may get him across a lava pond, it probably won't lift him high enough to get over other "on land" fire traps

I've currently set the Hoverboarder to always gain a 2px height advantage over terrain, all water objects, and all fire objects. We could probably raise this to 3px, but I probably wouldn't want to go any higher than that or it might start to look a bit odd.

Raised fire objects, meanwhile, are definitely a relevant concern. In fact, this is another reason we need to think about how the Hoverboarder "corners" raised pixels. If we keep current behaviour, the lem will attempt to "corner" the raised object, and will fail to do so - the lem will then be affected by the trigger area of whichever object it is they're attempting to traverse.

Conversely, if we decide to have the lem "ascend" at the side of the object, then they will awkwardly, but successfully, traverse the object in a rectangular motion. Here's a graphic to help visualise this:

it would feel inconsistent to me if he can bypass traps, but still collect pickups, hit buttons etc

Yes, this is my only reservation with allowing the Hoverboarder to bypass traps. But, then again, there's no point in bothering with the height advantage if there aren't any... well, advantages!

what would it change for level design if the purpose is to get one lemming ahead of the crowd, or onto a path the others cannot take?

I'm always reticent to get into level design specifics when discussing a skill or object proposal. My main reason for this is that it's like discussing how a game of chess might be played: sure, there are specific moves and rules and logical patterns, but when it actually comes down to it there are literally millions of different possible chess games; why try to account for scenario 1 and not scenario 1,000,001?

And OK, there might not be millions of different possible Lemmings levels, but I can almost guarantee that whatever we attempt to design into the feature for the purposes of a hypothetical level scenario, someone will find a way to subvert it - and I should cocoa!

In contrast, if the Hoverboarder himself can't ignore trap triggers either, then all this would change for the level designer is that they would probably have to provide a lot more Jumpers

Or Builders, or Stackers & Walkers, or a less-easily-accessible route, or a Disarmer pickup, or a Teleporter out of reach, etc, etc - you get the idea. Let's let level designers worry about that stuff.

Another thing to consider is what skills would typically be used to cancel the Hoverboarder

If we go with cancel-only, non-permanent, then we ought to allow as many skills as possible to be Hoverboarder-cancelling. However, whether or not the Hoverboarder should "corner" terrain becomes even more important, since we probably want to avoid fiddly "must start Bashing/Mining whilst over the corner" stuff. This is one of the reasons I wanted to disallow destruction skills, incidentally - I'd rather keep the corner-phasing behaviour.

it may become hard to stop the Hoverboarder at all

This then gets added to the list of possible scenarios on which to base a level: how to get down from a height, how to turn a lemming, how to stop a Hoverboarder...?

I think the "skipping traps" part only makes sense if the Hoverboarder visibly hovers above the trigger area - not if he passes through it and simply remains unaffected

I disagree here. It's impossible to account for every possible trap trigger height, and I don't want to force style creators or level designers to worry about pixel-perfect placement. Either the Hoverboarder ignores traps, or they don't.

Furthermore, we shouldn't - as players - actually know where the trigger area is. If the Hoverboarder takes notice of trigger area placement then the player also has to, forcing them to use CPM. That's a hard no from me.

slamming into a wall should probably cancel him ... simply because this means he falls off his board.

This definitely makes the most sense if we go with "can be cancelled by something other than player input".

then again, Gliders have skill shadows, too.

Yes, but only whilst actually Gliding, which in practice means it's generally a fixed distance. Depending on the various decisions we make about the Hoverboarder, they could potentially continue infinitely. This is currently the case with Ballooners at the top of the level - you can see in the Hoverboarder demo video near the end, the Ballooner skill shadow is drawn infinitely back and forth for the top-of-level part of the Ballooner's journey (this will be fixed for the release of 2.5 - we can cancel the simulation if the Ballooner reaches the top of the level). For the Hoverboarder, it's less clear-cut, especially as we haven't yet made decisions elsewhere.

As it currently stands, I'd probably vote against the Hoverboarder having a skill shadow at all.

[/b] What's of potential interest is whether the Hoverboarder can get over a given obstacle or not (be that terrain, a trap trigger, or a water object).

If we decide Hoverboarders can bypass traps, then they'll always bypass regardless of trap trigger height - no skill shadow needed. Terrain and water/fire trigger areas are admittedly different, especially if the water/fire objects are raised. My own personal thoughts on this are - start playing and see what happens! I realise that not everyone shares this mentality though, hence why a skill shadow may need to be a consideration. It is difficult to find a non-arbitrary limit to place on it, though.

a Hoverboarder also alters the Jumper arc now

The Jumper skill shadow would still be displayed whilst Hoverboarding, it's a separate shadow.

Yes, any kind of constructive or destructive skill should definitely cancel the Hoverboarder - otherwise, getting a lemming ahead of the crowd will prove pretty useless, if he can't actually do anything once he arrives at his destination

The Hoverboarder isn't only a "get a lem ahead" skill - it currently has something of a Swiss army knife array of potential uses. There are other things to consider, such as  - Should they be allowed to start Bashing when "cornering"? Should they be allowed to start Bashing at the point they collide with a wall? Should they be allowed to start Building in midair? Personally, I don't think that any of these interactions make sense, with the possible exception of midair Building... I'd need to see a bit more support for that particular idea though.

Could one of the sneakiest ways to stop a Hoverboarder actually be to assign a Blocker to him?

Haha, good idea!

[WillLem]

The more I think about it, the less I like the Hoverboarder idea - it's getting too complicated and I don't believe that we'll be able to reach conclusions about the various details that are satisfying enough to warrant its inclusion as a new skill.

If you have any comments, or want to answer any of the questions about the Hoverboarder skill in this post, please do share your thoughts and we can revisit the idea at a later date. For now though, I doubt this feature will make it into the 2.5 update.

[Strato Incendus]

This development is taking quite some twist and turns. I had given up on the idea of the Hoverboarder after you mentioned all the technical issues regarding the modified Jumper arc. But now that, as far as I understood, you’ve been able to solve those, I’m a little surprised about going all the way back on this idea?

Sure, as you mentioned earlier, there are a lot of conceptual questions, with regards to how the skill should behave. But none of these sounded unsolvable to me, especially given the video demonstrations you’ve already made — we’d merely have to agree on one set of rules and stick with them.

I’ve already provided my take on the questions from the post you linked to, so all I can add is I’m even more convinced now that the Hoverboarder should not skip traps by default. Especially that steep rectangular trajectory looks pretty weird to me (then again, that’s kind of what I expected the option to automatically skip trap triggers to look like).

Rather, if he’s hovering high enough to move over the trigger areas (instead of through them), he will ignore the traps automatically. Conversely, if the level designer wants to block a path for both Walkers and Hoverboarders, they merely have to place the triggered trap / fire object a little higher.

The reason I like to contemplate level design when discussing potential new skills is that it’s a way of anticipating what we might have to deal with in the testing phase. Also, 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.

If the Hoverboarder should not become a thing, after all, would the Runner be up for debate again instead? Now that you’ve already found a solution for altering the Jumper arc, that knowledge could still be used on the Runner, too.

[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.