Hi everyone! i've been going crazy for at least a week trying to make my character work but i seem to not be able to do that. i have a 2D platformer character that i've split in two to be able to play the top side animations on their own while he can still walk and run. doing some research i've found out about state machines and i've been able to make it work for the "leg" side, the problem i've been having comes with the top side. i tried to make a second copy of the state machine to control the torso but i cant make it work. i keep having issues wiht animations and states not switching when the "bottom" (literally a copy) counterpart is working fine. what am i missing here? how do i make a concurrent statemachine work? i'm not sure if any could could be of help here so i'll wait for some response to be able to gove something more specific. Thanks for reading!!
i’m working on a metroidvania and from what i’ve read online that would be the best way to go to no have a mess of a code in the long run. right now i would be fine with just moving and jumping but i dont want to have problem soon while developing the abilities
are you new to game dev? if you are be carful of scope creep, I just want to warn you that metroidvanias are one of if not the hardest game to make as an indie developer and to also make it good. there is a huge chance you won’t finish it. also I hope you made every mechanic you need for the game before you made the art. that would help extremely with a project like this.
hi! thanks for the reply. yeah i’m awear that its a pretty hard genre to takle and i’ve promised myself to keep it pretty simple! i will for sure test mechanics before going into detailed animations but that doesnt really scare me since i’m an animator so it wouldnt be too bad!
I think those “state machines” are making it needlessly complicated for your use case. You did get stuck after all. Why just not implement your character controller without them?
Don’t worry about the future code. Make it work now in the simplest possible way within your abilities. Don’t complicate things just because you’ve heard something might happen with your code in some hypothetical future. It might as well not happen.
Not really sure how we can help without seeing some code. I am doubtful that you need separate state machines for the two animation parts. Perhaps instead you need an animation_manager.
Don’t worry about the future code. Make it work now in the simplest possible way within your abilities.
I don’t think state machines are really that complicated and variations of the concept (behaviour managers, animation managers, base managers, vehicle managers, game managers etc etc) can be beneficial in many aspects of the game. So worth learning. However, how would we know what’s wrong without seeing some of your code?
Refactoring code and restructuring as the game develops are all perfectly normal. It sounds like you are prototyping to me, so just bash it out as best as you can and as fast and simple as you can just to make it work. You can make it slick and beautiful later. Or post some code about your state machines and we will take a look at that.
“State machine” is in fact one of the most trivial concepts in computing. The problem is with clunky turbo object oriented, node-based implementations that entered Godot tutorial lore and are touted as some kind of a must for player state management… or else your code will end up in some mythical proverbial “mess”. Ironically what is often seen with beginners, their code ends up a mess when they try to follow those state machine tutorials.
“State machine” is just a multi position switch. If you make a class with one variable and some code that does if on its value - you’ve defacto implemented a “finite state machine”. With two such variables, you have a “concurrent finite state machine” implementation. Such mouthfuls for such a simple concept.
Branching on an int value is a perfectly legit and useful implementation of a state machine. It’s also super simple and manageable, compared to some object oriented inheritance monstrosity scattered across blank nodes.
On top of this, the “state machine” from tutorials is really not an adequate pattern for modeling player state in most types of games, especially action games. It operates under assumption that player is always in some singular discrete state, which is almost never the case.