How to Add Gamepad Support Without Rewriting Input

Adding gamepad support to an existing mobile game takes two to five days when the input is properly abstracted, and two to five weeks when it is not. The difference is whether your game logic reads actions through an abstraction layer or directly from touch events. If it already goes through a single input service, adding gamepad is mostly mapping.

Why gamepad support matters for mobile

Three reasons to consider it.

1. Bluetooth controllers are common. A meaningful share of mobile players own one, especially in genres where precision matters: platformers, action games, racing.
2. It opens the tablet and TV market. Android TV and iPad with controller support are real audiences that require minimal additional work once gamepad input exists.
3. Some publishers prefer it. A build that supports both touch and gamepad demonstrates an input architecture that scales, which is a positive signal during evaluation.

The question is not whether gamepad support is valuable but whether it justifies the engineering time. The answer depends on how your input is currently structured.

Step one: audit your current input

Before writing any gamepad code, understand what you have.

Search your codebase for direct touch references. In Unity, look for Input.GetTouch, Input.touchCount, and any direct references to touch phases. In Godot, look for InputEventScreenTouch and InputEventScreenDrag.

Count the files. If touch input is referenced in three to five scripts, centralising it is a short task. If it appears in twenty scripts, the abstraction work is the real project and gamepad support is the easy part at the end.

Three patterns to look for.

• Touch in gameplay scripts. Moving the player by reading touch delta directly in the movement script. This needs to go through an abstraction layer.
• Touch in UI scripts. Buttons and menus using the engine's built-in UI system. These usually handle gamepad automatically with minimal changes.
• Touch in camera scripts. Pinch-to-zoom, drag-to-pan. These need gamepad equivalents mapped to stick input.

The input handling principles from Mobile Input Handling: Getting the Feel Right apply here. If your input already follows that structure, the gamepad addition is straightforward.

Step two: build the abstraction layer

The abstraction layer sits between your game logic and the input system. Game code asks for actions (move, jump, fire, pause). The abstraction layer figures out which physical input produced that action.

A simple version has three parts.

An action enum. Every input your game responds to, named by what it does rather than how it is triggered.

• MoveDirection
• PrimaryAction (tap, button A)
• SecondaryAction (swipe, button B)
• Pause
• Navigate (UI direction)
• Confirm (UI select)
• Back (UI back)

An input reader per device type. One for touch, one for gamepad. Each reader translates physical input into the action enum. The touch reader maps a tap to PrimaryAction. The gamepad reader maps button A to PrimaryAction. Same action, different source.

A single input service. Game scripts query this service, never the device directly. The service checks which input device is active and delegates to the right reader.

If your game logic never mentions "touch" or "gamepad," the input layer is properly abstracted. The game knows about actions, not about devices.

Step three: map the controls

Mapping is the decision about which physical input corresponds to which action. Most mobile games need a small number of mappings.

Two common complications.

Analog versus digital. A virtual joystick gives an analog direction and magnitude. A gamepad stick does the same. But a swipe or tap gives a binary direction. If your game uses swipe for movement, the gamepad mapping needs to decide whether the full analog range of the stick applies or whether it should be quantised to match the swipe feel.

Multi-touch gestures. Pinch-to-zoom, two-finger rotate, and similar gestures have no direct gamepad equivalent. Map these to shoulder buttons or stick combinations, and test whether the resulting control feels natural rather than bolted on.

Step four: handle UI navigation

UI is where most gamepad implementations stall, because mobile UI is designed for touch and has no concept of focus or selection.

Three changes make UI work with a gamepad.

1. Add a focus system. One UI element is "selected" at any time when a gamepad is active. The D-pad or stick moves the selection. The A button confirms. The B button goes back.
2. Highlight the focused element. A subtle outline or color shift that appears only when gamepad input is detected. Touch users never see it.
3. Handle the transition. When the player switches from gamepad to touch mid-session, the focus highlight disappears. When they press a gamepad button, it reappears on the last focused element or a sensible default.

Unity's EventSystem supports controller navigation with some setup. The key is setting explicit navigation links between selectable elements rather than relying on automatic navigation, which often picks the wrong target.

For custom UI elements that do not use the engine's built-in selectable system, you will need to implement the focus behaviour manually. Keep it simple: a list of selectable items, an index, and D-pad input that moves the index.

Step five: detect and switch input devices

The game should detect which input device is active and adjust automatically.

Detection. Check for gamepad connection on startup and listen for connect and disconnect events. When any gamepad button is pressed, switch to gamepad mode. When any touch event fires, switch back to touch mode.

What changes between modes. The virtual joystick and on-screen buttons should hide when a gamepad is connected and show when it disconnects. The focus system activates in gamepad mode and deactivates in touch mode.

What does not change. Gameplay logic stays identical. The abstraction layer handles the translation. The game never checks which mode it is in; it just reads actions.

Two edge cases to handle.

• Gamepad disconnects mid-game. Show the virtual controls immediately and optionally pause. A player who loses input during gameplay will leave a bad review.
• Multiple gamepads. For a single-player mobile game, ignore all but the first connected gamepad. Supporting multiple controllers is a multiplayer feature and a separate scope item.

Testing gamepad support

Test with at least two physical controllers.

Emulators and on-screen gamepad simulators catch some issues but miss the feel. A cheap Bluetooth controller is worth the twenty dollars.

What we would do

Start with the input audit. Count the files that reference touch directly. If it is under ten, the abstraction work is a one to two day task. If it is over twenty, schedule the abstraction as its own milestone before considering gamepad.

Build the abstraction layer first, verify the game works identically through it on touch, and then add the gamepad reader. This order ensures you do not break touch input while adding gamepad, which is the most common failure mode.

Test the UI navigation last, because it is the most tedious part and it benefits from having the input layer finished and stable.

The short version

• Adding gamepad takes days with an abstraction layer and weeks without one.
• Audit your codebase for direct touch references before starting.
• Build an action-based abstraction: game logic reads actions, not devices.
• Map actions to both touch and gamepad equivalents in a clear table.
• Add a focus system for UI navigation and handle the touch-to-gamepad transition.
• Test with two physical controllers and test the disconnect scenario.

Audit your input code this week. If you need help adding gamepad support to an existing mobile game, send us the build.

Related reading: Mobile Input Handling: Getting the Feel Right, Unity UI Performance on Mobile, and Android Device Fragmentation Guide.