Add multiplayer
- For an existing game with a working core loop.
- Review the current build and code
- Prioritise one play mode first
- Identify systems that need adapting
Multiplayer game development. Bring players together.
Add connected play to an existing game or build a new online title, from the first shared session to a scoped launch.
Online session
Player APlayer BPlayer C
Tools & technologies
- Unity or web clients
- WebSockets or UDP-based transports
- Authoritative servers
- Matchmaking services
- Databases and queues
- Cloud infrastructure
- Observability
What can we build?
Help players find the right session, invite friends and move from a waiting room into a match with agreed entry rules.
- Public queues or private rooms
- Party invites and ready states
- Region and skill rules where needed
What you receive.
Agree the deliverables and acceptance criteria before development. The handover covers the work included in your project.
Networked game code
Editable client and server work, with the information your team needs to build and maintain the agreed game modes.
Package contents
- Source and build instructions for the commissioned work
- State ownership and message-flow notes
- Dependency, licence and version inventory
Backend integration
Implemented connections for the agreed player, session and persistence services, with documented interfaces and configuration.
Package contents
- API or event contracts and environment configuration
- Account, room and result-storage integrations in scope
- Setup notes for third-party services and access ownership
Test evidence
A report tied to the tested build, devices and hosting setup, including observed results, unresolved issues and capacity limits.
What the test plan covers
- Joins, departures and reconnect outcomes
- Conflicting actions, delay and packet loss where relevant
- Agreed concurrent load and long-running sessions
- Reproducible test steps and known limitations
Deployment handover
A release package and operating guide, with a walkthrough for the people responsible for the service after launch.
Package contents
- Deployment, configuration and rollback instructions
- Agreed monitoring and incident escalation contacts
- Maintenance responsibilities and support boundaries
How can we help?
Build a new online game
- For a new title whose rules depend on connected play.
- Define target devices and match rules
- Review a first playable together
- Plan the content and release milestones
Improve a live game
- For a running title with a specific operational constraint.
- Review observed failures and demand
- Prioritise fixes, regions or new modes
- Agree a staged rollout and rollback
Two numbers shape the capacity plan.
Players in each match
How many people share one gameplay session? This shapes the rules, state updates and work performed by each game server.
Players online at once
Concurrent users, or CCU, describe simultaneous demand across the service. Include players in matches and any lobby or social activity the brief covers.
Capacity is tested against a defined build, regions, network conditions and hosting setup. A match-size target alone does not establish total capacity or a hosting price.
Two players. One shared match.
Read this example
Two friends join the same room.
- Room joined. Both players receive the current match snapshot. Players A + B connected.
- A move is confirmed. The server accepts the move and shares the updated positions. Authoritative state.
- A player reconnects. The returning player receives the latest snapshot rather than replaying an old move. Room state restored.
This recovery applies while the returning player still has a valid place in the match. If the place has expired, explain why rejoining is unavailable and return the player to a usable lobby instead of leaving them waiting.
Scripted illustration using sample information, not a client case study or a live system.
- Founded in
- 2013
- Projects delivered
- 550+
- Client countries
- 43+
- Global offices
- 3
FAQs
Can you work with our existing game?
We start with a playable build, the engine and package versions, and access to the relevant source. The review identifies which gameplay actions, objects and saved data need to be shared, and which single-player assumptions need changing. That assessment informs the estimate before a wider implementation is agreed.
Can mobile, desktop and browser players play together?
Cross-play needs an agreed platform matrix. Input differences, account identity, game rules, network transport and platform requirements all affect the design. We assess the intended combinations before committing to shared sessions; selecting the same engine does not establish compatibility by itself.
What affects the development cost and timeline?
The starting codebase, game modes, target platforms, shared-state complexity and existing backend integrations shape the work. New art, content, voice chat, moderation or additional regions change the scope. An estimate follows a reviewed brief and is broken into milestones with review points.
Are hosting and third-party fees included?
They are estimated separately from development unless the proposal explicitly includes them. Running costs depend on average and peak demand, regions, server resource use, spare capacity and traffic. We use the agreed usage assumptions and tested setup to discuss a cost range; there is no universal price per player.
Does an authoritative server prevent all cheating?
Server-side validation can reject actions that break the agreed game rules, but it is not a guarantee against every exploit. The threat model, abuse controls and investigation tools should match the title. Specialist anti-cheat products and ongoing moderation are separate decisions where needed.
What support is available after launch?
Maintenance and ongoing engineering can be scoped alongside delivery. Agree support hours, incident ownership, escalation contacts and the release process before launch. Hosting fees, round-the-clock response and feature development should be stated explicitly in the support agreement rather than assumed.
Who owns the source and service accounts?
Ownership and handover terms are recorded in the project agreement. Commissioned work, pre-existing code and licensed third-party tools may have different terms. The handover identifies the repositories, accounts and dependencies needed to operate the agreed build, with access transferred through the agreed process.
Bring the game you want people to play together.
Share the concept or current build, target platforms and the first mode you want to launch.
