I've whipped up an implementation of the input mapping system described in this article and posted it for free usage and manipulation over at my new Google Code repository. Check it out and abuse it as you like!
Previous Entry
Designing a Robust Input Handling System for Games
Next Entry
More scribblings!
Comments
NineYearCycle
That's very generous of you
June 17, 2011 01:17 PM
Thanks for providing the code!
One question about InputConstansts.h:
The enum values (ACTION_ONE, ACTION_TWO, STATE_ONE) you defined are very abstract and general. Do you think it would be a good idea to define values that are specific to the game like ACTION_USE and ACTION_SCOLL_MENU_UP?
One question about InputConstansts.h:
The enum values (ACTION_ONE, ACTION_TWO, STATE_ONE) you defined are very abstract and general. Do you think it would be a good idea to define values that are specific to the game like ACTION_USE and ACTION_SCOLL_MENU_UP?
June 18, 2011 02:08 PM
Yep - the idea of the ranges, actions, and states is that they should be game-specific. So STATE_FIRE_WEAPON and ACTION_JUMP and whatever else :-)
June 18, 2011 09:58 PM
Well ok, but then your current code does not work. Inside all your classes you use your defined enums ACTION, STATE etc. But actually the user of the input system has to define it's game specific enum and the maps have to use this user defined enum.
For example it should be this:
[code]
enum AStateThatTheUserDefined {
STATE_FIRE_WEAPON,
...
};
std::map<RawInputButton, AStateThatTheUserDefined> StateMap;
[/code]
How could I do this that the code works with every used defined enum?
For example it should be this:
[code]
enum AStateThatTheUserDefined {
STATE_FIRE_WEAPON,
...
};
std::map<RawInputButton, AStateThatTheUserDefined> StateMap;
[/code]
How could I do this that the code works with every used defined enum?
June 19, 2011 07:50 AM
Erm... not sure how the code "does not work"? The whole point is that [i]you[/i] provide the definitions for the game-specific actions/states/ranges, replacing the provided values with the ones you need for your game. For instance, instead of ACTION_ONE, you'd put in ACTION_JUMP, and use that value throughout the game code.
There's no magic going on that can guess what ACTION_ONE really means to your specific game; it's just an example of a dummy action so you know where to drop in your own enumeration values. The only part that's meant to be generic and reusable is the mapping/context layer. You still have to do some work [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img]
There's no magic going on that can guess what ACTION_ONE really means to your specific game; it's just an example of a dummy action so you know where to drop in your own enumeration values. The only part that's meant to be generic and reusable is the mapping/context layer. You still have to do some work [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img]
June 19, 2011 08:50 PM
I remember you telling me about this once upon a time. Thanks for the generous contribution!
July 05, 2011 09:18 PM
Advertisement
Latest Entries
A Few Farewells
14896 views
Code Reuse In Actual Practice
16838 views
Source-Level Debugging For Epoch Programs
5318 views
Using Poison to Reverse Engineer Code
3998 views
Using Poison to Reverse Engineer Code
372888 views
Debugging Information Success
3214 views
Debugging Information Success
6042 views
Debugging Epoch Programs
3486 views
Debugging Epoch Programs
7808 views
Epoch 64-bit compiler progress
2895 views
Advertisement