Procedural Animation School #1: You gotta rotate before you can walk.
Procedural animation. Most people think of spiders and a lot of legs. This is one part, but I would say transforming physical forces into rotations is even more important & a good start > Thread >
The rig is super simple and entirely done with empty gameObjects acting as bones and primitives parented under these "bones"
These are the global variables we need.
You see there a serializable class called AnimatedPart, that is what we will use to animate our body parts.
We will use velocity (Rigidbody in this case) and yawdelta (difference between current rotation.y and last rotation.y).
This is the logic used to animate the figure. I have separated character controller rotation and visuals rotation. This is something I find is very useful.
And this is my setup inside the editor.
This technique can be applied to animated characters. Just multiply procedural rotation to current bone rotation. This is not magic and you'll get the best results if the rigs are made with procedural animation in mind.
I hope this was to some use. Feel free to ask any questions! I will return with tutorial #2 in the near future where we'll set up some procedural locomotion.
Disclaimer: Any errors made in the code are intentional just to piss you off.
A softer setup. Endless possibilities!
The "look at my belly" setup.
If you make anything with this as an inspiration, or if you come up with ideas/improvements on your own, I would deeply appreciate it if you shared in DM or something :)
I saw errors. Sorry, retroactive update.
We need to add a Quaternion named startRotation to the AnimatedPart class and set that in the start. And then add the procedural rotation to that start rotation. Not needed on animated stuff since they have a set rotation per frame.
This is why im not a teacher.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
If your indie game project is a character running around in a nice environment. I would recommend going away from the computer, take a hot bath and ponder upon the core mechanics instead of getting the cape physics just right.
Not so much ”I hate Journey”, but rather ”Are you sure you’re working in the correct order of things?”
The risk as I see it. Is that people work their way in a massive ambition debt. Meaning, your game radiate a scope and ambition that will multiply through all aspects of your game. If you can't match that, there will be dissonance, and also put a lot of stress on the developer.
Felt like some the tutorial suggestions could be answered directly. This is a hard one for me because i recognize my privilege & everyones path is different. Just make games/prototypes I would say, share progress, don’t fret if it doesn’t get noticed, just keep at it. >
Do not let your ego get in the way of progress. Feedback does not need to be challenged. Feedback is not the law. Feedback is best when it’s unfiltered and raw. (Kids are amazing playtesters) Take the pieces of feedback you vibe with.
Stay in discomfort and make progress even though the brain wants you to flee in the opposite direction.
#UnrealEngine5 Lumen light game idea. Essentially similar the style of this old thing I did a long time ago. But the character would emit light. And there would be light pylons around the map that would change the player's color and give them >
different attributes while standing in the light. Absorbing the pylon would give the player a certain temporary buff that they could bring with them but deplete the pylon. Child pylons could be activated getting there in time with your timed buff. If a player already was colored>
when they absorbed a pylon they would get the product of those two colors combined and could then later activate a child pylon with that combined color. A very dark game where you would be the main source of light and could throw away parts of yourself acting as light sources.