tl;dr version: Roidz and I have just released a plugin for Unity called cInput 2.0 that allows you to change your controls at run-time.

About two weeks ago I discovered Roidz’s Custom InputManager 1.4 on the UnifyCommunity wiki.  The next day I happened to be in the #unity3d channel on freenode and saw someone in there named |Roidz|. I asked him if he was the same Roidz who wrote the Custom InputManager 1.4 and he told me he was indeed, and that he was just about finished with its successor: cInput 2.0.

He then asked me if I’d like to beta test it and give him feedback. Neither of us had any idea of what we were getting into when I accepted the offer.

At first I wasn’t too fond of cInput and Roidz didn’t seem too fond of my feedback. I thought it was too difficult to use and Roidz thought it was the best custom input manager available. I agreed with him that it might be the best custom input manager available, but other people might not see it that way given how difficult it was (in my opinion) to set up and access inputs. That convinced him to implement my feature request for an easier-to-use cInput. And while he worked on that, I decided to try making my own contribution to making cInput easier to use as well.

Long story short(er), we partnered up and both have been working day in and day out for the past two weeks improving cInput and preparing it for release on the Unity Asset Store.

What surprised me was how much work was involved that didn’t involve coding!

We thought we had the code pretty much finished up a week ago. Roidz began work on the website, and I wrote the bulk of the documentation since English isn’t Roidz’s first language. Roidz then worked on a mini game demo to show cInput 2.0 in action. As we were creating the code, we would think it was feature complete. But once we started using the code in the demo project or explaining the code in the documentation, we would find bugs or realize missing functionality that was imperative to the usefulness of cInput 2.0. Time and time again as we worked on these little pieces, feeling like we’d be finished any moment, something new would pop up. It seemed like there was always a new bug, an idea for a great new feature, or compatibility problems, etc., keeping us from feeling like it was finished. I now know why people say that the last 10% of a project takes 90% of the time.

It just goes to show how important it is to actually use what you produce, and to get feedback from others who are using your product. They may try to or want to use your product in ways you never even thought of and your product can be made so much better by enabling it to be used in those ways.

We finished up the documentation, example project, instructional videos, website, and of course the code itself, and have just submitted it to the Unity Asset Store.  So I expect it will be available by the end of the week. I suspect that when other people start using the code we will get even more bug reports and feature requests.

I’ll update this post with a link to cInput 2.0 on the Asset Store, but in the meantime you can check out the cInput 2.0 website for more information, documentation, a demonstration, and instructional videos.

Update: That was fast! cInput 2.0 is now on the Unity Asset Store!