This project is read-only.

Thoughts on Input for Nine

Sep 26, 2011 at 7:29 AM

Note: this deals with in-game input only (not GUI).

  1. Separate physical inputs (keystrokes, button pushes) from internal commands and states via bindings.
  2. Allow games to be written for one platform and played on another, within the limitations of the number/types of bindings available.
  3. Provide both push and pull interfaces.

It should be possible to (say) write a pinball game for the Xbox and then play it on the PC with no code changes using a known set of keyboard bindings. The Escape key should exit from a PC game, without having to write separate tests for a keystroke and controller button. A two player Xbox game should run on the PC (where possible) using another set of bindings.

I would suggest a set of abstract input commands representing standard usage on the Xbox and with a set of convenient bindings for the PC. A restricted set can be used for phone games, and an alternate set for two player games. The bindings for each platform should be configurable at start up.

It is common to have a user-controlled camera, and both a CameraInput component and the bindings for it should be configurable.

Doesn't look too hard. Main challenges are deciding on the abstract input events and the configuration mechanism.


Sep 26, 2011 at 8:19 AM
I personally think that input mapping is a high level component that should be build above the game logic. For each game, the raw input events should be transformed into the commands known by the game, and the game execute each command afterwards.

Take the camera control for example, you can abstract a event like move forward, and binding the W key and left thumb to it, so far so good, but in a real FPS game, the camera position is determined by the position and animation state of the main charactor, and for a pinball game, you don't need to move forward 'cause the camera is alway looking at the ball.

According to my experience when I'm writing a real time strategy game, these commands are generated not only from inputs, but from the inputs of other players though the network, or a replay file as well, so it is going to be very hard to figure out a set of commands that could fit for most games if you are writing a game engine.
Sep 26, 2011 at 3:53 PM

I think it's reasonable for a game engine to provide a keystroke binding capability, and to use that capability with a set of sample bindings throughout the sample programs. I also think it's reasonable for the engine to combine the various keyboard/mouse/controller inputs into a single abstracted 'super-input' device so that a single set of bindings is enough, rather than one for each API. That also greatly simplifies testing/mocking and replays.

I agree that the actual commands used in a game are a matter of game design. I guess my interests run more towards producing a number of smaller games rather than one monster, so abstracting common features is attractive.

BTW I don't have a controller right now, so I should get one. Does Nine support generic controllers, or Xbox only?

Sep 28, 2011 at 8:08 AM

I don't have a controller for PC either, so I cannot tell if the Xna GamePad class supports controllers on PC. But I know another open source project that abstract the controllers on PC using DirectInput, try search for Nuclex framework in codeplex. I think it also has some kind of keystroke binding if I remembered correctly.

You can abstract some common features you use for your games, and if you wish,  put into Nine.Game, that is the place where commonly used features will be placed. Either submit a patch using ( or I'll add you as a developer.

Sep 29, 2011 at 1:11 AM

The answer is (I think): XNA requires XINPUT controllers, which means it won't support everything that DirectX will. The solution seems to be to hook into lower levels of DirectX. if you haven't done that, the answer is probably a No.

Yes, I know about Nuclex (I said I'd done quite a bit of searching!), and at some suitable moment I was going to ask whether you were interested in integrating any of its features. It has game states, GUI, input and vector fonts with features which all potentially fill gaps in Nine. It's not easy for me to tell how well they would slot in, however.

You don't seem to have physics (another potential area for integration), but you do seem to have collision and some movement stuff, although I currently have no idea how to use them. Yes, I would indeed like to contribute but at present I'm mainly just trying to write little samples to try out how things work.