Multi-screen architecture (e.g. minigames) with Fleks

[tsmaster]

I'm new to Kotlin, LibGDX, LibKTX, Fleks - I've watched the Dark Matter YouTube tutorial series, and have begun looking at the RPG tutorial series.

One thing I liked about the early LibKTX app setup was breaking my game up into small pieces, "screens", which is a pattern I've used before. My current project will have several different modes, which I'm currently imagining using screens to implement. If you think of Mario Party, with one big game, and several minigames, that's a similar idea to what I'm heading towards, with different screen classes for each of the minigames and also for the big game.

My question is what the best practice is for using an ECS across screens would be?

My first guess would be to create the World in my toplevel game class, outside the screens, and then as I transition from screen to screen, I'd disable systems that I won't use in the new screen, remove most/all of the entities, and populate the world with new entities for the new screen.

The examples I've been seeing have the World created inside the screen, which suggests that it might make sense to have one World per screen, not try to reuse things across screen transitions. This might be more efficient, as I wouldn't have to purge all the entities from the old screen before getting the new screen up and running. It'd be a little less work in terms of getting the right set of systems activated as the screen is shown.

I can try it both ways and see if either way raises issues, I'm open to learning from mistakes, but if people have already experimented with each, I'd be happy to learn from other people's experiences.

Thanks,
Dave

[Quillraven]

I used your first approach in a few games and in my games it worked but felt really weird because you enable/disable systems all the time and also need to take care of entities that you might not need in all screens. Also, whenever you add a new system you need to make sure which screen needs it and which doesn't and enable/disable it accordingly.

One example of a dungeon crawler game I implemented: I had two main screens. One of the dungeon map navigation and one for the combat with enemies. Those were two separate screens but using one world (it was actually an engine because I used Ashley back then but it is the same).

I had utility functions to update the systems in the onShow method of each screen. Also, the player entity was used between both screens. In my approach the player entity simply had all necessary components meaning for dungeon navigation it still had combat relevant components and vice versa. That made it easier to have it working in both screens.

However, nowadays I tend more towards your second approach with separate worlds per screen. Imo it is a cleaner architecture since you configure the world according to your screen's need and you clearly see which systems are necessary for a specific screen.

Nevertheless, I see one point that might be trickier to implement but I guess nothing too difficult. Imagine my scenario from above with combat and dungeon navigation. You will end up with two player entities. One for the dungeon navigation and one for the combat. If you now get e.g. experience and loot in the combat you need to reflect that in the navigation screen as well.

This is a general topic with the screen approach when you need to share data between screens. I don't know a perfect solution for it. My solutions work and I guess that is the most important part 😅

[tsmaster]

Thanks, this makes sense.

I expect to have some game-wide database-like-storage of information containing e.g. player experience and money, which I use to initialize the player objects in my overworld and minigame screens - just have to remember to commit local changes up to the database.