How Bandit Trap Built Physics-Driven 3v1 Multiplayer with Photon Quantum

Building a multiplayer party game is difficult enough when every player shares the same goals, abilities, and view of the match. Bandit Trap adds another layer of complexity by making the experience asymmetrical. Three Bandits work together to steal loot, while one Trapper uses traps, tools, and environmental hazards to stop them.

For Picomy, the challenge was not only designing a slapstick, family-friendly take on the “1 vs. others” structure. The team also had to make destructible environments, water and ice propagation, role asymmetry, cross-platform support, and competitive match balance work reliably online.

That required a networking foundation that could keep gameplay fair and responsive without forcing a small team to build and maintain complex synchronization systems from scratch. After experimenting with different approaches, Picomy chose Photon Quantum for Bandit Trap.

Quantum’s deterministic simulation allowed the team to focus more of its engineering time on gameplay, tools, debugging, and balancing. Features created inside the simulation worked online by design, while deterministic replays made it possible to reproduce rare gameplay bugs with complete accuracy.

The result is a physics-heavy, chaotic multiplayer game that stays grounded in technical discipline: clear simulation boundaries, careful performance tradeoffs, extensive playtesting, and a networking architecture chosen early enough to support the entire production.

Key Takeaways

Quantum made a small-team production feasible
Bandit Trap was initially developed by one programmer, with a second programmer joining later for bot behavior. Without Quantum, Picomy says a game of this scope would not have been realistic for a team of that size.

Deterministic replays changed the debugging workflow
By storing replays after every match, the team could reproduce rare gameplay bugs inside the editor with 100% accuracy, identify root causes, and verify fixes using the exact same recorded match.

Not everything belongs inside the simulation
Core gameplay systems lived inside Quantum, but expensive or purely cosmetic elements, such as shard physics and visual Bandit damage, remained in the Unity view layer.

Asymmetry required constant balance work
Designing one Trapper against three Bandits meant every tool, trap, and countermeasure could shift the whole match dynamic. Picomy relied on extensive playtesting and win-rate monitoring to tune the experience.

Cross-platform consistency depended on early pipeline decisions
The team generated Quantum data once through its backend and distributed the same data across all platform builds, helping avoid desynchronization issues across platforms.

Gameplay felt close to local multiplayer
With Photon Quantum, Picomy could develop gameplay in a way that felt similar to building a local multiplayer game. That reduced networking overhead, saved development time, and made Bandit Trap feasible for a small team without a dedicated network programmer. 

Picomy has worked across very different projects, from Heroki and Monomals to Bandit Trap. What technical or production lessons from those earlier games carried over into building your first large-scale online multiplayer title?

To be fair, we had to do a lot of research and learn many new things for Bandit Trap. Heroki and Monomals were built using our proprietary Picon Engine, but for Bandit Trap we decided to move to Unity because we knew we needed a robust networking solution and simply didn’t have the experience or resources to build one ourselves.

That said, our first two in-house titles helped us establish a production workflow that was highly optimized for our team. We carried many of those workflows over into Unity, although we did have to develop new tools and technology to make that possible.

Bandit Trap takes the asymmetrical “1 vs. others” structure and moves it away from horror into slapstick, family-friendly chaos. How did that design decision (asymmetry) influence both the game design and user experience aspects of it as now you have to showcase two “different” games to the players at the same time.

Moving away from the typical horror-themed asymmetrical experience was a very deliberate choice. Creating games that can be enjoyed by the whole family has always been part of our studio’s identity. We’ve always loved asymmetrical games like Nintendo Land and Dead by Daylight, and even movies like Home Alone, which in many ways also capture that asymmetrical dynamic.

Designing the game around asymmetry had a huge impact on both gameplay and user experience. You are essentially building two different experiences that need to feel equally fun and rewarding. On top of that, asymmetrical games are inherently difficult to balance. Balancing the Trapper against the Bandits remained an ongoing process throughout development, and we’re very happy with how that balance turned out in the end.

From an engineering standpoint, what were the hardest systems to make work together: destructible environments, trapper/bandit role asymmetry, something else entirely?

One of the most technically complex features was definitely the fully destructible environments. Every wall in every room can break apart into tiny pieces, and even the smallest hole can allow water to flow from one room to another. On top of that, the water can freeze into ice and propagate across connected surfaces.

It took us a few tries before we landed on the final design. We quickly realized we wanted to use pre-calculated shard pieces for the destructible environments, but we also discovered that Photon Quantum did not support mesh colliders for dynamic or movable entities. That meant we had to rely on primitive colliders that approximated the shard shapes as closely as possible.

To solve this, we developed an algorithm that divided the destructible environments into a grid and tracked which parts of the mesh were no longer present. From there, we recalculated the collision shape by analyzing which grid cells were still occupied.

We also discovered early on that simulating every broken shard with physics inside the deterministic simulation was far too expensive for our CPU budget. Instead, we moved the actual shard physics to the view layer. When a shard breaks off, that rigid body is simulated locally using the Unity physics engine rather than inside Quantum. This means the shards themselves are not network synchronized, but since they have no gameplay impact and disappear after a few seconds anyway, it ended up being a very reasonable tradeoff.

At what point did you decide that Bandit Trap needed a deterministic multiplayer foundation, and what made Photon Quantum the right fit for the kind of physics-driven, 3v1 game you were building?

Early in development we experimented with several networking solutions, including Photon PUN. We quickly realized that Bandit Trap benefited enormously from a networking model that felt fair and responsive, especially because the gameplay can become very competitive between the Bandits and the Trapper. It felt frustrating when actions or hits failed because of poor network conditions.

The game also originally started as a mobile title, which made network reliability even more important.

What really stood out about Quantum, though, was how much easier it made feature development. In most cases, we didn’t have to constantly think about how to synchronize gameplay over the network — it simply worked. That was incredibly valuable because it allowed us to iterate quickly on gameplay ideas without the usual networking overhead.

Another major advantage, which became even more apparent during production, was deterministic replays. We stored replays after every match, and whenever we encountered a gameplay bug we could replay the exact match inside the editor with a 100% reproduction rate. In a chaotic game like Bandit Trap, that was invaluable for debugging and dramatically improved our development workflow.

One example was a bug where tools suddenly stopped working for all Bandits, without any obvious indication of what caused it. In the end, it turned out to be a very specific edge case where one player swapped tools at the exact same moment the Bandits transitioned from the hideout state into the actual match. This is the kind of bug where we likely never would have guessed the reproduction steps manually, and there’s a good chance we would never have encountered the exact same situation again naturally. By replaying the recorded match directly inside the editor, we could immediately identify the root cause, fix it, and even verify the fix using the exact same replay.

How did you structure the simulation between Quantum and the presentation layer? Which parts of Bandit Trap live inside the deterministic gameplay simulation, and which parts remain visual, cosmetic, or client-side only?

A large part of the game lives inside the simulation because it was very important to us that everything players see feels fair and responsive. That’s one of the major advantages of rollback networking.

The few elements that remained outside the simulation were mostly cosmetic or difficult to justify from a gameplay perspective. The biggest examples are:

– The active ragdolls for the Bandits
– The visual damage system for the Bandits, which is purely cosmetic
– The Trapper tower interactions, where the UI sends commands into the simulation

One of the biggest advantages of working with Quantum was that any gameplay feature we created inside the simulation would automatically work online without us having to manually build synchronization systems or constantly think about the network topology being used. That alone saved us an enormous amount of time during development.

The downside is that some features are intentionally limited inside the deterministic simulation because they would otherwise become too expensive performance-wise. We had to carefully decide which systems truly needed to exist inside the simulation and which could safely remain visual or client-side only.

Initially, Bandit Trap was developed by just one programmer, with a second programmer joining later to work on bot behavior. Without Quantum, a game like Bandit Trap simply would not have been feasible for a team of that size.

How did the game design team come up with game mechanics, given the asymmetric nature of the game, and how did they make sure that they are fun and fair? Especially with the bandits basically playing in co-op. Were there specific cases where you had to double check the mechanics to make sure they work online?

From the beginning, the core concept was simple: the Trapper places traps while the Bandits try to steal loot. A lot of the mechanics evolved naturally from that foundation during development.

Coming up with new mechanics was usually the easy part. Making them fair and enjoyable was much harder. Whenever we introduced a new mechanic for the Trapper, we usually had to create something for the Bandits to counter it. Properly balancing all of that required extensive playtesting with four players in real gameplay situations.

One important lesson we learned early on was that the Bandits could not rely too heavily on strict co-op mechanics. Playing with random players without voice chat made heavy coordination frustrating very quickly. As a result, we focused on creating cooperative gameplay that still allowed individual players to contribute meaningfully without requiring constant communication.

There were also many mechanics that sounded fun on paper but ultimately didn’t work well because they required too much coordination. For example, we experimented with special safes that required multiple Bandits to attack them simultaneously in order to open them. We also had ideas for special tools that required two Bandits to operate together, such as a pull bomb where players had to pull both ends at the same time.

Another mechanic we explored was stacking Bandits on top of each other to reach higher places. We originally designed treasure placements that could only be accessed by stacking players together. While the mechanic itself was fun, it once again relied too heavily on coordination between random players. In the end, we kept the stacking mechanic because it was entertaining to mess around with, but we intentionally avoided designing core gameplay progression around it.

Balancing one Trapper against three Bandits seems like a moving target, especially when each new tool or trap can shift the whole meta. What data, playtest observations, or internal rules helped you decide when something was actually balanced rather than just funny or chaotic?

We closely monitored end-of-match statistics throughout development and used win rates as one of our main balancing metrics. Our target was roughly a 60–70% win rate for the Trapper versus 30–40% for the Bandits, because playing as the Trapper generally requires more effort and multitasking than playing as a team of Bandits.

Early in development, almost every new feature caused major shifts in balance, so we made sure the largest gameplay-defining systems were implemented as early as possible. We also spent a lot of time fixing annoyances and gameplay bugs, since those could distort the data and make it harder to judge the actual balance of the game.

Toward the end of development, balancing became more about fine-tuning. We continuously adjusted smaller mechanics and edge-case scenarios until matches consistently felt close and competitive near the end.

Bandit Trap launched across several platforms and supports online multiplayer. What were the biggest cross-platform engineering concerns before release, such as matchmaking, input differences, certification requirements, performance budgets, or keeping versions compatible?

Photon Quantum made cross-platform development significantly easier because the simulation itself is deterministic and platform agnostic. We set up our build pipeline so that our backend generated the Quantum data once and distributed the exact same data across all platform builds, ensuring consistency inside the simulation. By establishing this workflow early and following best practices throughout development, we almost never encountered desynchronization issues.

Most of the matchmaking work involved getting authentication working correctly across all platforms, but fortunately Photon already provided authenticators for the major platforms.

We also invested a considerable amount of time optimizing the code in the simulation itself, since deterministic simulations can place a heavy load on consoles with slower CPUs compared to high-end PCs.

For another indie team building a physics-heavy online party game, what would you recommend deciding early: networking architecture, simulation boundaries, tool design, content pipeline, or playtest process? What would you do earlier if you started Bandit Trap again today?

Definitely the networking architecture and the playtest process.

I honestly don’t think we could have built Bandit Trap with such a small team without Quantum. One of the biggest advantages was that we didn’t need a dedicated network programmer. Developing gameplay often felt similar to building a local multiplayer game, which saved us an enormous amount of time.

Quantum does have a steeper learning curve compared to some other networking solutions, but for us it was absolutely worth it. Beyond the networking itself, the deterministic replay system completely changed how we approached debugging. Many times we discovered bugs in places we would never have expected, but by replaying the exact recorded inputs we could reliably reproduce the issue, fix it, and even verify the solution using the exact same replay again.

That workflow made it possible for us to create a surprisingly polished online multiplayer game with a very small team, especially considering how chaotic and physics-heavy the gameplay is.

On top of that, extensive playtesting is absolutely essential for any competitive multiplayer game. We constantly tested the game internally, organized larger studio playtests, and ran both closed and open betas on Steam. Those sessions were incredibly important for validating balance changes, monitoring win rates, and understanding whether gameplay adjustments genuinely improved the experience.

In the end, we were really happy we chose Quantum for Bandit Trap. It saved us a tremendous amount of development time, and we were also extremely happy with the fast support we received throughout production. We will definitely continue using Photon technology for future projects.

Conclusion

Bandit Trap is a useful example of how early architecture decisions shape the rest of a multiplayer project. Picomy was not just solving networking in isolation. The team had to support a game built around destructible rooms, water and ice propagation, asymmetric roles, competitive timing, co-op interaction, and cross-platform consistency.

Photon Quantum gave the team a deterministic foundation where core gameplay could be implemented once and work online without constant manual synchronization work. That mattered because Bandit Trap was built by a very small programming team, and every engineering decision had to protect iteration speed.

The team still had to make careful tradeoffs. Expensive shard physics moved to the view layer. Cosmetic systems stayed outside the simulation. Balance required repeated playtesting, match statistics, and late-stage fine-tuning. But with the networking model in place, those decisions became production choices rather than blockers.

For other indie teams building physics-heavy multiplayer games, the lesson is clear: choose the networking architecture early, define simulation boundaries carefully, and build a playtest process that can validate both fun and fairness under real multiplayer conditions.

As Picomy puts it:

“We are still very happy that we chose Quantum as our networking solution. It’s been a real blast working with it!”

Ready to Build Your Own Multiplayer Success Story?

Bandit Trap shows what becomes possible when ambitious game design is supported by the right technical foundation. Destructible environments, physics-heavy interactions, asymmetric gameplay, cross-platform consistency, and competitive balance are all difficult problems on their own. Bringing them together in a responsive online multiplayer game is where architecture matters.

With Photon Quantum, teams can build on a deterministic multiplayer engine designed for responsive, fair, and scalable online gameplay. Instead of spending months building networking systems from scratch, developers can focus on what makes their game stand out: the mechanics, the feel, the balance, and the moments players will remember.

Whether you are building a chaotic party game, a competitive action title, a physics-driven co-op experience, or something entirely new, Photon gives you the multiplayer foundation to prototype faster, iterate with confidence, and prepare your game for real players across platforms.

Start building with Photon Quantum today, explore our samples and documentation, or join the Photon Discord to connect with our team and community.

Your multiplayer success story could be the next one.