3.3. G AME I NPUT Handling input within games

In lecture exploration of answers to frequently asked student questions

Different input devices and their use within games

There are a wide range of different devices used to provide input into games. Some devices are platform specific, e.g. mice are mostly the preserve of PCs, etc. Devices tend to provide different usability profiles and will differ in terms of their suitability to some types of game. A game should best exploit the various input devices it is designed to run with.

Input devices need not restrict themselves to the press of a button or movement of some stick (e.g. touch screen, gamepad, driving wheel, joystick). Novel forms of game interface can include: Bit of fun: You have 5 minutes to come up with an interesting form of gameplay for any of these novel forms of interface. Distant motion recognition Speech input Emotion/thought recognition 5 mins4 mins3 mins2 mins 1 min 30 secFinished Start

Games on this module will likely use a keyboard, mouse or gamepad controller, from which the following types of input are possible: Pressing a key/button Releasing a key/button (key press+release = typed) Moving the mouse/thumbstick Pressing a mouse button Released a mouse button (press+release = click) Squeezing a trigger Aside: Buttons and keys are examples of 2-state discrete (on/off, in/out) input. Thumbsticks, mouse location and triggers are examples of ranged input (float/integer return value). To do: Apply to own game

Event driven input vs. input polling

Event-driven input assumes that one, or more, event handlers will handle a defined range of event types. Given an input event, the designated call-back event handler is executed, consuming the event and taking whatever associated action is necessary. In contrast, input polling operates by getting the state of the input device a regular sampled intervals and checking for change. Most games use input polling.

Low level of control, fits well with the frequent update-draw loop in games Input polling provides a snap-shot at an instant in time. Events occurring over a period of time must be inferred from changes in the snap-shots. This includes ‘basic’ events such as a typed key or more sophisticated events such as a mouse drag. Time 15ms 30ms 45ms 60ms 75ms 90ms 105ms State Up Up Down Down Down Down Up Typed Event Pressed +Released

update() { if( ‘Launch’ key is pushed down) LaunchProjectile(); } At 60 updates per second, there are some things you do not want to do every update (and maybe only twice per second) Sometimes you might only want to do something once an animation has finished playing: update() { if( input event detected ) if( event execution requirements passed ) ExecuteEvent() } In general:

Many games support multiple input devices and/or user configurable controls. Within such games it is advantageous to decouple input from input event checking. Decoupling enables input mapping logic to be separated from the code that responds to input events. More generally, decoupling helps promote software extensibility and reusability. update() { ConsiderInput() } ConsiderInput () { if( ‘A’ button pressed ) DoAction() } update() { CheckForInput() ConsiderInput() } CheckForInput () { if( ‘A’ button pressed, or ‘J’ key ) set JumpInputEvent = true } ConsiderInput () { if(JumpInputEvent == true ) DoAction() }

Overview of game input using XNA/Java

The Java Code Repository makes available a GameInputEventManager which offers basic keyboard and mouse input (including key/button pressed, new key presses, etc.)

XNA provides GamePad, Keyboard and Mouse classes each with a GetState() method that returns a GamePadState, KeyboardState or MouseState respectively. When using XNA it is common to store the previous input state (from the last update) and compare this against the current input state to detect input event occurrence (e.g. button just pressed, etc.) Aside: XNA4.0 also provides support for touch-screen devices and gestural input

To do: Consider Input In relation to your project, you should: For each layer, determine the needed user input (e.g. for navigating a menu, or controlling a character, etc.) Decide the emphasis that will be placed upon input in your design. Important: Marks will be given for designs that decouple input, enable user customisation, etc. This may be of interest for projects weighting the ‘Extent of game features’ section highly. Balance the implementation cost of this vs. what you hope to achieve in your game.

To do: Continue to explore image repository and select graphics Continue to write code that loads and displays images. Determine necessary input and how it will be implemented Today we explored: Different input devices and their use Event driven vs. Input polling Project input design consideration