No, this is not some secret announcement. Its my positive spin on last nights efforts to roll my own input system. Its perhaps the most hack filled piece of code I’ve written so far.
The model class basically sits between the regular Input class and the actual game code. It uses an axis setup pretty similar to the Input class, with static methods for GetKey and GetAxis and the like. And the results are near enough identical to those provided by the regular methods. Sure, its slower, with extra method calls and what not, but it works. It also exposes a bunch of methods for defining new axes and for changing the keys of existing ones.
The view is pretty straight forward as well. I built a bunch of UI that lets the user see the axis and has buttons to change the key. Once a user clicks a button to change a key we hand over to the controller.
Where it gets hacky is in the controller class. The only way I could figure to get the next keycode the user pressed was to listen for an event in OnGUI. OnGUI is so 2014. Its been so long since I used the legacy system I had to search the documentation to even remember what an EventType was, let alone why I cared about it.
So now I have this configurable input system that looks pretty good, and performs acceptably for my use case. But deep down inside I’ll always know that my code is essentially doing this:
using UnityEngine.UI;
Text displayText;
void OnGUI (){
displayText.text = Event.current.keycode.ToString();
}
(Totally dramatized that code for effect, don’t try to compile it)
So yeah, looking forward to Unity releasing a solid configurable input system, one built into the engine, not hacked on in the only place I could make it fit. Or if there is something I missed (it was pretty late last night) let me know that I’m being an idiot.