Building multiplayer from scratch
A co-op lobby, a competitive shooter or a persistent world. We define the topology, authority model and bandwidth budget before writing netcode, the code that keeps players in sync.
See the process
Multiplayer & Networking Engineering
Build or improve online play in Unity. We develop multiplayer architecture, synchronisation and backend systems around your game, target platforms and expected player numbers.
Summary
- Who it's for
- Teams building multiplayer from scratch, scaling an online game that works at small scale, or needing backend and server infrastructure only.
- What you get
- Multiplayer architecture, synchronisation code, matchmaking and server infrastructure in Unity, load tested against agreed player scenarios before launch.
- How it starts
- An architecture and protocol design phase for a new build. A profiling pass on the networking code and infrastructure for an existing game.
- Next step
- Tell us about the game, the expected player scale and the problem you need solved. We reply within 1 to 2 business days.
A server-authoritative MMO backend for Domi Online
Developed by Ocean View Games as the client's core technical partner.
Domi is a massively multiplayer online (MMO) game designed around a persistent player economy and a large multiplayer world. Gameplay is server-authoritative, so the server decides every outcome and players cannot fake results. It runs on FishNet, a networking library for Unity. Networking was led by Brinca, the project's network engineer.
All four closed alpha stress tests, invitation-only tests with up to 500 players, ran on a single Amazon Web Services (AWS) EC2 cloud server, keeping operating costs practical for an independent studio, which is the balance most multiplayer projects actually have to strike.
An unfinished brief is fine. The first conversation helps establish scope.
What are you starting with?
Multiplayer architecture is genre-dependent. Tell us the game, the expected player scale and the problem you need solved.
Scaling an existing game
Your multiplayer works at small scale but server bills, desync (players seeing different game states) or launch-day spikes are a risk. We profile the netcode and infrastructure and re-architect where needed.
Explore performance workBackend and infrastructure only
Matchmaking, player profiles, leaderboards and auto-scaling server fleets on AWS, Google Cloud or Azure, with PlayFab, Microsoft's managed game backend, where it fits.
Explore PlayFabHow we build a multiplayer backend
Agree the player experience, authority model and expected load early. These decisions guide implementation, infrastructure and testing.
1. Architecture and protocol design
Before any netcode, we choose the topology, define what the server validates versus what the client predicts, and calculate packet sizes and tick rates (how often the server updates) against your latency and platform requirements.
2. Netcode and backend implementation
State synchronisation on reliable and unreliable channels, client-side prediction with server reconciliation, lag compensation, plus matchmaking, database architecture and auto-scaling server fleets.
3. Stress testing and launch
Load testing against agreed player scenarios, deployment in the regions your audience needs, and monitoring and release procedures for ongoing support.
Multiplayer work
High-concurrency engineering delivered by Ocean View Games and its team.
Domi Online
MMO-scale architecture
The Challenge: Build a server-authoritative Unity MMO around uncapped progression and a persistent economy on an independent budget.
The Result: Server-authoritative FishNet gameplay and closed alpha stress tests with up to 500 players on a single AWS EC2 server.
RuneScape Mobile
Live environments at scale, at Jagex
The Challenge: Contribute to a live MMO role-playing game (MMORPG) with almost two decades of content while it was adapted for mobile.
The Result: David worked on live RuneScape updates, then built the mobile heads-up display (HUD) and converted more than 40 legacy interfaces on the mobile team at Jagex.
What the architecture has to get right
The decisions that make or break a multiplayer game, agreed against your genre and player scale before implementation.
Authority and cheat prevention
Server-authoritative logic so the client cannot dictate outcomes, protecting competitive integrity and the in-game economy.
Latency handling
Client-side prediction, reconciliation and lag compensation so the game feels responsive without giving up server authority.
Bandwidth budget
Packet sizes and tick rates tuned so the game runs on mobile data, not just a wired connection.
Cost of scale
Server fleets that scale up for peak hours and down overnight, so you are not paying for idle compute.
Matchmaking and persistence
Skill or region-based matchmaking, and low-latency reads with atomic writes for profiles, inventories and leaderboards.
Launch day
Load testing to find bottlenecks before players do, and regional deployment to keep global latency down.
Working together
Start with a free conversation about the game, the expected player scale and the networking or architecture problems you need to solve.
For a new build, an architecture and protocol design phase settles the topology and authority model before implementation. For an existing game, a profiling pass on the netcode and infrastructure comes first.
David and Adam stay close to the engineering, with MMORPG experience from Domi Online and RuneScape behind the multiplayer work.
Production runs in agreed milestones, with load testing and regional deployment before launch and monitoring in place from the first live build.
Meet the teamRelated services and technologies
Where multiplayer work connects to the rest of what we do.
FishNet
The networking library behind our server-authoritative architecture.
PlayFab
Matchmaking, player profiles and analytics as a managed backend service.
Performance Optimisation
Profiling and tuning when multiplayer performance or server cost is the problem.
LiveOps
Keeping a live multiplayer game stable and updated after launch.
Frequently Asked Questions
Potentially, but it can require changes to gameplay state, saving, input and scene architecture. We review the codebase and intended online experience before estimating the conversion.
We assess the authority model and hosting approach against the genre, player count, latency, security needs and running costs. Dedicated servers, relay services and peer-hosted approaches have different trade-offs.
We review the game requirements, existing code and team needs. Our work includes FishNet architecture on Domi Online, and we can assess other Unity networking options where appropriate. See our FishNet work.
We agree expected sessions and player behaviour, then use repeatable load scenarios to measure server, network and persistence bottlenecks. Test results apply to the measured configuration; a player count from another game is not a capacity guarantee.
Yes. We can scope monitoring, updates and incident investigation through our LiveOps service. Coverage hours, response targets and any on-call support are agreed separately.
Get your multiplayer architecture right before launch
Tell us about the game, expected player scale and the networking or architecture problems you need to solve.
Describe your multiplayer game