For the last 3 weeks or so we’ve been building 3 different game prototypes in Unity, and we’ve found these tools pretty useful along the way.
This is a relatively technical blog post, so it might be boring. We’ll get some less technical posts up soon.
Doing anything related to controllers with Unity is a terrible experience. As with quite a few aspects of Unity, input devices are a rather rough edge, and InControl smoothes it out quite nicely. It’s hard to blame Unity entirely here, since input devices are a hard problem to solve in the first place.
InControl does 2 things really well:
- For almost every button, and many, many controllers, answers the question of, “What button does ‘Action0’ represent for a GameCube controller?”
- It has a nice actions-based (rather than buttons-based) API that allows for easy rebinding of inputs at runtime
Most important is that it accomplishes #1, which represents a metric tonne of effort for an individual dev to have to do.
If you’ve used Reactive Extensions for any programming language, you know how amazing it is to be able to compose asynchronous actions together with a universal API. If you haven’t used RX at all yet, I highly suggest taking a look at it.
There’s already RX available for .Net with Rx.Net, but it won’t work in versions of Unity older than v5.5.
The other thing that UniRx gives you is Reactive Extensions for Unity, which allow you to easily turn Unity events (
OnCollisionEnter, etc..) into Observables.
It’s really hard to share object references around in Unity without writing a bunch of static singleton “manager” classes. In most programming environments, there’s a slew of dependency injection frameworks available that will make dealing with your class dependencies a breeze. With Unity there is Zenject. There was StrangeIoC, but it’s not actively maintained anymore.
Zenject’s not a particularly amazing DI framework, but it’s a DI framework that works, and that’s completely invaluable for Unity development.
Unity already provides a camera, but making it follow your character quickly becomes complicated.
Some of the problems that you have to tackle:
- Quaternion math: pointing in a direction while looking over the player’s shoulder from above and behind
- Lowering the camera to fit underneath of ceilings or objects above the player
- Shifting off-centre when there is an object obstruting the view of the player
- Zooming into 1st person view
- Zooming out to a top-down view
Those problems are just the tip of the iceberg when it comes to building an intuitive camera that follows a player.
I’m not certain that the solution we bought is the best one available, but it gets us onto solving the next problem without sinking a pile of effort into camera math.