The Hidden Cost of Retrofitting Multiplayer: Lessons from Dome Keeper

René Haberman (Bippin Bits) and Chris Rydinor (KAR Games) discuss the hidden consequences of adding multiplayer to a successful single-player game. Their conversation shows that multiplayer is not just a feature, but a fundamental change in system architecture. It forces a move from deterministic local simulation to complex, network-dependent state management. For developers and technical leads, this transcript serves as a warning: architectural choices made during early prototyping, specifically regarding physics and data structures, create technical debt that requires massive refactoring to resolve. The advantage belongs to those who recognize that simple features often require deep re-engineering, and that the most durable solutions involve accepting constraints that others try to code around.

The Illusion of Feature Parity

A common mistake in software development is believing a feature can be added without disrupting the existing system. Haberman and Rydinor show that this is a fallacy. When adding multiplayer to Dome Keeper, the team found that core mechanics, such as physics-based resource carrying, were incompatible with networked synchronization.

There is a lot of times where... there is a lot of bugs as we go through QA where things break down because there was never imagined that this cave could come at a different stage. It could come after the player instead of before the player or things like that where there is just no defensive programming.

-- Chris Rydinor

The team had to rebuild core data structures because the original design assumed a single-player environment with a consistent game state. This highlights a systems-thinking insight: optimizing for the immediate goal of a single-player game created a structural rigidity that made the later goal of multiplayer much more expensive.

Trust as an Economic Strategy

The speakers discuss a trade-off between technical complexity and economic viability. By choosing a peer-to-peer (P2P) model instead of a server-authoritative one, they avoided the high infrastructure costs of dedicated servers. However, this choice forces a change in the system trust model.

We decided to not have the sort of public lobbies where you play with random people. So instead you do play with your steam friends which really takes off the pressure of kind of okay now you have to prevent cheating... I think that was also just like a mandatory thing to decide to even attempt to do this.

-- René Haberman

By limiting the multiplayer environment, they avoided the need for complex anti-cheat and server-side validation. This is an example of routing around a problem by shifting system incentives. Instead of engineering a technical solution to prevent cheating, they used social constraints, such as playing with friends, to mitigate the risk.

The Multiplier Effect of Complexity

The most non-obvious insight is how local and online multiplayer interactions compound. Haberman notes that mixing local co-op with online play creates a state space explosion. Each additional player does not just add linear complexity; it multiplies the number of potential edge cases.

The team decided to wait until the single-player game was content-complete before adding multiplayer. By isolating the development phases, they ensured that content updates did not break the multiplayer foundation. This delayed payoff, spending years on a single-player game before introducing a major feature, is a competitive advantage that many teams lack the patience to execute.

Key Action Items

• Audit for Determinism Early: If you plan to add multiplayer, identify non-deterministic elements like physics-based interactions in your current stack. Evaluate if these can be replaced with event-based logic.
• Prioritize Cheap Multiplayer: Before committing to real-time, shared-world networking, evaluate if asynchronous or friend-only leaderboard systems provide the same user value at a lower engineering cost. This reduces infrastructure overhead.
• Implement State-Aware Networking: Create a network state manager that only sends packets to clients in the appropriate phase, such as loading versus active play. This prevents race conditions that occur when clients join at different times.
• Build for Debugging: Invest in tooling that allows you to launch multiple instances of your game automatically, connected to the same debugger. This investment in developer velocity reduces the time spent hunting edge cases.
• Restrict the Threat Model: If you are an indie team, avoid server-authoritative architectures. Use social constraints like invite-only lobbies to bypass the need for expensive anti-cheat systems. This keeps server costs near zero.