How to Make an App Like Fortnite

Building a game at Fortnite's scale means solving problems that most backend engineers never face. This post breaks down the architecture, real-time systems, and infrastructure decisions you need to think through before writing a line of game code.

What Does "Like Fortnite" Actually Mean, Technically?

Fortnite at peak had 350,000 concurrent players in a single event. The default Battle Royale mode puts 100 players in one match, with sub-100ms latency requirements, destructible terrain, physics simulation, and a live-service economy running on top.

That's four separate hard engineering problems:

• Real-time multiplayer with authoritative server-side physics
• Matchmaking at massive concurrency
• A live game economy with cosmetics, a virtual currency (V-Bucks), and seasonal content
• Cross-platform play across PC, console, and mobile

You do not need to solve all four on day one. But you need to know which ones you're deferring and what that costs you later.

Core Architecture: What Actually Runs the Game?

The Game Server

Fortnite uses Unreal Engine 5. Epic owns both the engine and the game, which gives them optimisation paths nobody else has. If you're building a battle royale, Unreal Engine 5 is the realistic choice. Unity works for lighter multiplayer games, but UE5's Chaos physics engine and Nanite geometry are effectively prerequisites for destructible-environment gameplay at that fidelity.

Each game session runs as a dedicated server process. That process owns the authoritative game state: positions, health, inventory, collision. Clients send inputs; the server runs simulation; the server sends state updates back. This is the standard authoritative server model and there's no real alternative for a competitive game where cheating matters.

Tick rate is the first honest trade-off. Fortnite runs at 30 Hz server tick. Valorant runs at 128 Hz. Higher tick rate means lower perceived latency and better hit registration, but it linearly increases CPU load and bandwidth per player. At 100 players, 30 Hz is a practical ceiling for most cloud instance types without custom netcode compression.

Netcode: Lag Compensation and Rollback

At 30 Hz, a player on a 60ms connection sees the world 60ms in the past. Lag compensation rewinds server state to the time a client fired a shot, checks the hit against where enemies actually were at that timestamp, then resolves the damage. This is why you can shoot someone who has already moved behind cover from your local perspective and still register the hit.

Rollback netcode (used in fighting games like Guilty Gear Strive) goes the other direction: simulate ahead, roll back when you get corrective data. It works well for 2-player games with deterministic physics. It does not scale to 100-player sessions with non-deterministic physics engines like Chaos.

Session Management and Matchmaking

Matchmaking is a queuing and allocation problem. You need to:

1. Group players by skill rating, region, input type (controller vs. mouse), and ping
2. Allocate a game server process on a host with available capacity
3. Hand clients the connection endpoint for that server

Epic Games built a dedicated service called Gauntlet for this. For a new game, you'd typically start with an open-source option like Nakama (Go-based, self-hostable) or use a managed service like AWS GameLift, which handles fleet scaling and session placement natively. GameLift charges roughly $0.05 per player-hour on c5.2xlarge instances, which adds up fast at scale but saves you six months of infrastructure work.

How Do You Handle Cross-Platform Play?

Cross-play is a networking problem, a latency problem, and a platform certification problem.

On the networking side, each platform's NAT traversal behaviour is different. Xbox and PlayStation both require platform-specific SDKs for friend systems and party invites. You can abstract this with a middleware layer like PlayFab or by building your own identity and party service, but the platform-specific SDKs are non-negotiable if you want features like cross-platform voice.

Input disparity between mouse-keyboard and controller is a separate problem. Fortnite uses aim assist for controller players. Tuning aim assist to feel fair to both sides is a UX and data problem, not an engineering one, but the engineering team has to instrument the telemetry that lets the game designers tune it.

Mobile is the hardest platform. At peak, Fortnite Mobile ran at 30 fps on an iPhone XS with a reduced draw distance, lower texture resolution, and simplified physics. The network stack was the same; the rendering budget was not.

What Infrastructure Do You Actually Need?

Compute

Game servers are stateful and latency-sensitive. You cannot run them on serverless compute. The standard pattern is a fleet of bare-metal or virtual machines pre-warmed in each region, with autoscaling policies triggered by matchmaking queue depth, not CPU utilisation.

AWS, GCP, and Azure all offer dedicated game hosting products. AWS GameLift Anywhere lets you run server processes on your own hardware and still use GameLift's matchmaking and session management, which is useful if you need bare-metal performance in regions where cloud instance types are inadequate.

A realistic minimum viable infrastructure for a small-scale launch (under 10,000 concurrent players) looks like this:

Component	Service	Approximate monthly cost
Game server fleet	AWS GameLift (c5.2xlarge)	$2,000–$8,000
Matchmaking	GameLift FlexMatch	Included
Player data / inventory	DynamoDB	$200–$800
CDN for game client	CloudFront	$100–$500
Analytics pipeline	Kinesis + Redshift	$500–$1,500

These numbers shift significantly with player count and play session length.

Storage and State

Player inventory, progression, and currency live in a database that must handle high-frequency reads and occasional writes. DynamoDB works well here. Game session state does not need to survive a server crash (matches restart), so in-memory state on the game server process is fine.

Replays are expensive. Storing a 20-minute match replay at full fidelity requires either recording all inputs and re-simulating (determinism-dependent) or streaming the state log. Most games store a compressed state log at reduced tick rate for replay.

How Much Does It Cost to Build This?

Honestly, a lot.

A production-grade battle royale with cross-platform play, a cosmetics economy, and anti-cheat takes a team of 20-40 engineers two to four years. Epic employs over 5,000 people. You are not building Fortnite; you are building something in the same genre with a fraction of the budget.

The realistic scope for a funded studio building a 100-player battle royale on UE5 with a six-person engineering team over 18 months is: one platform, one region, no destructible terrain, basic matchmaking, and a simple cosmetics shop. That's still a viable game. It's just not Fortnite.

If you're evaluating outsourcing parts of this, the backend services (matchmaking, player data, economy, analytics) are the most portable. The game server and netcode work require people who have done it before, because the failure modes are subtle and expensive at scale.

Conclusion

The architecture is knowable. UE5 for the game server, authoritative simulation at 30 Hz, GameLift or Nakama for session management, DynamoDB for player state, CloudFront for distribution. The hard part is execution: tuning netcode, scaling infrastructure ahead of player growth, and keeping latency acceptable across regions.

If you're at the point of scoping this out properly, start by defining your target concurrent player count and your latency budget per region. Everything else flows from those two numbers.

---

FAQ

How long does it take to build a multiplayer battle royale game? A small team of six engineers working on a scoped-down battle royale (single platform, one region, no destructible terrain) should plan for 12 to 18 months to reach a playable beta. A full cross-platform game with a live economy is a two-to-four-year project with a proportionally larger team.

What game engine should I use to build a Fortnite-style game? Unreal Engine 5 is the practical choice for a high-fidelity battle royale. Its Chaos physics, Nanite geometry system, and built-in networking are mature enough to build on. Unity works for lighter multiplayer games but lacks the physics tooling needed for destructible environments at scale.

What does it cost to run game servers for a battle royale? At under 10,000 concurrent players on AWS GameLift using c5.2xlarge instances, expect $2,000 to $8,000 per month in compute alone. Costs scale roughly linearly with concurrent player count and session length. Bare-metal hosting reduces cost at very high concurrency but adds operational complexity.

How does lag compensation work in a multiplayer game? The server keeps a rolling history of game state, typically 200 to 500ms deep. When it receives a "shot fired" input from a client, it rewinds to the timestamp when the client fired, checks whether the target was in the bullet path at that moment, and applies damage accordingly. This is why hit registration feels accurate despite network latency.

Should I build matchmaking in-house or use a managed service? Use a managed service first. AWS GameLift FlexMatch and Nakama both handle the hard parts (latency-based grouping, session allocation, fleet management) without requiring you to build and operate the infrastructure yourself. Build in-house only if you have constraints (data residency, custom skill algorithms, cost at extreme scale) that managed services cannot meet.

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