The question is, where should I store my game logic?
In this case, the game is single player only and has only one game type. It has multiple maps but changing the map does not necessitate any new data or logic. The same game rules work no matter the map.
I think that there is no reason to add an extra block in the daisy chain so to speak- no reason to make use of game mode/game state - I can pass data from actors and widgets to the Game Instance. Game Instance holds onto any data which needs to be saved and it will also generate data and run game logic which also gets passed down to actors.
As an example, a widget tells Game Instance, “we are starting a new exercise.” Game Instance generates data for this exercise, spawns a new pawn, and the pawn looks to the Game Instance for data it specifically needs for the exercise.
So the flow goes like:
user input into widget
data transfer to Game Instance
run logic in game instance
open level, spawn actors, deliver data to actors, play game
Typically people are using game mode/game state, but in my case because of the simplicity of the game, I believe that would only add an extra step of data transfer with no benefit?
Is this correct assumption? Can anybody share a lesson llearned, or possibility/contingency I might be missing?
The primary goal here is to refactor my project so that it is more easily maintainable for a solo developer. Right now I have data that needs to persist on things that do not persist, and without a clear central command I find I waste too much time trying to hunt down dependencies when I make changes.
Good to keep my expectations realistic - no matter what it’s never going to be perfectly clean and “easy”.
I’ve read more about it and talked with a few other people and I can see the utility of gamemode/gamestate for multiplayer, match style games. I can understand why you need these different places to store and protect data.
I think in my case the main concern is I don’t want to put data in a place it could be wiped out without me realizing it, and then also like first mentioned, I dont want to have to manage passing data to a place that isn’t really doing anything.
So today I will go ahead and consolidate my “game manager” code from an actor it had been on to the Game Instance. I’ll use the game instance as central command - actors and widgets will send and get data from there directly. Since the game instance is persistent there should be no threat of data getting initialized or destroyed when an actor spawns or destroys, or we change a level.
Any data that doesn’t need to be held onto simply doesn’t send it to the game instance, and then when level is changed or actor is destroyed, so to is that data.
That’s my thoughts right now anyway. If I learn anything which changes this entirely I’ll try to remember to update.
You can’t avoid using Game Mode, since the default is used every time. If you really want to avoid extending the Default Game Mode, you can use any actor in a level to hold data. Just make an Actor, then add the actor to the level (That’s more or less what the game mode is)
All these classes run per level and I think that’s where you run your game logic. Only in the case of persistent data that you want to keep across levels then you use Game Instance. That’s usually where you want to have your save game variables, player profiles, settings, etc, that usually gets saved to disk.
