Thanks! It needs a rewrite, it's clunky and could be more convenient to use.
FELES MACHINA
Creator of
Recent community posts
Your welcome, be warned of the lastest 2.2.0 release. A lot of changes compared to former rigs, could mess with compatibility with older rigs But it was the tradeoff to add Unreal/Unity compatibility too, and make it the semi-official rig of the Quaternius models. (check out his stuff if you haven't already. Great great free assets, models, animations, clothes, etc.
OH MY GOD. Thank you so much for not giving up! I've correct the mistake!
Sheesh, i keep former versions as I work and did not realize that I had re-uploaded a former v1 version on Itch, even though the Github had the latest. This explains so many questions i've had from users lately. Thanks so much for getting to the bottom of it for me.
I've fixed it, it should be good now, and i'll be more careful in the future!
The one in the description above is the lastest. But note, that is the name of the deform bones only. Not the control or other auxiliary bones that Rigify uses while in blender.
So when you export, with deform bones only, and import your model into Godot, you will see the bones listed above. But in blender, you will only see those bones if you really dig into the rig, because they're SUPER nested in their hierarchy, and even if you enable deform bones to be visible (because they are hidden in blender by default) the control bones are on top of them nearly exactly and will make them hard to click. So there is a little bit of "trust me they're there". Or just use the search bar in the scene viewer and type a bone name in question, you should see it pop up.
Are you getting any sort of errors at all when you hit the "prepare for Godot" button? if not, then it's likely everything is working correctly.
Are you using the lastest Rigodotify? There was a big change recently former versions of the plugin used a different final skeleton, but the past one (or two?) versions use a new naming scheme that makes it more compatible with Unreal and Unity and not just Godot.
So if you're using s former version than v2, youl'll likely see a different bone structure and names.
That said if you just want a gemeric camera system, just grab a different camera system from the asset library rather grab this full template/demo.
Any bigger template or demo has to make decisions for the dev making it less and less flexible for reuse. I'll do my best on a rewrite to make it properly modular, but still, it has to make decisions for the dev especially if it has any type of targeting going on.
So, the answer to most of your question are kind of linked to each other, even though you made it 3 different questions.
So your goal essentially is to be able to share animations and be able to tweak animations, while also doing as little full animating as possible. You want to mix and match across lots of places, and use root motion.
Cool cool. So, with Godot's retargeting, you can mix and match animations from Mixamo, from Rigodotify, from Stinty, from really anywhere that uses a standard skeleton that you can map into Godot. You can bring in as many animations as you like, save them into libraries, and share them across all your models. So whether to use Rigodotify, Mixamo, or some other skeleton as your base, depends on your needs.
If you just want to reuse animations, just rig a model in Mixamo, map it into Godot. You're done.
If you want create your own animations and have more control. Use Rigodotify for convenient control Rig, make the animations in there, you can always add Mixamo animations to it as libraries later in Godot. If you want some premade libraries, i have a few hundred animatins on my github i give away, some aren't great, but still, it's a massive free library so, have at it: https://github.com/catprisbrey/Godot4-OpenAnimationLibraries
Root bone should be on the floor, yes. And it should animate any velocity movement you want in your game. So forward and backward for walking, left and right for strafing. Etc etc. If a mixamo one is flying all over, it's probably thinking the hips are the root or something, and that's not what you want. Root is generally pretty steady. Some mixamo animations i believe are setup for root, they'll have a checkbox "in place" or not, and you want to have it NOT be in place, so that root drives it forward.
If you need videos on retargeting, and using libarries, my youtube channel is full of them. You'll probably want these ones relating to animation here:
https://youtube.com/playlist?list=PL35yqmsJzxjvuYNgoxrxpOFxu5ZzwhbZ5&si=4WrdbQAo...
I cover a lot on animation retargeting, using libaries, making your own, etc. Hope this answers your questions, and gives you places to find answers.
It depends entirely on the type of game you want to make, and how accurate you want the movements to line up with the ground, or be in sync with other actions. But for the most part, root motion only makes life eaiser for almost all attacks and movement code, and for the small percent where you want full control.. just code as you would as if it weren't root motion. At any time you can forcfully move your character somewhere anytime you want. if you choose to include the root motion information, then you just fetch it from the animation tree, but if you don't want it, then just don't do that, and code it as if it weren't root motion.
For a soulslike, you 100% want to have root motion, it'll look a hell of a lot better and make adding most actions a lot easier, and for the actions where you don't want root motion, you just code it like a regular dev. Imagine a big ax swing where the player takes 2 steps forward to swing the big thing. It'll look MUCH better to animate that with a root bone, controlling how far the player moves with each swing during the animation. Blender is easier to animate that with, no doubt. But imagine trying to do that in code. Telling him to wait a half second, then move forward .25 a meter, then wait, for the next step, and another .36 of a meter, and then another .15m to straight out his feet again... That is hell (and what the non-root version uses... and it's like honestly double the code)!
So for souls-likes, yes, root motion is better. Period. I'm making a Metal Gear style game now, and using root motion is a million times easiser there as well. But if I were to do a RTS, starcraft, age of empires, etc etc style point and click. It'd be easier and preferable to ignore root motion since i'll be moving enemies around on a grid... but if i didn't have a grid system... i may even still there use root motion so their feet match perfectly their speed as they walk.
For me, swapping to root motion solved most of my movement code woes. Game dev got a lot easier after that point. I don't use root motion for rotation, i prefer to control that myself based off camera, and for vertical motion like jumping etc, i also leave it out. Easier to do that in pure code or based off math rather than an animation. But for regularly directional movement, root motion is a massive massive time saver, and headache reliever.
Do you have specific questions?
If you use the root version of the project, then yes, it'll need a root bone. You can pop your character into Blender, parent the skeleton to a new bone called root, and be good from there. You just need a root at the base of the whole skeleton.
Otherwise, download the older version of the project, it's non-root.
I strongly recommend using and learning root motion though. It's not difficult to pickup and makes life a million times easier. I was reluctant for a good year or so of game dev to try it out. Kept telling myself "i don't need it, i don't mind, non-root is good enough". And yeah, you can get by, but honestly it's like using a spoon when you could be using a knife. It's just so much easier to do just about everything when you use root motion instead.
Sermon over. Good luck!
I think that's fair for sure. Even if this were something more generic too its be handy on my end. I already use your village generator this way, but if it were adjusted it'd be evnn more handy. Like, rather than similar shaped/sizes of homes, along curving roads-- having a few key/large buildings, that smaller buildings or props procedutally arrange around, and perhaps not on curves or a circle but on more square grid based rows?
Somewhat emulating a town square w/Town Hall buildings, or a school/gym/library that then smaller buildings, trees, parking or parks would arrange around. University campuses tend to imitate small urban layouts already. Like mini neighborhoods
All your generators are amazing and I've used them for inspiration of several game layouts. Which brought another idea to mind. Sorry to play the idea guy right now, but a 'facility generator' would be handy. Something that produces layouts of schools, universities, military bases, airports, hospitals, etc.
Examples of things it's shuffle would be parking, maintenance area, supplies area, administrative/public facing areas, scattered buildings, commissary/cafeteria, field grassy areas, fenced areas, etc.
The games areas I've worked on lately have needs for complete facility areas and your generators immediately came to mind.
I've been using your app for a while now and was inspired to make one similar for character design. Thanks for all the inspiration!
Character Idea Generator
Thanks for playing! Agreed on the oxygen meter, i probably could have turned it off in the pre-crisis scene. I consider the pre-crisis scene to be the tutorial area. It gives you about 500 seconds to figure out controls and get to the satellite. Once you're there, it refills to 100% after the crisis once the true level starts to give you a full chance of survival back to the ship. I hoped that was enough tutorial time for folks, while also keeping them from meandering around too long and testing the limits of the level's bounding box. But also... easy to stop it from ticking pre-crisis.
Some tutorial or explanation would have been VERY helpful. At the start of a new mechanic it's good to handhold the first use of it. I wandered around throwing watermelon at nothing for a long time before realizing there were animals to be fed. It wasn't clear to even be on the lookout for it.
Something as simple as once the watermelon / pineapple, etc is picked up the first time, the camera is forced to look at a creature pop up, Maybe even show a label for a moment like "It looks hungry"
As simple as that and you'd be golden. Level two was very pretty, i'd almost say lead with that one too rather than the library. Much more engaging environment to be in.
This game was a blast! It thought i wasn't going to win there for a minute (that last level with the BIG black hole is really great). I've played a bunch of submissions this week and this one was at the top for fun value. Great backgrounds, appropriate audio, on theme. I think the only thing it was missing was a powerup! Rapid fire, a AoE missile/bomb, or a stead stream laser or something.
Really great work though, very fun!
Thanks! I used MaterialMaker to create all the textures (fun fact, almost all are only 128x128 pixels haha, UV scaling for the win), and the shaders are mostly simple clamped noise, moving over time with emission.
Worked real well for making a space sky for very cheap and keeping file size small on all models.
Haha yeah, the gyro and thrusters are best done it short bursts, and then pause to gauge your new velocities. The draining Oxygen adds a sense of urgency but the trick is to stay calm and make careful moves. Our game can be quite boring and short if you just remain chill.
I'll still check your game out still during the jam. Everybody deserves a chance to have their game voted and played.
Hmm, having an issue making it unplayable? The game loads, but immediately shows the pause menu, and doesn't let me leave it? I hear music, the screen scales if i change the size, but it's just none of the keys shown, or mouse clicks or ESC or anything are responsive. Playing on Pop_OS Linux, in FireFox, 1080x1920 resolution. Music sounds nice though :)
Mixed feelings about this one. I loved the look of it and the feel. Great models, great textures with the hand painted look which went well with the music. Great looking shaders on the item picked up, etc. Visually great all around, and immediate world-building that worked! But then the other aspects didn't hold up,:
Animations with no blending, the jump action out of sync with the animation for it. The entire level restarting at each death rather than checkpoints before obstacles. Obstacles you can't beat without losing to them first because they didn't seem like obstacles in the first place (looking at you sinking bridge! what a bait and switch!)
It just felt aesthetic and mood were great but the programming didn't match it in quality. Lot of potential here though! Whoever is doing the art, and world building, you're stuff is on point! :)





