Managing Keyboard and Mouse support (extending proj from SFML Book)

[Kanefa]

I have been working on extending the code base from SFML Game Dev book.  I am adding mouse support, but my solution feels messy.

mKeybinding is declared in player.h as

std::map<sf::keyboard::key, Action> mKeybinding;

The problem is I want sf::keyboard::key to be more general to hold both keyboard and mouse keys/buttons.  I combine the two in a enum and handle the offsets.  I then have to begin converting from sf::Keyboard::key and sf::Mouse::button to my new enum and back.

In the end it will work, but I keep thinking there is a cleaner approach.  Any suggestions?  Thanks.

[Nexus]

Why don't you have two separate maps, one for keys and one for mouse buttons? It doesn't seem reasonable to mix them, you only lose type safety.

[Kanefa]

I want to have all my input from the keyboard, mouse, and joystick stored in one object.  Using the book as an example, the object would have six member variables for mMoveLeft, mMoveRight, mMoveUp, mMoveDown, mFire, and mLaunchMissile.  Each of these member variables should than correspond to a key, button, analog pad, etc. on a specific input device depending on its binding.

The issue I am having is storing events for the keyboard, mouse, and joystick, which are all of different types, into this singular object.  My shoving the keyboard and mouse into a large enum and then cramming it into mKeybinding was a quick and dirty attempt of this.  However, I am sure there is a better approach.

The reason I would like to do this is I want a uniform object to read for both the player and the AI (reading Game Coding Complete).  On a slightly unrelated note are there any game engine books you would recommend? 

[Nexus]

You should separate the logical actions, e.g. "fire" or "moveRight", from the raw input, e.g. "sf::Key::D". I still think two maps would be appropriate. When handling events, instead of traversing only the key binding map, you also traverse the mouse binding map and check if an event triggers an action.

If you need something more sophisticated or don't want to reinvent the wheel, I recommend having a look at Thor's Actions, they allow arbitrary mapping of input to logic actions. You can even combine multiple keys to use triggers like "Shift+R".

[Kanefa]

You should separate the logical actions, e.g. "fire" or "moveRight", from the raw input, e.g. "sf::Key:".

I am blanking on this.  Could you give an example?

I still think two maps would be appropriate. When handling events, instead of traversing only the key binding map, you also traverse the mouse binding map and check if an event triggers an action.

Alright, this makes sense to me.

If you need something more sophisticated or don't want to reinvent the wheel, I recommend having a look at Thor's Actions, they allow arbitrary mapping of input to logic actions. You can even combine multiple keys to use triggers like "Shift+R".

I'm just trying to learn as much as I can in the process of making a simple game.

[Nexus]

I am blanking on this.  Could you give an example?

You're already on the right way. I just mean that inside the input-handling class (Player in the case of the book), you can deal with SFML keyboard and mouse button types, but on your game logic side, you should rather have abstract actions such as "move left" or "launch missile". The idea is to avoid code like

if (/* M key pressed */)
    LaunchMissile();

I'm just trying to learn as much as I can in the process of making a simple game.

And...?

It's good if you understand the backgrounds, but once you know what's happening behind the scenes, it may be worthwhile to reuse existing solutions that are already tested. I'm not saying you have to use Thor, but if you want to learn as much as you can, you should also consider to have a look at existing approaches

The idea is always the same: In C++, you learn how arrays and new/delete work, but in the end you will use std::vector because it's more productive. For game development, you may learn about graphics cards and OpenGL, but for many cases it's appropriate to use abstracted libraries such as SFML, because they do all the work for you. Same with Thor, SFGUI, Let There Be Light and all the other SFML extensions...

[Kanefa]

As always I appreciate your response.  You are right I could learn a lot from an API like Thor.  I will look into it.

[SeriousITGuy]

I was wondering about the same "problem" the last days. The approach in the SFML dev Book is really nice, and I will definitely extend it to mouse and gamepad with additional std::map's to add those bindings as well.
After that I think Thor will be the next step for me to learn

Thanks again Nexus!