I really wish the other problems I run into when working on stuff were as easy to demonstrate in a simple cap like this. :p

Say I want a spinning boomerang thing that spins independently of the Bullet behaviour's angle of motion, and the behavior has an option to allow stuff like this - except it doesn't work, because the object's angle is always affected even if the option is switched to "no". I imagine nobody's noticed this because, quite frankly, you don't often want to make bullets not point wherever they're moving.

Example capx.

For those who were here back in the Classic days, this engine probably needs not much introduction. But now...

The original engine was using the Custom Movement, mainly because I hadn't really grasped original Static engine and wanted to try something simpler. Didn't quite work out, and also ended up resulting in being incompatible with the C2 custom movement. So when someone else continued with the static engine, I decided to port it over to C2... Though some issues still persist.

This engine is done completely in events, no behaviors. Mainly functions, detector objects, and a whole lot of math and variables. Needs work, but I'm getting there... Eventually. Oh, yeah, and it's totally open-source, so feel free to try and improve it.

<img src="http://dl.dropbox.com/u/919275/Screenshots/SCW2/StaticScreen1.png" border="0">

Current Features:

• Slope-based platforming movement
• Standard controls and moves (running, jumping, rolling, etc.)
• Loops
• Platforms (jump-thru)
• Springs
• Sonic can be hurt and die (With S3 animations rather than Advance, yes, I'm a bit lazy with that, but I'd rather be coding than doing animations)
• Spikes
• Rings and ring loss
• A few sound effects
• Monitors, some of them working fully (the icon doesn't float up and disappear yet, and monitors aren't solid, see issues list)
• Shields with special abilities (Bubble shield ability doesn't work yet for reasons listed below)
• Bumpers, both from Spring Yard and Carnival Night Zones, working more or less perfectly
• Balloons from Carnival Night Zone
• Shoved all the Sonic-specific stuff into its own event sheet, for the sake of organization

Known issues:

• It's easily apparent that the player doesn't rotate fast enough. This results in some awkward results when trying to move up slopes or loops.
• In certain slope situations, Sonic spontaneously stops for absolutely no reason, "snags", in a way. It may or may not be the result of certain sensors mucking things up when they shouldn't be.
• I just discovered a limitation of the Classic engine that carries over to this one - if you don't have a gap of wall between a curve slope and a floor, you will immediately move onto the floor once you've gone up the slope rather than flying off. Granted, this can be easily worked around with level design tweaks, but I still call shenanigans.
• I need to figure out how to make solid monitors and the Bubble Shield bounce work without making Sonic automatically go into 'idle' mode upon landing.
• Sonic's sprite lags behind the player object a tad now in some circumstances, for some reason.

Playable Demo! (Controlled with arrow keys and shift. Z+Down allows you to fall through platforms.) Also, an EXE download.

Construct 2 .capx, release 106, requires Standard license (requires the Function Plugin)

And for Classic users...

Classic .cap (Version r2, requires the MagiCam and Slgor's input system plugins.)

I didn't meant to accuse you of anything, mate. XD Still, it's a rudimentary thing that only works with specified objects, and can't work with curves.

Sonic the Hedgehog is practically the pinnacle of tight, well-designed platform rotation physics, IMO. When there's a guide on how to replicate it and existing examples out there, might as well copy from the best!

PROGRESS! Ashley has let me know that my suspicions were correct. Turns out that RotateAngle() is basically the same as C2's "Rotate towards angle" action, which required me to change some things and introduce a new 'angle sensor' purely for the sake of replacing the 'pvAngle' variable so I can take advantage of this.

The result, as you can see in the .capx, isn't perfect, but it's getting there. The angle isn't spazzing out, but there seems to be some odd delay at times, which makes me suspect that there is indeed collision issues.

Pretty much! Proper slope detection is a must, methinks. Might as go all the way if you're aiming to do that, since there's an entire framework already there to base the behavior on. :p

Tokinsom: Well, the platform behavior can move on slopes, but it can't automatically rotate on them, nor is it capable of properly traversing curves. But, yeah, general improvements are a good idea all round.

JohnnySix: To be fair, using two separate sprites is a well-known technique. And crouching is easy, make a separate animation for while the player holds down. :p

Believe it or not, Ashley, there's actually an entire guide on how Sonic physics works. The page linked in PixelPalette's post above is just one page in the whole thing!

Sonic Physics Guide

Plus,you can also check out the Classic version of the Sonic engine I'm trying to replicate in C2 (with some difficulty). The physics, to my knowledge, are quite accurate, so it's a good reference as well. Best to look at both, since the event-based engine works a bit differently when it comes to stuff such as rotations, due to the guide being based around methods used in the Genesis/Mega Drive Sonic games.

Really, creating a more advanced Platform Behavior based around Sonic physics may seem hard, but Sonic fans have spent years figuring out how it works. Obsessive, but it does have benefits. :) Build a solid framework based around those physics, and then provide users with options to be as flexible as they want with it, and then you have a behaviour that will let you do more than what is there right now, I think.

Speaking of which, Ash, did you get that PM I sent you about anglelerp() and RotateAngle()?

Edit: Fixed the links. And just to note, even Mario could run on walls at times in Super Mario World. Food for thought.

I know there are obviously other things that you want to do first, Ash, and there is a lot on that to-do list, but I do feel the need to point this out.

The platform behavior is neat, but the Classic behavior has some things that the C2 version doesn't:

• Variable jumping height
• Air speed options
• Inverse control
• Bunny hopping option
• Being able to fall through platforms (would be nice to be able to do it with a custom key, too)

But I also think that the behavior has some other limitations that could be addressed that limits what people can do with it. Namely, rotations. Some platformers (Sonic being one of the first examples) allow platforming characters to rotate on slopes, walk/run on walls, that sort of thing.

I've tried to do such things with the custom movement, but I'm pretty sure it's extremely difficult to do, because methods from Classic don't work very well at all. Physics... Just as difficult, if not moreso. And the only other alternative is making your own movement through pure events, and that can get very complex indeed (especially if you're trying to create something momentum-based like Sonic).

I think it might be beneficial to create an "Advanced Platform Behavior" that gives users much more flexibility and options on how they want to make a platform character to move. Do they want rotations on slopes, or not? How about being able to slide or roll down a slope to pick up speed? Stick to walls and ceilings, or fall off if there's not enough speed? That sort of thing.

It would unshackle more than a few of the limitations of the behavior while also giving users the option to start off with the "basic" version, and moving on to the more advanced options if they want them. Slope rotations, believe it or not, would go along way to extending what a platform character can do.

With that in mind, I imagine an "Advanced Platform Behavior" (or just an improved regular behavior) would have these features:

• Slope Rotations
• Slope acceleration/deceleration
• Collisions based on objects/families as well as the Solid/Jump-Thru behaviors
• Toggling collisions with particular 'solid' objects on a per-instance basis (rather than turning off the actual solid itself)
• Some other stuff I can't be arsed to think of right now

Long story short, if you can faithfully recreate Sonic platform physics using such a behavior, I would say that would be the point where you can say 'mission accomplished'. Can't be that hard, surely. :)

I know there's a LOT on your plate, but I guess it really can't hurt to make suggestions.

Uh... I've already done that, actually. That being said, "else" isn't compatible with the Function plugin, but that's not my main problem right now. *Points at my last post*

ALRIGHT. I've isolated the angle problem to TWO main possible factors. It can only be one or the other, not both, I presume.

a) The anglelerp(a, b, x) expression. It's supposed to replace the RotateAngle() expression from Classic, but I have a feeling it's not working right. I'm gonna ask Ashley about it via PM.

b) The collision detection system might not be working properly in this instance, though I can't see how it would cause spontaneous and virtually random changes in angle.

I do think I'll need an "else" for the function, yes, at the very least. Placing a function inside a function, as I said in the function topic, may not actually be at all necessary, and should logically be unnecessary in my opinion.

Alright, let's go with implementing "No triggered function" for now. For all we know, putting a function inside a function may not even be necessary. It was structured that way in Classic probably because putting an else as a non-sub-event caused an error in this case for no apparent reason.