Godot: Expose input mapper to players?

[admiralzeech]

Hi, my first issue submission so apologies for any mistakes. A feature suggestion.

Is there any way to expose the input map window to the players of the game, so they can see / customise the controls themselves? Since Godot already has this feature as part of the editor, it would be nice to save developers a little effort and allow it to be used in games. You could add additional functions to let devs reskin or modify the window to suit their game, but exposing it by default for all games would make those quick gamejam games just a bit more functional and friendly.

Anyways, I hope such a thing already exists, but if not, please consider this suggestion. Thanks!

[vnen]

I think the editor interface is too powerful for anyone to use in-game. You can already do it with code using the InputMap singleton.

[groud]

No, it's not a good idea. In most games the input map has an integrated design that fits the game style.
There no need to provide a default window by default, but someone could easily add such feature to the assetlib.

[admiralzeech]

There no need to provide a default window by default

When searching for related issues, I came across another issue where someone was trying to automatically detect the keyboard layout and remap WASD to the equivalently located keys. A commentor in that issue mentioned how it was annoying that many Godot games had hardcoded inputs and there needed to be an educational campaign to devs that not all keyboards are QWERTY. So far in my personal experience, every Godot games I've tried has hardcoded inputs and do not provide any ingame information on what keys they use - I have to load it up in the editor and check the project settings. The same goes for all of the Godot sample projects.

Rather than requiring every new game to reinvent the wheel (or to know of the existence of the tool in the assetlib) surely it would raise the quality of all Godot games instantly if at least some level of input mapping was provided by default? And allow game devs to customise to fit their game style if and when they want to do it?

[groud]

The input are not required to be hardcoded, you already have the possibility to define a set of actions and their default mapping using the InputMap Singleton. You just have to create a custom window if you want to reassign the mapping in games.

In any case, I'm against providing this as a built-in thing. For me it's out of the scope of the engine as it is already simple enough to map inputs. And if someone needs a default window to map the inputs, I think it should be made available through the assetlib.

[vnen]

I don't think adding such a tool would solve the problem, because the game developer would have to call it from somewhere anyway. It would also have some defaults that most of the time won't suit the game style and have to be tweaked. Many won't bother adding it (even if the discover it exists).

We can improve the docs and maybe add a tutorial about how to make your own remap screen. But I don't think that providing a default tool will solve the issue.

[LikeLakers2]

You just have to create a custom window if you want to reassign the mapping in games.

I think the point was to avoid having to do this, avoid having to write more and more code when in some instances Godot's interface might work fine for a time. If they wanted the input mapper to look or function differently than Godot's, then sure I understand, but...

---

I'd be up for this, personally. Not because of the same reason of so many inputs being hardcoded, but because it would (in theory) be easy to drop in and use until a dev can get their own version of an input mapper up and running.

[groud]

it would be easy to drop in and use until a dev can get their own version of an input mapper up and running.

Yes, that's the point of the assetlib. For me, this use case is very specific, used only for prototypes. As it is not required in most games, there's no strong need for it to be built-in. And as it can be easily done in the assetlib, that's where, IMHO, it belongs.

[hubbyist]

We have a very short Splash screen tutorial. May be input mapping dialog tutorial can be added to it since remapping inputs in splash screen also makes sense for small games that you directly start game play after splash screen.

[Ranoller]

This feature is not difficult to self-code in gdscript and you only have to do one time. One of the best things about godot is that your script code is easily reusable. Code that input-mapping that you need one time and apply to all your games... easy. It´s better to do yourself than using other people scripts, if you code that, you know how it works, what it do and how adapt it to new kinds of input. And control is one of the most important things that a game have... you should not give that responsability to the unity asset store.

[eon-s]

Engine input mapper is too big for common games, and won't fit game aesthetics with a theme that won't fit the custom ones because games are weird on input menu, and some even change according to connected devices.

I'm more for fixing it in the documentation, even with a demo or plugin in the asset lib, managing input actions can be confusing, the tool is powerful but lacks of documentation on common use cases.

The last 2 sections here http://docs.godotengine.org/en/3.0/tutorials/inputs/inputevent.html#actions can be expanded in their own pages with examples.

[akien-mga]

I'm not sure to understand what's asked for here. Have the full editor InputMap GUI available in games? IMO that's overkill, too complex for most games, and it would look out of place.

Instead you can implement your own InputMap remappings GUI in a few lines of code and a couple Controls. There's even an official demo about it: https://github.com/godotengine/godot-demo-projects/tree/master/gui/input_mapping

[admiralzeech]

I'm not sure to understand what's asked for here. Have the full editor InputMap GUI available in games? IMO that's overkill, too complex for most games, and it would look out of place.

Apologies for the late reply. I was away on a trip.

I take the point that the built-in editor is overkill for games. But I still think it's better for everyone if some sort of input mapping was provided by default, especially if it only takes "a few lines of code."

Here is my reasoning:

• Almost every game should have rebindable inputs, for reasons of accessibility, differing keyboard/gamepad layouts, and simple comfort, yet so many games neglect this important UI feature.

• If Godot implements a simple input rebind window by default, available for any game, what would the outcome be?
  --> For the 10% of games where the devs are motivated enough to implement their own appropriately skinned UI, there is no change - these devs can and will still do it.
  --> For the 10% of games where it's a deliberate design decision to prevent input remapping, this feature can be turned off in the options. There is no change.
  --> For the 80% of games which deserve input mapping but the dev neglects to implement it, we will get input mapping where none existed before. Players are happy, devs are happy, no-one is unhappy.

So in my point of view, this is a change that will make many people happy, and no-one unhappy. It's just easy to argue for the status quo for those that don't personally benefit. But if the feature already existed, no-one would argue for it to be removed. So I feel the arguments against are mostly just inertia.

[groud]

Godot is a game engine, it's meant to provide the tools to make a game, not the game itself. It's up to the user to implement such system, not to Godot. Next we're going to have people asking for a built-in inventory system, a built-in skills system, a built-in idontknowwhat... These take time both to keep up to date, and a bloating everyone's game for few lazy programmers.

My point of view is the following, in most games, people will want to implement their own system, so they don't need another built-in mapping system that increase the executable size for nothing. For those who wants to have a default built-in input making, they just have to find one on the asset store. For those who don't care, they wouldn't have used it anyway, and forcing them to have a popup window for inputs when their game starts (like Unity does) is a pretty bad idea. I prefer to let users choose what they want for their game instead of forcing them to use a built-in input mapping system.

[Ranoller]

And here is when we return to the mandatory default input actions that probably we don't need :D :D :D. No its joke, don't want to change conversation way...

[admiralzeech]

Godot is a game engine, it's meant to provide the tools to make a game, not the game itself. It's up to the user to implement such system, not to Godot. Next we're going to have people asking for a built-in inventory system, a built-in skills system, a built-in idontknowwhat... These take time both to keep up to date, and a bloating everyone's game for few lazy programmers.

@groud I don't want to get into a back and forth argument, but since your views are quite common I think it would be useful to address them.

First of all, we're not forcing anyone. Like I said, it should be an option that can be turned off in settings. Also, it doesnt have to be so in-your-face as a popup window on startup. It can just be a hotkey that's rebindable in project settings, like F12 or Alt-F12. It doesn't have to be pretty, it doesn't have to integrated, it just has to be available.

As for your slippery slope argument, doesn't that apply to anything? Why do we have localisation support? Why do we have high-level multiplayer? Why aren't we all just coding in assembler? You could argue that localisation and multiplayer are integral parts of games, but that's exactly what I'm trying to say - input remapping (and accessibility in general) is extremely fundamental and deserves to be available in all games.

The problem with accessibility issues is that it's so easy for people to dismiss them if they don't understand. "Why can't you just adapt and get over it?", "Why can't you just learn to use Autohotkey?" or the worst, "Why don't you play a different game?". For the player who can't play a game because it doesn't support her keyboard layout, or doesn't accomodate his physical abilities, your ideologies are meaningless. Your stance against bloat is meaningless, and blaming "lazy" game developers is meaningless. The only thing that matters is, if Godot has this feature, they can play the game. If not, they can't, or at least not easily.

If you wanted to apply slippery slope again, you might ask, "Well, why stop there? Why not include colour-blindness mode support by default?". Well, maybe we should. I imagine Godot would get nothing but acclaim to be the first engine to offer universal colourblindness mode support. But at the very least, I would like people to not reject things out of inertia or ideology, but instead consider things on a cost-benefit basis.

In this case:

• The cost: Not too much. According to akien-mga, "just a few lines of code."
• The benefit: Which games will benefit? Like I said, a big majority of games deserve input remapping but don't have it. So most games will benefit. Which players will benefit? Whilst many people will benefit somewhat in terms of comfort, there's a minority of people who really need this feature, and it will be a huge help to them.

Anyways, I hope this will convince everyone that this is a low-hanging fruit that will be very helpful to some people. I'm just getting started with Godot, but I'm willing to try to help implement if I can get some guidance on how to do so.

[mhilbrunner]

IMO, this issue should be handled in two ways:

• better docs and tutorials: show how to properly handle input, including key mapping, and use it as default in all tutorials and demos
• make sure it is easy to create a custom UI for key mapping on top of the engine features

A default "key mapping" UI is probably too much and better suited to a plugin/asset lib/third-party GitHub repo. Depends too much on a game.

It's like with movement logic:

We include ways to handle input, like move_and_slide(), so you can build your own game-specific logic on top of it. But we don't include a default "top-down" character controller, or a "2d sidescrolling platformer controller", but the tools to make such a thing yourself. Having those controllers would be cool, but they too would better fit in the asset lib or a plugin. Again, IMO.

[akien-mga]

Well again:

Instead you can implement your own InputMap remappings GUI in a few lines of code and a couple Controls. There's even an official demo about it: https://github.com/godotengine/godot-demo-projects/tree/master/gui/input_mapping

There's an official demo for it, and it's quite simple. If game developers don't provide input remapping possibility in their games, I don't see how we can force it on them. It's a matter of education, not features.

I'm not against improving things, but we need to properly define what needs to be done to improve things.

I doubt we can expose a "one size fits all" GUI for input remappings that game developers would want their players to use. But it can be a good project for a plugin on the asset library, to see if that's actually something developers will want to use.

[admiralzeech]

If game developers don't provide input remapping possibility in their games, I don't see how we can force it on them. It's a matter of education, not features.

I'm sad to hear that. Hopefully one day you guys will change your minds. I see no problem with a game engine having some universal system settings exposed to the user, just like Adobe Flash does, or a game emulator. It's not a library or a toolkit, after all, it's a game engine. Anything that gives the player more power over his experience rather than leaving it all to the dev is a good thing imo.

Relying on education basically means the problem will never be solved. It's like opt-in vs. opt-out for organ donation. The majority of "supply" don't care about the issue one way or another, but for the small minority of "demand", it's very important indeed. Having an opt-in system and spending lots of effort on advertising will only improve the situation a bit, but it will never solve it, unlike an opt-out system.

Heck, maybe some sort of super secret hacky thing, like the user can create an ini file in the game folder with some defined syntax and it will override the input mappings at runtime... like I said, it doesnt have to be nice, as long as it's there. The people who need it will find out somehow.

[groud]

It's not a library or a toolkit, after all, it's a game engine. Anything that gives the player more power over his experience rather than leaving it all to the dev is a good thing imo.

That's where you are wrong, a game engine is a toolkit. It's not up to us to decide what should be available to the player or not, but to the game developer.

Anything that gives the player more power over his experience rather than leaving it all to the dev is a good thing imo.

It's not up to the player to decide, it's up to the developer to choose what is player is allowed to do or not. We provide a tool to make games, not a game template.

[admiralzeech]

Shrug, whatever you want to call it, it's the same type of thing as Adobe Flash - which gives the user some universal system options. We're not going to agree on this, probably.

[mhilbrunner]

Closing, as this discussion seems to be finished.

OP and devs seems to just disagree about this raised point:

Anything that gives the player more power over his experience rather than .. the dev is a good thing

Godot places a high value on freedom for developers. See the MIT license. You could do far worse things with Godot than not implementing key-remapping. Thats the price of freedom. Godot hopefully will never force developers to do anything, even for a good cause, merely encourage developers to do the right thing.

Hope that doesn't discourage you from using it. :)