For Science! Performance Check-In
The team has been hard at work improving the performance of Kerbal Space Program 2 since launch, so we'd like to take a moment to really showcase the difference between the Early Access launch (v0.1.0.0) and the For Science (v0.2.0.0) release coming next week on December 19. Full global release timing graphic can be found here.
Here's a look at some graphs we use to understand the game's performance and the improvements that have been made to our minimum specification and recommended specification machines:
FPS between EA launch and For Science! on minimum specs.
FPS between EA launch and For Science! on recommended specs.
This represents a huge amount of work by the development team across a number of features and releases. With performance optimization being one of the most frequent requests since launch, we're looking forward to hearing from players how this work improves the overall gameplay experience.
If you're curious about performance tuning and how we make decisions in that area, the rest of this check-in provides a high-level overview from our Engineering Team and should provide a bit of extra context for the above graphs.
[h3]Performance 101[/h3]
As you can see in the charts, performance varies quite a bit between various scenes players might find themselves in. When we’re investigating performance-related issues, we need to investigate many variables both in the game and on the physical machine. Let’s examine the basics of performance tuning and what we look at when trying to make decisions about performance optimization.
In keeping with the theme of For Science!, we should start with defining our experiments and the measurements we will use to determine if we are moving in the right direction. So, let’s start with Frames per Second (FPS), which many of you will already be familiar with. A frame is the period required to fully recalculate what has changed in the game state and redraw the scene to the player. The more FPS, the smoother the game looks and feels, as this allows us to capture inputs quicker and update the game state showing those updates to the user in a more responsive way.
When we are digging into performance, we want to look at that value in a different way: milliseconds per frame (ms). Why would we do that? Basically, we want to understand what, in a given frame, is taking up time so we can make it faster. For a 30 FPS goal, we get 33.3 milliseconds per frame, so it becomes a lot easier to set a budget for how much time a given section of the game should take. But what are we taking time from exactly? There are two pieces of hardware we generally are looking at for performance: the GPU and the CPU.
At a high level, a Graphics Processing Unit (GPU) is a piece of hardware that specializes in the types of calculations that are needed to render a given scene. It is much faster at smaller tasks in parallel than a Central Processing Unit (CPU) but much slower at running tasks in a series. In order to get the maximum performance out of a computer, we want to use both to their full potential and optimize the game accordingly.
Now some of you are thinking “What about memory, storage devices or things like that?” And you’re right that we do consider those things, but for the purposes of this overview we are going to concentrate on the biggest items that affect performance. But bonus points all around.
An example internal debug output.
One of the important parts of performance tuning is to understand what the bottleneck is in each scene, either the CPU or the GPU. In the image above the CPU is taking 44ms per frame on a scene and the GPU is only taking 19ms. The CPU is the bottleneck in this case, so it doesn’t matter how much more optimization we do on the GPU. To improve this specific case on this specific hardware, we need to determine and target the most expensive operations on the CPU.
One of the challenges of making a PC game compared to consoles is the variety of hardware choices, specifically when it comes to CPUs and GPUs. There are thousands of combinations that someone could have, and each of them is going to perform slightly differently. That doesn’t even get into memory differences or software differences like operating system patches, hardware drivers, etc. This is why we publish minimum and recommended machine specifications - to help players understand what we have tested and if their machine should be able to play the game with adequate performance.
Now that we have some background on what developers look at for performance tuning, let’s go back up to those graphs at the top. For one, these are per-configuration graphs, which are used to tell us how the game is performing on that specific hardware. We do lots of these which help us to remove the hardware variables from the tests and just look at how the given build is performing overall. It also lets us look at this data over time and see if things are improving or not. As we add features, these will always affect performance, so we need to be checking the deltas consistently to determine where we need to spend time on improvements. The other thing these graphs help determine is if a given hardware setup has abnormal issues compared to other similar setups. A given manufacturer may have optimized their hardware in such a way that we get different performance out of certain improvements and knowing that helps us optimize the game for the entirety of our player-base across a wide range of hardware options.
[hr][/hr]We hope that this has been informative! As we work towards larger performance optimization goals in the future, we’ll be sure to share updates in posts just like this – and perhaps take a more technical deep-dive in a performance-focused dev blog, so let us know if you’d like to see that!
Thanks for reading and hope you enjoy For Science!
-The KSP Team
Here's a look at some graphs we use to understand the game's performance and the improvements that have been made to our minimum specification and recommended specification machines:
FPS between EA launch and For Science! on minimum specs.FPS between EA launch and For Science! on recommended specs.This represents a huge amount of work by the development team across a number of features and releases. With performance optimization being one of the most frequent requests since launch, we're looking forward to hearing from players how this work improves the overall gameplay experience.
If you're curious about performance tuning and how we make decisions in that area, the rest of this check-in provides a high-level overview from our Engineering Team and should provide a bit of extra context for the above graphs.
[h3]Performance 101[/h3]
As you can see in the charts, performance varies quite a bit between various scenes players might find themselves in. When we’re investigating performance-related issues, we need to investigate many variables both in the game and on the physical machine. Let’s examine the basics of performance tuning and what we look at when trying to make decisions about performance optimization.
In keeping with the theme of For Science!, we should start with defining our experiments and the measurements we will use to determine if we are moving in the right direction. So, let’s start with Frames per Second (FPS), which many of you will already be familiar with. A frame is the period required to fully recalculate what has changed in the game state and redraw the scene to the player. The more FPS, the smoother the game looks and feels, as this allows us to capture inputs quicker and update the game state showing those updates to the user in a more responsive way.
When we are digging into performance, we want to look at that value in a different way: milliseconds per frame (ms). Why would we do that? Basically, we want to understand what, in a given frame, is taking up time so we can make it faster. For a 30 FPS goal, we get 33.3 milliseconds per frame, so it becomes a lot easier to set a budget for how much time a given section of the game should take. But what are we taking time from exactly? There are two pieces of hardware we generally are looking at for performance: the GPU and the CPU.
At a high level, a Graphics Processing Unit (GPU) is a piece of hardware that specializes in the types of calculations that are needed to render a given scene. It is much faster at smaller tasks in parallel than a Central Processing Unit (CPU) but much slower at running tasks in a series. In order to get the maximum performance out of a computer, we want to use both to their full potential and optimize the game accordingly.
Now some of you are thinking “What about memory, storage devices or things like that?” And you’re right that we do consider those things, but for the purposes of this overview we are going to concentrate on the biggest items that affect performance. But bonus points all around.
An example internal debug output.One of the important parts of performance tuning is to understand what the bottleneck is in each scene, either the CPU or the GPU. In the image above the CPU is taking 44ms per frame on a scene and the GPU is only taking 19ms. The CPU is the bottleneck in this case, so it doesn’t matter how much more optimization we do on the GPU. To improve this specific case on this specific hardware, we need to determine and target the most expensive operations on the CPU.
One of the challenges of making a PC game compared to consoles is the variety of hardware choices, specifically when it comes to CPUs and GPUs. There are thousands of combinations that someone could have, and each of them is going to perform slightly differently. That doesn’t even get into memory differences or software differences like operating system patches, hardware drivers, etc. This is why we publish minimum and recommended machine specifications - to help players understand what we have tested and if their machine should be able to play the game with adequate performance.
Now that we have some background on what developers look at for performance tuning, let’s go back up to those graphs at the top. For one, these are per-configuration graphs, which are used to tell us how the game is performing on that specific hardware. We do lots of these which help us to remove the hardware variables from the tests and just look at how the given build is performing overall. It also lets us look at this data over time and see if things are improving or not. As we add features, these will always affect performance, so we need to be checking the deltas consistently to determine where we need to spend time on improvements. The other thing these graphs help determine is if a given hardware setup has abnormal issues compared to other similar setups. A given manufacturer may have optimized their hardware in such a way that we get different performance out of certain improvements and knowing that helps us optimize the game for the entirety of our player-base across a wide range of hardware options.
[hr][/hr]We hope that this has been informative! As we work towards larger performance optimization goals in the future, we’ll be sure to share updates in posts just like this – and perhaps take a more technical deep-dive in a performance-focused dev blog, so let us know if you’d like to see that!
Thanks for reading and hope you enjoy For Science!
-The KSP Team
On the launchpad we went from 77 to 91 fps
In-flight around the cloud layer, we went from 54 to 71 fps
