Five Things We Got Wrong Adding Multiplayer to Unreal

Goffy Clash is the first online multiplayer game this studio has built. Everything before it was single-player, and going in we assumed multiplayer was mostly the same work with some networking bolted on top. That assumption cost us months.
What follows is the honest version. Not a tutorial written after the fact by someone who already knew the answers, but the five things we actually got wrong, why each one hurt, and what we would do differently starting again tomorrow.
1. We built the game single-player first
This is the one that cost the most. We built movement, combat and scoring the way we always had, got it feeling good, and then started making it network-aware. It felt efficient. It was the opposite.
Single-player code makes an assumption on every line: that there is one authority, one source of truth, and that what you see is what happened. Network code cannot assume any of that. Retrofitting means revisiting every one of those assumptions individually, and the ones you miss do not fail loudly. They fail as a desync three players and forty seconds later.
Adding multiplayer late is not a feature. It is a rewrite you have not scheduled.
What we would do instead: run the project in a listen-server configuration from the first week, even when nothing is replicated yet. You will not catch every problem, but you will catch the architectural ones while they are still cheap to fix.
2. We trusted the client
Early on, a client would decide it had hit something and tell the server. It is the obvious way to write it, because it is how single-player works, and it was fine while the only people playing were us.
The rule that replaced it is simple and worth stating plainly: the client asks, the server decides. A client sends intent, never outcome. It may say that the attack button was pressed. It may never say that forty damage was dealt. The moment a client can assert an outcome, someone will eventually assert a better one.
This is not only about cheating. Server authority also fixes honest disagreement. Two clients with 80ms of latency will genuinely believe different things happened. Something has to be right, and it has to be the server.
3. We tested on one machine and called it multiplayer testing
Two Play In Editor windows on a development machine share a CPU, share memory, and have effectively zero latency between them. They will happily hide most of the bugs you are trying to find.
A build that is flawless in PIE can fall apart the first time it meets a real connection. Ordering problems that never surfaced at 0ms surface immediately at 90ms. Anything that depended on both ends processing something in the same frame stops being true.
- Test with real latency. Unreal can simulate it, and the numbers do not need to be dramatic. Even 100ms will expose ordering assumptions that a local test never will.
- Test with a real second machine before you trust a build, not after players report it.
- Test a client joining late, mid-match. Most state bugs live in what a joining player is told about a world that has already been running.
- Test what happens when someone disconnects at the worst possible moment, because eventually they will.
4. We treated sessions as the boring part
Hosting, finding, joining and travelling to a map is not the interesting part of a multiplayer game, so we left it until late and assumed it would be a few days of plumbing. It was not.
Sessions are the first thing every player touches and the first thing that can go wrong for them. A player who cannot join never reaches the gameplay you spent months on. It does not matter how good the brawl is if the lobby drops them.
It is also where platform differences bite hardest. Code that works on a LAN behaves differently on Steam, which behaves differently again on EOS or a dedicated server. Deciding late which of those you support means writing the layer more than once.
5. We had no way to see what the network was doing
For a long stretch our debugging process was print statements and guessing. A variable was wrong on a client, and finding out why meant reasoning backwards through what should have replicated, from where, and in what order.
Networking is the one part of a game where you genuinely cannot see the thing you are debugging. State exists in two places, changes in one, arrives late in the other, and by the time it looks wrong on screen the cause is long gone. Visibility is not a nice-to-have here. It is the difference between a fix taking ten minutes and taking a day.
Build or buy the ability to watch replication as it happens, early, before you need it. Every hour spent on that came back several times over.
The tools that came out of this
Most of the plugins we sell exist because of the problems above. We did not set out to build a product line. We built things to get Goffy Clash working, found they were the parts we would want in every project afterwards, and cleaned them up.
- ScarNet came out of problem five: making actors replicate without hand-writing RPCs, and an in-game debugger so netcode is something you can watch rather than infer.
- ScarMultiSession came out of problem four: hosting, matchmaking, a replicated lobby and travel, configured in one place instead of scattered across the Online Subsystem.
- ScarCore Communication came out of players needing to actually talk to each other, with voice, text and ping that do not care which platform you shipped on.
The full written documentation for each is published free in our docs, before you buy anything. If you are weighing one up, read the documentation first and see whether it fits your project. We would rather you skipped a purchase than made the wrong one.
If you are starting now
The short version: decide multiplayer on day one, never let a client assert an outcome, test with latency and a second machine, treat sessions as a real feature, and make replication visible before you need to debug it.
None of this is exotic. It is all the sort of thing that reads as obvious once written down, and none of it was obvious to us while we were in the middle of getting it wrong. Goffy Clash works now because of these lessons, not in spite of them.
The demo is out this month. If you find something broken in it, tell us on Discord. That is exactly the kind of report that produced everything above.
The gameGoffy ClashOur first online multiplayer brawl.
