Is the "State Machine" pattern suitable for every game genre?

I'm rather new to Unity and game development as a whole, but I have been coding for many years, mainly in C++ or C#.

I've created many "minigames" to get a grasp on Unity, and I'm really beginning to understand it quite well. I am starting a new game, it will be an open world RPG for mobile (think World of Warcraft/Runescape). One thing that I've really been researching is design patterns, since this will be a huge game. I find following design patterns to be good in the long run - I have many applications written in WPF that follow the MVVM pattern and they are so easy to maintain, and I want to be able to achieve the same thing in Unity.

One design pattern that pops up a lot is the "state machine" design pattern. I just want to know if this design pattern would be well suited for my game type, or if it's limited in certain aspects? As I understand it, I would have a different game state for things like quests, combat, skilling, etc.

Are there other design patterns that might suit my game better that I can look into? Or is this a fairly flexible and easy to maintain pattern that other developers have had experience with?

Thank you very much!

 

State machines are very commonly used. Especially to manage overall game state, and in speciality areas like AI and animation.

That said not every problem in Game Design can be reduced to a simple state machine.

 

Yeah, state machines are super common.

AI is often done as a state machine (there's other methods as well though... like behaviour trees).

The unity 'mecanim' animation system is all done as a state machine. They actually added support for it to have states in it tie directly to methods in a script file. With which you can actually use it as a visual tool for setting up state machines using the mecanim structure. I haven't used it myself... but it's there.

But yeah, as BoredMormon says, not everything can or should be reduced to them.

But since games are often a series of states with transitions between them, they are SUPER useful.

 

#JustJuniorDeveloperThings

 

Seriously, though, can I put that quote as my post signature?

 

I'm getting so innoculated to it that I totally missed it.

 

are you being sarcastic bro? Everyone starts somewhere, even yourself... if he feels confident about making something like that then support him, dont be a dick about it.

 

Saw that coming, I know most new developers here want to develop something similar. At least it's not a FPS...and it's actually much deeper than that, I have it all planned out on paper, but I wasn't about to go into detail about it. Appreciate the help though.

Thanks to everyone else for their input! Greatly appreciate it.

 

You are new around here. FPS games actually aren't that had to make the basics of. Hence why the first real 3D game was an FPS. We don't get that many noobs making FPS games.

Most of them want to make the latest open world, RPG, MMO, like WoW, but better. So your game is in good company with every other first timer on the forums.

 

I'm not attempting to make a "better" WoW, my game doesn't even have any form of combat. And do you blame people for wanting to attempt an open world RPG? They can be very fun, especially if the storyline behind it is deep.

Heh, "noob". Is this one of those communities? Anyway, I'm not taking offense to any of this, I had a legit question and you guys answered it for me, so thank you. I just didn't anticipate my game genre to be mocked, out of all things!

 

No, it's just that MMORPGs are not really single-man jobs. If you're actually serious about it, go for it, but there are millions of MURPGRS out there that got a month into development before dying when the sole developer realized that it would be a 20 year job on their own.

 

Sorry, new users have a habit of scoping way too big. Experienced users have a habit of poking fun at those ambitions. It's not the nicest of introductions. Don't let it scare you off, we are generally friendly.

Anyway, back on topic, the FSM is a very powerful tool. However a game is made up of many interlocking systems. Some of these systems are very good targets for FSMs. Others are not.

You'll seldom have a single pattern permeating through an entire game. Most games will include many FSMs. But they will also include a ton of other things that are not FSMs.

 

hammers are useful, but they're not the only tool but you can get away with using one in a lot of cases where another tool might be more appropriate... just don't try to use a hammer to put a small hole in a piece of tile, then you really need a drill (slow and steady does it!).

 

And to further stretch this, almost every building project will use a hammer somewhere. Almost none will be built with only hammers.

And the style (read game genre) of house you are building is irrelevant to the tools you use to build it.

 

I figured as such, no worries! I know RPGs can and usually are huge projects, although mine is rather small at the moment, but I'm not underestimating the extent of the work that will be needed. I've done quite a bit of research on the genre, and actually (sorry for the comparison as my game will be very different) Runescape was started by only two people way back then...and that was without all these amazing development tools like Unity! So I got that on my side, right?

Finite state machines are what I've been focusing on primarily - there are many open source systems out there that I could use but I think I'll implement one myself, just so I can understand it more thoroughly. I'm typically not a copy-and-paste kind of guy.

You mentioned how a game can have multiple FSMs, I was actually curious about this. So, for example, I would have a state machine for something as simple as movement (walking, running, jumping, idle, etc), and then I would have other state machines on top of that, such as one for weather (raining/snowing) and day/night cycles, quests, skilling, etc? I can see how that would be very useful.

To further add to my question, could you think of a scenario where a FSM may not be an appropriate solution? Sorry if the question is broad - I'm trying to get an idea. It might be something that I won't know until I cross that bridge.

 

I Find state machines are working very well for me in a couple of areas:

• Overall game state - like being paused, in the game, in the menus, in the intro, in the game over scene etc. Each of my states has a setup, execute and teardown method and its trivial to switch between them - and also very easy to setup state restrictions to catch logic flow errors (for example I had one situation where my game went from intro to game over instantly). Game objects can take note of when the pause state activates to stop moving, ignore input etc. Works beautifully I find. As most games have these states if you design the state system well enough it should be possible to get a nice generic game state framework up.
  
• AI - I guess this was the obvious one, as many people have pointed out, but if you have simple AI with simple actions (attack, run, patrol, hunt, etc) state machines work really well. Although if the AI reaches sufficient complexity the behavior trees might be a better choice.

As for over doing it? I have seem situations where a boolean value would have sufficed many times. If it has only two states its boolean!

Anyway that is my experience with FSMs so far. They are just a tool in your arsenal, but remember they aren't the only tool you have

 

There are plenty of cases where you have continuous state, rather then finite state. For example FSMs are not commonly used in physics. The pattern doesn't really make sense there.

Health and damage systems often don't conform to FSM behaviour, (though they can).