This question in very similar to this question, however I am still confused about how one would implement a story and quests in a finite state automaton RPG.
This is my first game that I am making (my background is in computational science not games) and it is similar to this game. At every frame in my game you are in a state. Examples of states might be
Player Stats screen, etc. Each state has a
previous state that allows one to progress (or back out) to one state after the other. For example if you are currently in the
World state, upon moving to the door of an inn the state changes from
Inn. After clicking to leave the inn the state then reverts back to the
World state. All of this appears to be what is described in the this question.
However, quests and story don't seem to fit all that well here and I am confused about what data structures to use for quests and how they should be implemented in the game. One problem with quests is that they cross states and time. For example, you might get a quest from the inn keeper (in state
Inn) and then have to go back into the world and perform some action to complete the quest (
World state). Maybe you then have to turn in the quest to the potion shop keeper (
Potion Shop state). All of this crosses multiple states and knowing when to post dialogue to the screen is time and state dependent.
The easiest solution seems to just create a quest dictionary and make it global. This way all states can see all the quests and data in the quest dictionary (e.g. different flags etc) can be modified at will. The downside here is that a) we are using globals, a generally frowned upon idea by most programmers, b) this quest dictionary could easily become quite large and cumbersome, and c) this idea is hardly OOP. Another idea I had was to create a class called
Quest and each quest would just be an instance of a this class. I would then pass these instances to whatever states need them. This is also pretty cumbersome though. Having to pass quests around to different states (and basically hard coding different quests to all the states that need access to them) seems like a bad idea. I could also implement the quests directly into the states. For example the
Inn state has methods and flags to deal with quest 1, quest 2, ... etc. This isnt very OOP though because what if I want more then one inn? The quests associated with my first inn would be different from those associated with my second inn (different inn keepers after all!!). I would have to write two different versions of my
Inn state class.
I suspect I am missing something obvious here given that my background is not in game design. I understand the finite state automaton at least in terms of moving from location to location within my game, but I am failing to grasp how to do something similar for quests and story. Should I have a global quest data structure? Hopefully this isn't marked as duplicate. Thanks for any help you can give in clarifying this for me.