J. M. Stark

Vacuous's Method for Player Input

I've learned early on to always decouple input code from game code. Even in Vacuous, where the player only operates with four buttons (minus input needed for menus), this seperation is very useful. It allowed me to easily plug in and remove experimental button choices. Each time I complicated the logic behind how an input worked, I wouldn't need to duplicate it several times in the game code to get everything consistent. Furthermore, this keeps the code readable and clean.

Blog Image 1

Here is the control code for the top thruster of the ship. The c_ThrustUp() function checks if the input for the top thruster is pressed. Notice how this queries the input abstractly, not specifying the device and button. If on this update the correct input is detected, the next velocity of the ship is calculated.

Blog Image 2

Take a look at the anatomy of the c_ThrustUp() script. Fitting all of this inside the expression in the game play code would be nasty. It checks if input is even allowed (it is convenient to remove all control from the user as the game transitions from room to room or performs some fancy animation). There is also a check to see if the console is open. If so, gameplay input is also ignored, since it is instead being focused on typing and submitting commands. For gamepad input, the existence of the gamepad itself has to be checked. Afterwards, there is a check to see if the thruster input has been inverted (left is right, up is down). Finally, all the valid buttons that would trigger the abstract input are checked, and if one is detected, the input returns true. The process is repeated for the keyboard input.

- J. M. Stark