koobas.hobune.stream
Quick Question on State Machine
Hello, all! I have just set up a finite state machine for my player, and I would like to know this:
Is it better to run all functions of the Player (for instance, the movement script) inside of the Finite State Machine?
Or is it best practice to keep the State Machine in its own script, and have other scripts attached to the player that reference it to get the state?
Thanks- YA!
If you want to learn on FS$$anonymous$$, you could have a look there http://unitygems.com/fsm1/ (Warning, it makes use of advanced topics)
Well yes I know that movement is a state and the State $$anonymous$$achine has a custom Enum called Player with all of the states. The State $$anonymous$$achine switches the enum for a variable 'player' in the script.
Is it better to have scripts reference that State $$anonymous$$achine or is it best practice to have all scripts pertaining to the player that work with the State $$anonymous$$achine be smooshed into it?
Interesting question , both main and the above comment. In the 3D buzz 3rd person character system there are 3 scripts on the character : Controller : $$anonymous$$otor : Animator ; and the State Engine was in the Controller script. All the scripts were static instances (Singletons) so there seemed to be no problem sending enum variables in functions called by all the scripts. When I tried this for myself but not using singletons, I had a problem where the name of the enum existed on another script but I couldn't just put the variable of the enum in the function e.g. $$anonymous$$oveChar( GoLeft ); . That left me just using one script for my player/enemies with the state engine. Saying that, I also use separate trigger and physical colliders often with their own scripts, which talk to their parent object script. Hope this generates some more traffic for you =]
Or is the question : If my script has 2000 lines, but most are 3 line functions, and only a few of those functions run per Update, is this efficient?
How you script is up to you. If code is efficient is also up to you! But the principle is simple : what am I doing on a per-frame basis?
Or the approach I have started using is one script for each behaviour. So movement , targetting, shooting, even getting inputs. Then when you start a new project, just drop your movement script onto a cube and instant game. Once you have written the code once, why write it again? I think this approach is called object orientated , although that could be more about monobehaviours generally looking after themselves.
I'd recommend encapsulating it in its own script:
It is important enough to be encapsulated in a separate file, since it is responsible for the player state, and this is non trivial.
Readers of the code including yourself will see "PlayerFiniteStateMachine" and be reminded of its responsibility.
Your Player file will be smaller and more encapsulated. Left unchecked, classes like Player can grow very bloated over time. The more code you have in a class file, the more you have to read/scroll/consider to get at what you want.
Pulling out the FiniteStateMachine into a separate class/file makes it easier to run diff tools on the file, allows other programmers to work on it in parallel with less source control conflicts.
It also decreases the amount of errors per file - if you have state errors, you can fix these in isolation, without thinking about other errors you may have in Player.
This will allow you to follow the Single Responsibility Principle
This is interesting to me as well and it makes sense. Thank you for your commentary.
$$anonymous$$y pleasure - this sort of encapsulation really does reduce headaches, and make code bases live longer. It is also easy to to extract scripts for use in other projects :)
One other thing, what is the advantage of making the, say, Player FS$$anonymous$$ its own Class? I'm not going to have multiple instances of it, right? So where would the advantage be? Thanks!- YA
The advantage is is that by making it its own class, you encapsulate it. The responsibilities of the Player class are broader then the responsibilities of the 'PlayerFiniteState$$anonymous$$achine'. You want to keep them separate, just like you keep cutlery in a different drawer from other kitchen stuff. It makes it easier to find/organise things.
Both :) Its own file and its own class. Aim for this 80% or more of the time, as the rule rather than the exception.
