Baton - yet another input library

[Tesselode]

Hey, it's me again, popping in to announce another library.

Tactile didn't have a good way of customizing controls, which sucks for accessibility. So this is my attempt to fix that. It has the axis/button system of Tactile with a data-driven approach to defining controls.

It loks like this:

Code: Select all

local baton = require 'baton'

local controls = {
  left = {'key:left', 'axis:leftx-', 'button:dpleft'},
  right = {'key:right', 'axis:leftx+', 'button:dpright'},
  up = {'key:up', 'axis:lefty-', 'button:dpup'},
  down = {'key:down', 'axis:lefty+', 'button:dpdown'},
  shoot = {'key:x', 'button:a'}
}

local input = baton.newPlayer(controls, love.joystick.getJoysticks()[1])

function love.update(dt)
  input:update()
  local horizontal = input:get 'right' - input:get 'left'
  local vertical = input:get 'down' - input:get 'up'

  playerShip:move(horizontal, vertical)
  if input:pressed 'shoot' then
    playerShip:shoot()
  end
end

And you can get it here!

[Ulydev]

Looks really intuitive. Thanks for sharing!

EDIT: The title is pretty funny, too. I think I just realised why you named it Baton

[Tesselode]

Looks really intuitive. Thanks for sharing!

EDIT: The title is pretty funny, too. I think I just realised why you named it Baton

uhhhhhhhhhhh did I name it something funny or suggestive on accident?

[Ulydev]

Well, it translates to Stick in French, which made me think of a joyStick, but you probably know that already. It's pretty original

[Tesselode]

I'm OK with that.

[Clyybber]

Well, it translates to Stick in French, which made me think of a joyStick, but you probably know that already. It's pretty original

And it's the english pronunciation of button.

[pevzi]

The API is nice, I don't think it can get simpler than that. But there are some things I'm concerned about.

1. What is the idea behind _getActiveDevice? Is it used to avoid source queries for a device that isn't used?
2. This one can be difficult to fix given the approach taken by the library but the shape of the deadzone should really be a circle, not a "cross". Tactile suffered from this as well, by the way.

[Tesselode]

The API is nice, I don't think it can get simpler than that. But there are some things I'm concerned about.

1. What is the idea behind _getActiveDevice? Is it used to avoid source queries for a device that isn't used?
2. This one can be difficult to fix given the approach taken by the library but the shape of the deadzone should really be a circle, not a "cross". Tactile suffered from this as well, by the way.

1. It's mostly for cosmetic things, like if you need to display different instructions for the keyboard or gamepad.
2. That's what getRaw is for right now; you can make your own circle deadzone. That being said, do you think it would be good to implement some sort of axis pair object in the library?

[pevzi]

It's mostly for cosmetic things, like if you need to display different instructions for the keyboard or gamepad.

OK I see but the additional loop seems kind of redundant to me. Maybe it'd make more sense to track the last used device in _updateControls itself.

That's what getRaw is for right now; you can make your own circle deadzone. That being said, do you think it would be good to implement some sort of axis pair object in the library?

That's probably a good idea, and now that I think of it, it may also include a solution to another problem relevant for many developers that is capping the movement vector to unit length when using keyboard input. How would it fit into the existing API though?

[Tesselode]

It's mostly for cosmetic things, like if you need to display different instructions for the keyboard or gamepad.

OK I see but the additional loop seems kind of redundant to me. Maybe it'd make more sense to track the last used device in _updateControls itself.

That's what getRaw is for right now; you can make your own circle deadzone. That being said, do you think it would be good to implement some sort of axis pair object in the library?

That's probably a good idea, and now that I think of it, it may also include a solution to another problem relevant for many developers that is capping the movement vector to unit length when using keyboard input. How would it fit into the existing API though?

Oh whoops, sorry I took so long to get back to you!

Can you elaborate on the redundant loop? Or, if you see a way to make it more efficient, feel free to make a PR.

I've previously toyed around with defining axis pairs in the table along with controls, but it made the controls definition too complicated. I think I might just implement it as a function like in Tactile, since something like that doesn't need to be data driven, as the player won't be redefining it.