Epic's Fortnite is growing to be a resounding success, especially after the debut of the Battle Royale mode (which has attracted the ire of Bluehole, as you might recall). In fact, Epic announced yesterday that over seven million gamers have played Fortnite already, though it's important to remind that the Battle Royale mode is now accessible for free.
Thanks to over 7 million of you who have played Fortnite! We want to keep the Battle Bus flying, so Duos and Supply Drops are available NOW. pic.twitter.com/sRx767u4aG
Epic is also the maker of what's arguably the most popular third-party engine right now, the Unreal Engine 4. While developing their third-person MOBA Paragon, they were able to further optimize the engine for everyone else. The same is now happening with Fortnite and the upcoming optimizations will affect both client and server, with a particular eye towards consoles where Epic was able to develop several tweaks to improve the memory footprint.
Once these optimizations roll out, hopefully other Unreal Engine 4 powered games featuring big online worlds (Dark and Light, Citadel: Forged With Fire, Conan Exiles, PLAYERUNKNOWN'S BATTLEGROUNDS just to name a few) can use them to improve performance.
Building and Rendering a Large Map
The map in Fortnite: Battle Royale has a playable area of 5.5km^2. You can see the entire map at once when parachuting in and we wanted to support long view distances during gameplay. We knew that we needed to optimize our level-of-detail solution to make that possible.
We used the Hierarchical LOD (HLOD) feature in the engine, backed by Simplygon, to combine regions of the map into single low-poly meshes that could be drawn in a single draw call when viewed from a distance. Those tools already exist – we use them in Paragon – but we needed to make changes to allow our artists to be more efficient.
The way the map was broken up so that artists could collaborate on it didn’t mesh well with our HLOD tools. We made some changes to HLOD to better support that workflow and added a commandlet to rebuild all HLODs in the map that could run overnight rather than requiring artists to rebuild HLODs locally. (Will be in 4.19)
Shipping on Console
The extended view distance and player counts of Battle Royale presented several performance and memory challenges on console requiring us to make improvements, particularly relating to memory. Much of this work was game-side content optimization but we also made a number of improvements to the engine.
Here are some of the console improvements, which will ship in 4.18:
[XboxOne + PS4] More efficient volume texture updates, which reduced peak memory by 240MB+.
[XboxOne] Added options for different render target layouts to maximize bandwidth utilization on the GPU depending on what rendering features are enabled.
[XboxOne] Reduced memory overhead in D3D12 descriptor heaps, and saved 120MB.
[XboxOne] Allocated and freed render targets on-the-fly to reduce memory usage by 100MB+.
[PS4] Optimized how we handle the texture streaming and defragmentation pools, saving 300-400MB.
While working on Battle Royale we identified some issues with input latency in the engine that particularly affected 30Hz games. We were able to make improvements to thread synchronization, reducing latency by around 66ms (the reduction will be around half that in a 60Hz title) to address this problem. These changes make a noticeable improvement to the feel of the game, making it more responsive and easier to aim. (Will be in 4.19)
Server Optimizations
Batched level streaming RPCs to reduce the number of RPCs that need to be sent to clients when they connect. (Will be in 4.19)
Make the OS socket buffer sizes configurable and raise them for Battle Royale. This prevents simultaneously connecting clients from overflowing these buffers resulting in excessive server load. (Will be in 4.19)
Reduce bandwidth for CharacterMovement RPCs when the character is not standing on any component, such as when jumping or falling. (Will be in 4.19)
Added the ability to limit how many players receive updates from the server per frame. We set the limit to 25 in the lobby and 50 during gameplay. (Will be in 4.19)
Limit the rate at which clients send movement updates to the server. Prevents clients running at high framerates from causing excessive load on the server. (Shipped with 4.17)
Added an option to not replicate client ping times to other clients as it results in a lot of network traffic when there are many players. (Will be in 4.19)
Removed several memory allocations during replication in FArchive::SerializeIntPacked and changing how CompatibleChecksum is calculated. (Will be in 4.19)
Switched property type comparisons from strings to FNames for speed during replication. (Will be in 4.19)
Added a way to view a dedicated server's network stats on a client in real time to more easily see stats for cloud-hosted servers. (Will be in 4.19)
Changes to the ability system to better account for relevancy, which greatly reduces replication cost when using the ability system. (Will be in 4.19)
