Mobile game development: where a project breaks at the start
Most projects in mobile game development break not on game mechanics, but on the link between client and network.
While a match has two people on one device, everything is predictable; as soon as there are more participants and the channel is unstable, match state synchronization stops converging — one has already made a move, the second doesn't see it, the third sees the previous one.
The second point of failure is dual logic for two platforms. Rules, scoring, and turn order are duplicated in the native layer and in shared code: the branches diverge after just a few releases, and the defect reproduces on only one of them.
A single rules core plus cross-platform assembly from one source removes the divergence — one implementation is fixed instead of two.
The third is performance under load.
Multiplayer in a mobile game holds exactly two, but at the eighth participant it loses responsiveness: the client sends the full match state instead of changes, prediction of one's own move is not implemented, and channel latency becomes visible to the player.
All three failures are architectural, not "we'll optimize later." An authoritative server, exchanging only changes, and one state model for all participants remove them at the stage of designing the game client architecture — while a fix costs one decision, not rewriting the network layer.
Next we break down how this is closed: which synchronization modes we choose for the genre, what we check with load, and how we move logic without losing player progress.
What changes after moving logic to a shared core
While match logic lives in two branches for each platform, any rule has to be written twice.
Scoring, timers, turn order, and victory conditions diverge in small details — and this surfaces not in tests, but on live players, when participants see different states of the same match.
Moving logic into a shared game core removes the source of divergence itself. The core is a deterministic match model: the same input produces the same set of moves and state transitions on any device.
The platform layer remains thin — input, rendering, notifications — while rules and synchronization live in one place.
A single codebase instead of two gives one set of checks on rules: a scenario that passed on one device is guaranteed to pass on the second.
Release assembly becomes predictable — one pipeline builds both platforms from one commit, so release build time stops depending on whether the second branch pulled someone else's fix.
The failure class "state divergence among participants" is eliminated separately: the network layer transmits player actions, not ready-made states, and the match converges for everyone along one sequence of steps.
This gives reproducible matches for reviewing disputed situations and rollback to a saved point without manual reconciliation.
The cost of the solution is discipline in the core: a change goes through review and verification before entering the build.
It pays off because supporting two platforms stops being double work, and we take mature tooling — Unity, where the shared layer and build for mobile platforms are well-established.
Multiplayer formats: comparison of approaches and limitations
The synchronization scheme determines not the visuals, but the class of failures: what happens when one of the players loses connection, who decides whose shot hit, and whether the result can be falsified on the device.
Therefore multiplayer modes are chosen before game logic is written — moving to another scheme later means rewriting the combat part and rebuilding the balance.
| Option | When it fits | Limitations |
|---|---|---|
| Authoritative server | Competitive and ranked modes where equal outcome matters | Requires permanent infrastructure; latency depends on how close the node is to the player |
| Direct connection between devices | Co-op for 2–4 people, early access without infrastructure | The host device becomes a point of failure; its owner sees the full state |
| Local host on one network | Tournaments and parties in one venue, showcase matches | Works only inside a shared network; outside it the mode falls apart |
| Hybrid network scheme | Mass modes that need both responsive input and a common rating | Harder to debug: desync shows up rarely and over long sessions |
In practice the choice is this: ranked matches — authoritative server, co-op — direct connection between devices, on-site tournaments — local host.
A hybrid network scheme takes a compromise: irreversible events and the match result are confirmed by the server, while the device computes response to a press immediately and suppresses divergence by reconciling state.
The cost is a separate set of checks with artificial connection loss, latency, and reconnection, otherwise desync will surface with players already.
Work stages: from prototype audit to handover to the team
A game prototype is usually assembled as a mechanics check: logic lives on the device, match state is sent however it turns out.
As soon as multiplayer and AI opponents appear, synchronization becomes the bottleneck — divergences between players, disputed hits, match breakdown when connection is lost. We carry out the work in stages, and each is closed with an artifact that the team accepts.
- Prototype audit. We look at where game logic is computed, how match state is stored, what can be reused. Output — a map of bottlenecks and a decision: refine the current foundation or move logic to the server.
- Network interaction scheme. We fix what is computed authoritatively on the server, what is predicted on the device, how conflicts are resolved, and how the match is restored after a disconnection. We agree on the scheme before the first line of code.
- Implementation. We assemble matchmaking, rooms, and state synchronization; AI opponent behavior is moved into settings so difficulty changes without rebuilding the build.
- Load checks. We run matches on an unstable channel and with different connection quality, looking for the threshold at which states diverge and the server hits its limit.
- Acceptance on devices. We run on low-end and flagship models, different OS versions, with match interruption by an incoming call and switching between networks.
- Project handover. Repositories, environments, schemes, release process, and training for your team — so development continues without us.
Each stage gives a verifiable result: audit report, agreed scheme, load test protocol, prioritized defect list. This sequence shows where the project is and what remains until release.
What we hand over: schemes, configurations, regulations
We hand over not "access to the repository," but a kit by which your team or another contractor can continue work without reverse engineering.
Each artifact is versioned together with the code and updated as changes occur — otherwise after two releases the documentation diverges from reality and stops being a source of truth.
- Architecture description — client layers, game session state, server logic, and extension points. A module scheme with clear boundaries: where a new mode is added without touching the network layer and balance math.
- Network flow diagrams — sequences of handshake, state synchronization, and reconnection after a connection loss. Separately — what the client sees during desync and how conflicts between players are resolved.
- Environment configurations — dev, staging, production with a list of variables, limits, and external dependencies. Standing up the environment is repeatable from scratch by instruction, without "asking the one who configured it."
- Access and secrets policies — roles in the repository and cloud, least-privilege principle, rotation of keys for payment and analytics integrations, ban on secrets in code.
- Update release process — branching, mandatory checks, rollout order to test groups, rollback criteria, and incident review timelines with root cause recording.
- Build and release tools — reproducible build, automatic upload to stores, versioning, and storage of code maps for analyzing production crashes.
- Data documentation — storage scheme for progress, metrics, and profiles, migration rules when the format changes, so an update does not reset player progress.
- Handover plan — joint sessions with your team, accesses, support procedure for the first releases, and a contact for urgent questions.
The kit is verifiable: if it cannot be used to stand up the environment and release an update without us, that is not a handover, but a dependency.
Case: match synchronization and AI opponents in combat
The project — turn-based battles where live players act in pairs with AI allies. The match was computed by each participant's device, and on real networks match desync occurred: one player saw a hit, the second saw a miss on the same turn.
Every fifth match ended in a breakdown, and on low-end devices the app heated up and crashed in the middle of battle.
What changed
Match calculation moved to the server: the client sends only input, the server holds the single correct state and sends confirmed battle snapshots.
The client became thin — it no longer needs to keep the entire move history in memory, and a connection loss is treated by reconnecting to the last confirmed step instead of restarting the match.
AI opponent behavior also moved to the server and became identical for all participants: the same decision on the same state, the calculation is bounded in time in advance, and it does not compete with graphics for device resources.
Result
Share of broken matches decreased from 18% to 2%, match connection time — from 6–9 seconds to 1.5–2 seconds due to the lightweight client and a short initial snapshot.
On entry-level devices, crashes in battle decreased severalfold, and the release in Google Play went without a wave of reviews about freezes — stability on low-end devices became a separate acceptance criterion.
What to do if the game is already released on its own server?
A released game is not only code, but live matches, rating, player progress, and purchases.
Therefore logic is moved not by the principle of "stop and rewrite," but in layers: first the boundary of authoritative state is determined and what exactly the client considers the source of truth. Then the new contour is enabled next to the old one, not instead of it.
First stage — parallel operation of two schemes. Read requests go to the new scheme, its responses are compared with the old scheme's responses, divergences are written to a separate log, but the old one still responds to the player.
This way correctness is verified on real traffic, including peak hours, not on a test environment, and no match depends on code that has not yet been verified.
Extraction of logic proceeds from non-critical to critical: first matchmaking and aggregated statistics, then game sessions inside a match, and last — accounts, purchases, and accruals.
Each layer switches separately and independently, so a failure in one does not drag down the others. Player state is migrated in the background, matches continue.
Rollback plan is built at the routing level: one switch returns traffic to the old scheme, and data formats are compatible in both directions — the new one writes what the old one can read.
Rollback takes seconds and does not interrupt active matches, so it is used as a standard tool, not as an emergency measure.
Updating a released game does not require a forced client release: the contract between client and server does not change, only the place where logic executes changes.
We track divergence metrics and the share of interrupted matches — while they are normal, the step is considered passed and the next one begins.
Technical doubts: rollbacks, cheats, load, privacy
Connection loss in a match, result substitution, peak load, and storage of player data are not abstract risks, but concrete places in the architecture where either a solution exists or it does not. Below are answers to the questions most often asked before development starts.
Principle is one: the server owns match state, and the client only sends intentions. Then reconnection, result verification, and scaling are solved by one layer, not three different patches.
What happens when connection is lost in a match?
The session lives on the server for another 30–60 seconds: state is fixed with a snapshot, the player sees a pause or a controlled bot, and upon return connects by session key and continues from the same second. The match is not recreated.
How are match results protected?
The result is computed by the server according to its rules, not by the player's device: editing local data or substituting packets changes nothing. Additionally, an action record is saved — anomalous accuracy and repeating sequences go to review.
How is peak load calculated?
We calculate not by installs, but by simultaneous matches at peak hour, with headroom for event spikes. The load run is conducted above forecast so the connection ceiling and queue are checked before release.
How is player data stored and how does version rollback work?
We store the minimum: identifier, progress, purchase facts — with encryption and a limited term, as Google Play requires. Game rules are moved into server configuration: an unsuccessful balance is rolled back by a switch without releasing a new build to the store.
Let's discuss the task: what to attach to an estimate request
To come back with an estimate and work plan, rather than general words, we need project inputs. We review materials before the conversation starts: then the estimate relies on mechanics, network model, and target platforms, not guesses. Below is what to attach to the request so that we discuss the task substantively.
- Description of mechanics: round rules, victory conditions, in-game economy, how the AI opponent behaves with different numbers of players.
- Prototype or existing work: playable build, screen drafts, level sketches — we'll show what we reuse and what we rewrite.
- Current network scheme: how state is synchronized between players, where server logic lives, how connection breaks and reconnections are handled.
- Target platforms: mobile systems and tablets, whether overlap with desktop versions and a single account between them are needed.
- Load: expected number of simultaneous players, average match length, requirements for control responsiveness.
- Timeline and stage constraints: tie-in to launch, what is critical in the first version, what we move to the second.
- Scope of work and accesses: whether design, analytics, and store publishing are needed, which storages and services you give access to.
With these inputs, we come back with an estimate and work plan for mobile game development: stages, order, risks, and what will be required from you at each step.