Hey not sure if this is the best place to ask since it's about a specific library, but I'm using Roomy to manage game states. The overall setup of the game is there's a world map where the player moves around and a series of towns they can enter that are represented as text menus. My idea is to represent the world map as one scene, and each town as its own scene.
For the most part, Roomy works very well since it allows you to "push" the town scene on top of the world map scene, then pop it and return to the world map scene. However my issue is that it that each scene is represented as a class, and the class is reinitialized each time the town is entered so there's no way to have persistence or have things change over time (for example, unlocking new shop items when you've completed a certain quest).
I've been banging my head against this for a while and am wondering if anyone has found a good way to use Roomy for something like the towns I'm envisioning, or have any other way of implementing a scene system with persistence?
I think that’s what I’m moving towards. My only concern is I will need to have a class for TownA, then another class for TownAStore, then another for TownASalloon… then I will also need separate structures that contain the data for TownA, TownAStore, TownASalloon, etc. I feel like this could get pretty unwieldy if there are like 5 towns with 5 shops each… or is that just how games are sometimes?
I think that’s just the nature of the beast. If you have a lot of complexity, it will require a lot of state to reflect it. Since it sounds like your game will require multiple play sessions, you should probably start thinking about how you intend to support saving and loading game state too, since that will require similar logic.
There are some tips in the docs about saving game state. I like to have save/load functions on each class so that they own the responsibility for deciding what needs to be saved and how. Then the top level save/load functions can call each directly (or indirectly, if they are hierarchically structured) and tuck everything into one giant state table.
Also, think about which bits of state are essential, and which can be inferred from other state. For example, you could save state reflecting exactly which items are available in a given store; or, you could infer the right items to make available based on the player’s level, their current inventory, which bosses they’ve beaten, or some other data you already record.
In all likelihood, you’ll discover a lot of things you need as you develop your game, so it’s probably not worth worrying too much about getting the framework right from the start. I’d prototype it, work out what you need, then start over….
That said, a single town class can be used to create multiple towns, a building class can create multiple buildings, etc. and initialising these can populate a single ‘state’ table that holds all the data. Then class updates change the values in the state table.
Thank you both for the suggestions. I think the takeaway is to not worry about it too much right now, though I like the idea of inferring from other classes (for example tracking quest progress in the player class) and I’ve seen the idea of having an overall game state object that’s shared between classes so I may look into that as wel.