About differences with analog/axis versus button only inputs...one thing some input systems do for anything that works on an axis, such as movement, is to store the input as an analog value between -1 and 1(or if you prefer separate values 0 to 1 twice). Then if the input assigned to that action is an analog input like an axis, you almost directly map it. If the input is a button or 2(be it keyboard or gamepad button), you can do a "simulated" axis. This is one thing even Unity's crappy input system actually does, as do some of the asset store packages that are really nice.

The other thing you can do is keep all inputs to either an on or off state. Then, if an key/button is assigned, you directly map it. And if an axis direction is assigned, you say on/off based on some percentage of tilt, maybe 20%, so if the X-Axis is tilted to a +0.2 or more, it counts as 'pressing the button.'

What kind of game you are making will determine which of these methods(or both in many cases) you need to use.

Some of the responses missed the part that this is about Unity.

While it has some flaws, Unity's input mapping system is quite capable. (Sometimes it is a bit tiresome, like mapping all XBox buttons for all controllers, but those are free to download).

With only a tiny bit of work you can configure the game to accept input from the keyboard, and from a controller, from a force feedback joystick, from a flight yoke, from alternative UI devices, whatever they want. If they want to remap arrow keys to WASD or IJKL or whatever they can do it. If they want to reverse up/down or left/right for their preferences they can do it. If they want some buttons one controller and alternate buttons for the commands on another controller, they can do it.

Set it up right and it doesn't matter what they use. All that matters to the game is that you have axis values and buttons for input.

If you need keyboard input it is slightly more difficult for non-keyboard configurations, but those are also handled fairly easily. There are plenty of tutorials on making a UI for keyboards that generate key events the same as regular keyboard events and also reading actual keyboards, then you can process them the same way. It gives the user the option to stay with their gamepad to type with their thumbs, or to start typing on their keyboard, or both.

TL;DR: It is Unity. It's easy to support both.

I personally mentioned Unity, and the actual lacking of Unity's input system. I highly recommend usage of a nice asset such as ReWired because of this. Unity's system can handle things somewhat well, but has a couple of downfalls, one of which for me is a deal breaker. You can't directly configure Unity's inputs at runtime, and that is really a big deal to me. Sure, you can code stuff on top of that to deal with it, but that takes time of course.

A bit late to this, but I'd strongly advocate for both. Shipping a PC game without mouse & keyboard support is opening yourself to ridicule, but at the same time, there are many PC games that I prefer to play with an XBox One controller.

What is the prevailing design philosophy on this?

I've been playing PC games for like 14 years, and I have never touched a PC game that didn't support a keyboard. It'd be as asinine as releasing a console game that doesn't supports the platform's controller.

Shipping a PC game without mouse & keyboard support is opening yourself to ridicule,

Exactly. Talking about this, Bethesda released Skyrim without proper mouse support at first, half the time the UI simply didn't work with mouse input. People were very, very angry about it.

Thank you for the detailed and informative responses, everyone. It's clear to me now that I have to support both Keyboard/Mouse and a game controller (s), at the very least. In addition, all types of input have to be configurable with ability to save input configurations, of course, and an option to reset to defaults.

The next question I have is whether to use a third party input system for Unity, such as ReWired, or Unity's new input system. I have done some research into ReWired and I agree that it is superior to what Unity offers out of the box today. However, there is a new input system in the works for Unity, which sounds promising, and they should be releasing an experimental version this summer. Here is a link to their blog: https://blogs.unity3d.com/2016/04/12/developing-the-new-input-system-together-with-you/. In general, if Unity offers a certain feature out of the box, I prefer to use it over any alternative third party solutions, provided their functionalities are fairly similar. Any opinions on ReWired vs. this new input system?

Thank you for the detailed and informative responses, everyone. It's clear to me now that I have to support both Keyboard/Mouse and a game controller (s), at the very least. In addition, all types of input have to be configurable with ability to save input configurations, of course, and an option to reset to defaults.

The next question I have is whether to use a third party input system for Unity, such as ReWired, or Unity's new input system. I have done some research into ReWired and I agree that it is superior to what Unity offers out of the box today. However, there is a new input system in the works for Unity, which sounds promising, and they should be releasing an experimental version this summer. Here is a link to their blog: https://blogs.unity3d.com/2016/04/12/developing-the-new-input-system-together-with-you/. In general, if Unity offers a certain feature out of the box, I prefer to use it over any alternative third party solutions, provided their functionalities are fairly similar. Any opinions on ReWired vs. this new input system?

How long do you think it will take to make your project? Are you expecting to finish soon and be waiting on Unity's new input system? If you think you will take a while(learning Unity, long project, etc...) then by all means it may be worth trying to wait on Unity's new system. The catch is that you don't want to be waiting forever, just to find out you can't continue your project without committing to a certain input method.

Reminds me of my wait for the new UI system. It took several years longer than they promised and was in a shabby state out-of-the-box. 2 years on, it's pretty usable, but still with some unnecessary complexity and missing functionality. My advice is not to wait for official features. Use what is there now, migrate if new stuff appears and is better.

Some of the responses missed the part that this is about Unity.

While it has some flaws, Unity's input mapping system is quite capable. (Sometimes it is a bit tiresome, like mapping all XBox buttons for all controllers, but those are free to download).

With only a tiny bit of work you can configure the game to accept input from the keyboard, and from a controller, from a force feedback joystick, from a flight yoke, from alternative UI devices, whatever they want. If they want to remap arrow keys to WASD or IJKL or whatever they can do it. If they want to reverse up/down or left/right for their preferences they can do it. If they want some buttons one controller and alternate buttons for the commands on another controller, they can do it.

Set it up right and it doesn't matter what they use. All that matters to the game is that you have axis values and buttons for input.

If you need keyboard input it is slightly more difficult for non-keyboard configurations, but those are also handled fairly easily. There are plenty of tutorials on making a UI for keyboards that generate key events the same as regular keyboard events and also reading actual keyboards, then you can process them the same way. It gives the user the option to stay with their gamepad to type with their thumbs, or to start typing on their keyboard, or both.

TL;DR: It is Unity. It's easy to support both.

Would suggest using an asset store extension such as incontrol though, as control mapping from controller to controller will vary significantly natively and can be a burden to work with (and though Unity is quite capable, the axis configuration is still a mess to work with tbh).

But the TL;DR is pretty much on point: Why not do both given it shouldn't take you more than half a day to a day depending on the project's scope.

Reminds me of my wait for the new UI system. It took several years longer than they promised and was in a shabby state out-of-the-box. 2 years on, it's pretty usable, but still with some unnecessary complexity and missing functionality. My advice is not to wait for official features. Use what is there now, migrate if new stuff appears and is better.

That's great advice! Plus, if an input system is well designed, it shouldn't be too hard to switch from one system to another, if necessary. Good software design principles are universal, after all. Thanks for that.

@kburkhard84 It's unlikely it'd be finished soon, i.e. it'd probably take a while longer.