Battle royale game development: a production guide

Making a battle royale game means designing a shrinking-zone match loop for 30 to 100 players, building dedicated-server netcode, and shipping live ops content on a season schedule. Most viable projects today start as indie or mid-budget productions on Unreal or Unity, with a focused map, a single mode, and a clear monetisation plan before scaling.

Battle royale game development: concept and scope

A battle royale game drops a large player count into a single match, removes respawns by default, and uses a shrinking play area to force contact. The format started in Arma 2 and DayZ mods, moved through H1Z1, and reached mainstream recognition through a small number of well-funded titles. For new entrants in 2026, the practical reference points are indie and mid-budget projects like Super Animal Royale, Off the Grid, Realm Royale Reforged, The Finals (battle-royale-adjacent extraction shooter), Naraka: Bladepoint, Free Fire, and Stumble Guys (BR-adjacent party). These titles show how a clear hook (animal cartoon shooter, third-person melee, mobile-first, hero abilities, supernatural urban setting) lets a smaller team compete without matching the scale of premium releases. The concept work for a new BR project locks the hook, the player count, the round length, and the platform set before any engine work begins.

Origins and design vocabulary

The genre vocabulary is well defined and worth using consistently in the GDD. The play area is the safe zone or circle; the closing edge is the storm, wall, or gas. The early phase is the drop, looting fills out the early-game inventory, mid-game is rotation and positioning, and late-game is a small-radius end fight. A round is usually 18 to 25 minutes, with a 100 player default that scales down to 30 to 60 for smaller maps. Solos, duos, and squads of three or four are the standard team formats. Naraka: Bladepoint and Off the Grid prove the format works outside firearm combat when the hook, pacing, and circle design are tuned for melee or magic ranges.

Sub-genre comparison

Three sub-genre patterns are dominant. Each implies a different netcode budget, server cost profile, and content cadence. The table below summarises the trade-offs.

Indie and mid-budget reference set

Reference titles for scoping should match the realistic budget and team size of the project. Super Animal Royale ships as a top-down cartoon shooter from a small studio and proves the format works at low art cost. Off the Grid built a magic-only combat loop on Unreal and ran for several years before sunset, showing the lifecycle risks of a single-mode game. Realm Royale Reforged uses class abilities and a forge system. Naraka: Bladepoint runs a melee-first BR with grappling traversal. The Finals (battle-royale-adjacent extraction shooter) targeted PC and PlayStation 5 with a supernatural urban setting. Free Fire and Stumble Guys (BR-adjacent party) are mid-budget mobile-first BRs with short match length and aggressive monetisation. These references cover the realistic spread of mechanics, art styles, and platforms a new project should compare against.

Core design elements of a battle royale game

Core design for a BR project covers the match loop, the map, the loot economy, and the moment-to-moment combat model. The match loop has four phases: drop, early loot, mid-game rotation, and end-circle. Each phase has its own design pressure. Drop needs varied named locations with different loot density so squads spread across the map. Early loot needs a clear weapon tier system and enough drop variety to create different builds. Mid-game rotation needs readable circle timing, vehicle or movement options on larger maps, and audio cues that telegraph fights at a distance. End-circle needs cover that supports the round length without favouring a single position. Squad communication, ping systems, and revive rules sit on top of the loop and shape how teammates coordinate without voice chat.

Map design and shrinking zone tuning

Map size depends on the player count and movement speed. A 100 player map is usually 4 by 4 km to 8 by 8 km; a 60 player map can sit at 2 by 2 km to 4 by 4 km; a 30 player mobile map can be 1 by 1 km. The shrinking zone is tuned through three numbers per phase: wait time before the next shrink, shrink duration, and damage per second outside the zone. Early phases use long waits and low damage to give time for looting; late phases use short waits and high damage to force engagements. Named points of interest (POIs) are placed so that no rotation forces a player through a single choke. Sight lines are broken by terrain, buildings, or foliage so end fights stay readable.

Loot, weapons, and balance

Loot tables are the main balance lever. A typical setup uses four to five rarity tiers, with the highest tiers gated to airdrops, vaults, or contested POIs. Weapon classes (assault, SMG, sniper, shotgun, melee, ability item) are tuned so that no single class dominates all ranges. Movement items (consumables, mounts, gliders, grapples) shape rotation pace. Items to lock down in the GDD before production scaling include:

Matchmaking, lobbies, and session flow

A BR match starts long before the drop. Players hit a queue, get sorted into a lobby, load into a warm-up area, and only then drop into the match map. The matchmaking system needs to balance queue time, skill rating, party size, region, and platform. For a new project, skill-based matchmaking is usually a stretch goal; the first release can ship with region-based and party-size matchmaking, then add an MMR signal once enough match telemetry is available. The lobby itself runs on a relay or session host service and only spins up the dedicated match server once enough players are confirmed. Session flow rules cover backfill (allowed in warm-up, blocked after drop), reconnection (allowed within a short window), and crash handling.

Dedicated server options

BR cannot be shipped on listen servers at scale. Dedicated servers are the default. The realistic options for a new project come down to managed services and self-hosted clusters. Each option has different cost, latency, and operational profiles.

Netcode and replication patterns

BR netcode is server-authoritative. The client predicts movement and weapon fire, the server validates and corrects, and the result is replicated to other clients in interest-zone slices. Three replication patterns are common, and most production projects mix them. Interest management based on a grid keeps bandwidth predictable when 60 to 100 players are alive. Tick rates of 30 Hz are workable for casual BR; 60 Hz is the target for competitive shooters. Lag compensation rewinds the world by the firing player ping to validate hits. Common patterns the team locks during pre-production:

Anti-cheat, monetisation, and live ops

A BR live game stands or falls on three operational systems: anti-cheat, monetisation, and live ops content. Anti-cheat is the first ship-blocker. PC titles on Unreal usually integrate Easy Anti-Cheat through Epic Online Services; some teams choose BattlEye instead. Console platforms apply their own platform-level integrity systems. Anti-cheat needs to be designed in, not bolted on: server-side validation of damage, movement bounds, inventory changes, and shot direction catches the majority of practical exploits. Monetisation for a free-to-play BR usually combines a battle pass on a 60 to 90 day cycle with a cosmetic store and limited-time bundles. Premium-priced BRs use a smaller battle pass and rely on expansions. Live ops content (seasons, events, balance patches, map changes) is the engine of retention and needs a content production team set up before launch.

Anti-cheat options

Monetisation models

For a free-to-play BR, the realistic monetisation stack is a battle pass at €10 to €15 per season, a cosmetic store with rotating items, a starter pack at €5 to €10, and limited-time event bundles. Cosmetics cover character skins, weapon skins, gliders or mounts, emotes, and finishers. The battle pass earns the studio steady revenue and gives players progression goals; cosmetic store sales spike around major events and crossovers. Hard currency conversion ratios should be locked early and not changed after launch. Pay-to-win items (gameplay-affecting weapons, ammo, or healing) damage long-term retention in the BR audience and are normally off-limits even when revenue pressure is high.

Live ops and seasons

Live ops cadence for a BR is usually one season every 8 to 12 weeks. Each season carries a new battle pass, balance changes, one to three weapons or abilities, a new map area or POI rotation, and a story or event arc. Between seasons, the live ops team runs mid-season events, double-XP weekends, and limited-time modes (LTMs) to keep the daily and weekly engagement curves stable. The internal production pipeline for live ops needs writers, designers, artists, and engineers staffed continuously, plus a separate QA track that focuses on regression and balance. Cross-platform play (PC, PlayStation, Xbox, Switch, mobile) is increasingly expected; account linking, cross-progression, and input-based matchmaking (controller vs mouse and keyboard) are the practical implementation points.

Battle royale game development in Unreal Engine

Unreal Engine is the most common choice for BR projects because the engine ships a mature replication framework, Lyra-style starter content, and direct integration with Epic Online Services for sessions, matchmaking, lobbies, and Easy Anti-Cheat. A Unreal BR project usually starts from the Lyra Starter Game or the ShooterGame sample, then strips and rebuilds the gameplay framework around a single-life match. Replication is configured through the engine actor system, with relevancy and net cull distance settings tuned per actor class. World Partition is the default workflow for the open-world map, with streaming layers for landscape, foliage, and gameplay actors. For a 100 player match on a 6 by 6 km map, the engineering team typically spends the first three to four months on networking, server build, and the streaming pipeline before any vertical-slice gameplay work begins.

Map and streaming setup

World Partition splits the level into grid cells streamed in and out around active players. A BR map needs one large landscape, a foliage spawner pass with HLOD setup, and gameplay actor layers for loot, vehicles, and named POIs. Data layers separate season-specific content so it can be toggled without rebuilding the level. Dedicated server cooks strip rendering-only assets to keep server memory and build size manageable. A typical server build for a 100 player map sits at 8 to 16 GB of RAM per instance.

Networking and replication in Unreal

Unreal replication for BR uses replicated actor variables, RPCs for events, and the relevancy system to limit per-client bandwidth. The character movement component handles prediction and reconciliation out of the box. Gameplay Ability System (GAS) is the standard for abilities, weapons, status effects, and damage. Net update frequency is set per actor: players at 30 to 60 Hz, projectiles at 60 Hz with bouncing networked physics avoided when possible, loot containers at 1 Hz. The team also tunes net priority and cull distance per class to keep the server tick budget within target.

Battle royale game development in Unity

Unity is the realistic choice for mobile-first or mid-budget cross-platform BR projects. The current networking stack is Netcode for GameObjects (NGO) plus Unity Multiplayer Services for matchmaking, lobbies, and managed servers. Unity Gaming Services covers authentication, economy, cloud save, and analytics, which removes most of the backend boilerplate for a small team. Free Fire and Stumble Guys (BR-adjacent party) demonstrate that Unity can ship a BR at scale on mobile when the map size, player count, and tick rate are tuned for mid-range devices. A Unity BR usually targets 30 to 50 players per match with a 1 by 1 km map and a four to six minute round length on mobile, or 60 players with a larger map on PC and console. Addressables manages content for live ops without forcing a full app update.

Project setup and pipeline choices

Render pipeline choice (URP for mobile and broad device coverage, HDRP for PC and console) is locked in pre-production because switching later is expensive. Mobile BR projects use URP with reduced shader variants, baked lighting where possible, and aggressive LODs. ECS or DOTS is used selectively for loot and projectile systems where instance counts are high; the main gameplay still uses MonoBehaviour-based code for team familiarity. Addressables groups split the build into a small initial download (login, lobby, first map) and on-demand groups for seasonal content, cosmetics, and additional maps.

Networking with Netcode for GameObjects

NGO handles ownership, NetworkVariables, RPCs, and Network Transforms. For a 60 player BR, the team configures NetworkObject visibility based on a relevancy grid, uses ClientNetworkTransform with server-side validation for movement, and offloads physics-heavy systems (vehicles, ragdolls) to deterministic or server-authoritative paths. Lag compensation is implemented in custom code on top of NGO snapshots; Unity does not ship a built-in rewind system. Matchmaker and Lobby services from Unity Gaming Services handle queueing, party formation, and ticket allocation to managed Multiplayer Servers.

Unity and Unreal for battle royale: where each fits

There is no single right engine for BR. Unreal wins for PC and console projects that need photorealistic art, large open worlds, and tight integration with Easy Anti-Cheat through EOS. Unity wins for mobile-first and stylised projects where build size, device coverage, and rapid iteration matter more than top-end visuals. The team composition is the second deciding factor. Studios with strong C++ and Unreal networking experience ship faster on Unreal. Studios with mobile-shipping experience and existing Unity tools ship faster on Unity. The choice is rarely about engine capability and almost always about team fit, target platforms, and live-ops tooling already in place.

Engine fit by project profile

Quick reference for engine choice based on target platform and budget profile:

How Game-Ace approaches battle royale game development

Game-Ace has been delivering custom multiplayer and shooter projects since 2005, with 120 plus in-house specialists working on Unity and Unreal across PC, console, and mobile. For battle royale projects the studio covers concept and GDD, prototype and vertical slice, full production, dedicated server engineering, anti-cheat integration, live-ops tooling, and post-launch support. Engagement models are Team Extension, Co-development, and Full-cycle delivery, with strict NDA, full IP transfer, and a documented handover at every milestone. The team works with Amazon GameLift, PlayFab, Epic Online Services, and Unity Multiplayer Services depending on the project stack. Selected case studies covering shooters, multiplayer titles, and live-service games are available under NDA on request.

See shooter game development for the studio service page, browse the Game-Ace portfolio, or contact our team to discuss a battle royale project.