Professional controls/binding scheme

[Taehl]

I've noticed that nearly all professional computer games offer the same scheme for binding controls: 2 sets of keys and an optional joystick, all configurable. Since I needed to overhaul Underlife's controls anyway, I thought I'd figure out how to recreate that scheme in Love. It ended up just being 33 lines of simple code (and allows both digital and analogue movement). Here's the resulting article: Professional controls

[Robin]

Ehm, I have some problems with that. It is nice in principle, but things like:

Code: Select all

        for k,v in pairs(control.keys) do control[k] = control[k] or love.keyboard.isDown(v) end
        for k,v in pairs(control.keys2) do control[k] = control[k] or love.keyboard.isDown(v) end

are problematic. You see, once you press "jump" or whatever, it will stick. control["jump"] will become true, and if you release the key, you get control["jump"] = control["jump"] or false. And since control["jump"] was true, it remains true (true or false is true).

It also has some namespace pollution, which is a shame.

Lastly, the examples don't work: you forgot the function keyword as well as leaving out control.update().

[Taehl]

It doesn't stick since the controls are reset to false at the beginning of each control.update(). It has potential namespace pollution since this is just an example which is meant to be tailored to a given game, not a standalone library. As for the examples: You're right, I forgot that. I'll fix it now.

[Robin]

It doesn't stick since the controls are reset to false at the beginning of each control.update().

Oh, you're right, I didn't see that. Still ugly, since you'd need to change that in two places when you add controls.

It has potential namespace pollution since this is just an example which is meant to be tailored to a given game, not a standalone library.

I mean, you can't call a control keys, keys, joyaxes, joybtns or update. That's pretty arbitrary. And so easy and quick to fix.

[kraftman]

It doesn't stick since the controls are reset to false at the beginning of each control.update(). It has potential namespace pollution since this is just an example which is meant to be tailored to a given game, not a standalone library. As for the examples: You're right, I forgot that. I'll fix it now.

It would be nice to have something like

SetBinding("KEY_PRESSED", "w", JumpOrFly)

[Taehl]

I mean, you can't call a control keys, keys, joyaxes, joybtns or update. That's pretty arbitrary. And so easy and quick to fix.

Sure I can. In my mind, a control is a thing a game system looks for ("jump", "run", "left"). An input is a hardware signal ("shift", "joybutton 0", "mouse coordinate"). Bindings links input(s) to control(s).

SetBinding("KEY_PRESSED", "w", JumpOrFly)

You could add such a function to my scheme with just a few lines of code. But I would much rather use control.key.JumpOrFly = "w".

[Robin]

Sure I can. In my mind, a control is a thing a game system looks for ("jump", "run", "left"). An input is a hardware signal ("shift", "joybutton 0", "mouse coordinate"). Bindings links input(s) to control(s).

No, you don't understand. What I mean is, that you can't call a control "keys" or "update" or those other things. Because control["keys"] and control["update"] are already taken.

Modifying it to what it says below this line causes it to crash and burn.

Code: Select all

keys = { up="w", left="a", down="s", right="d", jump=" ", attack="lctrl", menu="escape", update="u" },

[Taehl]

You can break /anything/ by changing a line the wrong way. Just don't do that.

[Robin]

You can break /anything/ by changing a line the wrong way. Just don't do that.

The wrong way, yes. There was nothing wrong about my example.

[T-Bone]

There isn't really a big problem in what our TC is doing, but calling this "professional" seems like a bit too much when it has such relatively simple issues.