Hi, this is Paul Furio and I’m the Senior Manager of Engineering on KSP2. As I like to tell the software engineers on our team, I have two jobs. First, make sure all the code that makes up Kerbal Space Program 2 does what we expect it to do, delivers amazingly fun features, is highly performant and stable, and ships on time. Second, help every engineer on the team to grow their careers and become better versions of themselves.
When I think about engineering for the next Kerbal chapter, I’m working with the engineering team to balance out a variety of different requirements. For example, how do we take advantage of the hardware capabilities of modern gaming systems and deliver an experience that is beautiful and cinematic? Obviously we’re building on an updated version of the Unity 3D game engine, which brings a large number of visual and performance improvements to the table. But we’re also working with people behind some of the biggest Unity features and plugins so that we can offer incredibly detailed stellar body surfaces from approach, through orbit, right down to surface landing, all while maintaining a smooth frame rate for our brave green astronauts.
Next, how do we deliver an experience that grows beyond just a single star system? Because of the enhanced scale of the game, we had to update how we handle positioning. To quote author Douglas Adams, space is “vastly, hugely, mind-bogglingly big”, and representing the relative locations of ships, planets, and distant star systems requires a bit of cleverness. Even on a modern CPU that can handle 64-bit math with ease, if we state that our lowest spacial resolution is 1mm (which, honestly, is not nearly small enough for what we do), the maximum signed distance we can represent is 9.2 Trillion kilometers, which is just shy of a Light Year. We could use double-precision floating-point values, but then we start to lose fidelity as the numbers grow larger, which leads to instability in physics and jumpy positioning as we move away from the origin. With interstellar travel being so important for Kerbal 2, we’ve solved this by implementing a Spacial Scene Graph at Interstellar Scales, which allows us to arbitrarily “break off” sections of space and simulate them with a high degree of precision while still fully understanding their physical and positional relationship to the stars and planets around them, and all while not sacrificing compute performance that might slow down frame rates or lead to spaceships that are more wobbly than our Kerbal Engineers intended!
How do we deliver new spaceflight challenges and experiences? We’re enhancing our physics simulation above and beyond the original Kerbal Space Program to account for some more complicated orbital dynamics. One example that has already been shown in the trailer are the binary planets Rask and Rusk, which orbit each other. One approach to simulating this would be to have an invisible gravitational center point between the two worlds, but this would make orbiting Rask and Rusk just like orbiting any other body, with slightly different parameters for collision, and the side effect that ships would be drawn to the barycenter between the two bodies. We’re aiming for a higher degree of realism. Instead, in the case of Rask and Rusk, we’ll be calculating the gravitational pull of multiple bodies on our Kerbal vessels, so that developing a stable orbit in complex conditions like a binary planet system becomes a new and exciting challenge! In addition, attempting a landing on Rask or Rusk will be a different experience depending on the location of the sister planet in relation to your target for touchdown, and yes, there will be an astable Lagrage point between the two planets (if we pull this off correctly). Full system n-body gravity is, of course, not planned for KSP2, as it would be overly compute intensive and also require complex station keeping on all vessels in orbit that, we feel, distracts from the fun of the game. However, we look forward to how players will deal with, or take advantage of, some of the interesting properties of the special cases where physics gets far more interesting than we’ve grown accustomed to in the original Kerbal Space Program.
A final exciting engineering challenge is around Multiplayer. My first role as a software developer in the games industry (several decades ago) was writing the network code for some automobile racing and real time strategy games, so I have a long-time passion for how we make our game experiences able to be shared between friends. We have dedicated engineers on our team to ensure that playing with your friends, docking at each other’s colonies, and trading resources is a fun and seamless experience whether you’re playing in the same room, across campus, or with friends who might as well be on another planet.
Of course, delivering all of this in a stable, high performing manner, across multiple platforms, takes time. At launch, we want to ensure that the only crashes we experience are the onscreen “Rapid Unscheduled Disassembly” of our Kerbal-commanded ships. Despite the unprecedented challenge posed by the global pandemic, we’re still coding away on KSP2 from the safety of our homes thanks to the magic of distributed development, and the unsung heroes of our IT department, who have kept our team humming along. Every week we see new features added, and we’re super excited to be working towards delivering an amazing new experience for all our fans and players.