This semester I've been taking "Computer Theory 1" in college, primarily dealing with finite state machine design. I haven't done the analysis myself yet, but to any of the desktop engine devs here how feasible do you think using a state machine could be in keeping track of, say, the map engine in a Sphere-compatible implementation? I'd probably use an implementation similar to that presented in this Stack Overflow q/a.

I know for web usage specifically I'd also have to deal with certain threading considerations and how they might affect the state as well. I'm counting on y'all for direction, peeps!

Isn't a map engine largely stateless though?  I don't see how implementing it as a state machine would even make sense, honestly.

I don't really think a finite state machine would be a good way to implement a map engine.

I find it pretty rare that implementing anything as a state machine actually makes sense.

Well to be fair, oftentimes you'll have micro state machines at a lower level (NPCs keeping track of their walking direction, etc.) but yes, at the macroscopic level a state machine usually doesn't make sense.  It's easier to implement and maintain if you can keep your high-level logic (e.g. UpdateMapEngine) as stateless as possible.

Well to be fair, oftentimes you'll have micro state machines at a lower level (NPCs keeping track of their walking direction, etc.) but yes, at the macroscopic level a state machine usually doesn't make sense.  It's easier to implement and maintain if you can keep your high-level logic (e.g. UpdateMapEngine) as stateless as possible.

Sure. Although at a microscopic level, it becomes increasingly up to interpretation what can be considered a state machine.

I've heard that some parsers work well as finite state machines, but I've always found it much easier to write recursive-descent style parsers. Probably the only time I found a state machine to be obviously easier for parsing was to write a component that parsed C/C++ integral type declarations (int, long int, unsigned long, long long unsigned int, etc.) Which probably indicates that the mushier and harder to define a syntax, the better suited a state machine would be for it? I don't really know how true that is.

Well to be fair, oftentimes you'll have micro state machines at a lower level (NPCs keeping track of their walking direction, etc.) but yes, at the macroscopic level a state machine usually doesn't make sense.  It's easier to implement and maintain if you can keep your high-level logic (e.g. UpdateMapEngine) as stateless as possible.

This is almost certainly the missing bit of education I needed regarding usage, "keep the state management as micro as possible."

In a broader sense look at RPG Maker. It's state system works well for events and quests. A finite state machine is good for quests and quest progression. This can in turn be applied to a map engine. But it is just one piece, certainly not the map environment itself.

Also, good to hear from you N E O. It's good to know you seem to be hanging in there, taking classes again.

But it is just one piece, certainly not the map environment itself.

Yes, this is pretty much what I meant about having state management at the micro level.  In a sense, a player's entire game session (for an RPG at least) is a huge complicated state machine, but that kind of stuff tends to fall under "game logic".  If you're building an engine, it's probably good to shy away from modal logic where possible.

Also, good to hear from you N E O. It's good to know you seem to be hanging in there, taking classes again.

Thanks, dude. All the donations helped keep me afloat long enough for my financial aid to kick in. Work study came in late but I have it nonetheless, and I'm working on making a particular set of plans happen for the winter semester. We'll see how things turn out.

I'm really glad to hear things are well too. And funny coincidence: I have been learning about state machines in relation to ROM hacking recently.