Hello dear forum : )
I have a tile-grid-based game (and layered) with some GUI-widgets on top.
Additionally, I'm rolling an entity-compoment-system, so there is a graphics-component per entity aiming to be visualised (contains proxy to their texture).
At the moment, I store them in a vector - being the level-structure itself.
The order represents the coordinate in the grid: First element is upper-left of the grid and last element is bottom-right.
Now, sending my level-structure to the painter-class should not happen - why would a painter-class need to know how my level is structured..
Additionally, I require multiple sf::views (one for a GUI-menu and one for the level).
How would you structure your code?
My component-factory could be linked to a scene-graph. Immediately adding a reference of every graphics-component upon creation.
But then, what is about multiple sf::views?
Should there be a view-graph as well? One that can simply add sf::views to an unordered map, each having a unique string as key ("gui" or "level_scene"). Every node within the scene-graph would then refer to either sf::view.
Probably a better idea: Have one scene-graph per view. Every scene-graph composites one sf::view.
When my GUI-loader loads, I create one graph just for that. When my level-loader loads, I create one graph just for that, too.
Both are then added to the painter-class, who iterates over their owned visualisation component.
Only thing about that, it would require my painter-class to additionally iterate over a vector of scene-graphs (just feel like this is bad design - not trying to prematurely optimise).
I'm really curious if there are any neat patterns that solved this issue already? Are there already other SFML-projects that tackled this problem?
Thanks a lot, have a great day : )
