Re: [gluon] FW: Input Actions for Gluon Input GCI Task

[Arjen Hiemstra <djfreestyler@xxxxxxxxx>]

On Wednesday 01 December 2010 13:49:46 Tony Young wrote:
> > From the conversations I've had with leinir and djszapi in #gluon, I've
> > come up with http://pastebin.com/b8Z6FiF6
> > 
> > There are no GluonInput-specific implementations in the code and it's
> > very generic. It uses Qt signals for notifying anything interested in
> > input actions and, by overriding checkActionState of InputAction, one
> > can determine if their action has triggered or not, and which state
> > it's in (Up or Down) by calling update on the InputAction every frame
> > (simplified by using InputActionManager).

An important thing to consider is that the idea is that the actions system 
abstracts away the actual input devices. This means that, as a game developer, 
you would create a set of actions, not directly knowing what device will be 
performing these actions. You seem to have approached this already, however 
the previous person who wanted to attempt this task pointed out that there are 
two major types of actions. Actions relating to some form of button press, 
such as a keyboard key press, mouse button press or touchscreen tap and 
actions relating to movement along an axis, such as basic mouse movement or a 
joystick throttle movement. He suggested creating two main action types, one 
for axis movement and one for button press. 

> > 
> > An action can be created by subclassing InputAction and overriding the
> > pure virtual method checkActionState which returns either None, Up or
> > Down depending on the action's state.
> > 

Hmm, I would really prefer not having to do this. The idea here is that at 
some point we will have a generic input component handling a list of actions. 
The game developer simply creates a bunch of actions with a default input 
device binding and a name. Having to do subclass-magic for this would make it 
rather awkward, I think.

Another important thing to consider here is that most of this should be event 
driven. If I recall correctly, it is necessary to update the input devices 
during the game loop, however, this could be handled by the component. The 
actions themselves are triggered whenever the key associated with the actions 
is pressed. These actions will then trigger an event in our yet-to-be-
implemented game-wide event system. The game developer can then write code 
that responds to this event.

> > What I'm not sure about is whether or not if I actually need to
> > implement
> > any interface to GluonInput. I've been told that I don't need to, and an
> > abstract implementation of actions is fine, but since this is your task
> > I'd like to just check with you.

No, you do not need to. What I want to see is a proof of concept 
implementation of the system. This can be using any toolkit you prefer and 
basically any language you prefer, although C/C++ is preferred as we will 
still need to be able to use it to some degree. :p

Another thing I would want to see is a bit of a somewhat higher-level overview 
of how you think the system needs to work. I'd love to have a few paragraphs 
of text explaining, on a higher level, the design.

> > 
> > Waiting for your reply,
> > Tony
> 

- Arjen


---
+----------------------------------------------+
Gluon is a high-level game development library for the KDE desktop enviornment.
http://gluon.tuxfamily.org/
http://gitorious.org/gluon