Explicit state machine is better than an implicit one. And every program is one of these.

4 KLOC for big chunk of game logic is rather frugal.

The main problems that are plain is not enough names (for states, flags and triggers) and not having split off text to some central repository. (Making translation easier.)

Orthodox version of the state machine would have code execute while you're changing states rather than in any given state.

The big switch statement is a good design with mediocre implementation. (Compare with Sierra's AGI LOGIC code: https://wiki.scummvm.org/index.php?title=AGI/Specifications/... )

The giant switch statement doesn't bother me that much. It's essentially just a big table at that point.

What would drive me nuts are the lack of symbols for each case. At least there's a comment for many of them.

And it works! I learned a lot about preventing magic with this here: https://gameprogrammingpatterns.com/state.html

For me - and I mostly do frontend apps now - I always advise to go for state pattern instead of complex if/thens. Thanks to the aforementioned article.

I'm not at all accustomed to game design or game code. How is game state normally called upon and saved?