Currently implementing input support for a single player game and I'm unsure how best to handle the (admittedly odd) situation where the user plugs in 2 or more controllers. Should only one be active, or should they all control the character?

What I'm currently doing is the following:

  • If there are multiple connected when the game starts I just using the first one that's picked up.
  • If the user connects another controller I ignore it.
  • If the user disconnects a controller I pause the game and ask them to reconnect or press a key to drop back to keyboard/mouse controls.

But I'm wondering if this is reasonable. Should all controllers pass input to the character (this is going to be a nightmare for button mapping though, I'd need to implement some way of providing profiles for different controller types). If not, should I just allow the user to switch controller after disconnecting by pressing one of the buttons? Should a newly connected controller override the previous one?

There's just so many options here...


1 Answer 1


TL;DR - Ideally you should allow all controllers to open up your game's options menu and select the "Primary" controller (which can be defaulted to the first controller you see). That controller is the only one that can make changes to your game. If you detect that controller disconnecting, you can pause your game and open up the same options menu and ask the player to select another controller.

That being said, this problem can be solved multiple ways, and the more helpful answer would be to the question "How do I approach this kind of complex problem where all sorts of things can go wrong?"


When you run into a problem like this, it's often a good idea to list out the list of scenarios you can think of possibly occurring:

  • Your player has multiple controllers connected, but prefers the red one.
  • Two or more players are screwing around and trying to control the same game character all at once.
  • The controller runs out of battery while the player is playing.
  • Two players are taking turns playing your single-player game; they each have their own controllers.
  • etc.

Your real list will likely be longer, depending on how complicated or broad the case you're studying is.


Next, you want to prioritize these use cases. The unfortunate truth is that corner cases and user stupidity will have you outnumbered- you can only prepare for so many problems.

  1. Battery Runs Out
  2. Player wants to use on of multiple controllers

  1. Two players want to take turns using their own controllers
  2. Multiple people want to share the same character.

Notice first how the one the user had little control over (running out of battery) got prioritized, and the one that fits our game the least (multiple players controlling a game intended to be single-player) is at the end. Notice also how we drew a divider down the middle. This divider shows us items that are important enough to build into our game, and the items that go into our backlog of "nice to have" things.


Now let's solve the first scenario (Controller battery dying). Let's flesh out our fictional scenario:

  1. Little Timmy is playing your shiny new game, but his older brother forgot to charge the controller. Half-way through a boss fight, the controls stop responding.
  2. Little Timmy mashes the buttons for fifteen seconds as his character dies a horribly unresponsive death.
  3. Little Timmy finally looks down at the controller and realizes the lights are off- battery must be dead.
  4. Little Timmy is so frustrated that his careful boss-slaying plans have been thwarted by so cruel a fate, so he throws down the controller and vows never to play the game again.

Now Timmy could just get more batteries and retry the boss fight, but it actually doesn't hurt to assume the worst when starting out.

Now at this point there should be a little voice in your head saying "But wait, that's not how the story goes!" Good! Listen to that voice and see how we could change the story:

  1. Little Timmy is playing your shiny new game, but his older brother forgot to charge the controller. Half-way through a boss fight, the controls stop responding.
  2. The Game pauses and a screen opens up asking Timmy to check his controller.
  3. Timmy realizes the lights on the controller are off, and gets new batteries or plugs the controller in.
  4. Once the controller is working again, Timmy presses the "Continue" key and keeps playing.

This scenario has a much happier ending, but it can be improved- what if at step #3 we find out that Timmy is out of batteries? He has another (wired) controller on standby, but he can't use it since the game only 'sees' controller #1. We could run through the scenario a third time and say "Timmy picks up another controller and clicks "Continue"- the game uses this as the primary controller going forwards.

Again, you have to budget your time and choose how much time you want to spend helping Timmy with his wireless controller vs. building the actual game Timmy will be playing, but this technique allows you to iterate just as many times as you need.


If you find this technique useful and are interested in learning more about UX, you might consider looking at more advanced UX techniques such as formal UML use cases or Journey Mapping (but if you're just an indie developer, they may be overkill).

Let me know if that answers your question.

  • \$\begingroup\$ Thanks, that answers my question. I've already got it set up to fire off an event on controller disconnect that can be used to pause the game if needs be. I like the idea of being able to choose the active controller from the settings menu, I hadn't even considered that. Also thanks for the links, I've used UML before, but only for database architecture so that looks promising. :) \$\endgroup\$ Commented Dec 5, 2016 at 0:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .