Spawn Siege: Real-time PvP Battler

The challenge

Real-time PvP games live or die on two very different things at once: whether the moment-to-moment combat is actually fun, and whether the progression and economy around it give players a reason to come back tomorrow. Building both together, before knowing if the first one even works, is how most PvP projects waste months on systems nobody ends up using.

What we built

A 1v1 space-battler built as a Godot client talking to a Go backend, with energy-based spell cards and live matchmaking. We shipped the core battle loop on its own first, deliberately leaving progression and economy out, so we could validate the part that actually matters before building around it.

• Real-time 1v1 matchmaking and live combat over a persistent connection
• Energy-based spell system with per-card cost and cooldown
• A Go server split across two protocols — see below
• Meta-game systems now in progress: trophies, leagues, ship upgrades across multiple currencies, and a loot-chest reward loop
• Post-battle rewards flow designed to make progression visible, not just a number going up

Feature spotlight: two protocols, one game

The server exposes a regular HTTP API for everything that can tolerate normal request latency — account data, the store, meta progression. Live matches run over a separate, persistent TCP connection authenticated by token, because re-authenticating a REST call on every game tick is far too slow for combat that has to feel instant. Splitting the two lets each side be built for what it actually needs, instead of forcing real-time gameplay through infrastructure meant for CRUD calls.

Feature spotlight: the long way to real-time

The current architecture is the third attempt, not the first. The initial prototype paired a Unity client with a Go server — the server held the authoritative game state, but physics ran locally on the client. It didn't hold up: client-simulated physics drifts from what the server thinks happened, and in a PvP battler that drift shows up as hits that shouldn't have landed and ships that teleport.

The fix looked obvious — move physics onto the server — but Go didn't have a physics library stable enough to build a real-time game on, so that became its own round of prototyping in C++. That solved the drift problem, and immediately raised the real one: how do you keep a server-authoritative simulation feeling instant when players are on real, laggy connections, without the game feeling unfair or delayed?

That network architecture — keeping combat responsive under real-world latency without the client and server ever disagreeing about what happened — was the actual breakthrough, not the choice of engine or language. Once it held up, we could layer in physics that's tuned to feel good rather than strictly simulated — a little more forgiving than real physics, deliberately, because a technically accurate hit detection isn't the same thing as a satisfying one. The client moved from Unity to Godot along the way too, once the rest of the architecture had settled — a smaller change next to everything the netcode went through, but one more sign of how much of this was iteration before it looked like the current build.