InputManager

Jan 26, 2012 at 2:28 PM

Hey, quick question, I'm curious to know why you put so many of the mouse properties as internal in the InputManager.

Coordinator
Jan 26, 2012 at 2:55 PM

Hi Wudek

This is just an API design decision. It's because I wanted the main access to input not to be made from the InputManager itself but through one of the PlayerInput instances available.

There is only 1 keyboard and mouse in a given computer so it was logic to save memory and place their properties in a single place: the InputManager.
But in order to access them, you'd pass through the PlayerInput instance that concerns you.

I preferred to create a Player class which I would at runtime associate with a PlayerInput instance depending on the LogicalPlayer it belongs to and test its properties instead of passing the InputManager instance entirely to the Player class.

It also allows to have a consistant way at looking at input either you are developping for Windows, Xbox 360 or WP7. I can then attach input events to the buttons/sticks of a virtual gamepad saving developers time matching input with their actions: If on Xbox 360, you use PlayerOne.LeftThumbStick.X to move your character from left to right which inputs is provided by a physical GamePad, on Windows, you'd use the same access but you'd map it to use either left/right keys or mouse X axis values; and on WP7, you'd still use the same access point but provided by the new virtual gamepad ;)

This also was a requirement for other IGF features, especially for the game Session & Logic features which are tightly linked with it: a PlayerAgent, once a player session starts has an Input property populated automatically with the logical PlayerInput (which may be different from a physical PlayerIndex gamepad for instance) and you can then add behaviors which would get access to this property to test specific actions.
In this case, the behavior becomes independent of the Input used.

Jan 26, 2012 at 3:00 PM

What if you want to be able to use the full keyboard and not worry about the virtual mapping from keyboard -> xbox gamepad.

I'm saying this because I'm making a windows game, eventually, maybe I'll consider porting it to the xbox but for now, I want to publish it on Windows only.

One of the main reasons for this is that I want to have full keyboard + mouse support.

Coordinator
Jan 26, 2012 at 4:30 PM
Edited Jan 26, 2012 at 4:30 PM

You still can access KeyboardState & MouseState from the PlayerInput.KeyboardMouseState.Keyboard or Mouse properties and test for keys pressed and mouse position and buttons pressed the usual Xna way.

However you may also want to use the InputManager.KeyboardState property which is a significantly improved Xna KeyboardState property (actually, the class used is named KeyboardInputState) allowing you to perform operations such as:

if(Application.Input.KeyboardState[Keys.A].IsPressed){} 
// or 
if(Application.Input.KeyboardState[Keys.A].IsReleased){} 
// or 
if(Application.Input.KeyboardState[Keys.A].IsDown){}

It takes care for you of handling international Keyboard layouts (QWERTY, AZERTY or whatever...) and much more (have a look at the properties and methods of the KeyboardInputState class to know how to use it for your game).

For mouse, you can also access the Mouse property from the InputManager if you want.

Jan 26, 2012 at 5:20 PM

Awesome, the KeyboardInputState is super useful.

I did a change to the code for the InputManager to make the MouseInputState accessible since it provides similar neat features. 

Was there any reason why the MouseState property was returning a MouseState vs a MouseInputState?

KeyboardState is returning a KeyboardInputState...

Coordinator
Feb 1, 2012 at 8:03 AM

Hi,

I just forgot to change the MouseState property to return the MouseInputState ;)

I'll add this change to my next commit.

Thanks

Coordinator
Feb 1, 2012 at 8:04 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.