40 million players a month. Over 4 million players online at a time. Fortnite Battle Royale ran on Unreal Engine 4, targeting PC, console, and mobile simultaneously. The optimization work Epic did to make that possible is a masterclass in production-scale performance engineering.
Significance Manager
With up to 100 players in a single match, not all of them need equal CPU attention at any moment. Epic built a Significance Manager that categorizes players into priority buckets based on visibility and proximity. Visible players are set at higher priority; closer players rank higher than distant ones.
Different platforms receive different bucket allocations — console gets larger high-priority buckets than mobile. Systems like animation, LOD, and tick rate all query the Significance Manager to scale their effort per actor accordingly.
Animation Optimization
Fortnite's character design uses one base model with four separate meshes (head, body, bag, weapon), each with its own animation blueprint. The discovery: Blueprint-based animation evaluation cost 0.93ms per character. Converting to C++ dropped that to 0.19ms — a 5x improvement per character, multiplied across 100 players.
Additional animation strategies:
- Fast Path animations — direct variable access in the anim graph without Blueprint modification overhead
- Disabling tick updates for meshes not visible on screen
- Update Rate Optimization (URO) — running animations below frame rate for distant or off-screen characters
- Switching from AnimDynamics to RigidBody nodes for physics-driven secondary motion
Rendering
Supply drops (the falling crates) used skeletal meshes but were rendered as static geometry when not animating, reducing the rendering pipeline cost. Dynamic animation bounds were calculated from physics assets rather than recalculated from vertex positions every frame.
HUD and Widget Performance
Converting HUD code from Blueprints to C++ gave significant gains. Widgets that didn't change every frame were wrapped in Invalidation Panels to prevent continuous re-evaluation. The "dumpticks enabled" console command was used during profiling to identify systems ticking unnecessarily.
Object Pooling
Particle effects and frequently spawned objects were pooled rather than destroyed and respawned. C++ components were prioritized over Blueprint versions for faster instantiation. Soundcue evaluation overhead was reduced by batching and pre-caching.
Level Streaming
Rather than loading the entire map upfront, Epic used dynamic level streaming with adaptive time budgets. During the skydive phase at match start — when players are moving quickly across the map and many new areas become visible — the system allocated 5ms per frame for post-load processing. During normal walking gameplay, this dropped to 3ms. I/O operations were overlapped across sequential level loads to minimize stalls.
Collision and Movement on Mobile
Instead of continuous collision checking during player movement, capsules teleport between server-provided transforms. This eliminated most per-frame collision evaluation on mobile where compute budget is tightest.
Texture Streaming
Texture streaming ran conservatively during active gameplay to preserve frame time. The system accelerated texture loading during the pre-match lobby, when players customize skins and performance requirements are lower.
The Philosophy
Epic's optimization work wasn't a single big win — it was dozens of small ones compounded across every system. Identify what work is unnecessary, eliminate it or defer it. Measure on all target platforms. The console numbers will mislead you on mobile. Prioritize the common case.