[Request] Update 8 Direction Behavior

I’d like to request an update to the 8 Direction Behavior and collisions. The behavior works well when colliding with 90 degree angled solids, but really fails when dealing with off angle solids. Here is an example:

When hitting an angled solid, the movement just stops. Here's how I think it should work:

The object should move with the angled solid until it hits an angle limit - probably anything > 45 degrees. I feel like this update would make the 8 Direction Behavior act more like professional games with top down movement.

And here is a capx to save some time in setting up a test:

http://www.louisferina.com/games/8dir.capx

-Lou

Wall sliding would be nice.

Here's an example of how it could look.

is normal that the object stop... you are using the basic behavior without any code... and the behavior works well...

you have to make a easy script to make your gameplay...

for instance, if the player touch some wall, the player "bounce" 2 px.... you can also use physics behavior and platform behavior... it dependes how you would like to make it...

you can find a lot of example in this forum

R0J0hound - Thanks Ill check that out tonight.

Ribis - Yes, as stated in the OP the behavior does work well, but sliding against angled walls seems like it should be part of the behavior similar to how the platform movement deals with slopes without extra code. The Platform Behavior has received many improvements to increase it's usability but 8 Direction hasn't gotten much attention.

The more specific the behaviors become the more limited in use they become.

My personal issue with 8 direction is it rotates sprites. Might have to make a new thread about it now that I mention it haha.

Tylermon - I don't believe that's making it specific, it should be the default movement. Also, you can shut off rotating the sprite.

+1 Update 8 Dir with wall slide.

I agree.

This behavior is very common in video games, so I think it is very reasonable to expect an option to do this.

From a side scroller or platformer perspective this seems like a must have feature..... From a top down game, I can see issues where I wouldn't want things sliding along collisions.

Perhaps there is a barrel in front of the player. Now instead of hitting it, they might slide all around it. Despite a barell being a solid object you want a player to stop at. Or if an environment has objects or props rotated, now these become sliding obstacle courses.

Pushing objects at angles could now break and have players struggle to position themselves. The Boulder they were pushing is now a sliding wall and a nusance to the player.

Only a few examples, but I'm sure people could think of others.

Point being, it is a useful feature depending on the game. Aka specific uses.

Personally if something like that got added, a few of my projects would break. I would have to change over to custom movement which isn't a big deal, but defeats the purpose of an object that is meant to have basic functionality for us to then add on to for our specific games.

Also the 8 way movement is simpler in my net-code would hate to have it break haha.

Add too much, and it becomes the platformer movement. Great for that one purpose. Limiting for much else.

"My personal issue with 8 direction is it rotates sprites"

This is actually a parameter on the behaviour ; it can be disabled, or set to preset values (smooth, 45 or 90deg. angles)

As for the request itself, my feeling is that behaviours and components should remain as generic as possible, letting the end-user achieve the desired results with a bit of custom logic where necessary. Anything beyond this becomes too specific or too convoluted to be practical.

Typically in a game, there will be surfaces that can have wall-slide, and some that don't ; ledges you can grab, and some you can't ; some areas that cause slipping/sliding (ice, etc.), and some that don't. Etc. We don't want behaviour parameters for each possible scenario, that would be clunky, and would imply coupling between concepts that need to remain separate (e.g. character movement <> environment mark-up).

Can you re-create Metroid, Castlevania, Mario, Megaman II and Zelda II, all 2D side-view platformers, with the *same* player behaviour ? Hardly, because each of these have different requirements and work in different environments. You don't want a player behaviour that handles "everything" ; you want a flexible base you can customise to your needs, and that's what movement behaviours are.

Construct Classic had push out mode "Normal (use for slide)" on Custom movement. I think that would be good addition.

Tylermon

Perhaps there is a barrel in front of the player. Now instead of hitting it, they might slide all around it. Despite a barell being a solid object you want a player to stop at. Or if an environment has objects or props rotated, now these become sliding obstacle courses.

A solution to your barrel problem - the underlying collision for your barrel example should probably just be a non angled box anyway. If you need it to slide at angles, have two underlying collision objects, one solid that doesn't rotate to stop the player, and one non solid that rotates for pushing. It seems much easier to account for pushed objects rather than coding complex movements. Perhaps to take it a step further, a no slide behavior could be made. That seems unnecessary though.

I'm not sure I understand your "sliding obstacle course" example. If an obstacle is slightly angled, it shouldn't stop you. It's awkward to get stuck on it. Players shouldn't be expected to push, up, then right, then up, then right, etc to move at an angle that's not 45 degrees.

Add too much, and it becomes the platformer movement. Great for that one purpose. Limiting for much else.

The platform movement is pretty awesome. You can mold it to how you want. How is it limiting?

Refeuh

Can you re-create Metroid, Castlevania, Mario, Megaman II and Zelda II, all 2D side-view platformers, with the *same* player behaviour ? Hardly, because each of these have different requirements and work in different environments. You don't want a player behaviour that handles "everything" ; you want a flexible base you can customise to your needs, and that's what movement behaviours are.

I would argue that you can get very close to each of those games movement systems with the platform behavior. It's extremely flexible. Want jump through platforms, add them, change gravity, jump heights, double jump, etc. Of course you have to use code to customize it, like i just added hanging from ledges and climbing over them into my game. The base movement is there and has all the basic features needed to edit them. What if slopes weren't included in the Platform Behavior? That is similar to wall sliding not being included in 8 Direction. It is a basic function of top down movement.

Fair statement, and I don't deny it's a sensible request, but I think both points of view can be valid. In the end it's all about what features people think are or are not part of a "default" behaviour. Which is obviously very subjective.

Continuing with the platformer example and the functionalities mentioned previously, many games these days have ledges, ladders, double-jump, etc. Does that mean they should be included in the default movement behaviour ? I don't know ; and I don't think there's a black/white answer to this. There's a trade-off, and a balance to find between components doing too little/too much and the amount of "glue" logic the developer needs to implement.

My worry would be to end up with "monolith" components that try to do too much and become hard to customise every time your scenario doesn't fit nicely in the expected use-cases. If I was designing the underlying modules, I think I'd try to make the "slope/sliding" movement logic bit a separate behaviour (purely reactive, unlike input>movement) that you can add, or not, to the entities. That'd avoid unnecessary coupling in scenarios where this features is not required.

Refeuh

Yeah I agree. I don't want or need everything to be built in and I understand worries about behavior bloat. I guess to me sliding against a wall is expected behavior and extremely hard to code separately. Check out R0J0hound 's solutions (Thanks for those R0J0) which are really good, but not perfect and still have a few caveats like having to shut off solids. That said, a separate sliding behavior seems like it would be a fine solution, if that's possible.