World War 3 RSS Feed
Available in following languages:PL[worldwar3.com] | RU[worldwar3.com] | DE[worldwar3.com] | FR[worldwar3.com]
We wanted to bring to you a bit more technical overview of what does it mean to change Unreal Engine version to a newer one and how the optimization is done and what it consists of. This one is going to be a bit more technical, but we’ll try to keep it understandable.
First of all, a bit of news from last week! We celebrated the 4th of July with our American friends the best way possible - by helping Military and Veteran Gamers with their 24-hour holiday stream. We’ve added their patch and weapon emblem to the game to support their cause. You can see them and the new 4th of July skins in the game right now. We as a company are working with various charities and we have in the past supported veterans and their families.
Currently, the game is using Unreal Engine 4.19 and has been for over a year. We’ve updated the engine multiple times in the past, but as the full release comes closer and we have a live game to support, big changes like this are more and more dangerous. Game engines are insanely complicated and take years and years of work not only to make, but also to understand, so it’s not a small task to switch engine version - it’s not a one-button click and done - a lot of base systems change from version to version, which means a lot of work and sometimes redoing some parts of the game to better utilize new technology or even to get it to work properly.
To add to that, we’ve made some changes to the engine to suit our needs and those also have to be taken into account when making the switch. Our team has to be careful and test a lot between steps to know which part is problematic and fix it immediately.
This all is intentionally a bit vague to not get bogged down in details, but for completeness sake, we’ll take a look at one of the biggest changes coming in 4.21 for us, which means the Replication Graph.
Replication is a term used to describe how game and server talk to each other - how player position, rotation, state and all variables are moved between game and the server and other games in a match. In 4.20, Epic Games added the Replication Graph which can decide which information from which parts of the level are most important to you and how to get to them the fastest. Remember: the server has to calculate positions and rotations of dozens of players, their movement, health, ammo, hits, it has to simulate vehicles and bullets, calculate wall penetration and ricochets. We do some clever tricks to lower the amount of data that is transferred between players, but the Replication Graph helps with this a lot, freeing up the CPU time on both the server and the client.
Now, it all sounds pretty great, but the challenge is that everything in the game is relying on this data being reliably transferred between players and most bugs in multiplayer games are related to this data being lost or corrupted.
If you would just update the engine and do nothing more, the Replication Graph wouldn’t even do anything. We have to change how our netcode works to use this new, awesome feature to its fullest potential. This means changing a lot under the hood and a lot of testing, to make sure it works faster and more reliably than before. Additionally, other teams also have to take this into account - animation states, weapon data, vehicles - everything is being moved between players and has to synchronize well.
So, to summarize: while the basic engine update itself is not very hard and can be done in a day or two by one person, it’s the work that comes after that’s the challenge - making sure everything works and doesn’t crash, with hundreds of thousands of lines of code written over the years by us and Epic Games.
The other big part of the 0.7 preparations is taking another deep look into the performance of the game. In 0.6 we’ve made major strides, speeding the game up by a lot and making it perform vastly better than before, but we’re still not satisfied completely with the result.
Optimization is not only done by technical staff, though - it’s a team effort, starting on designing features and mechanics that are not requiring a lot of processing power, through level design that takes into account sight lines and level streaming, going through the assets that have to be prepared in a certain way to perform the best they can, down to the technical side of optimizing code and calculations, as well as rendering, creating clever tricks to only render what is absolutely necessary.
Currently we’re working very hard on three major areas: level (asset) optimization, RAM usage and stuttering related to server performance. All of those areas are working together in a big way, because optimizing levels will increase the average FPS, but eliminating stutters and freezes will make those FPS feel a lot better. Having more free memory to load textures and objects will also reduce the number of loading stutters and will speed up the loading.
The good news is that we know what needs to be done to make sure the game performs as good as we can. We’re constantly testing things internally and sometimes even externally with the community (like we did last week on the PTE), looking for ways to increase the game’s performance and from this research come plans on how to make it awesome.
We estimate that since the release of the Early Access version in October last year, we’ve increased the average FPS 200-300% for most players and reduced stuttering by more than 75%. There’s still a lot of things we can make better and this work is progressing nicely - it just takes time, but rest assured, optimization is something we’re really focusing on.
Please let us know if a bit more technical Reports are something you’re interested in, join our forums and subscribe to the newsletter if you aren’t already!