Propelling KSP 2 to New Frontiers: A Call for Technological Evolution

[ShadowDev]

Dear Intercept Games Team,

I hope this letter finds you all in good health and high spirits. Let me start by expressing my deepest appreciation for the dedication and passion you're pouring into Kerbal Space Program 2 (KSP 2). Since the game's inception, I've been an ardent supporter, following every update, and looking forward to the revolutionary gameplay experiences I know you're creating. It's my unwavering belief in the KSP 2's vision, coupled with my dedication as a member of its community, that has driven me to develop various mods to enhance our collective gaming experience. Among the numerous mods I've crafted, the "Better Parts Manager" stands as a prime example. This mod, specifically designed to alleviate lag issues within the parts manager, is just one testament to my commitment to improving the gameplay. Each mod I've developed is a reflection of both my passion for the game and my understanding of its intricate mechanics.

However, as a concerned fan and a technically inclined individual, I've noticed some technical nuances within the game that I believe are worth addressing to elevate the overall player experience.

Understanding Unity's Single-Threaded System:
At the heart of KSP 2's operation is a system that can be likened to a single assembly line, where every item (or game element) has to wait its turn to be processed. In simpler terms, each part of the game, is handled one by one, in a specific sequence, for every frame or update.

Think of it as reading a list of instructions. If the list is short, you can quickly read through it. But if the list grows longer, with more detailed steps, it takes much longer to read and follow.

The Problem with Parts: Every additional part in KSP 2 is like adding another instruction to this list. Whether it's a new engine, a fuel tank, or a landing gear, each part demands its own set of computations – from how it interacts with other parts, to how it responds to in-game physics. As players design more intricate spaceships with numerous components, the list becomes extensive. A single-threaded system would go through each instruction for every part, sequentially, causing a longer wait time before the entire cycle completes for a single frame.

Multiple Ships, Multiple Challenges: Beyond the intricacy of individual ships, players often have multiple ships operating concurrently – whether orbiting planets, docked at stations, or exploring new frontiers. Each ship, with its multitude of parts, represents its own list of instructions. The single-threaded system, bound by its nature, processes each ship's instructions in sequence, extending the cycle further. So, while one ship's physics and interactions are being computed, all other ships are in a waiting line, leading to even longer frame processing times.

In a gaming context, this sequential processing translates to lag and delays, especially as the game world becomes richer and more complex. It's like trying to watch a high-definition movie but experiencing pauses because the player can't process the data quickly enough.

and that's all without adding on future updates with colonies and gigantic interstellar ships with 1000's of parts.

The Evolution of CPUs and the Need for Multi-Threading:
Understanding the concept of single-threading and multi-threading can be likened to the evolution of our workplaces over the years. When Kerbal Space Program (KSP 1) was developed roughly 12 years ago, computer processors (CPUs) were akin to small offices, with typically 4 main workstations (or "cores"). Assigning one primary task (or "thread") to be handled sequentially in such an environment made sense. It was like having one main project and four employees with one working on the project (the game) while the others worked on other projects (the os). 

Now, fast forward to today, and imagine the office has expanded exponentially. Modern CPUs have grown to have 8, 16, 32, or even more cores, similar to an office having multiple departments with numerous employees in each. If we continue to assign just one main project to one worker, it means that while one department is working, all others are waiting idly. This is not only inefficient but also a waste of potential, given the manpower available.

Multi-threading is like breaking down a project into multiple sub-projects and assigning them to different departments simultaneously. In the context of KSP, consider each spaceship part as a sub-project. In KSP 1, when your spaceship had a few parts, a single-threaded system could manage. But as players demand bigger and more intricate spaceships in KSP 2, the system can become overwhelmed, leading to lag and reduced performance, especially when we have so many more "departments" or cores available for work.

So, while single-threading was apt for the time when KSP 1 was released, due to the limited "office size" of CPUs, it's now outdated for the grand vision of KSP 2. The tech world has evolved, with CPUs boasting more cores, and to harness this power fully, multi-threading is imperative. It's like modernising our office's workflow to ensure every department and employee is engaged, optimising productivity and efficiency.

The Issue at Hand:
While KSP 2 is ambitious and promising, adhering to the older single-threaded model will restrict its potential. There could be a temptation to leave out certain features or simplify game mechanics to ensure smooth gameplay, Like in ksp 1. A clear manifestation of this limitation is the game lag with even a small number of parts, an outcome of its single-threaded nature.

The Potential Solution – Unity's DOTS:
Unity's Data-Oriented Technology Stack (DOTS) is a cutting-edge framework designed to harness the power of multi-threading and optimize game performance for contemporary hardware. DOTS streamlines processing, allowing for simultaneous computations, making it immensely more efficient than traditional single-threaded systems. By adopting DOTS, KSP 2 can achieve the agility and scalability essential for its ambitious goals, ensuring a seamless and enhanced gaming experience while preserving its unique intricacies.

To sum up, my intention isn't to critique, but rather to provide constructive feedback that I believe could immensely benefit KSP 2 and its expansive community. I trust in the game's vision and your team's capabilities, and I'm optimistic about what the future holds for KSP 2.

Sending my best wishes and looking forward to the game's continued success,
Kind regards,
ShadowDev

[gluckez]

I'm pretty sure pretty much any development team knows what concurrency is.
Applying asynchronous programming can be very beneficial in most cases, but does not come without it's caveats.
When applied to something like a ship, and all its parts, there's a lot you need to account for that could end up 
costing you more resources. One of the issues is that parts of a ship also react to other parts of the ship, not
just it's environment. So even though each part can concurrently interact with the environment, any update
on a part will need to impact connected parts as well, which is something that, when done concurrently, would
need to be simulated in memory and may actually cost you more computing power than if you would just do it
synchronously.

I do agree that DOTS is a super powerful solution, but it might be more interesting for loose parts and procedures,
especially if you can properly leverage it's data oriented aspect and the burst compiler.
in the long run, this is definitely something that they should aim for though, so it's a discussing that they should really
have internally.

[dandoesstuff]

cool

[shdwlrd]

It was mentioned that they intend on using DOTS for later parts of the game. (Primarily the background resource tracking.) Intercept knows the flaws of KSP1 and intend on not repeating them. (How successful they will be has yet to be determined.)

[Spicat]

15 minutes ago, shdwlrd said:

It was mentioned that they intend on using DOTS for later parts of the game. (Primarily the background resource tracking.) Intercept knows the flaws of KSP1 and intend on not repeating them. (How successful they will be has yet to be determined.)

Since when? Citation needed because DOTS is production ready (at least from official statement) since a few months ago only.

[shdwlrd]

25 minutes ago, Spicat said:

Since when? Citation needed because DOTS is production ready (at least from official statement) since a few months ago only.

 

 

[VlonaldKerman]

Great post. I think this is a microcosm of a general theme with style over substance (as far as we know- maybe they’ve got big things planned on the backend). I made a thread about this kind of thing a while ago:

I suppose we can add multi threading to the list.

2 hours ago, gluckez said:

I'm pretty sure pretty much any development team knows what concurrency is.

I think he was explaining it for the benefit of other forum users.

[cheese3660]

Just now, VlonaldKerman said:

I think this is a microcosm of a general theme with style over substance

I have to disagree, there are a few valid arguments as to why they didnt use the DOTS/Entities system, the main one being that it was not fully released out of preview until last year, while the game has been in development for longer than that.

[VlonaldKerman]

12 minutes ago, cheese3660 said:

I have to disagree, there are a few valid arguments as to why they didnt use the DOTS/Entities system, the main one being that it was not fully released out of preview until last year, while the game has been in development for longer than that.

Yes, you may be right. However DOTS is not the only way of doing multi threading- with how much KSP 2 is supposed to be “ground up” I would think that building the game with multi threading would be a priority from day one.

I’m pretty ignorant about this technically, but am I way off?

[PDCWolf]

4 hours ago, shdwlrd said:

Intercept knows the flaws of KSP1 and intend on not repeating them.

Lmao.

Regarding multi-threading, there's lots of evidence to it already being implemented, specially with the visible racing issues that plagued earlier builds. They also mentioned at least once that part of the performance optimizations down the road include "pushing processes out of the main thread".

As a side note, hunting for every bit of information when they seemingly fire it off from a shotgun and it lands wherever gets tiresome. We need a proper compilation thread for all the stuff they've promised said regarding this or other topics.

Edited August 23, 2023 by PDCWolf

[CorkyTheCactus]

Bold to think this dev team is capable of handling something like multi-threading. 

[dok_377]

This is strange. If you think that the developers are good and you have faith in them, then surely you would think that they know what multithreading is already. This simplified explanation kind of implies the opposite. 

[ShadowDev]

Just now, dok_377 said:

This is strange. If you think that the developers are good and you have faith in them, then surely you would think that they know what multithreading is already. This simplified explanation kind of implies the opposite. 

The explanation is for the average joe.

[GradientOGames]

7 hours ago, ShadowDev said:

The Potential Solution – Unity's DOTS:
Unity's Data-Oriented Technology Stack  

I've been advocating for the use of DOTS for years, however it is nice to see someone more recognisable in the community wanting the implementation of this technology as well.

I'm sure there's a small handful of unity users in this forum who despises those who blame the engine, when they provide solutions to these problems.

Admittely I've been datamining KSP2 (I know, I'm a horrible person) and I've found no DOTS packages, no C# job system package, and no entities package. This is very dissapointing as, speaking from experience, converting an existing project to DOTS is an absolute nightmare! I hope the KSP2 devs have an easier time converting KSP2 to DOTS... assuming they don't give up doing so...

[Dakitess]

Uh... But MultiThreading is already a thing for multiple craft, nah ? I read the opposite in the OP. 

[ShadowDev]

13 minutes ago, Dakitess said:

Uh... But MultiThreading is already a thing for multiple craft, nah ? I read the opposite in the OP. 

nope. everything runs on 1 thread. 

[Dakitess]

Hmm... It's not what I witness, maybe it's incomplete / dirty, but when I decouple a substantial part of my ship / rocket / whatever, the parts all remain active and calculated (the amount of part is not reduced as long as it's in the physical bubble) but the calculus are spread on other threads, at least some part of the calculus. Same goes when I decouple a part if my orbital station, framerate goes up and is the same whatever the craft i'm active on, more than the whole thing stacked together. And if I redock, bam, framerate lower because one craft, one thread.

Am I missing something ?

Edited August 24, 2023 by Dakitess

[ShadowDev]

The game has no multithreading, so thats not true. everything shares the same thread.

I cant share the code but if you want to look at the decouple code you can find that in Module_Decouple starting line 213

The fps gains will probably be from the less complex resource graph. 

Also there's no physics bubble in ksp2, it has a render bubble style thing where the craft will pop into and out of existence. all launched craft & all parts are always running.

[Dakitess]

Okay ! Thanks for the information, I really though it was something related to multithreading and it was a hit word by the time an update actually brought this "framerate optimization" (whatever the cause then) when you would decouple / separate one craft into 2 or more. I don't remember anyone pointing out it was not related to multi-thread / multi-core, although it was nothing miraculous by any mean and more like a "good to have" update which would include some very specific edge case of multi threading. But it's not, apparently ! You sure, though ? ^^

Edit : I actually struggle finding back all the "now one craft will be allocated to one core / thread, so when you have 2 craft near eachother, you'll have way better performance than before the update" blablabla, but I found some that clearly say that, but I would totally understand that it was an overstatement from people who don't really know what is up about it.

Edited August 24, 2023 by Dakitess

[cocoscacao]

32 minutes ago, ShadowDev said:

The game has no multithreading, so thats not true. everything shares the same thread.

Wat? Even electric/fuel/whatever consumption? Off the top of my head, I don't know if multithreading is a reliable thing to do there, but... None? Terrain rendering? Anything? 

[Lyneira]

3 minutes ago, cocoscacao said:

Wat? Even electric/fuel/whatever consumption? Off the top of my head, I don't know if multithreading is a reliable thing to do there, but... None? Terrain rendering? Anything? 

I was under the impression that KSP2 does do some of the work in other threads like rendering and sound but all of the vessel simulation (which is really the bulk of the CPU work) happens in one thread because it's so interdependent on each other that it's hard to parallellize.

As for Multithreading being the solution:

The game is supposed to scale to dozens of vessels/colonies with thousands of parts in total that will all be running physics simultaneously, yet it has performance issues with even moderately sized ships and no others running in the background. That's before we get into interstellar, colonies and multiplayer, which will all demand players to add more stuff that, as the game currently stands, has to be tracked at all times. Multithreading can help harness untapped potential from our hardware but without optimization it won't really solve the issue. To make the game scale, it will have to be smarter and avoid doing simulation work every game tick that isn't strictly necessary.

[cocoscacao]

21 minutes ago, Lyneira said:

To make the game scale, it will have to be smarter and avoid doing simulation work every game tick that isn't strictly necessary.

Not familiar with Unity, so I don’t know if every thread responds to game's tick at the same time. 

I guess they can delegate threads to non-focused vessels, and to those that are not in the vicinity of the focused one. Sounds simple... in theory, that is... 

[Socraticat]

This is the most fascinating critique/suggestion/discussion this forum has had in a while.

Thanks @ShadowDev

[Spicat]

1 hour ago, cocoscacao said:

Wat? Even electric/fuel/whatever consumption? Off the top of my head, I don't know if multithreading is a reliable thing to do there, but... None? Terrain rendering? Anything? 

Terrain generation would be on the GPU side, so the task will obviously be parallelized because that's what the GPU is good at.

In my comprehension, physics of the craft are dependent of each other and that's why multithreading was difficult or next to impossible when they started development.

Unity DOTS seems to be a wonderful thing (I don't actually know much about it) but it was shown in 2018 for the first time and only fully released 3 months ago so that's maybe why they didn't use that yet. I don't know how much time that would take to overhaul their physics system with that though, it might be not worth it currently.

[cocoscacao]

6 minutes ago, Spicat said:

In my comprehension, physics of the craft are dependent of each other and that's why multithreading was difficult or next to impossible when they started development.

Don't know about dots either. I don't know if it can solve whole problem. Games usually don't have things like docking.