Finite state machine

Started by
5 comments, last by Gnollrunner 1 year, 5 months ago

I'm a little familiar with finite state machines. I programmed a small poker game that used a finite state machine. I also found this (kinda cool) tutorial: https://www.aleksandrhovhannisyan.com/blog/implementing-a-finite-state-machine-in-cpp/

That said, what do you think a tactics rip-off would need, in terms of states?

Advertisement

taby said:
I also found this (kinda cool) tutorial:

Wow. I have learned how to replace this:

struct Light
{
	int state = 0;
	void Toggle () {state = (state+1)&3;}
};

With 5 classes, singletons, pointers, something like 10 files, designs and concepts.
But still no reason to use, or giving an example requiring a state machine.

That's the kind of coolness you get from wearing Nike shoes, but not the coolness you get from running 100m in 7s. ;D

taby said:
That said, what do you think a tactics rip-off would need, in terms of states?

Idk, but it's surely something you'd like to be ‘tweakable content’, not actual ‘program code’. So something data driven.
Big engines use node graphs and scripting languages for that. But that's too much work for just one little game, i guess.
But you can still do it in some minimized fashion.
I use something like a ‘Command List’. I can add commands to represent various processing tasks and their order, e.g. ‘Simulate’, ‘Upscale’, ‘Surface to simulator’, ‘Simulate erosion’…
It can also do loops which i use to do my tiled processing stuff.
It could also implement branches and jumps to implement some logic and state machines.
So basically, a very simple scripting language running some byte code, which could be written in text files.

Maybe that's a reasonable alternative to having tons of C++ classes for every little thing.
I just don't know how ‘minimized’ and low effort this can be vs. using a ‘real’ scripting language (lua, Angle Code, etc.), which might be the better option.

taby said:
That said, what do you think a tactics rip-off would need, in terms of states?

State machines are concepts. There are as many ways to implement them as your imagination can dream up. On the simple end they can be a number and a giant switch statement. On the elaborate end they can involve huge collections with a bunch of classes and complex interactions.

As JoeJ mentioned, for larger games they're generally driven by data, for smaller games they're generally driven by code.

A tactics games will likely need a set of commands, a way of ranking or prioritizing commands such as an AI driven by utility functions that calculate the utility of all the various commands, and a way to transition between command states and idle states waiting for the player or the clock. How to build those, and how complex to make them, are up to you and your designs.

Kind sirs… thank you so much for the insight.

@joej are you referring to me as the underage Chinese factory worker? Lol. “my” reflection method is more like… Hushpuppies lol

Way back when, I implemented a finite state machine system with macros in C. You would actually write the FSM tables into the code in table form. It was mainly for parsing. I added the ability to add optional function pointers for each state and input combination. In addition, those functions could select one of a number of possible new states on return. You could also run FSMs within FSMs by the use of said functions. I wrote a couple scripting languages that actually got a fair amount of use at the company where I worked.

This topic is closed to new replies.

Advertisement