When should you add controller compatibility?

Just a really generic game dev question. When making a game, at what stage should you be thinking about enabling a player/tester to use different inputs (keyboard, controller, etc.)?

Very early on, once you have fully working controls for the base input, or towards the end?

 

I get my games supporting all of my planned controllers from as early as possible. Getting feedback from players is important, and should be done in as close to real play conditions as possible.

For what it's worth, if you use something like Rewired then supporting multiple types of controller is trivial, because it separates buttons/axes from the actions you do with them.

 

Just make sure you abstract input properly and you can add it whenever you want

 

Immediately. Control is core to game design.

 

I generally agree. But, as a counterpoint, if you're still prototyping, you might not want to spend the time to set up controller support if there's a high chance that you'll dump the prototype anyway. This very much depends on your gameplay. If you're prototyping an action game like a platformer, definitely add it immediately because you need the feedback. But if you're prototyping a menu-based game like Papers Please or Balance of Power, it's a waste because that's not the focus of your prototype.


Side note for @Denisowator - If this is the game you're making with the Dialogue System, it has Rewired Support. If you're not using Rewired, the Dialogue System's Input Device Manager component will still gracefully handle switching between gamepad and mouse+keyboard using standard Unity Input, for the Dialogue System stuff at least.

 

I would say that you should add it fairly soon, especially if it's something that involves a large variety of control options. There's nothing quite like going from a keyboard to a gamepad to make you re-think your player experience.

 

It depends on the type of game. A title where controller-style input is core to the experience should have such support integrated immediately. A game where controllers are a secondary concern can probably wait until later in the process.

If you are a making an action-platformer, you should probably be integrating controller support in the prototyping phase. That style of game typically uses controllers and works best with controllers. (possibly even with analog stick controllers as a requirement) If you're making a point-and-click adventure game, controller support isn't nearly as central to the experience. That genre typically uses mouse pointer control, and adding controller support would probably be a secondary consideration.

Personally, I like to cook up a basic controller integration for most games, and re-use as much of it as I can for other games. Controllers are largely ubiquitous at this point, and should probably be included in any game's development.

 

Never, obviously.

 

This.

That's what you should do when you have any design challenge where you want a consistent API but might have different underlying structures.

For example, I have an object that I call my playerInputController, which is a member of my player object. In the code where I want to check if my player is pressing their jump button, I do m_inputController.jumpButtonState(). None of the code gives a crap about what jumpButtonState has to read, it just cares about the end result. So I was able to use a keyboard for most of development, but it was trivial to assign different input modes because I could just add new subclasses. It even allows me to have multiple controllers for split screen.

Think about exactly what your player character needs in order to react to the input. For example, you may be tempted to check the values of W,A,S and D, but what you really want is just a movement Vector2. I created a getMovementVector() function in my controller, the keyboard version does some checks on the WASD keys, but the xbox controller version checks the left thumbstick. Again, the playerController code doesn't care.

 

Exactly, I would probably abstract them to Commands though so in your case CheckCommand(Commands.Jump). With commands its also easy togo evejt driven and subscribe to command state changes. And abstract both rotation and translational movement into Vectors and delta rotetion etc.

 

It has nothing to do with the initial question. You guys are answering the 'how', not the 'if'. The question was if they supposed to put the code in there in the beginning. And the correct answer is somewhere around @TonyLi. Depends on the game-play. If the controls are secondary (walking sim, puzzle game, etc) than no, if the controls are primary (any kind of action game: shooter or platformer) then yes, definitely ASAP since it's vital part of the experience.

 

There aren't too many right answers in life.

 

I prototype with controllers if it's that sort of idea.