my currently favored solution to the above problem is to have layered finite state machines [FSMs]. For example the top layer is a FSM that holds state about the current story 'chapter'. Each chapter is simply identified by an ID and a state in the ‘all-chapters’ FSM. All chapters FSM owns a set of chapter FSMs, one of which is activated, where the others are inactive. Each such chapter FSM owns a set of ‘location’ FSMs, one of which is current at any given time, depending on where the PC currently is located in the game world. For the chapter ‘Market Day’ the location FSM 'town square' would be different than the FSM for the same location during chapter ‘Execution Day’.

Drilling down to the location-FSMs, each of them owns a set of non-player-character[NPC]-FSMs, multiple of which can be currently active.

Viewed from the NPC, for a given NPC ‘Joan of Arc’ the NPC-FSM of, say the 'town square' location-FSM could be made up of completely different states than Joan's NPC-FSM of the location ‘Joan's hovel’. It could contain different dialog sequences or behaviors for Joan to act out. Also Joan's town square FSM during Execution Day would potentially be somewhat different to Joan's Market Day FSM.

Question: is this any good for modelling a fairly complex story based RPG game? Or am I missing something? Is there a better way to model something like this in code?

The one other way I could think of, doing this would lean more towards a big table of states, which can be looked up. But there I don't see how this would be manageable, without having big sections of branching code, always checking for many of the table's values.

Thanks for any tips.