How to Make an App Like PUBG Mobile

Building a battle royale game at the scale of PUBG Mobile means solving problems across real-time networking, physics simulation, anti-cheat, and live-ops infrastructure — all at once. This post walks through the core architecture decisions, the trade-offs you'll actually face, and what it costs to get it right.

What Makes PUBG Mobile Hard to Replicate at a Technical Level

PUBG Mobile peaked at around 100 million monthly active users. At that scale, the engineering constraints are severe. The game runs a 64-player match in an 8x8 km map with ballistic physics, dynamic weather, and a shrinking play zone — all synchronised across players with wildly different network conditions.

The difficulty is not the game loop itself. The difficulty is maintaining a consistent game state across 64 clients, each sending position and action updates at roughly 20 ticks per second, while keeping latency below 100ms for most players. Everything else — graphics, sound, UI — is downstream of that problem.

The State Synchronisation Problem

PUBG Mobile uses a client-server architecture where the server is authoritative. Clients send inputs; the server resolves the game state and sends back snapshots. This is standard, but the implementation is demanding.

The server tick rate in PUBG Mobile is reported at around 30Hz for high-traffic regions. At 64 players per match, each sending ~20 packets per second at ~50 bytes each, you're processing roughly 64,000 bytes per second per match just for movement. Multiply that across thousands of concurrent matches and you understand why Tencent built dedicated server infrastructure across regions.

Client-side prediction and lag compensation are mandatory. Without them, the game feels unplayable above 80ms. Implementing lag compensation correctly — rewinding server state to validate a shot fired 120ms ago — is genuinely difficult and is the source of most "I shot first" complaints in games that get it wrong.

Physics and Hit Detection

PUBG uses Unreal Engine 4. The ballistic system simulates bullet drop, travel time, and suppressor effects. Hit detection runs server-side to prevent client-side cheating.

Unreal's built-in physics is PhysX. For a game at this fidelity level, you'll be writing custom hitbox management and extending the engine's net code. The default UE4 replication graph is not sufficient for 64-player outdoor maps — most studios replace it with a custom spatial partitioning approach to limit which actors replicate to which clients.

What Does the Tech Stack Actually Look Like?

Layer	PUBG Mobile approach	Realistic indie/mid-scale alternative
Game engine	Unreal Engine 4	Unreal Engine 5, Unity with Netcode for GameObjects
Server runtime	Custom C++ dedicated servers	Agones on GKE, or Photon Fusion
Networking	Custom UDP with RUDP	Mirror (Unity), ENet, or GameNetworkingSockets (Valve)
Backend services	AWS + proprietary infra	AWS GameLift, Azure PlayFab, or Nakama
Anti-cheat	Custom + BattlEye	Easy Anti-Cheat (integrated in UE5)
Analytics	Proprietary	Amplitude, Snowflake, or BigQuery

Unreal Engine 5 is the right engine choice today for a PUBG-class game. Nanite and Lumen reduce per-artist workload significantly. The Lyra sample project gives you a functional shooter framework — it saves weeks, not months, but it is a legitimate starting point.

For dedicated server orchestration, Agones on Kubernetes is a credible open-source option. AWS GameLift Anywhere is the managed alternative and reduces ops overhead substantially, at higher cost.

Mobile-Specific Constraints

Android and iOS impose constraints that PC development does not. Draw call budgets on mid-range Android devices (Snapdragon 680 class) are around 200-300 per frame at 30fps. PUBG Mobile runs a heavily modified rendering pipeline with LOD (level of detail) systems that swap assets aggressively based on device tier.

Thermal throttling is a real problem. A device that benchmarks at 60fps will drop to 30fps after 15 minutes of play as the SoC throttles. Your game needs to detect this and scale quality settings dynamically.

Battery consumption is a competitive metric. Players notice. Keeping a sustained session under 8% battery per hour on a mid-range device requires GPU workload discipline — not just art optimisation.

How Do You Handle Anti-Cheat at Scale?

Anti-cheat is an arms race. Speed hacks, aimbots, and ESP (extra-sensory perception cheats that reveal player positions) are the most common attack vectors in mobile battle royale games.

The server-authoritative model eliminates a class of cheats — anything that requires the client to control game state. But it does not stop aimbots or modified clients sending humanly-impossible input patterns.

BattlEye and Easy Anti-Cheat work by running kernel-level processes on the device. On iOS, this is restricted by Apple's sandbox model. On Android, rooted devices can bypass most userspace anti-cheat. This is why statistical server-side detection matters: flagging accounts whose headshot rates, movement patterns, or kill-to-damage ratios fall outside normal distributions. You store replay data and run post-game analysis. Manual review and community reporting feed the ban pipeline.

No anti-cheat system is complete. The practical goal is making cheating expensive enough that the majority of players do not bother.

What Does It Actually Cost to Build This?

This is where most estimates go wrong. People budget for the game and forget the infrastructure.

A realistic team for a PUBG-class mobile game from scratch:

• 8-12 gameplay engineers (C++ or C# depending on engine)
• 4-6 backend engineers for matchmaking, player data, and live-ops APIs
• 2-3 DevOps engineers for server orchestration and CDN
• 10-20 artists depending on asset fidelity targets
• 2-4 QA engineers with device lab access
• 1-2 data engineers for analytics pipelines

Timeline from green-field to a functional closed beta is realistically 18-30 months for a team of that size. PUBG Mobile took roughly 2 years to reach global launch, and Tencent had both the original PUBG PC code to port from and a very large team.

Server costs at launch depend entirely on player counts, but budget for $15,000-$40,000/month in cloud compute for a soft launch with 50,000 daily active users. It scales roughly linearly with concurrent match count.

The smarter path for most teams is to scope down: smaller map, 32 players per match instead of 64, fewer weapon categories. Games like Garena Free Fire proved that a lower-fidelity version with tighter design could outperform PUBG Mobile in certain markets. Free Fire peaked at around 150 million monthly active users on hardware specs PUBG Mobile would not support.

Matchmaking Architecture

Matchmaking for a battle royale is not trivial. You need to fill 64-player lobbies within 30-60 seconds across skill tiers and regions. A lobby that takes 3 minutes to fill loses players.

Skill-based matchmaking (SBMM) in battle royale is controversial because lobby fill speed and match quality are in direct tension. Most studios use a hybrid: strict SBMM for ranked modes, looser skill brackets for casual queues with a timeout fallback that widens the bracket if fill takes longer than 45 seconds.

OpenSkill (the Weng-Lin model) is a reasonable open-source alternative to TrueSkill for rating calculation if you want to avoid Microsoft's licensing terms.

Conclusion

Building a PUBG Mobile clone is achievable, but the word "clone" is misleading. The systems involved — state synchronisation, lag compensation, anti-cheat, server orchestration, mobile rendering pipelines — each require serious engineering investment. Choosing the right scope is the most important decision you'll make. A 32-player match on a 4x4 km map with good feel is a better product than a technically ambitious 64-player game that stutters on 60% of target devices.

If you are evaluating this as a build, start with a playable prototype in Unreal Engine 5 using the Lyra framework, Agones for server orchestration, and Nakama for backend services. Get one match type working end-to-end before expanding scope.

---

FAQ

How long does it take to build a PUBG Mobile-style game? Realistically, 18 to 30 months for a team of 25-40 people to reach a closed beta. That assumes using an existing engine like Unreal Engine 5 rather than a custom engine. Scope is the biggest variable — a 32-player match on a smaller map can cut that timeline significantly.

Which game engine should I use to build a battle royale mobile game? Unreal Engine 5 is the strongest choice today for quality and tooling. Unity with Netcode for GameObjects is viable for teams with existing Unity expertise and tighter hardware targets. Godot 4 has improved networking support but lacks the ecosystem depth for a production battle royale at this scale.

How do dedicated game servers work for a battle royale? Each match runs on a dedicated server process that holds authoritative game state. Clients send inputs, the server resolves physics and hit detection, and sends state snapshots back. Orchestration platforms like AWS GameLift or Agones on Kubernetes spin up and tear down server instances per match, so you only pay for compute when matches are running.

What is the biggest technical challenge in making a game like PUBG Mobile? State synchronisation under real-world network conditions. Getting 64 clients to agree on game state while each experiencing different latency, packet loss, and device performance is the core problem. Lag compensation, client prediction, and server reconciliation are all partial solutions that introduce their own edge cases.

How much does it cost to run a battle royale game's server infrastructure? Costs vary sharply with concurrent player counts. A rough estimate for 50,000 daily active users at soft launch is $15,000-$40,000 per month in cloud compute, depending on region distribution, match duration, and whether you use spot instances for non-critical workloads. Costs scale roughly linearly with concurrent match volume.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.