Uploaded image for project: 'Minecraft API'
  1. Minecraft API
  2. MCAPI-124

Separation of controls input from the game logic to easily support alternative input methods (especially gamepads)




      Proposed Addition:
      Developers should be able to more easily add alternative input methods to the game.

      Specific Features:

      • Separating the input from the game logic. Having readily accessible functions for actions like attack, repeated attack, starting to sprint, etc
      • More streamlined handling of input in GuiScreens and GuiContainers

      Justification and Use Case:
      Having Minecraft to support the standard (xinput [xbox 360] and normal USB gamepads) and non-standard (Wii Remote, Kinect) game controllers would allow for fun and casual play, while also giving the player the possibility to run the game on multiple-monitor configurations and have a single-pc same-room gameplay.
      While LWJGL already supports the USB HID game controllers (and they are easily accessed using the Controllers API) some features of the game are internally tailored to the mouse and keyboard input and are hard to easily integrate with the alternative inputs.

      Things like the left and right click counters, no separation between right click actions (right click both opens the doors, activates held object, initiates trading, gives item at hand or places block on the ground - on a controller it might be feasible to attach different actions to different buttons) or the way the player initiates sprinting are all implemented in a quite kbd+mouse specific ways. Some actions in GuiScreens (enchanting, trading arrows, scrolling in the creative inventory) are hard to call when the controller itself has no concept of the cursor (instead heavily relying on the concept of active gui elements).

      Challenges Faced:
      The way the input is handled would have to be rethinked. Whether to change some implementations of the GuiScreens, GuiContainers (separate actions from game logic, separate the input detection from the container) and separate the "attack" and "use" loops from mouse input or alternatively add a layer of "virtual mouse" where the mouse actions and cursor could be controlled by different input methods.




            • Assignee:
              shiny Ljubomir Simin
            • Votes:
              5 Vote for this issue
              2 Start watching this issue


              • Created: