   Input abstraction
  My input system revolves around action instead of specific keys. So a game might listen for the "shoot" action. You can bind keys to action using conf scripts etc. Similar systems is used in several game/engines.My problem comes when I want to be able to substitute two "move" actions, say "move_up" and "move_down" with the analog stick of a controller. I don't know how that should be done properly. Maybe something like: 'bind +left_stick move_up' and 'bind -left_stick move_down'. Using + and - to tell the game if we mean the positive or negative axis.What's your thoughts?   
  You are on the right track. Building an abstraction is fairly easy in your case. What you need is a base class that holds an std::map or hash map. Each item in the map (say, a key value) is bound to an internal value (a move action). For example:enum KeyVal{  UpValue,}class BaseInput{  public:  virtual InputVal pollInput() = 0;};class KeyboardWin32Input : public BaseInput{  std::map<KeyVal, unisgned int> keyboardValueMap;public:  KeyboardWin32Input()  {    keyboardValueMap[VK_UP] = UpValue;   }  virtual InputVal pollInput()  {    // Do something here to poll the keyboard state (Win32 Implementation - up key)    Return keyboardValueMap[VK_UP];  }}THen later in the code, just reference the base classint main(){  BaseInput *bInp = new KeyboardWin32Input;  InputVal kVal = bInp->pollInput();  // kVal should equal UpValue from the enum above}To switch to a joystick or something, just make a class that wraps around the Joystick functionality. Internally, the map can be modified so that you can cuztomize the bind between the enum and whatever value is returned by the hardware (joystick, etc). I don't claim that this is the full implementation, just a really rough one off the top of my head.   ;  I have something like your Action with overloaded methods for keyb, mouse & joystick:struct Action {    virtual void run(i){} // for keyboard    virtual void run(int x, int y){} // for mouse    virtual void run(some_joystick_structure& s);{} // for joystick    ~virtual Action(){}};This is rather pragmatic then academic approach.Then there is Action* actions[NUM_KEY_EVENTS + NUM_JOY_EVENTS + NUM_MOUSE_EVENTS]NUM_KEY_EVENTS = number of keys (usually 256)NUM_MOUSE_EVENTS = number of mouse kyes + motionNUM_JOY_EVENTS = number of joystick buttons + motionsThen you put a pointer to an action object at respective key, mouse button, joystick etc ...Using:void keyboard_func(int key){    actions[key]->run();}void mouse_func(int button, int x,y){    actions[button]->run(x,y);}void joystick_func(some_joystick_structure& joystate){   actions[joystate.button]->run(joystate);}Then you create ations like this:class Shoot : public Action {public:    void run(){ do shooting here .....    }    void run(int x, int y){ run(); } // this action does not need x and y ...    void run(some_joystick_structure& s){ void run(); } // s is not needed here};This approach means that original mouse and buttons keys has to be redefined to fit in interval after keyboard kyes (#define mouse1 255+1 .... etc); Since I save only pointers to actions, it is inexpensive to have pointer in several places, for example: for ctrl, left_mouse and joy_fire_button:Shoot* shoot = new Shoot();actions[KEY_CTRL] = shoot;actions[MOUSE_BUTTON1] = shoot;actions[JOYSTICK_BUTTON1] = shoot;It is simple to "remap" actions to different keys and if your action does not handle mouse or joystick or keyboard just don't implement the function for that device.More academic would be to create Action/Listener system like one in java but that would require some more work :). My approach is basicly baking lists of  "action listeners" in one and same array for all event types; and Event (Action) hierarchy into one class. I loose some compile type safety and type checking. For example nothing tells if Shoot is mouse event, key event of whatever. I could have preserved that if I used event hierarchy like in java; but I found that in a game I don't have so many actions, so this never becomes an unmenagable problem.Maybe not best approach but it works for me. Like above ... also not a full system, but something I used once in a project :).   ;  Inputs can be split into several layers. The input state, the input events, and the action mapping that are a combination of input events that translates into a game action being performed. The input state is straight forward. That's the current state of your buttons, keyboard, mouse, that you poll every frame.The input events is simply looking at the transition between two states (or more for say, detecting double clicks). When a state changes from on to off, then the key has been released, and you can fire a 'key up' message. An action ('fire weapon', 'switch weapon', 'rotate left', 'strafe right') would be a reaction to the input event. -> key('lshift') down -> start running. -> key('lshift') up -> stop running.-> key('s') down -> start walk back (x running speed).-> key('s') up -> stop walk back.-> mouse button(0) down event -> weapon trigger pressed.-> mouse button(0) up event -> weapon trigger released.-> mouse button(1) down event -> quick stab.-> mouse button(2) double click -> drop weapon.-> mouse axis (0) move -> rotate player (pass in the mouse move speed as part of the notification). you can split the 'mouse move' notification using' mouse move positive' and 'mouse move negative'.[Edited by - oliii on September 8, 2008 4:41:26 PM]