This is my third post in what looks like is going to turn into a series, examining parts of the example project I provided for the Unity Hacks presentation – delivered at a couple of the Unite conferences this year.
You can find the project and a recording of the presentation in the videos section of this site.
The DualControls interface has a very straight forward purpose: Provide a 2 × 2 axis input interface across platforms and compatible units. This is exposed via the DualControls.Left and DualControls.Right accessors – each returning a Vector2.
Supported out of the box is:
- WASD + mouse.
- Xbox360 controller (windows-only)
- ps3 controller (OS X-only)
- Shadowgun-style touch controls (left/right screen split)
However abstraction is relaxed enough that virtual sticks or alternative input like the leap motion could be added fairly easily (assuming you have a means of capturing that input data in the first place).
So controllers are not exactly nicely wrapped up in the current version of Unity. Which ungodly hack did I have to apply to get them to play along with just working out of the box in an easily installable package? It is actually not so bad. However I had to concede to some compromises up front. Basically when it comes to joysticks and controllers, you generally have two complications: the hardware itself and the driver.
So? What is so bad about that? Well, in a perfect world you had one driver for each controller type or at least all the drivers for the same hardware would map the buttons and axes in the same way, right?
Enter: This world. For every controller you always have at least two drivers set up differently: One for OS X and one for Windows (the Linux one often being based on the Windows one as I understand it). Why would anyone be content with just two drivers though? There exists a good number of different packages and open source solutions, vendor and OS provided drivers for the different controllers.
The way these are differentiated in the Unity runtime is via the joystick name string – as accessible via Input.GetJoystickNames.
This is what DualControls checks for in its Update handler. If a new joystick is found connected, it runs the name by the controller wiring and activates the appropriate controller (optionally if accepted by a callback).
Per default I have compromised and only provided wiring for the Xbox360 controller on Windows and the ps3 controller on OS X. This particular configuration stems from the fact that those OS’es ship with a pre-installed default driver for those controllers.
Microsoft clearly should support their own hardware and I’m assuming that Apple just supports the ps3 controller because it’s hardware from a direct Microsoft competitor.
However, again, the abstraction is loose enough that if you want to, you should be able to add support for more controllers fairly easily. See the end of the Controllers.cs script for that.
Oh, but I almost forgot the hack: As I am using the standard Unity Input API for this, the input manager needs configuring, right? So with no API for it, how do you go about doing that for a package?
You use the AssetDatabase API to load ProjectSettings/InputManager.asset and then the ScriptableObject API to modify it.
I hope you find this useful. For more details, these are the Unity Hacks scripts related to this post: