Ahmetovic et al.: Handing half your controller to someone else — Fukai Reads

TL;DR

For people with limited hand or arm movement, a game controller can be a wall. It is especially high when a game demands many inputs in quick succession. Four researchers at the University of Milan asked whether that wall can be lowered by splitting the controls between two parties. Thirteen participants played Rocket League while handing part of their control to a human copilot in one session, and to a software copilot in another.

Seven of the thirteen said they would not have been able to play the game without such support. How much they kept for themselves varied widely: eleven kept steering, nine kept acceleration, six kept boosting. There is no single correct split, and that is the most practical finding in the paper.

The interesting part is how it fails. Participants repeatedly mistook the copilot's actions for their own. The paper calls this collaboration confusion, and argues that a software copilot must make clear what it just did and why.

About this paper

Today's paper is "Video Game Accessibility through Shared Control for People with Upper-Limb Impairments." The authors are Dragan Ahmetovic, Matteo Manzoni, Filippo Corti and Sergio Mascetti, all of the Department of Computer Science at the Università degli Studi di Milano.

It sits on arXiv as arXiv:2601.11218v2 [cs.HC], with a stamp dated 1 May 2026. Neither the body nor the footnotes name a conference or journal, so I treat it as a preprint whose peer review I could not confirm. That said, the same four authors published the study that precedes this one in the CHI 2026 proceedings (DOI 10.1145/3772318.3791080). This is a group working steadily in the area.

I picked it for two reasons. First, this series had not yet covered accessibility research. Second, the idea at its centre — splitting the controls between two parties — looks continuous with hint systems and difficulty settings in puzzle games. Reading it only as "research for disabled players" narrows the view too much. The question of how much help you can give before you take the play away belongs to every game.

What was already known

The paper groups earlier work on making games playable for people with upper-limb impairments into three approaches. The first is input remapping: reassigning buttons through in-game settings or external tools. The second is alternative controllers — pads that work one-handed, sit flat on a surface, or accept swappable parts.

The third is alternative modalities, such as voice commands or facial expressions. The paper notes that all three share a weakness. None of them reduces the number of inputs the game asks for, and none relaxes the speed it asks for them. They change how the hand works, not how much work the game demands.

This is why shared control has drawn attention: hand part of the job to someone else. Consoles already ship with it. Xbox Copilot and PlayStation Share Play both let two controllers act as one player. But of course, that requires another person in the room.

The other route is partial automation, where a piece of software plays the assistant. Research prototypes exist (Dino Dash, Dozo Quest, Zac - O Esquilo), and commercial games ship narrow versions of it as aim assist or steering assist. The paper's verdict: "partial automation solutions discussed above are all specifically designed and implemented for each considered video game, thus lacking generalizability." Every title needs its own bespoke build, and that was the dead end.

Against that dead end the authors set three questions. How do players perceive gaming in human cooperation and in partial automation? How do players collaborate in each, and how do the two differ? And what functionalities should partial automation provide to assist players with upper-limb impairments? The third is the one that matters most to people who build games.Celeste. Its assist mode is a standard reference point for support built into a game. This paper does not discuss the title; I place it here only as an anchor for thinking about help and difficulty. Image from the Steam store page.

How they studied it

The authors first built a framework of their own, GamePals. Rather than modifying a particular game, it intercepts controller signals and merges them, so it works with off-the-shelf commercial titles. That is the main departure from earlier prototypes.

GamePals has four parts. A command interpreter turns each player's raw input into game actions, and each player can carry their own remapping. A command arbitrator merges the actions arriving from several humans (and an agent) into one stream, following a configurable policy. A virtual controller then sends the merged result to the game as ordinary controller input. In partial automation, a game state reader and an agent are added.(Diagram) The GamePals pipeline. Pilot and copilot inputs are merged by an arbitrator and reach the game through a virtual controller. The copilot may be a human or a piece of software.

The game was Rocket League — football played with cars — chosen because its goal is obvious at a glance and it can be learned quickly. Participants played 1v1 matches against game-controlled bots: one match with a human copilot, one with a software copilot, roughly five minutes each. The order was counterbalanced across participants to cancel out ordering effects.

Thirteen participants with upper-limb impairments took part; the paper states that thirteen met the recruitment criteria. The conditions were varied: SMA type 2, Duchenne muscular dystrophy, Becker muscular dystrophy, merosin deficiency, FSHD, tetraplegia, spastic tetraparesis, amyotrophy, amputation of hands and legs, and reduced arm mobility. One further participant, who completed neither session because of motion sickness, was excluded from the analysis.

Before the matches came a configuration phase. Each participant decided which game actions to keep and which to hand over. They also chose between a standard Xbox controller and an Xbox Adaptive Controller with optional Logitech accessories, and were free to remap buttons. That act of deciding for themselves turns out to matter later.

The team recorded screen capture, ambient audio and the input logs of both parties, then combined them into augmented videos showing both controllers' states at once. Semi-structured interviews followed, and the transcripts were analysed with reflexive thematic analysis (a qualitative method in which the analyst reads and re-reads the material to build up the themes that recur in it).

What they found

First, whether the support worked at all. Of the thirteen, seven (P3, P6, P8, P9, P11, P12, P13) "reported that they would not have been able to play without such support," in the paper's words. The remaining six agreed it would have been harder. P1's remark stays with me: they could have played alone, "though it probably would've been harder at first and maybe not in the way I like to play. After a while, I think it might become a bit frustrating."

So the question is not only playable versus unplayable. There is a state just short of that: playable, but not in the way you want to play. Anyone designing difficulty options is dealing with the same distinction.

Second, what participants kept for themselves. According to Table 4, eleven kept steering (everyone except P12 and P13), nine kept accelerating, six kept boosting, five kept braking, four kept jumping and two kept the handbrake. It is not a clean ranking; the combinations differ from person to person.

Their backgrounds differ too. The paper notes that "Console/PC gamers (P1, P2, P4, P5, P7, P10, P11) generally kept three or more game actions under their control," while mobile-first players tended to keep two or fewer. What decides how much you hand over is not only the severity of the impairment but the games you have played before.

Third, and most interesting to me, collaboration confusion. It takes two shapes. One is false causation: attributing to yourself a movement the copilot produced. The other is unexpected action: the copilot does something you did not see coming, and you lose track of who is holding what. The confusion familiar from people working alongside automated machinery turns up inside the game.

Fourth, how the two coordinate. Two productive patterns appeared: synergising, where both contributions combine into one move, and correction, where the copilot catches and fixes the pilot's mistake. With a human copilot, participants talked to each other and anticipated the partner's next move. There were also stretches where the two pulled against each other and cancelled out.

And one awkward finding. The better the software copilot played, the more helpful it was — but participants sometimes felt overshadowed by it. A human copilot brought sociality and reassurance, at the cost of depending on someone. A software copilot brought independence, at the cost of being harder to predict. The authors do not resolve this into a preference for either.

What builders can take from it

The study uses Rocket League, an action title, but much of it carries over to puzzles. Here are some concrete applications. These are my own extrapolations, not claims made by the paper.

(1) Design hints as taking over an action, not as giving an answer. In a Sokoban-like, instead of revealing the solution, offer to put one crate back in the right place. Just as participants kept different sets of actions, players differ in which part they want taken off their hands. When you tier a hint system, you can grade it by scope of action, not only by amount of information.

(2) Let the player choose the support. The configuration phase in this study is a usable template. Rather than bundling everything into easy/normal/hard, expose separate switches: remove the timer, make undo unlimited, loosen input timing. In the study, those choices diverged sharply between people.

(3) Always show what the automation did. That is the lesson of collaboration confusion. If a puzzle game offers to advance one move for you, animate that move, log it, and let it be undone. A board that changes silently is the worst case. The same applies to auto-tidy features in casual games: a board that cleans itself breaks the player's model of it.

(4) Rebuild two-players-one-character play as an accessibility feature. Games where one controller drives two characters already exist. Implement that split as "you can hand one half to someone else" rather than as a difficulty gimmick, and it becomes an accessibility feature outright. It is worth considering a copilot who is not in the same room.Brothers - A Tale of Two Sons, where the two halves of a single controller drive two brothers at once. The paper does not discuss it; I use it as a legible example of splitting control in two. Image from the Steam store page.

(5) Make the strength of assistance adjustable mid-play. The paper argues that support levels should not be fixed but should adapt to the player. In a puzzle game, you could raise or lower assistance according to how long someone has been stuck. Change it silently, though, and you recreate problem (3) — so the change has to be announced.

Limits

The authors list six limitations. The first is the framework itself: GamePals only works with controller-based games, leaving mouse-and-keyboard titles out. Given how many puzzle games are played with a mouse, that is not a small gap.

Second, only one software copilot was used — a single pre-trained bot — so there is no evidence it would behave the same way in another genre. Third, the participant sample: thirteen people spanning a wide range of impairment types and severities. The authors themselves urge caution about generalising.

Fourth, the short exposure. Around ten minutes in total cannot show how someone adapts over a long session or how their preferences shift. Fifth, there was a single human copilot, whose skill and personality are mixed into the results. Sixth, the effect of the initial configuration went underexplored; iterative refinement might have changed the outcome. The analysis is also confined to single 1v1 matches, so it says nothing about longer play or larger groups.

From here on, these are points I noticed as a reader. First, whether someone could play is measured largely by self-report. There are almost no numbers for score or success rate. That is consistent with a qualitative study, but it makes the results hard to compare against other interventions.

Second, the human copilot was the study supervisor. Facing an experimenter, a participant may hold back, or may feel unusually safe. Playing with a friend or a family member need not produce the same result. Third, because the game is Rocket League, nothing here predicts what would happen in an unhurried puzzle game. It is possible that the support worked precisely because the title demanded fast, repeated inputs.

How Fukai reads it

I want to place this study in a longer movement: the dismantling of difficulty as a single dial. Difficulty settings have traditionally moved values inside the game — enemy strength, time limits. What this paper moves is the range of actions the player takes on. Recomposing who holds what is less a difficulty adjustment than a division of labour. And precisely because it is a division of labour, the side effect surfaces directly: it can damage the sense that you did it. Designing support is designing help, and at the same time designing where the credit lands. That is how I read this paper.

In closing

If you want to go deeper, read the preceding paper by the same four authors, presented at CHI 2026. It studies the human-to-human cooperation that already happens today, and this one continues from it. Read side by side, they map where the group has come from and where it is heading.

This series has also covered work on the relationship between difficulty and motivation, which is useful for thinking about how a player's sense of accomplishment moves when support is added. There is a separate article on hint systems in puzzle games for anyone who wants to get down to implementation.

Sources

Papers and materials referenced in this article:

・Video Game Accessibility through Shared Control for People with Upper-Limb Impairments (Dragan Ahmetovic, Matteo Manzoni, Filippo Corti, Sergio Mascetti, 2026, arXiv:2601.11218v2 [cs.HC] — preprint)

・The full text was read in the arXiv HTML version (v2).

・Related work by the same group: Shared Control for Game Accessibility: Understanding Current Human Cooperation Practices to Inform the Design of Partial Automation Solutions (Ahmetovic et al., CHI 2026, DOI 10.1145/3772318.3791080)

・Related articles on this site: Designing hint systems / Lu et al. on difficulty, effort and flow / The philosophy of Maddy Thorson / Brothers - A Tale of Two Sons

・Images are from the Steam store pages of Celeste and Brothers - A Tale of Two Sons. Neither title is discussed in the paper; they appear here to make the topic legible. The single diagram was made for this article.