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

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