Chaos in Sync: How Roadside Research Became a Physics-Driven Co-Op Hit with Photon Multiplayer

What happens when you mix a gas station simulator with stealthy alien deception and throw in four players? You get Roadside Research by Cybernatic Walrus, a uniquely chaotic co-op experience where teamwork, physics, and unpredictability collide.

From day one, the developers made a bold decision: this wouldn’t be a solitary simulation, but a shared experience built around collaboration and emergent chaos. That choice shaped everything, from networking architecture to gameplay design. By leaning into Photon Fusion, the team avoided the usual pitfalls of multiplayer development and focused instead on what matters most: creating fun, unpredictable player interactions.

This interview dives into the technical backbone behind that experience. How physics replication, AI authority, and bandwidth constraints were handled and what it takes to ship a multiplayer simulation that “just works” across devices and network conditions. As with many successful multiplayer stories, the real narrative isn’t just about features, but about solving complex problems in a way that lets gameplay shine.

Key Takeaways

Multiplayer-first design pays off
Building the game around co-op from the start simplified architectural decisions and ensured systems naturally supported shared gameplay.

Efficient physics synchronization is key
Using Photon’s physics tools and input authority allowed consistent object behavior across clients without excessive bandwidth usage.

Optimize data transfer, don’t over-sync
Smart handling of user-generated content (compression, caching, hashing) avoided unnecessary real-time replication and reduced network load.

Balanced authority improves player experience
Combining client-side validation with host-driven AI created responsive gameplay while maintaining consistency across players.

Scalable infrastructure removes launch pressure
Photon Cloud handled high concurrency seamlessly, freeing the team from backend concerns and allowing full focus on gameplay.

To kick things off, Roadside Research blends a gas station simulation with a stealth-based alien invasion theme. From a technical standpoint, at what stage in development did you decide this needed to be a 4-player co-op experience rather than a solo sim, and what were the immediate architectural challenges in synchronizing that ‘chaotic joy’ for multiple clients?

This was already for the start. We set the goal that whatever we would make needed to be co-op multiplayer. Limiting it to 4 players was based on the roles for each player within the game. Since we were not going for a competitive game it made it clear to us we should aim for the game to be peer to peer but since it also uses physics we wanted to use an engine that could handle this without us having to do all the heavy lifting ourselves.

The game relies heavily on tactile interaction, restocking shelves, pumping gas, and placing over 25 customizable items around the station. How did you approach the replication of these physics-based objects? Specifically, how do you ensure that when Player A knocks over a display, Player B sees the exact same mess in the same tick without flooding the bandwidth?

We rely on the physics addon provided by Photon to perform physics simulation on both ends. The next step was ensuring that we properly control input authority when carrying items so the player in charge of an item has a smooth experience with the other clients simply showing expected behaviour.

One of the community’s favorite features is the ability to literally draw ‘human’ expressions on the alien disguises. Technically speaking, how did you handle the data transfer for this user-generated content? Replicating texture or vector data in real-time across a lobby seems like an optimization hurdle. How did you solve it?

We didn’t, there is no realtime aspect to it, which helps a lot.

Because players lock in their mask when they join, we can rely on the joining events and spawning delay to send over the data to everyone, we limit the image size and apply compression to send the image to everyone who is connected. 

And we save a copy of that image in memory and identify it with a hash so we don’t resend it if that player already has a hash of that image in their own local cache.

You have a unique mechanic where customers have a ‘Suspicion Meter’ that reacts to player behavior. In a peer-to-peer or host-client environment, managing AI ownership can be tricky. How do you handle the state authority for these NPCs to ensure they don’t desync or react to a player who isn’t actually near them on their own screen?

When it comes to detection when performing certain suspicious actions, we actually collect the detection data for the client performing the action and streamline it before we send it along with the action if needed back to the host. This ensures that a client isn’t spotted by an unseen NPC who might have been behind the corner of a building because we assume that the client is the source of truth here.

Beyond that, all Ai logic is run on the host with Network Transforms and Network Animators doing the heavy lifting of ensuring the correct animation is playing on all sides.

Reviews have highlighted that Roadside Research is a ‘go-to’ on handheld PCs like the Legion Go. These devices often rely on variable Wi-Fi connections. Did you have to utilize specific lag compensation or client-side prediction techniques to ensure the simulation remained smooth on handhelds where packet loss might be higher?

So far we have not experienced a lot of issues. Connections seem generally stable, we did opt for client-host instead of shared authority to attempt to benefit from the potential p2p connections. Although so far it does seem to not always work as smoothly as expected.

Selling over 330k copies is a massive milestone, but it of course comes with a surge in Concurrent Users (CCU). Can you walk us through the launch window from a backend perspective? Did you have to adjust your matchmaking logic or room capacities to handle the sudden scale?

Not really, I did reach out to the lovely people at Photon before the launch as we know this would bring in some big CCU as we also had a game pass deal on top of the steam launch. They assured us that their servers could take care of it. So we did not need to limit anything.

You’ve committed to ‘large systems-wide updates every 3-4 months’ during Early Access. When you are pushing updates that alter core mechanics, like the recent addition of choosing the number of alien toes, how do you manage version compatibility in your networking stack to prevent fragmenting your player base?

At the time of writing we don’t yet! Although with our upcoming update we are going to be introducing a networking version number to ensure users with different versions get a clean message informing them of a mismatched version. It does help that steam has really clean near instant publishing of new builds and that Microsoft’s platforms force updates.

Simulation games are notoriously data-heavy due to the sheer number of interactable entities. In tuning your netcode, how did you balance the need for ‘Full Consistency’ (where everything is perfect) versus ‘Eventual Consistency’ to save CPU cycles and bandwidth? Did you have to write custom interest management for items inside the shop versus outside at the pumps?

We currently don’t really handle a lot of these situations. The things to keep in mind though is that the number of items on shelves is pretty much condensed into an ID and a count and that we have a pretty space to play without many additional things to interact with. A single shelf of 9 products doesn’t take a lot of bandwidth when just updating when a player stacks it or when a customer takes a product.

Looking back at the prototype phase, what was the biggest technical pitfall you encountered when networking a simulation game? If you could give one piece of advice to a studio going into multiplayer using a state-sync engine, what would it be?

Really dig into the differences between the available Topologies. It makes all the difference for the gameplay. Especially digging into the differences between shared and client-host. If your game is not a competitive game, you can be a lot more relaxed in how accurate your predictions are.

Your roadmap mentions expanding ‘multiplayer interactions’ and adding new alien tech. Without spoiling too much, does this involve more complex networked physics or new ways for players to interact with the shared world, and how are you preparing the codebase for that expansion?

Most of the things we want to implement already exist in some way or another in the game. We want to leverage motions and mechanics the player is familiar with and build on those. So for now we don’t have a lot of brand-new networking code to add. Preparing the codebase for us mostly entails rewriting some existing mechanics to function in a more generic way after maybe being too specific coming from the original prototype implementation.

Conclusion

What stands out most in this story is how pragmatic the development approach was. Instead of chasing perfect synchronization or over-engineering systems, the team at Cybernatic Walrus consistently made decisions that balanced effort, performance, and player experience. Whether it’s delegating authority between client and host, simplifying data replication, or postponing versioning until it becomes necessary, the approach is iterative and grounded in real production needs.

Photon played a supporting role in that process by handling the parts that would otherwise require significant engineering time, network transport, scaling, and core synchronization, allowing the developer to stay focused on gameplay and system design. This reflects a broader reality in multiplayer development: reducing technical overhead often has a direct impact on how quickly and confidently teams can ship and iterate.

As the team summarizes it:

“We were familiar with Photon from working with it on projects before Roadside Research. But to us it is pretty clear that they kept evolving into what we would consider a very robust networking layer that supports just about any game you would like to make with it.”

Looking ahead, the focus remains on refining existing systems rather than expanding complexity. That includes generalizing mechanics that started as prototype implementations and improving structure where needed. It’s a continuation of the same mindset seen throughout development: solve the problem in front of you, keep systems flexible, and evolve the codebase as the game grows.