What I want to do, is Sonic the Hedgehog styled physics, sticking to the surface & angling to it based on speed.
I’d think it’d be as simple as raycasting to the relative “down” of the player & getting the surface normal, checking the normal values vs your speed, and then rotating the player to line up with the normal if they are the right speed.
So, how would I actually go about scripting this?
If the player is going a higher speed, they can attach to a broader range of angles
The player, given enough speed, can run a full loop without a pre-scripted event, just physics
The player is controlled by a rigidbody
If the player leaves the surface (jumps, slips off) they will follow normal gravity and fall down
When the player looses their speed, they fall to the global “down”.
The player doesn’t randomly rotate in the air since there is a curved/not-flat angle somewhere below them but they haven’t landed yet
I think the rest of my game will be easy enough, but that (the 360 degree running) is an important element of it.
So for starters there’s several different sonic physics types.
The 3 big ones are:
classic 2d sonic (which is obviously 2d)
sonic adventure/early sonic 3d
sonic boost
As well as multiple offshoot gameplay styles, like the 3d blast, 2d mobile, and others… but I’m assuming you’re referring to one of the main series ones.
Big thing to consider here is that the way sonics physics usually works is contextual. Especially in the 3d sonics.
Take for instance Sonic 2006, known for its buginess… walking on walls when you shouldn’t be able to, or other walls you should be able to run down not working, or gravity swapping on you weirdly. Now you might think this is just unique to a poorly made Sonic2006, but it’s not… I mean the poorly made is definitely a huge flaw of it, but the cause of the bugs are inherent to the design of Sonic physics in general.
Basically in a sonic game there are trigger boxes all over the place that change sonic between his various physics (and this goes for 2d sonic as well… watch a video showing the Sonic Mania level editor and you’ll see the various triggers).
When entering a loop it’s set up in a way that you can’t enter the loop unless you pass through some ‘entrance way’, and this entrance way has a huge trigger box that tells the game sonic is now in a loop, and as a result sonics physics changes to meet the requirements of moving through a loop. This is why you can walk around a loop in Sonic 2006:
The flaw in Sonic2006 is that they forgot to add in a “if(velocity.magnitude < X) sonic.FallOffLoop();” line in their code.
So yeah, you come up with the various contexts for physics. And then you deal with those contexts as required. But HOW you deal with those contexts hinges on what they are, and what style sonic you’re talking about.
It kind of is actually, because there’s a really simple solution to that in Unity… Layer masks and tags (though not necessary but can help with some more advanced functionality). You could even use a GetComponent to get information from a common interface on objects, feeding the character whatever contextual information it needs, as a single GetComponent per frame isn’t bad, but a handful of them definitely is.
OP probably does mean the classic 2D sonic type though, in which case a raycast relative down, while applying a relative down constant force and a surface angle direction force can be nice. Though you may want to take it a step further with a raycast at both side of the bottom of the character and one in the bottom middle, this way you can check for many different contact conditions, and replicate that classic balancing over the edge animation Sonic does. That’s similar to how the old 2D games worked, though their version of a Raycast was more of a pixel tile cast.
When I said it’s not unique to Sonic 2006. I mean in that all the Sonic 3d games have this contextual physics to it… it’s just that 2006 didn’t do enough bug fixing on it and thusly dropped the ball. But all the sonic games use the same general concept for contextualizing its physics.
And your example of using GetComponent is basically just an implementation of it. You need a way to know where you are, what object to call ‘GetComponent’ on… sure, once you have it you know in what context you are. Sonic 2006 knows WHERE you are when you walk on the loop… that’s not the problem, the ball was dropped in that they failed to do a test for if going slow drop off the loop.
Also, I’ll point out the flaw in just having a component on the surface and you GetComponent on said surface to know what’s what… it does not account for how you entered the surface. The reason sonic games use a entry trigger into set pieces like loops and wall runs and what not is because it acts different based on how you entered it. You don’t stick to the loop unless you run into the entry way of the loop… if you had got there some other way, like say jumped before the loop and tapped the edge or top of it (for whatever reason)… we don’t want to stick to said surface, instead it should be treated as any old obstacle.
In any case, the intended physics are more like the Adventure series, or, the Blitz Sonic fangame series where (i have gone through the source) there are no loop triggers, and instead you raycast down and rotate to the angle 0f the surface, angles proportionate to speed.
Anyway, i got it working on my own in Unreal engine C++, but thanks, guys.
