I'm a young developer who wants to make my very own 2.5d fighting game like SFV (not on the same scale of course). As of now, I've had a good 3 months of programming experience, especially on Unity, but I won't say that I'm an advanced or even intermediate level programmer yet. However, I really want to make this dream game, or at least do a good job trying, but I have somethings on my mind that are causing me some roadblocks.

I play a lot of fighting games (I'm alright but not the best) as a form of research and also looked up some aspects of game development/design that apply to fighting games, and one of the main components are state machines or FSM's. However, I don't know how to go about writing an FSM and I don't want to use Unity's Mecanim controller as I've seen that it doesn't really work well for more complex fighting games. To pretty much sum it up, All I want is some advice on how to go about making a state machine primarily for fighting games.

You basically have two parts, the design time code and the runtime code. Design time means anything you need to setupt your FSM properly, what states exist, what are the results of each state and so on. There you have a couple of possible options, write it into a file and parse it on startup, use ScriptableObject and create the database in Unity or use som kind of node based graph to visually click that together.

(On GitHub)

And finally the runtime code, when all nodes are connected to each other. You have to grab the first or active node from your FSM and evaluate it, if it evaluates to any of it's connected conditions, change the state, perform the action behind and store the node behind the condition as new active node in the FSM. On next update continue, it is just that simple.

Or use a ready solution also from GitHub

Thank you, for your advice. Basically, from what I can understand, I have to create a database of each state and their data/variables and find a way to connect each one depending on what conditions they have achieved, and whether which states they can transition into. I kinda understand what goes into a state machine, but the real confusion is how to go about making/programming it. Like, do I use enums? because that's what most people seem to do, do I make scripts for each state and create a way to link them together so they can effectively transition to the right states? do I use scriptable objects? Pretty much what I'm trying to know is how to build a state machine and a good effective way on how to tackle it, and not what goes in a state machine. Maybe It's me and I don't really understand it yet, but I just need some more clarifications. But thank you again for the response.

There is no fixed way to program a state machine, unless you're reading too much design patterns.

A state machine consists of 4 things:

- Something that indicates the current state (a variable)

- An initial state (initial value of that variable)

- A function that changes based on the current state.

- A function that decides if a state change should happen, and if so, to what new state.

Anything with those 4 components is a state machine, As such

b = True

def output():
  global b
  if b:
  	print "On"
  else:
    print "Off"

def Toggle():
  global b
  b = not b

is a state machine, current state in "b", initial state "True", "Output" prints something different based on state, and "Toggle" changes state.

Usually however, there is more data involved, and often different values for different states, so you get towards

class State:
  def __init__(self, val):
    self.val = val

s1 = State("On")
s2 = State("Off")
current = s1

def Output():
  global current
  
  print(current.val)

def Toggle():
  global current
  
  if current is s1:
  	current = s2
  else:
    current = s1

If Output uses a lot of data you may want to use the State itself for computing it. You may want to have arrays with additional data, etc etc, whatever you need to make the functions work.

But as said, anything with the 4 parts as listed above is a state machine, so for your state machine, identify what each part contains, and then implement each part in a way that you like.

You shouldn't use Enums for a fighting game because you propably want to involve new skills and then need to change the enum every time so go for a class that represents the move would be a good way to start

2 hours ago, Shaarigan said:

You shouldn't use Enums for a fighting game because you propably want to involve new skills

You can use enums, but then you need to define all levels in one state machine, and cut off parts of the higher levels by adding a sufficient skill level as condition to enter such states.

Defining a new state machine at each skill level is likely simpler to start with. The disadvantage of that approach is that if the lower skill levels are a subset of the states of the higher skill level, you get duplication of states.

And you have to manage a tree of state machines which is a massive overhead depending on the complexity of skills and combo skills

On 7/22/2019 at 7:42 PM, Harmones81 said:

I'm a young developer who wants to make my very own 2.5d fighting game like SFV (not on the same scale of course). As of now, I've had a good 3 months of programming experience, especially on Unity, but I won't say that I'm an advanced or even intermediate level programmer yet. However, I really want to make this dream game, or at least do a good job trying, but I have somethings on my mind that are causing me some roadblocks.

I play a lot of fighting games (I'm alright but not the best) as a form of research and also looked up some aspects of game development/design that apply to fighting games, and one of the main components are state machines or FSM's. However, I don't know how to go about writing an FSM and I don't want to use Unity's Mecanim controller as I've seen that it doesn't really work well for more complex fighting games. To pretty much sum it up, All I want is some advice on how to go about making a state machine primarily for fighting games.

You can have as many state machines as you want... do you have a _purpose_ for them?

I would assume the primary purpose it for evaluating moves. Most fighting games have combos, or chained button combinations to perform a move. This can be seen as a state machine. The player has a state that defines if they are standing/crouching/etc... and the state machine should respond to inputs according to it's current state. So pressing down, while in standing state will transition to the crouching state. The crouching state will respond to not having the crouch button held, and return to standing. There ofcourse could be other events, such as getting hit by an attack, or starting a combo. Pressing attack from the crouch state may start a crouch-based combo attack... triggering an animation, and maybe a timer. If the timer expires, then the player might return to standing state, however, while in this combo state, maybe hitting a different attack button changes the player state to a chained attack from the previous.

Etc, etc. In reality, there are FSMs everywhere in programming. The state of the game, such as 'Menu', 'Playing', 'Fighting', 'Win', etc.... The entire game is infact one giant FSM. Any game, for that matter. The only thing that really _defines_ a FSM, is that there are defined states, (a finite amount of them), and a machine that processes data based on those states, including changing the current state. Often Enums are used, since there is a finite amount of states.

There _are_ bad ways of programming FSMs. Primarily I would warn you to watch for invalid states. The simplest example would be if you 'state' was stored in an integer, but only values 0-10 are valid states. You would need to watch closely for the possibility of the state becoming 11, or 19283, or whatever. That's a fairly simple example, a more common one would be if your state was stored as individual booleans. For example, the player's state could be stored in several variables: isStanding, isSitting, isLowHealth, etc... Now we have the possibility of isStanding and isSitting both getting set to true. Depending on how other logic is written, this could cause all sort of issues. Here, an enum would be better, since those states are mutually exclusive. 'isLowHealth' being placed in the enum would explode your possible states, since it's not mutually exclusive. So now you need enum states like 'isStandingandLowHealth', 'isStanding', 'isSittingandLowHealth', etc...

Hopefully all of that helps... sorry for the rambling nature of it all. Just start trying. 3 months of programming is an eye blink, keep at it, and you'll figure it out. Youtube FSM tutorials. Happy Coding

Thank you all for the answers, I think I've kinda figured it out now and I've been following his tutorial on youtube where the guy is making a 2.5d action sidescroller and,  although it's not a fighting game, there are concepts that are very similar and he made a state machine that I feel could really work for my game. Again thanks to all of you for helping me out, but I know that there's probably a lot more questions I might ask later down the line, so I hope you guys will be willing to help me out.