I've been spending a lot of time (probably too much) working on the game's input and controller support. Unity's input manager does a swell job for simple projects, but it doesn't let you do a few key things:
- Build and load controller presets. I want to let the player say, "I'm playing with the mouse and keyboard," or "I'm playing with a Logitech gamepad," and have the game set up the best possible control scheme with no further effort.
- Edit subtle control elements like dead zones on the fly. Normally this is not important, but it is in any sort of sim.
There are cool 3rd party libraries that will help you with these problems, namely Rebind and cInput, but neither did what I needed without a lot of modification. So I wrote a system that integrates with the command console.
Config files are read from a folder, and will set up your controls based on a simple syntax:
controls.action.bind +weapon_fire space mouse0 joy1button0
If you've ever written configs for an id engine, this should look familiar. You can even write aliases that enter console commands and bind them to buttons, but I imagine this is more useful for debugging.
If this stuff makes you go cross-eyed, have no fear. Most players will never have to touch a config file. This is there for those with crazier control hardware or those that want to have the freedom to rebind whatever they want.
What You See Is What You Get
Games are interactive, and your input devices are the glue between them and your players. So draw your input on screen. I don't care how simple your game is, you will learn a lot about how it handles by being able to visualize what's going on. Don't be lazy. Your game will feel better because of it.
Once I did this, I learned there were deadzone bugs in the pitch/yaw control. I learned that my digital inputs hooked up to axes were overriding input when you let off the stick, making re-centering feel sluggish. I had never drawn the mouse steering circle/deadzone, but when I did I noticed that long ago it had been written to be configured by absolute pixel size instead of relative screen size.
For a space sim, Enemy Starfighter is on the super lean side of necessary controls and even then, seeing this data helped out with the feel immensely.
"Draw debug info," should not need to be said, but it's hard to be diligent about writing this code. It takes a decent amount time to implement a good visualization for the data you're trying to present, time that could be spent elsewhere. But with critical systems, it's almost impossible to have too much good information.