StateMachine nightmare :D

divergy321

Hello!

I'm trying to create nice movement and combat system for my Metroidvania game. I already created movement state machine where i can jump, dash, wallslide, run, fall... also input buffer and "coyot time" to make game feel more responsive, and now it is big and complicated. And ye, it all is in one script. Now i have to implement combat system. I want to create some slasher like combos. I know that it will be hard, but i want to create different move set based on that are you in rage mode or not. I know that it will be tons of code. Problem is that both, movement and combat, systems will be complicated and it will become bigger nigtmare than it is now.

So my questions are: Maybe StateMachine like GDQuest shows is better or have better performance? Or maybe someone knows other StateMachine template that will not becom in to the nightmare like my own Statemachine did? Can someone please explain main idea of slasher like combo hit system and base idea of how I can create something like that? * Is it a good idea to create two or more StateMachines for Movement, Combat and possibly for something else later? Or better to try merge them in to one uber StateMachine?

Sturcture of my statemachine is simple but at the same time it is complicated: At the begiining with ready function I declare that start state is "Idle" I have one main physic process function running. It calls current states "update" method, that conains state logic, and "check_next_state" method that checks possible next states. Thats all, it works, but it turned in to 400+ rows of code. :#

cybereality

You probably want a single state machine, as moving and fighting are intertwined. Like you can be dashing and then press attack. Or maybe jumping and hold down the strong attack for a big slash. So they have to work together.

In terms of combos. There are a few ways to do it. I've seen people try to do this using timers, but I find this gets messy as you then have to manage the timers (stop them when an action is cancelled) or deal with several timers at once, which can get confusing. It is easier for me to just store the time point of when a certain action happened, and then update the time counter (by adding delta each frame) to check if it is within the limit you set.

Here is some pseudo code that might help you:

var light_slash_time = -1

func _process(delta):
   if light_slash_time >= 0.0:
      light_slash_time += delta
   if light_slash_time > 1.0:
       # combo is limited to 1 second so if 1 second has passed
       # stop checking for combos and reset time counter
       light_slash_time = -1.0

   if Input.is_action_just_pressed("light_slash"):
      # light slash is not engaged to set it to zero to start checking
      if light_slash_time < 0.0:
         light_slash_time = 0.0
      elif light_slash_time < 0.5:
         # do combo one if less than half a second
      elif light_slash_time < 1.0:
         # do combo two if between half a second and 1 second

This type of logic can be combined with several different attacks (like a light attack and heavy attack) but make sure you have states for each attack type so you can tell when to switch to which state. Also, this only works for timing based attacks when 1 button is pressed (such as light + light + heavy or those type of combos). If you need Street Fighter style attack moves (like charge back for 2 seconds then press forward + attack, or half circle gesture recognition) it becomes more complex as you will need to store the history of the input presses in an array and parse through that. That should give you an idea though.

fire7side

Now that you have this experience, it's a good time to review what other people have done with state machines and see if there are any that would fit better for what you are doing. Maybe they don't look any better, maybe they do. Just do a search on youtube and watch a few videos. I've done it before and generally feel better about it after. Sometimes the best thing you can do is reorganize and you will find it's not as bad as you thought because most of the processes are actually very similar and much of your code can be just copy pasted.

divergy321

Hmm, ye, its a good idea to use delta to count time passed. I've been thinking about combat system implementation almost for a week, and this is what i figured out: To StateMachine that i have at the moment add "attack" state and use it as a bridge between two messy systems. I dont know how i could realize that to make it as easy to read as possible, but I'm gonna create combat system that will contain current "Combo_Sheet" (that means that i want to add more than one combo sheet), calculate which hit will be next depending on input and previous hit or state and of course active combo sheet. Also it will allow or prohibit movement durning attack. I think by using "attack" state I could make movement StateMachine and Combatsystem work together and impact each other. (Lol, it is gonna be something very complex and interconnected :# ) Because i am that one who figured out about this, i cant watch on this idea objectively, so, to avoid remaking, can someone say, is there any issue in my idea?

Also i found out idea in Youtube to create massive as a buffer that will contain previous attacks and types, and using it, i could calculate next attack type. But thats all. I didnt find any other useful information about how to code that. So if you know any useful tutorial about combat system, share it plz. I can try to code it from scratch, but it will be a little bit painful :/

About that, use timers or delta: I think i could use one timer to clear buffer that contain previous attacks. Using delta to count time passed sounds good, but I dont know which mothod will be better. I can create exit and enter functions for attacks that will end timer or change timers wait time. Also i can use delta and do same oparations withot using timer node. Or maybe use them together? Idk

It grows more and more complex, so i started thinking that I am doing something wrong... I already reconstructed my statemachine 3 or more times, and now it is relatively easy to read and orientate in code. at least at the moment. I dont have enought experiance and youtube is poor on information i want :'( , so any ideas are welcome!

cybereality

Yes, you can use a Timer if you want. This would reduce a bit of the code and might make it easier if you have many Timers going at once (rather than having 20 different time variables). The Timer has a "time_left" property you can use similar to my code I posted. https://docs.godotengine.org/en/stable/classes/class_timer.html

fire7side

If the states can occur at the same time, it's not really a state machine, so having two? For instance running while attacking is separate from running. Jumping while attacking is separate from jumping and you will have to transition from running to running while attacking or jumping to jumping while attacking and vice versa. I can see having transitions separate from the state because you might not even be in that state anyway. If you want to separate states that are basically the same thing, it kind of points to a design problem.

divergy321

Okay, deal with two different state macihnes will cause lot of transition problems between them. But what if there will be one main statemachine and subStateMachine? Them i have other idea: What if to my stateMachine I will add state "attacking" as a base attack state that will delegate all taks and calculations to sub statemachine? I think i could make this sub statemachne get current combo sheet, calculate next attaack type, apply animation of this attack and check next possible state. attack state is reachable from states: Idle Jumping Fall And next possible states of attacking will be: Idle * Fall

Is there in my idea a fundamental issues i missed, or maybe someone can try to predict issues that probably will occur later? To avoid rebuilding process, maybe someone sees what could possibly go wrong, or maybe some recomandations? =)

cybereality

It's possible, but I think it's unnecessarily confusing to have 2 state machines. It is called a Finite State Machine, the entire point is that you are only in 1 state at any given time. You can easily limit which states can transition to which other states, that is not a problem (and is in fact easier with 1 machine).

xyz

How about ignoring this whole concept of "state machine" which often leads to a lot of code bloat for simple objects like metroidvania characters. Instead you can just use several basic state flags. Their composition then determines the actual state. The state is implicit. This approach is to the classic state machine what ECS system is to a class hierarchy :)

For example, you can have the following flags: jumping_up, falling_down, walking, standing, attacking. Combination of these 5 flags gives you an implicit state machine with substates and overlaps that may be better suited for solving your problems than a rigid state machine. You just process any combination of these flags that represent a state of interest. For instance, if attacking flag is set you can process the attacking part regardless of the state of movement flags or you can take into consideration only those movement flags that influence the attack. This is conceptually and practically much simpler than managing ever increasing bunch of discrete states like jump_attack, stand_attack, rage_jump_special_attack... ect.

fire7side

@xyz said: For example, you can have the following flags: jumping_up, falling_down, walking, standing, attacking.

State machines are there to eliminate the flags. It's hard to say if one is better than the other. It depends on the circumstances, but the more states, the more messy the flag system gets. You can picture is_running_while_attacking, is_falling_while_attacking. Then what about multiple attack types? Usually that ends up into an endless stream of code. Code is easier to maintain if you can separate it into some type of group and states works fairly well. It can still get messy with like 50 states or something, but that's better than an endless stream of if statements. With states you are only dealing with what the thing is doing and the possible transitions to another state. It doesn't really get confusing adding more even if there are more possibilities of going from one state to many more others. The key is getting the information you need to make the choices up front. It can't just be input because sometimes it might be a collision that changes a state or it just finished and needs to go back to the previous state. That would be a signal possibly. That's why people get over their heads with it.
I don't think a node system would be a bad idea because a node could have it's own timer, tween, animation player or who knows what. I haven't used anything but a simple system so far, though.

xyz

Sure, it depends on the problem. Things can get tangled up both ways. OP originally got confused over a regular state machine approach that's supposed to make their life easier :)

I just think insistence on using discrete state machine pattern is like insistence on using elaborate object-oriented approach without first assessing if it's really needed. If there is a lot of behavior overlap between states, designing with a rigid state pattern may fall short and result in code bloat. Sometimes you can get a lot of behavioral diversity from a small number of flags, if you choose them smartly. More so if the thing needs to do several classes of actions simultaneously, like move, punch and cast a spells in overlapping time frames. The more parallelism of actions you need, the more tedium in the discrete state machine management you get. At some point it may be wise to think of alternatives.

On top of that, flags do not necessarily translate to ifs, as it's evident if you look at any ECS-like pattern. If your choice of flags is well thought out and you process them in a structured and nicely wrapped up fashion, no cascading ifs should ever appear on the screen.

If you think about it, every state machine is just a bunch of bruteforce ifs. At least one if per state. It just tries its best to hide them from you :)

fire7side

@xyz said:

If you think about it. A state machine is also a bunch of ifs. At least one if per state. It just tries its best to hide them from you :) I think it's mainly separation of code. Sometimes you need it, sometimes it's not necessary. We haven't seen the OP's code, but probably it's not very well designed as a state machine and could well be closer to what you are talking about.

I was looking at GD quest state machine and it looks pretty good for separating code and keeping it from getting confusing: https://www.gdquest.com/tutorial/godot/design-patterns/finite-state-machine/

xyz

@fire7side said: I was looking at GD quest state machine and it looks pretty good for separating code and keeping it from getting confusing: https://www.gdquest.com/tutorial/godot/design-patterns/finite-state-machine/

Well even in that simple example they had to deal with state bloat, so to speak. They needed to introduce a state called "air" which is a new state that "merges" two other states - jump and fall.

I generally see each state in a classical state machine as a sort of flag. So why have a lot of mutually exclusive flags, processing each separately when you can have just a few processing them "in parallel".

Imo thinking of game entities as always being in some discrete state may limit one's game design and game mechanics ideas.

Separation of code is always good and should be done either way, but it's a mere practical issue, not a design issue.

fire7side

@xyz said: Imo thinking of game entities as always being in some discrete state may limit one's game design and game mechanics ideas.

Separation of code is always good and should be done either way, but it's a mere practical issue, not a design issue.

The combination of states in air is actually a good idea because it's probably not necessary to separate it further in a simple example like that, showing that you don't have to think in terms of an absolute state. You can make broader categories. He still could have easily done one state for each one but the complexity didn't demand it. His example was just an example and too trivial for a system like that. No one would do that. They would just do some flags. If you have multiple attacks with different weapons something like that would probably be useful. I'm not sure I would go that far myself and probably only use a function for a state. It's really more about thinking about what will be needed such as inputs, signals, collisions and what you need to keep track of before you actually come up with it and make a one off solution for it that turns into a code nightmare.

xyz

It seems that state machines serve their purpose when you have relatively small number of mutually exclusive "top-level" states. Add more complexity and overlap and they start to wear you down. But ironically, if you have just a small number of discrete states you can easily handle that with flags. And flags can, on top of that, handle much fuzzier situations. So it seem that state machines are actually useless abstractions. One of those things that sound good in theory but falls short in practice. Maybe it's just that I don't like them :) but I really can't see the need to abstract the solution to state problem further than having a dictionary of functions.

divergy321

Oh i didnt even know about flag system :o Sound interesting!

Code that represents main idea of my statemachine

var current_state:String = ""
var previous_state:String = ""

func _ready():		# say that Idle is starting state
	state_change("Idle")

func _physics_process(_delta):
	match current_state:
		"Idle":
			Idle_state_update()	# state logic
			check_next_states(current_state)	#check next states

		. . . # same for every state


# example of state logic
func Idle_state_update():
	velocity_calculated.y = move_toward(velocity_current.y, max_fall, gravity)
	velocity_current = move_and_slide(velocity_calculated, Vector2.UP).round()

#example of check function
func check_next_states(state):
	match state:
		"Idle":
			if dash_check():	#dash check returns true if dash conditions met, same works every other "state_check" functions
				state_change("Dash")
			elif jump_check():
				state_change("Jump")
			elif fall_check():
				state_change("Fall")
			elif run_check():
				state_change("Run")
			. . . # same for every state

# state change function
func state_change(new_state:String):
	#store prevous state
	previous_state = current_state
	state_exited(previous_state)	# for previous state call exit function. I does nothing now, but maybe something will need it, so i created it just to be
	#set new state as active
	current_state = new_state
	state_entered(new_state)	#for new state call enter function. It set ups animation and variables if needed

#and then i have 7 "state_check functions"
#example for one of them
func idle_check():
	if velocity_current.x == 0 and is_on_floor():
		return true
	else:
		return false

This is main idea of how my statemachine works. I didnt know about flag system before, so i dont know will it be easier with flags or "rigit statemachine"? Or maybe someone knows how to avoid these long match functions?

How i planed my state relations: How i imagine attack state under hood:

So will it be simpler if i will use flags? I already figured out how i could implement combat system, but it again will be hard and unpleasant work with bugs and state transition logic, but if probably I can do it simpler, im listening =)

fire7side

It's not simpler to use flags. They are just states but not organized into states. I think it would be all right to use an attack like that now that I see it. Nice little flow chart.

xyz

Well, ask yourself some questions; What do you need these states for? Do you even need them? Can your character dash and fall at the same time? If yes, how would your state machine handle it?

But since you already designed the range of your actions under the paradigm of discrete states, then you should probably try to implement it as such. I'd personally go for something simpler and more flexible.

I see a lot of people, especially beginners, using state machine abstractions only because they think they're supposed to. Then they got stuck because the thing won't allow for what they want to do. You're not in any way obliged to think under constraints of a finite state machine.

To avoid match stuff, make each state a separate function and put them all in a dictionary. That way you can replace it all with a single function call.

cybereality

@xyz said: I see a lot of people, especially beginners, using state machine abstractions only because they think they're supposed to. Then they got stuck because the thing won't allow for what they want to do. You're not in any way obliged to think under constraints of a finite state machine.

Well state machines are the "correct" solution, just like object oriented programming is usually the "correct" solution, but you should use the tool that fits the job. Also, beginners are probably better off learning the hack way first (with a bunch of boolean flags) that way they can understand how logic works, and also understand how that becomes a spaghetti mess and why state machines were implemented in the first place. But jumping from not knowing game programming to the ultimate solution can be confusing if you didn't learn the other steps along the way.

xyz

I'm not a big fan of obligatory object orientation, as you can probably tell :) I'd always vote for starting with simple stupid ifs and then incrementally refactor and encapsulate if things are becoming untidy. It keeps one from overthinking and overdesigning, which is a common problem with object oriented design, especially among non-experienced people. The infamous beginner's 'classitis' and such.

But it seem that op got stuck inbetween two approaches, judging from the code posted. They ideated their system as a state machine but implemented it using bunch of ifs instead of writing "proper" state classes that abstract away ugly parts of code. Worst of both worlds if you ask me.

So what to do? I'd suggest starting without thinking inside confines of the state machine concept. Just using simple flags/ifs. Most of the movement state from op's diagram is implicit anyway and the total number of states is small. Values and signs of the velocity vector components are defacto state flags here. Op's code snippet even treats them as such. If that starts to feel hard to handle, encapsulate stuff into functions. If that becomes cumbersome, write state classes.

Other alternative is to just go full by-the-book-object-oriented-finite-state-machine, and use one of the existing state machine systems mentioned earlier.

But as I already said - be aware that discrete states may not be the best frame to think about the overall state of the player entity in an action game, where parallelism of actions and sub-state overlaps are often wanted and needed. I wouldn't want to sacrifice that just to comply with some textbook design pattern.