If you were going to pick a game to cut your teeth on online multiplayer, you probably wouldn't pick one where both players control the same character – and timing is everything.
Tentacle Tango puts two players inside a single character controller: two octopi physically connected, spinning through obstacle-filled levels where every button press matters to the millisecond. When one player moves, the other client has to receive that input and execute it at precisely the right frame. Miss by a few frames and the character snaps back to where it was. The whole feel of the game falls apart immediately.
Cable Nest knew this and they did it anyway.
"It felt very outside our comfort zone," said Fredrik Claw, the lead developer on Tentacle Tango. "We hadn't shipped anything multiplayer before."
Cable Nest is the console and PC brand of Gro Play, a Swedish studio based in Stockholm. Gro Play has spent fifteen years making kids' games for mobile. Cable Nest was created as a separate brand to make something different: games for Steam, Nintendo Switch, and older players who want a real challenge.
Tentacle Tango started as a game jam prototype by Fredrik. The team count fluctuated naturally during development, but the core team was Fredrik as the sole programmer, one artist, and one game designer. Around ten people work at the studio overall.
The game was built from the start as local co-op but, about halfway through development, the plans changed.
"We decided that to spread wider and get a bigger audience, we need to make it online," said Henrik Sallander, co-founder and CTO at Gro Play. "It turned out to be more than a couple of months of additional development, but I think the outcome is really good. It's a really tight online experience."
Another developer at the studio had already been prototyping with coherence on a separate project. That was enough of a signal to start. Fredrik picked it up. A basic connection was working within a few hours, input syncing in another day or two.
Then the real problem arrived.
Most multiplayer architectures assume each player owns their own character. One client, one player, one set of game objects to sync. Tentacle Tango doesn't work that way, and this turns out to matter quite a lot.
Both players simultaneously influence the same character controller. The two octopi are physically connected. When one player rotates the pair, the other player's position changes too. There is no clean separation between "player one's objects" and "player two's objects." There is one shared simulation with both players acting on it at the same time.
Fredrik's first attempt was an authority assignment. The player actively pressing a button gets authority over the shared controller. When they release, authority transfers to the other player. On paper, clean enough.
In practice, a game built around precise timing got hit hard by the lag inherent to online multiplayer.. With authority swapping, timing-critical inputs arrived from the non-authoritative client, traveled across the connection, and landed on the authoritative client several frames too late. The local simulation had already moved past the intended position. It had to roll back. Characters teleported and restarted animations. Anyone who has spent time debugging this kind of networking behaviour knows exactly how Fredrik felt about it.
"You sent an input, but the other person would receive it too late," said Fredrik. "Then we would have to roll back gameplay frames because they wanted to stop somewhere, but the character had already gone past that point." The result? A jittery mess on screen.
He tried local input delay next: adding artificial lag to the local client to bring both sides closer to in sync. It helped a little. But artificial delay in a timing-critical game is just moving the problem around, not solving it.
"We were halfway toward a GGPO solution," said Fredrik. "We might as well just do the proper thing."
He spent the next two weeks trying to build his own rollback netcode implementation from scratch.
Then he got on a call with the coherence team.
Somewhere in that call, it came up: coherence already had GGPO built in.
"I spent like two weeks trying to make my own GGPO thing," said Fredrik. "Then we had a meeting with you guys, and one thing that came up was that you have a GGPO solution. So we started using that instead."
Two weeks of head-scratching solved by a single video call. These things happen.
The GGPO support was experimental at the time, not officially featured. Henrik had spotted a mention of it in the forums. A coherence developer named Benito pointed them toward it directly in a follow-up conversation.
"He told us about this GGPO support that you guys had, but it wasn't official," said Henrik. "It was kind of experimental in the documentation. We tried it and found, okay, now the timing feels really tight."
For anyone not familiar with how GGPO works: instead of syncing game state across clients, it syncs only inputs. Each client runs its own full simulation locally. There’s an imperceptible input buffer before inputs get executed. This is what creates space for syncing corrections. When an input arrives from the other player, both simulations execute it at the same frame and should arrive at the same result. When inputs arrive late, the GGPO buffer will re-order them in the correct sequence before the on-screen action is allowed to proceed, and the lag effect is completely hidden from players. Done well, this produces a tight, responsive feel that state-sync approaches genuinely struggle to achieve in timing-critical games.
For Tentacle Tango specifically, the shared character controller stopped being a liability. GGPO doesn't care that both players are influencing the same object. It only cares that both clients receive all inputs and execute them at the same frame. The framework handled the rollback. The teleporting was gone.
Now the actual work could begin.
GGPO works on one assumption that does not come for free in Unity: determinism. Both clients are running independent simulations and must arrive at identical results from identical inputs. Any divergence and the simulations drift apart, producing completely different game states from the same input history. The further they run without correction, the further apart they get.
Most Unity games are not deterministic by default. Floating point arithmetic can produce slightly different results depending on hardware and compiler settings. Execution order for components can vary. Physics calculations can diverge. For a simple game this might be imperceptible. For Tentacle Tango, every system in the game had to be audited and fixed to produce identical results on two separate machines simultaneously.
That is a lot of game systems to audit.
"The difficult part was actually to get our game to be deterministic," said Henrik. "It took longer than we thought. All the different bosses, all the different obstacles that can occur in the game."
It’s worth being clear about what this means for anyone evaluating rollback netcode: this work belongs to the game, not the framework. It is the inherent cost of GGPO regardless of which tool provides it. coherence handled the rollback machinery. The determinism grind was on Cable Nest.
Fredrik's description of his day-to-day during this phase is telling:
"Most of the work was implementing the rollbacks of different mechanics and making them deterministic. We only used coherence to send the inputs back and forth, and that was about it."
Henrik put it plainly: "The coherence part works really well. It just syncs these GGPO things." The hard part was... everything else.
Tentacle Tango uses different networking approaches in different parts of the game, which is worth knowing if you're thinking about something similar.
The main gameplay levels use GGPO entirely. Inputs are synced. Both clients simulate locally. Rollbacks correct divergences. This is the timing-critical section where the shared character controller creates the networking challenge, and GGPO is the right tool for it.
The overworld map, a Mario-style level select screen where players move between stages, does not need the same approach. No shared controller edge cases, no timing-critical input windows. Fredrik handled it with standard coherence commands: sending state over the network the conventional way. Less infrastructure, less complexity, more appropriate for what that part of the game actually needs.
This is worth flagging for anyone evaluating rollback netcode: GGPO has a real setup cost, both in the initial implementation and in the determinism work that follows. For parts of your game where the timing requirements don't demand it, simpler approaches work fine alongside it. You don't have to go all the way down.
"When everything is hooked up and the inputs are sent, I don't really need to think about the networking anymore," said Fredrik. "I can just focus on the actual game."
This is easy to miss, but it's a significant observation for anyone who has worked on a conventional state-sync multiplayer game. In a typical online game, the networking layer is always present somewhere in your thinking: which objects are synced, at what frequency, what happens during host migration, what's the bandwidth budget, why is this component drifting. It occupies mental space the whole time.
With GGPO handling rollback and coherence handling the input transport, Fredrik's networking surface area collapsed to a single question: are both clients receiving all inputs at the right frames? Once that was working, the rest of development felt like building a single-player game.
When Cable Nest moved toward their Nintendo Switch release, Henrik reached out to the coherence team with questions about platform-specific implementation requirements. The response was fast and direct. Mathias, an award-winning game developer himself, and a senior engineer at coherence, worked through it with him, sent the code he needed, and then turned the whole conversation into a full documentation article on Switch integration so future developers wouldn't have to start from the same place.
For Henrik, that interaction was consistent with how things had felt throughout the project.
"We noticed that the people who actually answer in the forums, it's not some outsider," said Henrik. "It's the actual coherence development team. That was a good sign."
For Henrik, the evaluation is over. coherence is not a project-by-project decision at Cable Nest anymore. It is the default.
"We want to use coherence in all our projects, basically," said Henrik. "So we can learn from each project and improve from that."
That compounding effect matters for a small studio. A developer who has worked through GGPO and determinism on one title is meaningfully faster on the next one. The knowledge transfers. The studio is actively building that shared fluency across games.
Tentacle Tango was Cable Nest's first shipped online multiplayer game. They picked a hard problem for a first attempt: timing-critical shared controller, no networking specialists, online added mid-development to a game already in flight. They worked through dead ends, rebuilt around GGPO, and spent weeks making game systems deterministic one at a time. The networking layer, once it was doing its job, stayed out of the way.
"When everything is hooked up and the inputs are sent, I don't really need to think about the networking anymore," said Fredrik. "I can just focus on the actual game."
That is the outcome worth chasing. For Cable Nest, it turned out to be exactly what was available.
Tentacle Tango is available now on Steam. A Nintendo Switch release is planned. Follow Cable Nest on YouTube, Instagram, and TikTok for gameplay and speedrun content.
coherence is a multiplayer networking engine and co-development studio built by a team of veterans from DICE, CD Projekt Red, Crytek, Ubisoft, Blizzard, and Playdead. Studios use coherence to add or build online multiplayer in Unity without rewriting their games. For more, visit coherence.io.
Written By
