Some engines do have something called an “Input Map” where we can define Input Actions and assign multiple keys and input methods for the same Action.
For example we could create an Action called “MoveRight” and assign the ‘D’ and the “Right Arrow” key to this input so both key do the same.
So instead of doing
D key is pressed
Right key is pressed
Then Move right.
We could add both keys to an Action called “MoveRight” and just say if “MoveRight” Action pressed Then Move Right.
Now imagine that we also want to add joy support so then we could reduce 3 conditions to 1 only and imagine that different joys have different input maps so we might have in the future PS Right button, Xbox Right Button, Logitech Right button and what not to be different. So then it means to support all joys, we need to check 3 more inputs means 5 in total and maybe in the future we also going to have virtual (touch) buttons too in GD. So whatever the situation may be, we can always reduce multiple condition checks to only 1 and if we ever want to change any input we need to do it only once in the input map.
It would also benefit artists and designers who don’t want to deal with events and logic so they can just go to the Input Map properties and change any key for any action (jump, move, fly, run, shoot, power1…etc) as they see fit without need to touch any events.
I made a PR with this some time ago. It was refused as I added it to the keyboard extension but 4ian wants it in a separate extension.
Just to be clear I’m rarely refusing or rejecting things, but suggesting another approach or asking for more explanations/details/careful design.
With GDevelop, we’re making a game engine and any feature will probably live for the next 2, 3, 5 or even 10 years => everything won’t be perfect, but we must try to do things as cleanly as possible.
In this case, we need to layer things, and keep responsibility separated:
- The game engine contains support for touch/mouse/keyboard. It exposes this through something called “gdjs.InputManager”. It does one thing (handling these touch/mouse/keyboard events) and does one thing well.
Now we’re like “ok that’s good BUT it’s not flexible, in a game I want to move right my character if I press a key OR another key OR a mouse button (maybe) OR a joystick key”. We should have an input map, i.e: what @ddabrahim is asking for. It’s making sense!
We could be “ok let’s add it to the gdjs.InputManager of the game engine”. Sure it could work but from what I remember in your original implementation this is handling only keyboard events…
We’re also making the game engine more complex. If we re-implement the game engine for another platform, it’s better to have less to implement.
Instead let’s build this input manager on top of the game engine in… an extension
It will be cleaner and the extension can have input map that is:
- composed of keyboard, mouse, touch… but also joystick (if the gamepad extension is installed) or even gestures
- We can see even further! The extension can handle combination or inputs. Press Space AND the left button to fire a big rocket.
- We can see even further! The extension can handle timing or combos. Press A then B then Up, then Down… (to do a Konami code or just a combo in a fighting game)
- We can save/load the input map to a JSON maybe?
- Finally we can add a visual way in the editor to define keys (this would need to create a dialog using React, might need a bit of refactoring on my side to allow an extension to create dialogs with React… but that could be something!).
So I think this extension would be very very interesting But seeing its potential, I also think this is something that must be not part of the “core” game engine. It’s a feature that must be built on top of the rest. Extensions are made for this.
EDIT: card is actually already one the roadmap: Trello
Just to clarify, I didn’t meant this as a bad thing, I know that it is better as an extension and why, I just posted that because I thought it might be relevant to the topic.
Sure thing Do you think you’ll rework the PR by the way? If not in the near future let’s close it and re-open later to make things clear?
I will rework the PR, but I am not sure when. I have way too much projects at once and a broken PC You can certainly close it for now, when I begin working on that again I will make a new one.