Handling Input. For many it seems simple, and it relatively seems to be. However finding a good way to structure you're input management can be hard. Mainly because for a lot of libraries input is either handled by the Window or an Event object. When it's handled by the window, it's hard to figure out where to place your resources (Should the Input object have a pointer to the window, or should it have the window so my Draw class can have a pointer to it?). Here's some small things I recently found out when writing my own input manager.

1) Single Responsibility Is Important
I've already talked about the Single Responsibility principle, however I feel, especially in this case, that I should emphasize it. It may be tempting to have your input manager also draw everything to the screen (I mean, it already has the Window and Event, right?!?!). However, as we've already seen, that can have adverse affects. You want to make it so that everything is completely isolated to it's own object. It'd be misleading also. Imagine having your Input object also draw everything. That's confusing, isn't it! It get's even more important when you're making a tile based game, like I am, because there are more complex algorithms and functions that I use to figure out what I need to draw and how I need to draw it.

2) Being Specific Isn't Bad
In my Input class, I have a function that can get key presses by taking in the type of key press (As an sf::Key::Type) as a parameter. Then it's simply seeing if that sf::Key::Type is equal to the current key being pressed. Now, arguably, I could use this for many cases by just programming them in whatever is using Input. But that makes for a bad interface and badly written code that no one can read. So instead, I have a plethora of functions that compliment that one. The same goes for getting mouse input. I made many functions for different cases I knew I'd need instead of going through having one complicated and hard to read function. This is important because it makes your code easily readable. Imagine your game getting huge. If you get fellow programmers to help you, having that one hard to understand function that's trying to "catch-all" will make it nearly impossible for them to understand what's going on without looking through an insane amount of code.

Overall, your Input class should handle input, and only input, and should have a large amount of options for you to check different kinds of input.

If you enjoyed this blog post, please comment down below about what you'd do different and share your tips.