Should i call the baseState in State Machine?

Getting Started
,
1

Hi, compulsory “sorry for noob question”. I’m tinkering with state machines. All my animation/various stuff is done by the base state. This is fine, but, I must call the baseState from each subState to start a new animation. I’m guessing this isn’t good protocol. I have other similar issues but they all boil down to the baseState containing core routines I dont want to duplicate 10 times. All and any suggestions as to how to get around this are welcome. How “bad” is calling/accessing variables in the baseState?

2

Make sure this is a useful expenditure of time, I mean doing this in the abstract rather than for a specific game or function.

FSM finite state machines:

This is my position on finite state machines (FSMs) and coding with them:

All generic FSM solutions I have seen do not actually improve the problem space.

I suggest never using the term “state machine.” Instead, just think:

  • I have to keep track of some THING(s)
  • That THING might change due to reasons
  • Depending on that THING, my code might act differently

That’s it. That’s all it is. Really!! The classic example is a door:

  • track if it is open or closed
  • if it is open, you could close it
  • if it is closed, you could open it
  • if it is open you could walk through it
  • if it is closed you could bump into it

Wanna make it more complex? Try this:

  • put a latch on one side of the door.
  • handle all the above with the latch locked or open

I’m kind of more of a “get it working first” guy.

Ask yourself, “WHY would I use FSM solution XYZ when I just need a variable and a switch statement?”

Your mileage may vary.

“I strongly suggest to make it as simple as possible. No classes, no interfaces, no needless OOP.” - Zajoman on the Unity3D forums.

1 Like
3

Thanks. That’s super informative and food for thought.
Since I got a reply I’ll add a bit more context to (hopefully) get any extra wisedom. I am “making” a game ( + expanding my learning unity/c# knowledge). Most of it revolves around Item usage. The item class, although structured, got out of hand (drop, collect, animate on different states. appear/disappear on flag etc etc) so I am currently converting it to an FSM. But this is my 1st time using “Design Patterns”.
I suppose my point is that: The states seem to rely on the BaseSate too much. What am I missing?

4

I mean the pattern of ‘subclass sandbox’ does exist: Subclass Sandbox · Behavioral Patterns · Game Programming Patterns

Though I would avoid situations where you want to call base.SomeMethod(), as it can be easy to forget to do this, and leads to hard to find bugs.

I would suggest something like this instead:

public abstract class SomeState : IState
{
	public void OnEnterState()
	{
		// do stuff
		OnEnterStateInternal();
	}
	
	protected virtual void OnEnterStateInternal() { }
	
	public void OnExitState()
	{
		// do stuff
		OnExitStateInternal();
	}
	
	protected virtual void OnExitStateInternal() { }
}

This way you don’t need to remember to call the base method, you only need to override the protected methods you provide yourself.

1 Like
5

yes, I think that’s probably the obvious thing I’m missing. (more abstraction?) Much Appreciated. Gonna try it out today. No more replies means success :slight_smile:

1 Like