//UPDATE: For instructions on how to install it via package manager, please see here. //UPDATE: Mentions of preview builds are outdated. You can use the "develop" branch in the GitHub repo with any Unity 2018.3 version or 2019.1 beta. No special build is required. Hey everyone, First, we’re sorry we’ve been radio silent for a bit. We wanted to make sure we had more than just a “Hey, we are still working on it.” So… what’s been happening? After an evaluation by several teams inside Unity, we found things falling short in a number of ways, chief among which were performance implications of the event model we had chosen. After reviewing what we had to change, it became clear that while our C++ parts were headed in the right direction, our high-level C# layer was going to have to be fundamentally changed and this meant a rewrite. Having gone through what’s already been a rather protracted period of development, it was a bitter pill to swallow but we really think it was the right thing to do given that whatever becomes final will be final for some time to come. After spending time back at the drawing board, we’ve made rapid progress implementing the new system and are getting close to having feature-parity with the previous system. We’re excited about how things have turned out and are seeing solid progress with the issues we’ve previously identified. We’ve also gone through another round of internal reviews getting a much more enthusiastic response. However, to get to the next stage, we want to open development up to a wider audience to make sure we’re hitting all the right targets. To this end, we’ve made our C# dev repo public as of today and will be providing preview builds of the editor shortly (our goal is to have them available before Christmas) so you can run the system yourself and be involved in shaping its final form. Be aware that things are still under heavy development. What you’re seeing isn’t 1.0 or even 0.7. This is not a polished “final” release and all accompanying materials are work in progress. Beyond the preview builds, our plans (disclaimer blablabla) are to land our native backend changes in a Unity release and to make the C# code available as a Unity package. By that point, anyone will be able to use the system with a public Unity build. Of course, throughout that process we will listen to feedback and adapt. We’re trying our best to take extra care we’re getting it right. Q&A What are the main differences to Unity’s current input system? Whereas Unity’s current system is closed off and only internally has data about device discoveries and events that happen, the new system sends all data up to C# for processing to happen there. This means that the bulk of the input system has moved into user land and out of the native runtime. This makes it possible to independently evolve the system as well as for users to entirely change the system if desired. Aside from this fundamental architectural difference, we’ve tried to solve a wide range of issues that users have with the functionality of Unity’s current system as well as build a system that is able to cope with the challenges of input as it looks like today. Unity’s current system dates back to when keyboard, mouse, and gamepad were the only means of input for Unity games. On a general level, that means having a system capable of dealing with any kind of input -- and output, too (for haptics, for example). How close to feature complete is the system? There still remains a good chunk of work to be done on actions and especially their various editing workflows. Output support (rumble/haptics) has a design in place but implementation is still in progress. Also, while desktop platforms are starting to be fully usable, there still remains a good deal of work on the various other platforms. Documentation also needs major work. There’s lots of little bits and pieces still missing in the code. And, finally, there’s a stabilization pass that hasn’t happened yet so a good solid round of bug fixing will be required as well. Beyond that we’re working on equipping the system to function well in the world of C# jobs and the upcoming ECS. However, we don’t think the system has to be 100% feature complete to be useful to users and instead are aiming for a baseline set of functionality to be fully completed by the time anyone can use the system with a public Unity build. From there we can incrementally build on it and ship updates through Unity’s package system. How can I run this? The C# system requires changes to the native part of Unity. ATM these are not yet part of a Unity release. We will make preview builds of the editor based on our branch available shortly which can then be used in conjunction with the C# code in the repository. As soon as we have landed the native changes in a public release, everyone will be able to run the code straight from a normal Unity installation. Are action maps still part of the system? Yes. While the action model has changed and there’s still work to be done on actions (and *especially* on the UI side of them but also with things like control schemes and such), actions and bindings are still very much part of the system. Take a look at InputAction and InputActionSet in the repo. In the old model, actions were controls that had values. In the new model, actions are monitors that detect changes in state in the system. That extends to being able to detect patterns of change (e.g. a “long tap” vs a “short tap”) as well as requiring changes to happen in combination (e.g. “left trigger + A button”). Is it still event based? Yes. Source data is delivered from native as an event stream which you can tap into (InputSystem.onEvent). The opposite direction works as well, i.e. you can send events into the system that are treated the same as events coming from native. Is it extensible? Yes. Being able to add support for new devices entirely in C# has been a key focus of the system. We’re still polishing the extensibility mechanisms but the ability to add new devices without needing to modify the input system is already there. What were the performance problems of the previous event model? The previous event model was very granular. Usually, one control value change meant one event. Also, events had fully managed representations on the C# side which required pooling and marshaling. Events, once fully unmarshalled, were sent through a routing system which additionally added overhead. This was compounded by a costly way to store and manage the state updated from those events. In the new event model, all state updates are just memcpy operations and events contain entire device snapshots. Event and state data never leaves unmanaged memory and there is no routing. This model is also much better equipped to work with the upcoming C# job system (where a C# InputEvent class will become unusable). I’m seeing things in a namespace called ‘ISX’. What’s that about? This is temporary. Ideally, we would like to use the UnityEngine.Input namespace but given that’s a class in UnityEngine.dll, that comes with problems. We’re still thinking about the best approach here or whether to just use a different namespace inside UnityEngine but it’s still TBD. The name itself comes from the fact that the system initially had the internal name “InputSystemX”. What are the plans for migrating to this from the old system? For now, the two will stay separate and exist as two independent systems in Unity side by side. The existing input system in Unity is such a fundamental part of pretty much every Unity project that we cannot safely consider a migration until the new system is fully ready in terms of both functionality and stability. Projects will have a choice of which system to use (including using both side-by-side) and will be able to turn one or the other off (with the new system being off by default for now). Once there is truly no reason anymore to use the old system over the new one, we can start thinking about what to do about the old one. Are the APIs that are already there reasonably close to final? At this point, it’s still too early to tell. There may still be significant changes.