Lots of little bits done today.
I think a refactor is in order to streamline the reaction lifecycle.
There's a lot of cross-talk in the nodes right now, especially when overriding sonic's animations and when taking damage.
Need to make the programming pattern more consistent if I potentially expect other people to use this.
This is all starting to come together. Not much on the actual features side done tonight, I spent most of my time working out a better flow pattern for delegating calls
Each ability gets passed a state object to modify and can either pass it on to the next in the chain, or return a final state
For example the hitbox might care about flashing when invulnerable and then let another ability decide what animation to play
It's similar to how .net core handles middleware
Few days since the last update but it's mostly been engine things. Abilities are now able to interrupt key lifecycle events like input and animation.
The playing Animation drives whether the hitbox is in normal or crouch mode, and if it's attacking or not.
I've also started adding in interactive elements like breakables and enemies, and environmental areas like water.
Oh, and sound. I've got a 4-channel sound script that simulates the limitations of older consoles.
for the sound script, unless otherwise stated, it will try and be smart about what channel it plays the sound on.
First it looks to see if the effect is already being played on an existing channel, and just restarts the effect (this prevents something like the super spin dash from deafening the player)
Then it looks for the first free open channel.
If no free channels are found, it takes the last channel used and plays the sound through the next channel up.
Today's items are pushable blocks and more animations.
I want to thank the Spriters Resource for not only the Sonic animations, but the massive Sound Effects library. The new site refresh is excellent.
https://www.spriters-resource.com
They're over on bluesky, https://bsky.app/profile/spriters-resource.com
So I have no idea if this is how the OG corkscrews work since I can't find anyone who's done a breakdown, but this is a decent emulation with minimal changes to the player system.
The rainbow collider is only solid when Sonic is going fast, slow down and you fall through (this is also how I plan on doing running on water)
The collider tells the animation system they're in a corkscrew, and to play Frame x% through the corkscrew animation (if not rolling)
I have accidentally turned the straight-jump bug into a drop dash bug :|
When I refactored the jump code I forgot to listen to the 'disable jump' flag I added.
Oh, also, jumping is an optional ability now.
I'm going to *try* and decouple the physics code and make running like sonic optional too, though that might be more difficult than it's worth.
Button button, who's got the button?
I do. And I've made the ultimate Sonic block-pushing puzzle.
This is truly Sonic at its most difficult.
(I promise no game I make will require anything this to progress, but I can't promise I won't hide some obtuse Easter Egg behind it)
Also, ignore the janky slope pushing, the fact it works at all right now is purely accidental.
First power up in, Speed Shoes.
With the physics chain in place powerups can decide if they want to apply their changes before or after later abilities.
Water is handled as part of this chain so we can decide if we want to replicate the OG water bug or fix it, just by re-ordering the nodes.
I think I prefer the water reducing key variables by half, rather than just cancelling your speed shoes (though, regardless it will restore your shoes once you're out of the water)
Back to normal service. Picking off some easy wins after that week of frustration.
Pushing blocks uphill is now smoother (there's a slight animation hiccup the movement is smooth)
One of the edge-case issues with Sonic is that, on flat ground, his left/right push sensor is at his ankles. On slopes it's from the origin.
I've added a new push sensor from the origin that only triggers other blocks (no repositioning) if the original push sensor doesn't hit anything
@imp3tuz I've been thinking about how to do this for the last week. It's the only way that makes sense to my programmer brain.
I wouldn't be surprised if the constraints of the old console meant they had to do some crazy wizard shit to make it work though.
I'd love to know the maths behind it but I am not qualified to reverse engineer this stuff.
@imp3tuz My plan, had this not worked, would have been exactly that. On contact, take the players speed, and hijack the movement to follow a path.
Let the player hold left/right to slow down and drop them off at the end or when they slowed down.
It's a LOT more work to do that though so I'm glad this way worked out.
@BigTheDave is the player also colliding with the corkskrew itself or is it glued to the rainbow collider?
And this looks really cool!
@themipper the rainbow collider is just treated as ground by the foot sensors, but only if the player is running faster than a threshold.
The animation frame being played is dependant on the characters X position from the left side of the corkscrew.
Nothing fancy besides that.
BigTheDave
imp >:3
Whatisgoingon