RE: [GD-General] Key handling revisited

[Grills, J. <jg...@so...>]

We have a totally separate system for text input and game control input as
Tom suggests.  The text input system is reasonably straight forward, but the
game control system is pretty interesting, so it's all I'll describe here.

We have a class in the engine called InputMap which converts raw user input
into a series of game events, which is all the game ever sees.  The raw user
input is taken as a stream of events, where an event contains the device id
and the change that happened to it.  All we need to do in code is read the
hardware and send the events to the InputMap.  Then, in data, we create a
new InputMap mapping from the hardware (keyboard keys, joystick buttons,
mouse buttons, or any and all of them) to the game event identifiers.  Each
game event has both a type (move forward, turn, shoot, etc) and a float
value.  We treat digital buttons (keys, many game pad buttons) different
from anything with variable input (joystick axis, pressure sensitive game
pad buttons, POV hats).  

Digital buttons can have several messages associated with them sent at
different times.  There's a message when the buttons is pressed, one when
it's still down (repeated), one when it is released, and one if the
application loses focus (used only by PC platforms).  If you want a button
to issue a single event, you likely only assign it a pressed message.  If
you want it to react whenever it is down, you could assign it the same
pressed and repeat message.  If you want something like a Decent plasma gun,
the press message could send a "start charging" message, the repeat message
could send a "continue charging" message, and the release could send a
"fire" message.  If the user task-switched while charging, the lost focus
message could be "abort firing".  Buttons can also have the same message but
different values associated with them.  Strafe left and strafe right can be
implemented with two buttons but one game message with different values
(-1.0 and 1.0).  You could also have walk, walk fast, and walk slow be three
buttons sending "walk" with different values. 

Some buttons can be designated as shifting keys.  Shifting keys add or
remove bits from a shift state bit mask.  The current shift state bit mask
determines which button map will be used for the messages.  One of the most
tricky problems to solve was what to do when a user presses a key, then
presses a shift key, then releases the key before releasing the shift key.
We decided to bind all the messages a key will ever send at the time that it
is pressed.  This seems to have the least amount of user surprise, and is
relatively simple to implement (just copy the data on press).

Joystick axis and POV hats are handled differently.  They always send down
their message per frame, but the value is taken from a mapping of the
position of the stick or the hat.  Pressure sensitive buttons could be
handled the same way.  Any change to the shifting state instantly changes
the messages that variable input device sends.

In your code that processes the game events, you may need to be careful to
make sure that users can't gain an advantage by mapping multiple keys to the
same event and have the sum of those events exceed some allowable game play
threshold.

Hope this helps,

Jeff Grills
Technical Director, Austin Studio
Sony Online Entertainment

-----Original Message-----
From: Jamie Fowlston [mailto:ja...@qu...]
Sent: Monday, February 11, 2002 5:18 AM
To: gam...@li...
Subject: RE: [GD-General] Key handling revisited


that's really my problem :) for any given system, there's an obvious
approach to use. just trying to unite the ps2 and pc principles is hard, let
alone going further afield than that. the pc is event driven, whereas the
ps2 is state driven. you can translate between the two, but it's a bit
whiffy.

jamie


-----Original Message-----
From: Tom Forsyth [mailto:to...@mu...]
Sent: 11 February 2002 11:08
To: Jamie Fowlston; gam...@li...
Subject: RE: [GD-General] Key handling revisited


I think there are two separate issues, which Brian sort-of talked about.

-Text input. Need to handle international chars, shift-alt-meta-squiggle
wierdness and all that. As much as possible, try to get the OS to do all the
hard work. Usually queue-driven, so you won't miss keypresses. I don't know
anything about macs, but on Windows you just use the WM_CHAR messages. They
will tell you what is printed on top of the key that the user pressed, and
handle virtual keyboards and macros and so on. Probably exposed as a stream
of ASCII-like things, except probably 16-bits wide. Could possibly use
UNICODE?

-Game control input. You just want the keyboard to be returned as a big
keypad with 100+ keys, and tell you which keys are pressed at any one time.
This is what DirectInput exposes. Usually polled, not queue-driven, it's
just a big array of key states (up/down).


The only crossover between the two is when the user is defining their keys.
Then you want to find what is printed on the top of the key that the
"gamepad" has pressed down. Fortunately you can assume that when they are
being defined, the user will be pressing exactly one key at a time, so just
watch both systems to see which WM_CHAR-like message corresponds to which
keypad keydown.


For Windows+DirectX, you're pretty sorted - WM_CHAR for the first,
DirectInput for the second. I don't know much about other platforms.


Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Jamie Fowlston [mailto:ja...@qu...]
> Sent: 11 February 2002 10:36
> To: gam...@li...
> Subject: RE: [GD-General] Key handling revisited
>
>
> I'm also interested in a related issue: if anyone has a
> sensible input model
> that can work across computers and consoles, i'd love to hear
> it :) at the
> moment the plan is to reimplement the control interface on
> each platform
> (it'll need tweaking for each platform anyway), but i don't
> want to have to
> do more work than is necessary on a problem that _surely_
> must have been
> solved? :)
>
> Jamie