Input System Update

//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.

 

Thanks @dadude123.

ATM I'm still figuring out how to best handle pointer positions especially with respect to multiple displays and the fact that the input system can be used in EditorWindows as well (not just in game code).

What you can already do is put custom processors on pointer position controls which modify the stored value the way you want to when it's being queried. Also, I think that once output support is complete you'll be able to set the value on arbitrary InputControls -- though that needs figuring out how it'd work with actions (which need to be able to observe state changes).

I'll have a think about your use case and how the API could best support it.

By default, yes, there's buffering. However, unlike in the old system, the buffering happens on the source data, not the aggregated data. What this means for mouse input on Windows, for example, is that it would sample mouse input at probably a higher rate than your framerate (IIRC the default on Windows is 120Hz) so there'd usually be multiple state updates for a frame, all of which come through in C#. Also, where it's on us to sample rather than the system (XInput, for example), we're making sure sampling happens at user-controlled frequency rather than framerate.

Preconfigured input updates, where we flush out data, ATM happen right before fixed updates and right before dynamic updates. One or the other will be able to be turned off.

Buffered data can be flushed out manually -- which, however, ATM only benefits you in the case of data that isn't fetched from OS-supplied event queues that are tapped on the main thread's player loop.

Finally, there's work under way to give C# game code control over the arrangement of the player loop so with that in place, scheduled input updates can also be moved around within the loop.

Events are actually the third option. The notes aren't worded well. It's talking about 1) callbacks, 2) polling, or 3) events where events in this case means a "give me all the events that have accumulated" style rather than "we notify you whenever there's an event".

Yup, indeed, the concern isn't the processing overhead of input but more the logic that is affected by input. Say your entire game logic is chunked into nice jobs with clear dependencies. But then, part of that logic depends on the state of the input system. If you can't get to that data in your jobs at the point you need it, then you have that ugly sync point that forces you back on the main thread. You can put it up front to before scheduling any jobs but that's still a constraint on what you can do in your logic and what you can't.

Believe me, this has led to some heated internal discussions

 

Yup, working on it On the native side, we have the foundational pieces in place but on the managed side, we're missing the part where you can write into state and have the updated state reach the underlying backend. It won't be in place for the preview builds but it's high up on the list of things to get finished.

Yes, though "handling" can refer to a lot of things

You can have arbitrary many gamepads (or any other type of device -- there's no device count limits in the system).

Code (CSharp):

1.  
2. // Find the last gamepad the user used.
3. var gamepad = Gamepad.current;
4.  
5. // Find all gamepads.
6. var gamepads = Gamepad.all; // In the API but not yet implemented; will throw.
7. gamepads = InputSystem.devices.Select(x => x is Gamepad);
8. gamepads = InputSystem.GetControls("/<Gamepad>"); // Every device using the gamepad template.
9.  

With actions, you can have a set of actions, for example, and then use that same set for a 4-player local coop scenario:

Code (CSharp):

1.  
2. InputActionSet UseActionsWithGamepad(InputActionSet set, Gamepad gamepad)
3. {
4.     var clone = set.Clone();
5.     clone.ApplyOverridesUsingMatchingControls(gamepad);
6.     clone.Enable();
7.     return clone;
8. }
9.  
10. // Determine which gamepad to use for which player in some way specific to your game.
11. var player1Actions = UseActionsWithGamepad(myGameControls, gamepad1);
12. var player2Actions = UseActionsWithGamepad(myGameControls, gamepad2);
13. var player3Actions = UseActionsWithGamepad(myGameControls, gamepad3);
14. var player4Actions = UseActionsWithGamepad(myGameControls, gamepad4);
15.  
16. // In reality, you'd probably have a component representing the input for one player and then have four player GOs with that component...
17.  

There'll be more refined ways to work with multiple devices of the same type and sets of actions being applied to them but the core of it is there.

Absolutely. ATM what we have is.... nothing much. We're hoping to get the R&D content team to help us out there. As we get closer to full release, there will definitely be more polished supporting material and more examples to work off of.

ATM it's possible by listening to the input stream. Events tell you which device they are for so you can see when the user changes from one to the other. However, noisy devices make that tedious (e.g. the PS4 gamepad will constantly spam the system due to have sensors in the device).

Eventually, there will hopefully be more refined mechanisms.

No one wants to see that happening. Least of all anyone who went through the reboot...

We're very confident we addressed what needed to be addressed and are on a really good track going forward.

 

I don't think that's fair. In at least the latest iteration, Spiderman also got an annoying child actor with lots of unfunny one-liners.

Agreed that consistency of mappings is a big deal. If you can't rely on the A/south/cross button to be in the spot you expect it to, that's not much good.

IMO this has two axes: 1) consistency across platforms and b) consistency across a specific interface (especially HIDs on desktops).

1) is something we're working on to address from the get-go. Unity's current input system is 90% platform-specific code with huge variations given that all the interpretation of "what does this input mean?" happens on a per-platform basis. What we're going for now is both much less platform-specific code as well as more consistency between platform-specifics. I think this step alone will make a big difference.

2) I think will partially be something that will build up over time as we add profiles for devices to the system. We did license InControl's roster of profiles but things have changed so much that we'll have to re-evaluate at some point what we can still bring over in some form. Consistent support for XInput and PS controllers will be there from the get-go, though.

It does pertain mostly to a very specific segment of input devices, though (namely gamepads and joysticks). The system overall aims to address input in a more comprehensive picture.

 

We agree, and we're working on something in that direction

 

We don't yet have hard numbers for you as this is aggregating a host of possible setups but I definitely think in addition to giving you a certain level of control, the system also needs to give you an idea of what to expect.

It does depend quite a bit on what device we're talking about. For things that get tapped on the main thread ATM (stuff like the mouse on Windows), there is a platform-specific distance between that and where the player loop brings input into C# land -- which happens as the first thing in fixed and dynamic updates. There's stuff in the works to give more control over the placement of input processing which would allow you to move things closer.

For asynchronously collected input, we either pick things up as fast as the system produces (for devices that notify us) or pick things up at user-controllable frequencies. If you want the freshest possible set of async data, you can explicitly flush things out yourself. Out of the box, the system does that kind of stuff for head tracking where we need an extra update right before rendering.

Is that at least a somewhat satisfactory answer?

Yup, you do. We perform as little processing on the native side as possible and send the data up to C# as raw as possible. There's all kinds of conditioning you can do in the C# system for delivering final values (deadzone processing being the most obvious example) but you always have access to the raw unprocessed source data we picked up.

When the preview builds are out, it'd be great if you can give it a whirl and see if the data does match your expectations.

Glad the packman guys jumped in this thread and yup, 100% on board. The existing package management solution we have in Unity is weak and I'm super happy about what's brewing there ATM. Just looking at .NET dev in general with NuGet (or any other contemporary dev ecosystem for that matter), it's really something we're missing. But that's about to change

That's an interesting idea. Let me have a think on it.

The one worry we have with the namespace is that we assume users (especially new ones) will likely expect anything input-related to be called something with "input". Which would get doubly confusing if there is something called UnityEngine.Input and it's *not* the right thing to use. But maybe we're overestimating how much importance that really has (definitely interested in hearing opinions).

Absolutely. We consider being able to accurately map whatever input device is connected to Unity to be a key aspect of a proper input solution.

For HIDs, the Rewired folks are definitely right that it can be tricky and will often require resorting to a database of per-product data about how to make sense of a specific device (thus big controller matrices like http://guavaman.com/projects/rewired/docs/SupportedControllers.html).

ATM we have a two-pronged approach that will hopefully have you covered.

Product-specific templates can be built to specifically deal with individual devices. This is the database-style approach. You can see an example here.

Additionally, there's a fallback path that represents a best effort when there's no product-specific template in place. Using the HID descriptor, it tries to figure out how to best represent the device in Unity. ATM this is still very bare bones. You can see it here.

Note that HID data from the platform is now available 1:1 in managed code (we are literally working with raw HID reports in C# code). If what comes out of the box proves insufficient, you can always set up support for your specific HIDs entirely in user space without having to modify the input system. Vendor and product IDs are available to you (see here).

That said, HID is where it ends. We do not ATM have support for other USB device classes. I.e. if your device is USB but not a HID, it won't get picked up ATM.

We are closely working with the XR team in Bellevue and are working towards converging our efforts when we land the native changes in Unity and a public release. At that point, XR input should be a first-class citizen in the system next to the other types of devices.

 

While it's technically possible to do so, the compiler will still spam about the naming conflict between the UnityEngine.Input class and the UnityEngine.Input namespace (as it's still there, even if just used as a parent).

If we're okay to live with the conflict, we could actually even make the jump straight to UnityEngine.Input. But it does kinda seem like not solving the problem but rather just living with it. If it was spamming just for the InputSystem DLL compile, I think I'd be okay with it. But it'll spam for everyone actually using the system and that's... not nice

That's a good point. And I think you're right that having the two systems coexist side-by-side will create some confusion no matter the naming of the new system.

Unfortunately, I think we won't be able to mark the old system deprecated until users really have an out-of-the-box, zero-functional-regression, and reasonably-finished alternative. Otherwise it's a bit like putting Mecanim v1 out there and immediately marking all existing animation features deprecated. I think that would have caused a lot of chagrin.

The problem is that the existing UnityEngine.Input has methods and properties. These cannot be moved anywhere but to within another class. So the only way to move both systems into the UnityEngine.Input namespace would require leveraging the script updater to move all the method and property uses around in existing code.

 

Yes, we're working on leveraging ISX for crossplatform XR input

 

Yup. Implementation is still ongoing but API-wise the idea looks like this ATM:

Code (CSharp):

1. Gamepad.current.leftMotor.value = 0.5f; // Go half-speed on low-frequency motor.

Still a number of things to sort out, though.

The idea is for a device to be able to determine its own set of haptics-related/output controls just like the device already determines its input controls. This would go all the way up to things like a device having a control representing an audio buffer into which you can shove a waveform pattern.

While in theory this could be used to give a device representing the current handset a more sophisticated haptics interface including duration, I think we're missing a bigger piece there. I think ideally there'd be a system that can control playback of haptics effects against simpler output APIs and thus give you control over duration, for example, regardless of whether the underlying device supports that directly or not.

However, that part is still a good stretch away from where the code is ATM.

 

Heh, good point. Did like the shortness of "IO" but didn't think of the ambiguity with System.IO.

You're probably right. I like the idea of just going with "UnityEngine.InputNew" (immediately obvious which one is old and which one is new) and then at a stable point in the future, using the script updater to both relegate the current UnityEngine.Input to something like UnityEngine.Input.Deprecated and to move UnityEngine.InputNew over to UnityEngine.Input.

This is an interesting one. We've been bouncing possible solutions for this kind of usage scenario around. Our current thinking is to add a function that will block until either a specified time has elapsed or until there's input available either background or foreground (read OS message pumps) feeds. With that in place, we think there's multiple avenues this can be exploited to set up throttling scenarios. However, no work has happened yet to put this in place and it will unfortunately require additional per-platform work. I want to give it a try on just Windows but will have to get some other pieces done first.

So.... while probably disappointing to hear, all I can offer ATM is that we have it in the picture but there's a good chance it won't make it into the initial rollout.

 

Thought about and worked on

There's a Pen device class that has pressure, tilt, and twist controls. ATM only the Windows backend actively implements pen input but that'll change. Note that since the system works in both play and edit mode, it'll be possible to write editor extensions supporting pressure sensitive pen input.

 

Heh, that sounds familiar. Force-feedback on the desktop has proven to be a bit of a mess. For HIDs, there's the pretty decent and comprehensive PID spec but I have yet to encounter a device that *actually* does anything but implement but a few trivial controls from it (like the Windows Xbox controller HID driver does but turned out to be a no-go due to its left/right trigger combining).

And given Microsoft's fragmentation of their input API space (abandoning both DirectInput and XInput), it seems vendors often just go with custom vendor-specific, proprietary protocols and then providing SDKs.

Of course you can ask... and I would answer that it is a reasonable expectation

Given our prior failings, we don't want to be committing to anything but the very next milestone (which ATM is public builds so people can do more than just marvel at the prettiness of our C# code) but a reasonable expectation is... reasonable

 

I think ultimately we'll get there. Good defaults, APIs allowing for compact code. At this point, our main focus is still on giving you pieces that are combinable and tweakable in a way that allows you to achieve the exact result you need. I'd rather have APIs that take a line or two more of code to use but can be made to do exactly what you need than having super compact APIs that fail you as soon as you need something slightly different from what they do. I think nice wrappers we can always add along the way as it becomes clearer how the system is commonly being used.

For devices it does not specifically have a template for, it will make a best effort to come up with a sensible fallback. Depending on the type of device that can take various forms. If even the fallbacks fail, however, the device will not get added. It'll be on a list of "discovered devices" and if the system can make sense of the device at some point in the future (e.g. if someone registers a template for it), it'll pull the device back up and add it.

Code (CSharp):

1. InputSystem.devices

will only contain devices the system could make sense of.

It would be easy to expose the list of InputDeviceDescriptions the system is keeping for all devices that have been discovered in addition to

Code (CSharp):

1. InputSystem.devices

. Not sure, though, what problem in particular are you thinking of?

I think that's definitely useful. ATM there's three levels of control. Whether that's enough, I think we'll have to see.

1. Tell native backend "I'm not interested in this device; don't send me its data". The mechanism is in place but it isn't hooked up yet. I think this will be especially useful for very noisy devices that just spam the event queue with events and generate needless work if you don't use them. This mechanism should automatically kick in if a device is not recognized by the system.
2. InputPlugins. This will allow stripping entire chunks of functionality out of the system. Your game/app is keyboard/mouse only? Exclude the XInput plugin, for example, from builds.
3. You can kill templates manually.
   Code (CSharp):

   1. InputSystem.RemoveTemplate("Mouse");
   and mouse support in the system (including mouse devices that have already been created) is gone.

Very much agree. In the new system, there is no clearing of state in response to scene changes. And something like that will most definitely not get added.

In the first step, output controls will be entirely device-specific and there will probably not be an effort to unify/abstract things. That'll mean, for example, that the Oculus Touch controller will likely have a different haptics interface than the Vive controller. Same probably for Xbox gamepads and the Switch controller.

After that, I'd really like to get to a point where we can provide a more unified interface that internally knows how to make stuff work on devices with different capabilities but the baseline to me is that you are able to have access to the capabilities of the specific device you are working with.

They actually don't Or, well, the Linq Select() statement does and the last GetControls() call does (although there is a version where you provide a pre-allocated List).

GC is definitely big on our minds. The system as is already does a lot to stay away from allocating and to optimize allocations where it actually does have to allocate on the managed heap (for example, control hierarchies internally use shared arrays to minimize the number of heap objects in use and to improve scanning performance).

Code (CSharp):

1. InputSystem.devices

does not allocate. You get a ReadOnlyArray directly accessing the system's internal array of devices.

Code (CSharp):

1. Gamepad.all

, once implemented, also won't allocate.

So, yup, proper GC behavior is definitely crucial. Some parts still have some way to go (enabling actions, for example, does cause garbage whereas it really shouldn't) but we're working on it and will keep having our eyes on that "GC Alloc" column

 

Yup, in that case we are. And I think in this case it actually makes sense.

Templates can be constructed *from* types (using reflection) but that's just one way. They can also come in from JSON or be constructed on the fly from template constructors. And they can come in over the network from connected players. There is no 1 C# type == 1 template correspondence.

So using compile-time identifiers for templates won't work. We could certainly add a wrapper method

Code (CSharp):

1. InputSystem.RemoveTemplate<Mouse>();

and probably will do that but in the end, all it'd do is find a string name for the template to remove.

 

Ah yup, that is indeed an interesting problem. Within the XR space, the XR team is working on solutions to make games work with devices they weren't specifically built for.

Within the input system, we've introduced a new mechanism called "usages". The idea is that instead of talking about a control with a certain name (like button "b"), you're talking about a control with a certain usage. Like, "PrimaryTrigger" or "Back". In this approach, a device not only describes its available controls but also the intended usage of those controls. Any bindings that involve usages will then be able to work with the device even if they didn't know about the specific type of device at design time.

We're only at the very first step of figuring out how *exactly* this going to be used but it looks promising. It'll probably take more than just this mechanism to fully solve the problem but let's see.

Note that this also works for devices (which are controls, too). So you can have one device with the usage "LeftHand", for example, and another device with the usage "RightHand". XRController already uses that to make static XRController.leftHand and XRController.rightHand accessors available (see here).

Overall, turns out usages have a surprising number of... usages. Like, if you talk about "PrimaryStick" and "SecondaryStick" instead of "leftStick" and "rightStick", you can support a lefty gamepad layout simply by swapping what's the primary and what's the secondary stick.

 

Yup, no more resetting between scenes.

It is. Where we have to poll (XInput, for example), we poll on threads at user-settable frequency. Where we get events, we surface all of them including timestamps. There's still a state system meaning that ultimately events are aggregated into frames worth of state but the source data is there and you can go directly to it if need be. Also, actions observe every state change, even if multiple happen in the same frame.

 

You don't need to fiddle around with JSON directly. To create an action set asset, right-click in the project browser and select "Create >> Input Actions". You can then edit the actions in the editor UI. The thing is still pretty bare bones but you can already create sets, populate them with actions, and assign bindings to them. We're working on making this thing be a polished UI. Consider what's there ATM programmer art

At the device level, you don't have to deal with JSON except if creating new profiles for input hardware.

Sure. Again, consider the UI that is there preliminary. ATM there's no way to edit parameters on the modifiers, for example. The parameters are there in code but there's simply no UI for it yet.

Overall, the action stuff is by far the least finished part of the system. We'll continue building it out and eventually it'll be nice and shiny but our main focus for now is getting the foundation of the system solid.

The old input system kinda taught us that this central kind of system is really bad. The InputManager asset has consistently been a pain in the behind for asset store devs as well as for team workflows. Also, the approach where you have a single place where you have to define *everything* doesn't scale well to projects that have lots of different action contexts. Thinking of FarCry, for example, where the actual binding used for "Fire" may move around on the gamepad depending on whether you're driving or walking.

I think what you get right now, though, is actually much nicer. Say you have created an asset MyGameControls.inputactions with the workflow outlined above. If you tick the "Generate C# Wrapper Class" box in the importer section, you'll get a nice C# class that handles all the lookups etc. So in your code, all you do is

Code (CSharp):

1. public MyGameControls controls;
2.  
3. public void Awake()
4. {
5.     controls.fire += Fire;
6. }
7.  
8. public void OnEnable()
9. {
10.     controls.Enable();
11. }
12.  

We're working on an alternative API for InputActions that doesn't involve callbacks. With that API, you'd simply tap the action in Update() and process its changes.

You don't need to create them in code. As mentioned in the video, it's just one workflow. I think it's a nice workflow for prototyping and gamejamming where I think an .inputactions asset just adds complexity. But the "proper" workflow is to go with an asset.

As for needing an in-editor tool... hmm, why would you *not* want one?

Heh, completely agree And it's where we would like to end up. I think it's important to bear in mind where the system is in its development. So far, the majority of the work has gone into making the guts of the system work. The UIs that are there are little more than bare bone implementations just to have *something*. We'll have time to make UIs polished but our primary concern at this point is getting the device&control level stuff including native backends into a Unity release and into user's hands. After that, making things nice and polished instead of just functional will become a focus.