This is going to be a minor rant about singletons...
Ok, we all know this. Singletons are evil. We did I use them, because I tried to cut corners in the beginning of the development process. We all know that the project you're working on will be rewritten. That's not gonna happen, instead they grow, infested with technical debt. But it's not all bad.
Actually, singletons have served me well. I have a concept of a ServiceDesk that provides services/managers to you. This works great for the following services or Managers as I seem to call them.
- Sound
- Asset management, textures and stuff
- Console management
Unfortunately, these are the places it doesn't work well.
- Input management (keyboard and mouse - this is were it broke down badly)
- HUD management
- Selection management
To understand why it all broke down for me is that I have screens to represent different states of the game. First you enter a splash screen, then it gets replaced by a main menu screen. When you start the game it's really only one other screen and will most probably ever be and that is the game screen. It all worked fine so far.
Until I added an in-game menu screen. When it pops up all input should be directed to that screen. Well, the way I designed it any entity in the game asks for input from a singleton. The entity itself does not have a concept if it is displayed or not. So that means that the game still takes input as if it's active and visible.
I tried to approach this from a couple of different angles, but it all boiled down to providing an Input Manager for each screen that can be turned on or off. This sadly means passing some kind of context along everywhere to resolve the correct Input Manager to use at any given point.
Also the Selection Manager is indirectly affected. It handles the current selection of the mouse.
This will lead to some refactoring/remaking of course. I'll branch the code and fix that during a longer period of time. Hopefully I have someone joining the project to make som graphics.
Community
