Sprite Management

Question

I'm working on a game right now using my own engine. In the engine, I have a State Machine which handles input for, updates, and draws the current State - the one at the back of the vector. The game engine itself stores Sprites in two maps and a vector, and the States also store pointers to those Sprites. With this many references, it is becoming difficult for me to manage all my Sprites and their scope. Furthermore, I have a Button class which derives from Sprite and adds some mouse input behavior.

I'm trying to figure out a storage solution for my Sprites that would allow me to update all Sprite animations, handle Button input, identify specific Sprites (likely by a string name) primarily for cutscenes, access Sprites directly to begin animations or instantly modify their position, color, or texture coordinates, and batch Sprites of the same batch type (Menu, Background, Player, etc.) together for drawing.

My current solution stores a map of BatchType (an enumerator) to a vector of shared_ptr's pointing to Sprites, solving the batching problem; then a map of strings to Sprites for naming; next, a vector of smart pointers to Buttons for their specific handleInput function; and lastly, the engine's createSprite method returns a shared_ptr to the new Sprite so it can be stored in the State that created it for direct access. In order for any Sprite to be deleted, I have four potential references to delete, and it feels convoluted.

Are there any better storage methods which will still achieve all this? I think the main problem here is that I need to separate Sprites from Buttons in order to call the Button handleInput function.

Answer 1

Update to my solution: I have been doing more research into game development and I feel a lot more prepared after looking into best practices and design patterns. Probably my biggest mistake was treating my game states as scene managers rather than the scenes themselves. Realistically, the title screen is in itself a scene with a sub-scene for the specific menu the game is in, which also solves my problem from a while back wherein I was unsure how to handle Sprite batching in combination with state. Ultimately I have a background and logo Sprite displayed by the base Title Screen and it draws the sub-scene on top. Plus, each of these menus, now treated as scenes as they should be, will store their Sprites independently and only need one additional draw call for the Menu batch. This allows me to define Sprite scope easily and reduces the risk of lingering Sprites between scenes by having to manually delete them.

Overall, I will store Sprites per-scene and use the State Machine for the core Opening Credits, Title Screen, Game and Cinematic states, then basically treat Title Screen and Game as scene managers which have sub-scenes that share Sprites with their super-state. This will come in handy later for pause menus and player menus (quests, inventory, etc.) which get displayed on top while still drawing the super-state normally.