Scenes

Progress on the Scene system

Right now I am working on the Scene System. This means how is the game going to change the things you can see from one "section" of the game to another. This could be as simple as changing the Intro at the start of the game to the actual Main Menu. But I needed an actual structure for the different types of Scenes in my game as well as a thorough refactor.

What was the state and what should it be

Before I started with a Scenes rework, all things drawn in the game are tracked and managed by my "GameContext" class. Soon I realised this becomes more and more a controller rather than a "Context", because with the introduction of Scene traversing I got some issues with dependency injection. My little MonoGame-Framework-TopUp I programmed includes a system on how to change Scenes, but I just didnt use it, because I never changed any scenes. Which means I didn't have issues with entities which are being tracked twice or lost due to new scenes.
Now however, I first made a little refactor of my SceneService, just to keep things more clear when working with it. My humble scene life cycle for creating, caching and disposing scenes works well. But I would like to introduce a scene-structure, so that changing major sections of the game (like going from the main menu to the actual game) is standardized and straight-forward to use in the future. For that I have implemented a "LoaderScene", which acts like "glue" between Scenes. It allows me to induce jobs inbetween Scene-Traversing like saving the game and it also allows me to customise the loading screen as I want. Or in short: Go to Menu -> Go to LoaderScene -> Load / Save / etc. -> Go to game

Current issues

It is not fun to be honest. I don't care much about the main menu right now, but swapping between map sections within the game is already difficult and probably the most complex kind of transitioning the game will have. That is due to the fact, that the GameContext class, which previously did all the work for the game, is a Singleton and was implemented, so that opening the scene would recreate the context and thus the game. Kinda bad if you're going to implement a load and save game system next week. Also, changing from one map to the other I could just change the map in the context and apply logic to adjust each and every entity, item, object and more in the game. But that is obviously prone to bugs and a lot of boilerplate code, when I could also just keep one part of the game isolated in its own scene. But wait, if I keep things isolated in their own scene, the scene will not run if the player is not in there. (a kind of fundamental architecture I use). So changing the scene will effectively pause the game for the left scene. I was thinking about allowing this inconsistency, because frankly entities and machines are the only things I would need to adjust so that things would look normal. But the issue is again scalability. Because that would require specific boilerplate code - maybe even for individual map-parts. Ok then why do I not just leave some scenes running in the background? This is not too bad of an idea, because I can use asynchroneous programming for CPU efficiency, the entire world would run as it should all the time. But loading the game would require me to kick-off every map in its own scene and simulating the map-part in full could also cause unexpected events to happen while the player is away and asynchroneous programming is also risky, because my MonoGame-Framework-TopUp is working synchroneously. This leads me to:

The solution

I still keep one GameContext to manage and track all entities and items and so on. This does come with the caviat, that I need to distinguish between game elements in the current scene and those who are not. On the other hand it implies the differentiation of active scene logic and non-active scene logic. So it kinda is already a railway on differentiated logic regarding different scenes. Also, my GameContext is already a Singleton, so it does not require a big refactor (spoiler: it turned out to be a bigger change anyways). But the biggest problem was, that swapping from one scene to another, which is supposed to have the same GameContext, while the GameContext was designed to use the injected services of its creator Scene. So I implemented the very ugly work-around and programmed a Singleton object, which allows to create a blank instance first and register services later *disgusting noices*. Anyhow, this worked like a charm except every time when I use a new Service in my GameContext or add a new fundamental element (I don't know maybe something like Shader or... Vehicles or so.) then I would need to add them manually. I still consider this to be easier to maintain than code which guards the consistency of each map-part so here we go. Last but not least, I have this feeling I forgot something when developing this Scene extension, which is never a good sign...

Anything else?

Well, I think I sincerely need to change the grass tiles. I also realised I need to fix some minor map issues and I need to address some things of the Tile rework from the last three weeks. I was so focused on creating maps, that I forgot about some erroneous code regarding tiles. Also, I tested the game so many times using that little dog character, that I decided to keep him and actually got myself the other dogs (and cats). I think this resolves well for the bright, peaceful and easy environment and kind of game I am making. And good animations for a project like mine are hard to find. Naturally they will require some modifications and additions, but all-in-all I am happy to officially use them here.

What is the next step?

I will need to test traversing back and forth between maps using the new system and the interactions are not working properly. But interactions are supposed to be done in their own week anyways, but I guess it doesn't hurt to fix some Scene-related bugs. After that I will have 2 weeks for Saving and Loading the game. As I said earlier I want to do these tasks in my Load-Scene and I need to make sure that I know what exactly I need to store, how to store, and where to store. Then I can also start developing the game with save states, rather than having a new game every time I start the project.