[BEHAVIOR] Sonic Physics

No new release yet, but I felt it was worth giving a quick update since I mentioned the 11th as a potential release date. Progress has been pretty good so far, I got the bulk of the work on the angle stuff done, so I'm well on the way to getting something released, though as usual, I'd probably best not give a date I can't guarantee.

As it turns out, SAGE has been delayed, which doesn't really have a bearing on this, but I guess it means that if I get a template going by the new deadline (whenever that is) I could get something submitted, so at least I don't have to write that off till next SAGE.

Anyway, this weekend will probably be taken up by the Ludum Dare, so I may not be able to get further work done for a bit yet. Thanks again for your patience, guys!

Also, Rilem, that looks pretty cool, I've never actually put any sprites to the behaviour yet, so it's good to see it looks ok! I assume you're just setting the sprite to SurfaceAngle there, or are you interpolating things somewhere?

Really amazing engine, love the way it's a nice behaviour, tight and tidy. This could potentially take over the crown of Sonic Worlds in the indie sonic dev community.

Thanks! As long as it can end up as at least a viable alternative I'd be pretty happy.

Yeah I'm using the SurfaceAngle, but I'm using construct's "rotate to" function to interpolate between the angles.

Good luck, can't wait to see this finished.

How'd you get the surface rotation to work here exactly?

PixelMonkey thanks for this plugin.

> Good luck, can't wait to see this finished.

>

>

How'd you get the surface rotation to work here exactly?

Alright, so another status update, probably the last for the short-term. As mentioned previously, most time spent on this recently has been for replacing the way retrieving surface angles work. As of recently I managed to finally fix all the issues I was having, getting things to effectively the same point as the previous release, just easier to expand from, in theory.

The current issue, though, is that now that I've started trying to actually add things (namely rotation and tilemap support) I've started uncovering more bugs and edge-case scenarios.

Now, I'll still eventually get to the point where I can fix these, but A: running up against MORE BUGS after spending all this time on just getting back to square 1 is demotivating, and, more relevantly, B: university has started again.

It's not really fair for me to keep saying "soon, I promise" since it's already been like 6 months, so this is effectively notice of a hiatus in development for the behaviour, at least for a few months.

I still intend to continue work on this eventually, I'll continue adding any bug reports or feature requests to the todo list if anyone has anything, and if anyone needs suggestions for workarounds in the meantime I'm happy to give suggestions, but I thought it'd be only reasonable to let you guys know that development isn't speeding up quite yet.

This is a very good addon. I have been using this to create a Sonic "engine" thing which is supposed to recreate things that were in the genesis games, such as loops and the spindash, for example. However, while I was working on the engine thingy, I came across a few bugs:

-If you try to change Sonic's max speed while in-game, an error message occurs.

-In the engine, I added springs. However, if you jump into the springs, you wouldn't go so high.

-Even if the player walks on a extremely small gap, the physics would cause the player to try to walk onto the gap (I noticed this when I was trying to recreate a Sonic 2 level in the game)

Ah, thanks for the feedback!

For the first issue, it turns out that's a very quick fix, just a typo. It'll be working whenever the next build releases.

For the springs, how have they been implemented, and what specifically do you mean by "wouldn't go as high"? The initial thing that comes to mind is that the variable jumping could be messing with it, which could be fixed in a couple of ways, but I'll probably need a couple more details.

As for the third issue, I don't understand entirely. Would I be able to get a screenshot of what kind of terrain the issue is being caused by? And what do you mean by trying to walk onto the gap?

Very interesting behaviour. I like it a lot. Similar to what I'm looking for.

How did you retrieve the angle of the surface? Is there a way to do it based on an object's position rather than touch?

For example, if an object is high up, is there a way to see the surface angle beneath its 'feet' so that a check can be made to see if it would land successfully?

The way it works is to offset the position by 1 so the object is overlapping the ground, and then figure out which segment to check the angle for.

You could probably achieve something along those lines by shifting the object down until it hits the ground, checking the angle, and then pushing it back up again, although looking at the plugin as it is now it seems there isn't a way to specifically trigger the surface angle check. I might make a note to add an action to recalculate the surface angle.

Another alternative could be to have a sensor object sitting on the ground and following the object above, though keeping it on the floor nicely could present issues, depending on the terrain.

How would I get something like the bumpers in levels like Casino Night working?

You'll want basically just:

Sonic: On collision with Bumper:

-Set Vector X to 420 * cos(angle(Bumper.X, Bumper.Y, Sonic.X, Sonic.Y))

-Set Vector Y to 420 * sin(angle(Bumper.X, Bumper.Y, Sonic.X, Sonic.Y))

The Sonic Physics Guide, particularly the Springs and Things page, gives some more numbers and info, but you'll want to update most values from pixels per frame to pixels per second.

^ That said, though, I tried it out myself, and I've recreated TheAmazingApple's bug in the process. Unless you're holding down the jump button, it caps your speed to Min Jump Strength. So the above example events currently won't work unless the jump button is being held down.

If you wanted a really hacky workaround, you could simulate jump button under certain conditions to stop the behaviour from limiting the jump, but I realize that's pretty terrible.

Ah, thanks for the feedback!

For the first issue, it turns out that's a very quick fix, just a typo. It'll be working whenever the next build releases.

For the springs, how have they been implemented, and what specifically do you mean by "wouldn't go as high"? The initial thing that comes to mind is that the variable jumping could be messing with it, which could be fixed in a couple of ways, but I'll probably need a couple more details.

As for the third issue, I don't understand entirely. Would I be able to get a screenshot of what kind of terrain the issue is being caused by? And what do you mean by trying to walk onto the gap?

For the springs, I used the vector Y action. However, as you noticed when you tried to implement bumpers, it doesn't bounce as high as intended.

The third issue is hard to explain.

First off, have two ground sprites sitting next to each other, one sprite's angle being 330 and the other sprite having the angle being 30. If Sonic tries to walk up one of the sprites, he won't simply walk to the other sprite. He would instead act as if he was walking on that surface until he would adjust to the angle of the other sprite.

Anyways, your welcome for the feedback. I really like the classic Sonic games. And I can't wait until the next update for this addon (I want to use tilemaps so badly. I hate using sprites.)