KZR

To clarify, the new Falling Angle Threshold property should be set to 46 to make this work (in the last version, this was hardcoded as 45, which was 1 degree off). With it at 0 I can see the issue, but setting it to 46 fixes it.

Alright, small update to the behaviour. Again, so sorry about the wait. Had I known I'd be this busy I'd have waited until I could provide more regular updates.

Changes:

Air drag now works

Simulate Jump now works again

Can now specify an angle threshold for when the downhill slope factor will have an effect.

Issue with 45 degree slopes locking controls fixed

KZR:

Found that slope issue you were talking about! When the object stops moving on a slope (assumed to be because it's too steep) the engine locks horizontal controls for a fraction of a second while the slope factor kicks in and pushes the player downhill a bit. Generally this is a good thing, since you don't want the player on a slope they can't walk up just pushing against it, but with slope factor disabled (which I'm assuming is what you did?) and when on a 45 degree slope (also assuming you did that) it triggers the lock, doesn't push the player down, and just sits there counting down the horizontal control lock and repeatedly triggering it again when it hits 0.

The threshold for the angle is 45 (non-inclusive), but with swapping between radians and degrees being a little unexact it's counting 45.0000012522 as being above 45. Which it is. I've changed it so it's a parameter defaulting to 46: FallingAngleThreshold. If the slope is shallower than that, falling off should not trigger. Should fix the issue as it currently is, as well as allowing some fine-tuning if it still presents a problem.

There are a couple obvious issues still present that I really need to work on (including tilemaps, which I will get to, I promise!), but if I'm honest I'd still expect things to be a little slow on my end for a bit longer yet. Please keep letting me know if there are any issues, and I'll try to solve them as soon as I can!

Also, regarding rotation and the Set Angle property, I've had a quick go at it and ran into issues reliably moving things around so as not to clip a non-square bounding box into terrain or off a slope it should be sticking to. It isn't ideal, but as a workaround I'd recommend keeping the collision poly for the main object square, and overlapping another object with a non-square poly if you need one for other collisions.

I'm getting to the point where my inexperience with some of this is showing, so if it comes to it, please bear with me as I try to refactor things to make future changes more feasible.

KZR:

Yes, sorry, I've fixed the jump issue and added an air drag effect already, I just want to do a couple more things before I release an update. Sorry for the wait!

R0J0hound:

Ah, cool, that should be helpful, thank you!

KZR:

Ah, sorry, I misunderstood you. The sim jump issue is definitely something I can reproduce, and I can have it fixed by the next release. For the slopes, have you changed the downhill slope factor then?

Azu:

Eventually the Set Angle of Gravity action should be able to manage things like that, though I need to go back and change a couple of angles to be relative to that.

Momio: To be fair, the Sonic Physics Guide is the main thing that make the physics accurate.

KZR: Still can't replicate the issue. Is it happening in the example capx? If not, could you give me one where it is happening?

My weekdays have been fairly busy (and probably will be for a few months more unfortunately), so my general plan is to work on things on the weekends, releasing an update on Sunday evenings if I can get anything substantial done.

That said, I might not manage to release anything by tomorrow. I'd like to address the tilemap issue in the next release, but I haven't made as much headway as I would have liked today. I guess I'll see how tomorrow goes.

Ah yeah I saw the Sonic Portal thing on Retro, didn't have an account at the time though. From those videos it certainly looks like you had much more success with the event-based approach than I did. Looking forward to seeing what comes from that!

KZR: Is it something you can reproduce reliably? I can have a look at it, but I haven't had any noticeable issues on slopes myself.

Yeah I'd certainly say so. As far as I can tell I've done things in much the same way as the Platform behaviour, so there shouldn't be much impact.

Candescence: Thanks! I've had 2 or 3 attempts at making an event-based system myself, but the whole thing failed to hold up with even the basics, and doing it via a behaviour seemed far more sensible and user-friendly.

Thanks! Yeah, no events yet, though I'd like to add some as some examples of extending the behaviour via events like you would the Platform behaviour, but for the essentials it's as simple as assigning the behaviour to a Sprite!

Whoops. Yeah the c2addon file was wrong, should be fixed now! I've also added the example capx, though at the moment it's very basic.

The Sonic Physics behaviour is a heavily adapted version of the Platform behaviour that can handle slopes and curves in the same way as the classic Sonic the Hedgehog games. The behaviour is mostly accurate to the physics of the games and is primarily targeted towards Sonic fangames, but the behaviour has specifically been made so that unneeded components can be disabled in some way, for use in other games.

The goal of the behaviour is to be a simple to use as the Platform behaviour itself, aside from some obviously more complicated parts, so the behaviour works almost identically, handling Solids and JumpThrus as you would expect.

The Sonic Physics Guide was referenced heavily in the development of this behaviour.

At some stage I intend to work on a template containing supplementary events that didn't fit with the behaviour, as well as things you'd expect to find in a Sonic game, as a base for fangames and a better example of how to use the behaviour.

Notable Features:

• Snaps to angled surfaces, as long as speed is above a specified threshold
• Slopes will affect movement speed and jump angle
• Modified variable jumping to have a maximum and minimum jump rather than a sustain time (more accurate to old Sonic games)
• Added variations on basic acceleration, deceleration etc parameters for when in the air or rolling
• "Compare Speed" condition offers choice between X component, Y component, or both
• Rolling, which works under the same conditions as it does in the Sonic games. On by default but easily disabled if it's undesirable.
• More to come, hopefully!

DOWNLOAD LINK

EXAMPLE

EXAMPLE CAPX

Actions added/modified:

• Actions corresponding to properties. In order to not clog up the action select window, selecting a property with multiple versions (like acceleration) will offer a combobox asking which variation you'd like to set.
• Simulate control: Roll
• Trigger roll/unroll. Overrides the initial conditions for rolling (ie, this isn't the same as "Simulate control: Roll") but triggering a roll is still subject to unroll conditions (ie low speed) and vice-versa.
• Removed "Set Jump Sustain" as I've changed how the variable jumping works.

Conditions added/modified:

• As mentioned above, the "Compare Speed" condition now has an extra combobox to specify whether you'd like to compare X vector, Y vector, or both. Both is the default, which functions as the Platform behaviour's "Compare Speed". Equivalent to comparing Object.SonicPhysics.VectorX/Y.

Expressions added/modified:

• "SurfaceAngle": The angle of the surface the player is on. Returns 0 if not on an object.
• See list of properties below. Most (or all) of those have a corresponding expression to get their value at runtime.

Properties added/modified:

• "Soft Max Speed": Max Speed has been separated into two components. This one is the top speed the object can reach via its own acceleration on flat ground.
• "Hard Max Speed": Essentially the old Max Speed property. The object simply will not move higher than this speed, horizontally. Best not to make this too high, as if you reach these speeds it'll likely start clipping through solids.
• "Friction": Renamed "Deceleration" property. Effectively passive deceleration, slowing the player when no input is present.
• "Deceleration": Active deceleration, slowing the player when their input is in the opposite direction of their movement.
• "Air" versions of several of the above: Take effect when the player isn't on the floor. Mostly optional so as not to require swapping things around in events all the time.
• "Rolling" versions of several of the above: As with the "Air" versions, these apply when the player is rolling. Of note is that acceleration is set by default to 0, though this isn't necessary.
• "Roll threshold": The speed at which the player must be moving to be able to roll.
• "Unroll threshold": The speed below which the player will revert back out of a rolling state.
• "Uphill slope factor": The rate at which an uphill slope slows the player.
• "Downhill slope factor": The rate at which a downhill slope will speed up the player. If both are identical, then the player will remain at essentially the same speed after going down and up to identical slopes, if not factoring acceleration if they go below the soft max speed.
• "Roll" versions of slope factor. To get the effect of rolling giving more acceleration, have uphill factor be significantly lower than downhill.
• "Wall Speed Threshold": The speed below which the object will lose its grip when moving on a wall or ceiling surface.
• "Max jump speed": I've changed the variable jump height setup so that instead of moving at a constant rate when the jump key is held (like the Platform behaviour), there is a maximum jump and a minimum jump, with the engine automatically giving you something inbetween if the jump key is released between the two. This is done because A: it's more accurate to the Sonic games and B: It gives a more parabolic jump curve.
• "Min jump speed": As above. Should obviously remain lower than max jump speed, or identical if no variable jumping is desired.
• "Rolling Enabled": Set to quickly disable rolling. Same effect can be acquired by disabling default controls and simulating all but the roll key, but this is quicker. This will also effectively disable any rolling-related actions.
• "Rolling jump control lock": In some Sonic games, jumping while rolling would lock the controls. It's enabled by default for accuracy's sake, but it could definitely be undesireable so it's optional.
• "Set Angle": Whether the object will rotate at 90 degree intervals when moving across slopes. NOTE: Not currently working yet. I want to make it offset the position so as not to cause the object to clip into or off of collision polys but that's not quite done yet.
• "Air Drag Rate": The amount X speed is multiplied by each 1/60th of a second, under certain conditions.
• "Air Drag Y Threshold": Y Speed, in pixels per second, above which Air Drag is applied. Must be below 0.
• "Air Drag X Threshold": X Speed, in pixels per second, above which Air Drag is applied.
• "Downhill Slope Factor Threshold": Distance, in degrees, from 0, under which downhill slope factor will not be applied.
• "Uphill Slope Factor Threshold": Distance, in degrees, from 0, under which uphill slope factor will not be applied.
• "Falling Angle Threshold": The lowest angle of terrain the object can fall off of.

TODO:

Rotate the object at 90 degree intervals while moving

Add smoothAngle expression (and X/Y offsets) to allow smooth rotation on slopes

Allow objects to move with a rotating Solid object (think seesaws)

Make TileMaps work. See Known Issues!

Known Issues:

Tilemap doesn't work! Tilemaps use an array of collision polys (I think) rather than just a poly or bounding box, and I'm still working on making that work. If anyone knows a simple way to get the relevant collision poly from a tilemap via the sdk, please let me know! Should be fixed in the next release, provided I can figure this out. For the time being, I'd suggest making tilemaps not solid, and having solid sprite objects act as collision.

Changing Angle of Gravity can mess with things. This is definitely something I want to fix (Mario Galaxy planets with Sonic Physics, anyone?) but with the behaviour being as complicated as it is it may take a bit of time.

Possibly the most important one: Intended for use with Sprites with collision polygons set to bounding box. Preferably square, but that's just so that all sides are even, since the behaviour doesn't yet rotate the object. The methods I used for getting points of collision are somewhat shonky and "good enough", but I'd prefer to redo them at some stage (which also ties in somewhat to the tilemap stuff). For now, the behaviour works best if you have a rectangular Sprite. For rotation, you can have another Sprite pinned to it that changes angle along with the SurfaceAngle expression.

If you have any feedback, requests, or bug reports, please share them in this thread!

It's worth noting that this is the first Construct 2 addon I've worked on, as well as the first time I've played around with javascript, so if anyone with more experience in either of those things has suggestions for improving this, I'd be happy to hear them!

Update: Release 1.0.3

Changes:

-Set Soft Max Speed now works

-Vector Y is no longer capped to Min Jump Strength if jump button isn't held (should allow springs and bumpers to work)

-Rolling Jump Control Lock now functions if enabled

-Removed Is Double Jump Enabled condition

Yeah, proper behaviour addon, mimicing Sonic physics. Got the essentials down, like you can see in the gif, just working out the details.