Hello everyone!
While we’ve talked about “what’s next” a few times now, we want to share a bit more detail with you on some of the specifics. Today, we are going to focus on game performance.
Our development teams are hard at work reviewing how best to optimize performance. But what does that really mean? Performance can be broken down several ways, each way being broken down further and further. Today, we'll break it down into a few basics.
Bottlenecks: Any program (games included) will have a bottleneck. This is where one resource is holding back the ability of other resources to work to their fullest extent. Where these bottlenecks occur, throwing resources of other types at the problem will not improve your framerate - it is a waste of machine resource and developer effort. A good example here is that, historically, the Red Orchestra/Rising Storm franchise is CPU heavy, due to the amount of calculations we are doing for gameplay as well as all the detail we are trying to draw on screen at once (these are done in something called a “draw call” on the CPU before it is passed to your GPU to render). All those detailed (and accurate) calcs for ballistics, bullet penetration, damage chew up the CPU - accentuated by the volume of projectiles in the air, with so many automatic weapons.
Spikes: Often times games are not making use of resources in exactly the same way moment to moment or even frame to frame in a game or rendering thread. Sometimes something comes along that requires more resources than was available and can often cause a new temporary bottleneck. An example of this is when a commander has called in an artillery strike and the CPU suddenly has a lot more work to do - the checks and physics being calculated by those impacts can cause a sudden drop in frames.
Performance Goals: When making a game you set out some performance goals which also inform your minimum and recommended specs. In our case, here at Tripwire and Antimatter, we target a minimum setting that can be run on low at a stable 30 frames per second on the minimum spec machine and a high that can be run at 60 frames per second on our recommended spec machine.
Now with our performance goals in mind, what are we doing to hit those? It all starts with our QA team working to document overall map scenes that don’t meet our performance goals as well as discover and profile spikes that can occur in gameplay.
Level designers and 3d artists: Looking for and fixing collision issues and scenes with too many draw calls. This can mean redoing the collision model (complex collision on objects that don’t need it can result in slower calculations on the game thread) on the item, more aggressive culling (having the game not draw items such as small objects in a house at distance, reducing the overall draw calls) in a scene while minimizing the overall impact to the look, and more. This is very labor-intensive. It requires tools to help highlight the issues, a lot of work from QA to help home in one each individual issue, then the legwork from the designers/artists to correct/improve each individual asset.
Effects Artists: Working to reduce instruction count and complexity which makes effects easier and faster for the CPU to calculate and have rendered, as well as other related optimizations to further reduce the spikes they can cause on the rendering thread. Again, labor-intensive.
Engine Programmers: The final team focusing on performance. They are looking at the overall performance and making recommendations for the other teams based on engine best practices as well as looking at ways to improve the systems in place to make them better. They are also the ones doing the very complex work on how the engine actually goes about chewing through the millions of calculations per second required, worrying about details of “wavefronts” of data moving from CPU to GPU, ideally looking for spare milliseconds and figuring out ways to make use of them.
In summary, all of the above will help performance gains across all maps, Hue City being a good example.
And as previously highlighted, we have already addressed balance issues on a couple of maps and will continue to do so on a ‘need to basis’, based on community feedback. Additionally, bug fixing will always be an ongoing effort, pre and post launch. We'll continue to keep everyone updated on a weekly basis, and asking for additional feedback where needed.
Thank you for your continued support.
Tripwire Interactive & Antimatter Games