Design

It's a crisis of sorts. There is so much going on in my head that I can't seem to make sense of it all. Collapse is exponentially more complex than any game I've ever attempted, and it's beginning to overwhelm me. I don't want another rewrite, I want it right this last time. I'm not even back to the point where I was previously, because some serious design decisions must be made before I can progress.

Thoughts

There are many things that must be accomplished every frame, and so many different ways it can happen. I have already committed to a state-driven engine system, with states such as e_MAINMENU, and e_INTRO. Each primary subsystem has access to a Game_State& reference, so it can modify it as it wishes. Though, this may be changed to reflect another state, a sub-state if you will, that switches between actions within a primary engine state. Such as a e_HUD state within the e_GAME engine state. This is still in consideration though, and the more I think about it, the better of an idea it seems. In addition to this minor dilemma, many other things still hinder me. In any given frame, there could be event handling, level updating, collision detection, object rendering, HUD updating, and dozens of other operations. None of these are mutually exclusive, nearly everything depends on or interacts with something else. My idea is to split everything into 3 primary subsystems: World, HUD, and Menus. The game engine will take care of interaction between them, such as passing them between each other when necessary. Hopefully I won't create circular dependencies... That'd be bad. 

World

This will be a class, most likely named Game_World, since it is indeed a game-specific element. It will handle most of the game mechanics, such as rendering of objects on-screen, map loading/updating/saving/rendering, enemy AI tactics and operations, player event response, and all collision detection between those elements. It will need to share an inventory system, and possibly more, with the HUD subsystem.

HUD

This will also most likely be a class, Game_HUD or something equally obvious. It'll take care of many UI-related functions such as health and ammo bars, player tank attributes, power-up storage (as opposed to actual handling of the power-ups, which will be left to the World subsystem). It will also house a player inventory. Though not strictly the inventory itself, but rather the rendering of the objects within it on an organized layout.

Menus

The final (probably not) subsystem will handle all menus. This one is basically already implemented, known as the Game_MenuManager class in the code. Simply put, it takes care of any and all menus. The only one that relies on the other subsystems is the pause menu (currently), but I think that can be taken care of with a simple engine state change. Something like State = e_PAUSEMENU; Seems simple enough.