[To people that know how to code well] What opportunities have been gained with the farther out release date?

[mcwaffles2003]

I remember early, soon after the game was announced, there was discussions of unity updates and what they could mean for the game. As far as general  improvements, increase in scope, added functions, and so on. Not much of a programmer but I recall discussions of multi-threading rigid body physics, the (im)plausibility of it being possible, mentioning of DOTS and BURST etc.

So instead of either being sad that we have to wait another year and a half at least for the game (oh god so long...) or simply cheering on "we can wait!" / "it's done when it's done"... As a layman I ask the more coding literate among us.. What new possibilities can be considered in bounds now? What future updates would this game have missed that might now be implemented?

Edited May 31, 2020 by mcwaffles2003

[Incarnation of Chaos]

27 minutes ago, mcwaffles2003 said:

I remember early, soon after the game was announced, there was discussions of unity updates and what they could mean for the game. As far as general  improvements, increase in scope, added functions, and so on. Not much of a programmer but I recall discussions of multi-threading rigid body physics, the (im)plausibility of it being possible, mentioning of DOTS and BURST etc.

So instead of either being sad that we have to wait another year and a half at least for the game (oh god so long...) or simply cheering on "we can wait!" / "it's done when it's done"... As a layman I ask the more coding literate among us.. What new possibilities can be considered in bounds now? What future updates would this game have missed that might now be implemented?

Likely none; you don't delay a game for a year because it just needs a bit of TLC. You do it either because you showed the publisher the end result and they laughed in your face or encountered a fundamentally game-breaking issue that you'll have to slog thru and essentially rebuild the entire source code chasing the dependencies that were also broken when fixing it.

That all being said; this could be a fantastic chance to increase community engagement, get information out to modders early, and generally build a good reputation with the people who will ultimately make or break KSP2's success.

[mcwaffles2003]

2 minutes ago, Incarnation of Chaos said:

Likely none; you don't delay a game for a year because it just needs a bit of TLC. You do it either because you showed the publisher the end result and they laughed in your face or encountered a fundamentally game-breaking issue that you'll have to slog thru and essentially rebuild the entire source code chasing the dependencies that were also broken when fixing it.

That all being said; this could be a fantastic chance to increase community engagement, get information out to modders early, and generally build a good reputation with the people who will ultimately make or break KSP2's success.

So you don't think there is a chance to use or incorporate a more up to date version of unity than was originally intended? Wouldn't "essentially rebuild the entire source code chasing the dependencies" provide such an opportunity?

[Incarnation of Chaos]

5 minutes ago, mcwaffles2003 said:

So you don't think there is a chance to use or incorporate a more up to date version of unity than was originally intended? Wouldn't "essentially rebuild the entire source code cmovihasing the dependencies" provide such an opportunity?

No; because then you have to fix that same broken code. THEN target it on a newer version of Unity, and fix any issues that arose from that.

You'd be duplicating effort at the worst possible time, and that's assuming moving to that newer version didn't wake up any other nasty gremlins that you now have to chase down all over again. And the developers would be slowed down; since they would have to re-learn portions of their workflow due to various bits being depreciated/added/changed from the previous one.

[mcwaffles2003]

2 minutes ago, Incarnation of Chaos said:

And the developers would be slowed down; since they would have to re-learn portions of their workflow due to various bits being depreciated/added/changed from the previous one.

At least this part seems mitigated by the fact that they recently changed studios and turned over staff / hired a lot of new staff. Sorry if I'm being unrealistic, just trying to be hopeful.

[Gotmachine]

There are probably people that are much more knowledgeable on the subject than me on the matter, but I don't think there is much to be gained from the unity engine.
On the gameplay side, KSP isn't really a data intensive game. So while there is probably some ways to optimize a few things trough DOTS I don't see a major impact.
Although it could be quite relevant for a few things, mainly rendering bodies (PQS system, terrain features...).

As for addressing the current performance bottlenecks of KSP, people are usually focused on the physics engine, but the reality is that the physics processing barely account for a third of the CPU usage of KSP, and that proportion tend to go down with the part count.
The part-count dependent lag actually mostly comes from huge inefficencies in the PartModule system and also from the thermal, aerodynamics and resource systems.
So contrary to the PhysX engine that is very optimized, and actually multithreaded to an extent, there is a huge margin for optimization in the KSP specific core systems, and that just comes down to the skills and effort from the dev team, it has very little to do with Unity.
PhysX is being updated from v3 to v4 in unity 2019.3, but that doesn't change much. If there is any performance improvement on that front, it's likely we will get it in KSP 1 too.

Edit : I'm mostly talking about gameplay / performance here. Graphics is an entirely other matter, and I haven't got much to say about that.

Edit2 : There is zero reasons to not update to the latest bleeding edge Unity versions while they're in development. Migrating to newer versions of Unity is quite easy and usually doesn't break anything.

Edited May 31, 2020 by Gotmachine

[Incarnation of Chaos]

3 minutes ago, Gotmachine said:

There are probably people that are much more knowledgeable on the subject than me on the matter, but I don't think there is much to be gained from the unity engine.
On the gameplay side, KSP isn't really a data intensive game. So while there is probably some ways to optimize a few things trough DOTS I don't see a major impact.
Although it could be quite relevant for a few things, mainly rendering bodies (PQS system, terrain features...).

As for addressing the current performance bottlenecks of KSP, people are usually focused on the physics engine, but the reality is that the physics processing barely account for a third of the CPU usage of KSP, and that proportion tend to go down with the part count.
The part-count dependent lag actually mostly comes from huge inefficencies in the PartModule system and also from the thermal, aerodynamics and resource systems.
So contrary to the PhysX engine that is very optimized, and actually multithreaded to an extent, there is a huge margin for optimization in the KSP specific core systems, and that just comes down to the skills and effort from the dev team, it has very little to do with Unity.
PhysX is being updated from v3 to v4 in unity 2019.3, but that doesn't change much. If there is any performance improvement on that front, it's likely we will get it in KSP 1 too.

Care to elaborate on that a bit more? That's actually a new one for me.

[mcwaffles2003]

6 minutes ago, Gotmachine said:

As for addressing the current performance bottlenecks of KSP, people are usually focused on the physics engine, but the reality is that the physics processing barely account for a third of the CPU usage of KSP, and that proportion tend to go down with the part count.

The part-count dependent lag actually mostly comes from huge inefficencies in the PartModule system and also from the thermal, aerodynamics and resource systems.

Thats both surprising and unsurprising at the same time. Always thought the rigid body dynamics was a huge bottleneck but most of us know by now how much better the game behaves when its finally in space and not dealing with aerodynamics. As for resource systems, I can finally see why that's a bottleneck. I recently started using kOS for an RP-1 campaign and have been working on a "launch any rocket to orbit" type script and WOW does resource monitoring for automated staging bog the game down... 

Though there's no way I can expect kOS to operate nearly as efficiently as C# or whatever KSP is coded in. No disrespect to the kOS devs, great mod!

Edited May 31, 2020 by mcwaffles2003

[kerbiloid]

Unlikely KSP needs some physical or graphical improvement or newer versions of Unity or PhysX.

We already could see everything we can dream about, implemented in mods. So, the only actual problem is performance.

Either they have faced the performance issues and need to rework the codebase nearly from scratch, or there are some non-development issues unrelated to the programming at all.

Edited May 31, 2020 by kerbiloid

[Gotmachine]

The performance difference between aero and space situations 100% comes from KSP in-house implementation of aerodynamics and thermodynamics, which are incredibly CPU hungry.
It has indeed absolutely nothing to do with the physics engine that handle joints and rigid bodies.

8 minutes ago, Incarnation of Chaos said:

Care to elaborate on that a bit more? That's actually a new one for me.

I could go on for hours. For example, every partmodule in the game is an isolated system that does it's own thing and consume a lot of resources to do so, and in a lot of cases, all partmodules of the same type on your vessel are doing a computation that could have been done once for the whole vessel. It also mean that a lot of things that are vessel wide can only be analyzed by querying all individual partmodules.
But it's a very specific example, and maybe not the best one, since the PartModule model is also great because it allow a lot of flexibility and is dead easy to work with.
But that's the general problem of KSP. A lot of core systems are built in a kinda "brute force" way, using the simplest implementation, usually the one that require the less work.
There is very little consideration for performance at the heart of all those systems. And it shows. KSP has received a lot of "after the fact" micro-optimization, but there is so much you can do without starting from scratch.

I'm not saying the physics engine isn't a bottleneck, it is. But there are a lot of low hanging fruits in everything else in KSP.

[Incarnation of Chaos]

5 minutes ago, Gotmachine said:

The performance difference between aero and space situations 100% comes from KSP in-house implementation of aerodynamics and thermodynamics, which are incredibly CPU hungry.
It has indeed absolutely nothing to do with the physics engine that handle joints and rigid bodies.

I could go on for hours. For example, every partmodule in the game is an isolated system that does it's own thing and consume a lot of resources to do so, and in a lot of cases, all partmodules of the same type on your vessel are doing a computation that could have been done once for the whole vessel. It also mean that a lot of things that are vessel wide can only be analyzed by querying all individual partmodules.
But it's a very specific example, and maybe not the best one, since the PartModule model is also great because it allow a lot of flexibility and is dead easy to work with.
But that's the general problem of KSP. A lot of core systems are built in a kinda "brute force" way, using the simplest implementation, usually the one that require the less work.
There is very little consideration for performance at the heart of all those systems. And it shows. KSP has received a lot of "after the fact" micro-optimization, but there is so much you can do without starting from scratch.

I'm not saying the physics engine isn't a bottleneck, it is. But there are a lot of low hanging fruits in everything else in KSP.

That's like looping thru an array with a for loop every single time you want to calculate a value instead of just storing the value....i knew KSP was bad.....but i didn't know it was THAT bad...

On the bright side; it does mean that they likely haven't overstated just how much of a performance uplift a clean-sheet rebuild will be.

Thanks for the explanation.

[Gotmachine]

2 hours ago, Incarnation of Chaos said:

That's like looping thru an array with a for loop every single time you want to calculate a value instead of just storing the value....i knew KSP was bad.....but i didn't know it was THAT bad...

On the bright side; it does mean that they likely haven't overstated just how much of a performance uplift a clean-sheet rebuild will be.

Well, KSP isn't that bad. It just isn't programmed in an optimized way that scale well when there is a large amount of things in the game.
And on the other hand, most of KSP systems try to be quite physically accurate, with varying degree of success, but that's one of the main reasons why they are so CPU intensive.

A big issue in KSP is that almost everything is done in the main physics engine cycle, which has a fixed budget of 20ms (50 ups).
KSP performance bottleneck mostly comes down from the fact a lot of things that aren't related, or needed, for physics are done in the physics cycle.
It's like this because in Unity, it's the default, easy, fastest dev time way of doing it.

But for a lot of the most CPU intensive simulation features of KSP, there is very little justification in having such a rapid 20 ms update cycle. KSP is not a game were there is a need for "instantaneous" interactions between everything, like in a FPS or a RTS.
Introducing a separate custom loop that work on a larger timestep, lets say 100ms for example (and ideally on a separate thread) would allow to take out a good chunk of the CPU load from the physics loop.
The resource system, the thermal system, the orbit solver, all that doesn't need to be on a tight update cycle.
The only things that really require it are the aerodynamics and the control/thrust providing modules, because they directly interact with physics and need to react quickly to player inputs.

It's indeed an area where Unity DOTS could provide a better infrastructure, as the "legacy" Unity gameobject system is firmly tied to the "standard" Unity update cycle. But it could be done without DOTS.
Unity is a graphics engine that provide a "general purpose" game loop framework (and a ton of other features), but there is nothing preventing a developer to use it only partially and implement a more specialized system that better fit specific purposes.
That's kinda what DOTS is about, to provide some less constrained tools for specific performance intensive applications that require a custom approach, without having to implement a completely from scratch custom solution.

But a specialized game that require performance intensive computations has to implement custom solutions. You can't expect a general purpose framework made to fit any game from 2D platformers to 3D FPS to perform specialized tasks in an optimal fashion, and this is a valid point for every single game engine.
An over the top example is Principia : it's a completely custom N-body engine written in C++ that interface with Unity and KSP, but implement a high performance, multithreaded chunk of code with it's own independent update cycle, made for a highly performance constrained specific feature.

But don't underestimate the amount of work that is needed to make all those, and how complex those things are.
One of my main worries for KSP2 is that instead of implementing high performance solutions, they dumb down some subsystems/features.
Or worse, for the sake of their multiplayer or interstellar timescales ambitions, which add an order of magnitude of complexity for solving those issues.

Edited May 31, 2020 by Gotmachine

[Incarnation of Chaos]

19 hours ago, Gotmachine said:

Well, KSP isn't that bad. It just isn't programmed in an optimized way that scale well when there is a large amount of things in the game.
And on the other hand, most of KSP systems try to be quite physically accurate, with varying degree of success, but that's one of the main reasons why they are so CPU intensive.

A big issue in KSP is that almost everything is done in the main physics engine cycle, which has a fixed budget of 20ms (50 ups).
KSP performance bottleneck mostly comes down from the fact a lot of things that aren't related, or needed, for physics are done in the physics cycle.
It's like this because in Unity, it's the default, easy, fastest dev time way of doing it.

But for a lot of the most CPU intensive simulation features of KSP, there is very little justification in having such a rapid 20 ms update cycle. KSP is not a game were there is a need for "instantaneous" interactions between everything, like in a FPS or a RTS.
Introducing a separate custom loop that work on a larger timestep, lets say 100ms for example (and ideally on a separate thread) would allow to take out a good chunk of the CPU load from the physics loop.
The resource system, the thermal system, the orbit solver, all that doesn't need to be on a tight update cycle.
The only things that really require it are the aerodynamics and the control/thrust providing modules, because they directly interact with physics and need to react quickly to player inputs.

It's indeed an area where Unity DOTS could provide a better infrastructure, as the "legacy" Unity gameobject system is firmly tied to the "standard" Unity update cycle. But it could be done without DOTS.
Unity is a graphics engine that provide a "general purpose" game loop framework (and a ton of other features), but there is nothing preventing a developer to use it only partially and implement a more specialized system that better fit specific purposes.
That's kinda what DOTS is about, to provide some less constrained tools for specific performance intensive applications that require a custom approach, without having to implement a completely from scratch custom solution.

But a specialized game that require performance intensive computations has to implement custom solutions. You can't expect a general purpose framework made to fit any game from 2D platformers to 3D FPS to perform specialized tasks in an optimal fashion, and this is a valid point for every single game engine.
An over the top example is Principia : it's a completely custom N-body engine written in C++ that interface with Unity and KSP, but implement a high performance, multithreaded chunk of code with it's own independent update cycle, made for a highly performance constrained specific feature.

But don't underestimate the amount of work that is needed to make all those, and how complex those things are.
One of my main worries for KSP2 is that instead of implementing high performance solutions, they dumb down some subsystems/features.
Or worse, for the sake of their multiplayer or interstellar timescales ambitions, which add an order of magnitude of complexity for solving those issues.

If you had two loops like this; one for "On-demand" calculations that must be done as quickly as possible alongside a slower one for those that don't need that rapid of a update. Could you then put those on different threads?

Because from the sound of that; there's quite a bit on the physics loop that could be multithreaded if it was broken out like you're proposing since it doesn't actually need to be done sequentially as it's unrelated to the physics.

As for the rest; yeah you can dig thru my post history and find plenty of me attempting to explain that making a game like KSP requires a large amount of custom code. And that trying to do weird stuff like N-body, GPU acceleration of physics and etc. all puts you in a whole different level of complexity that requires much different skillsets to converge to make it all work. Many of the issues KSP faces aren't related to Unity as much as the developers not rolling their own custom solutions and trying to make the Unity implementations work where they're very much outside their intended scopes.

And for the last one; are you talking about the actual code or the game? They've been pretty adamant from the beginning that KSP2 won't dumb down the experience, and will use improved onboarding to make the learning curve less like a cliff and more like a gentle, rolling slope. Or are you saying that you're worried that the systems programmed won't be as accurate/extendable in KSP2 as they were in KSP?

[Gotmachine]

5 hours ago, Incarnation of Chaos said:

Or are you saying that you're worried that the systems programmed won't be as accurate/extendable in KSP2 as they were in KSP?

Yes. My main worries comes from the whole interstellar scope of the game.

KSP 2 will have to deal with interstellar travel time scales. Meaning they will need to run the simulation at even higher timewarp factors than what is used in KSP 1.
Timewarp is a huge technical constraint. In KSP1, almost every feature is either disabled, or doesn't work consistently when you timewarp and even more for inactive (unloaded) vessels.
The few system that are actually somewhat handled in timewarp, like the resource system, the thermal system or commnet have a special, barebone or inconsistent (to not say broken) behaviour.

Simulation algorithms that work consistently at varying, arbitrary time steps are orders of magnitude more complex. They require more processing, and they severely constraint what you can do.
And no matter how smart that code is, there is the issue that the simulation entry variables aren't constant. The whole point of a discrete simulation is that you evaluate every external variable continuously, at an interval that is faster than a significant change in those variables.
If you have, for example, an algorithm that depend on whether the vessel is in sunlight or in the shadow of body, you need to have at least a couple sampling points for each situations.
At 100 000x and 50 ups, it mean a simulation step is done every ~30 min of real time. It's already a quite low "resolution", a lot of things can change wildly during 30 minutes.
From my experience, the maximum time step that still work reasonably accurately is on the order of 1-2 minutes, which at 50 ups, correspond to a timewarp speed in the order of 5 000x
And you can see that in KSP. Going from 1000x to 10000x is the threshold at which everything start working weirdly.

Now, in stock KSP1, it doesn't matter much. First because almost every gameplay feature is only enabled in the physics, real time (4x timewarp max) bubble.
Second because the few features that are actually enabled in non-physics warp (main example is the drills/ISRU/core heat system) are quite shallow, and simplistic enough so the inconsistencies don't matter much.

But KSP2 apparently intend to have several core features for which that issue is applicable.
They have mentioned the ability to run engines during timewarp/in the background. And there is the whole colony building thing with supply chains, ISRU, etc. Those are great ideas on paper.
But by enlarging the scope of the game to interstellar timescales, and consequently to even higher timewarp speeds than KSP 1, IMO, they shoot themselves in the foot if they intended to make any non ultra simplistic and more or less physically accurate subsystem, like resource chains, thermals, comms, radiation, life support, or any time based game mechanism (science, scanners...)
In KSP1 (or in KSP 1 mods), those features have tons of issues with timewarp, but the 100 000x limit still is more or less manageable.

And on top of that, there is multiplayer, which add another huge range of constraints, although it will all depend on what is actually KSP 2 multiplayer.
Since we've got zero information on that, I won't go into technical details about what those constraints could be, but they are potentially non-trivial as well.

And finally, on a more conceptual level, and it is more my personal opinion than a technical issue, I have a problem with the whole interstellar aspect they are introducing.
IMO, the core concept of KSP, what make it an unique game compared to all other "space" games is that it is a relatively accurate, and realistic physics sandbox.
It is exactly in the sweet spot between a pure simulation (like Orbiter or MS Flight Simulator) and a "enjoyment focused" game.
It has a few simplifications, like 2 bodies orbital physics, abstracted fuel types, less constraints on engine usage (throttle, ignitions...) for the sake of gameplay, but not much.

By going into the realm of pure hypothetical, science fiction technologies, it breaks that fundamental contract.
On a surface level it doesn't change much, but it make all the dimension of attempting to model the actual, known, physical challenges of space travel and exploration almost pointless.
What's the point of a physically accurate thermal simulation if you introduce engines and energy sources of such magnitudes that they don't have an actual realistic solution in that regard ?
What's the point of a communication network with a range system when you work on distances for which there is no realistic solution ?
What's the point of a somewhat realistic ISRU/colony system when it is producing structures and technologies that are so enormous and advanced that all the current industrial capacity on earth couldn't do it ?
What's the point of representing any current space technology or goals if we are put in the realm of science fiction after a few hours of gameplay ?

Something that made me realize that is the interview with Nate Simpson and Scott Manley, where Scott Manley made the remark that SRBs can gimbal.
Why would they care ? They are focused on the color of science fiction engines exhaust plumes that make SRBs an irrelevant and obsolete technology.

That interstellar scope clashes fundamentally with anything we can relate in the current age of space exploration.
They could have done everything they are doing but with staying in a single planetary system.
There are tons of "near future" technologies they could have implemented, with actual real science and physics to back that.

So yes, I'm not thrilled.
I fear a lot of things will be very shallow, both because of the unrealistic interstellar scope, and because of the technical constraints.
I fear they are trying to much to have "exciting" features, and that in the process they will both fail at making a good game and a good space exploration simulation that is appealing to people that have an interest in relatable, current space technologies, programs and prospects.
It might be a better "wide audience" commercial strategy, and maybe they expect the modding scene to provide what they won't on that aspect.
But on the other hand, all the (speculative) technical issues I talked about might get in the way of that.
Modding is hard, it's time consuming and the difficulty increase exponentially when the features you're trying to implement have no solid ground in the base game.
Future will tell.

[DStaal]

Just to add: They've also merged into a new team, added team members, and had Covid-19 come out.  Even with nothing else being added to the game, that's probably 6 months of additional time needed to get the game out, just in adapting to the coding environment.

[Incarnation of Chaos]

On 6/1/2020 at 11:09 AM, Gotmachine said:

Yes. My main worries comes from the whole interstellar scope of the game.

KSP 2 will have to deal with interstellar travel time scales. Meaning they will need to run the simulation at even higher timewarp factors than what is used in KSP 1.
Timewarp is a huge technical constraint. In KSP1, almost every feature is either disabled, or doesn't work consistently when you timewarp and even more for inactive (unloaded) vessels.
The few system that are actually somewhat handled in timewarp, like the resource system, the thermal system or commnet have a special, barebone or inconsistent (to not say broken) behaviour.

Simulation algorithms that work consistently at varying, arbitrary time steps are orders of magnitude more complex. They require more processing, and they severely constraint what you can do.
And no matter how smart that code is, there is the issue that the simulation entry variables aren't constant. The whole point of a discrete simulation is that you evaluate every external variable continuously, at an interval that is faster than a significant change in those variables.
If you have, for example, an algorithm that depend on whether the vessel is in sunlight or in the shadow of body, you need to have at least a couple sampling points for each situations.
At 100 000x and 50 ups, it mean a simulation step is done every ~30 min of real time. It's already a quite low "resolution", a lot of things can change wildly during 30 minutes.
From my experience, the maximum time step that still work reasonably accurately is on the order of 1-2 minutes, which at 50 ups, correspond to a timewarp speed in the order of 5 000x
And you can see that in KSP. Going from 1000x to 10000x is the threshold at which everything start working weirdly.

Now, in stock KSP1, it doesn't matter much. First because almost every gameplay feature is only enabled in the physics, real time (4x timewarp max) bubble.
Second because the few features that are actually enabled in non-physics warp (main example is the drills/ISRU/core heat system) are quite shallow, and simplistic enough so the inconsistencies don't matter much.

But KSP2 apparently intend to have several core features for which that issue is applicable.
They have mentioned the ability to run engines during timewarp/in the background. And there is the whole colony building thing with supply chains, ISRU, etc. Those are great ideas on paper.
But by enlarging the scope of the game to interstellar timescales, and consequently to even higher timewarp speeds than KSP 1, IMO, they shoot themselves in the foot if they intended to make any non ultra simplistic and more or less physically accurate subsystem, like resource chains, thermals, comms, radiation, life support, or any time based game mechanism (science, scanners...)
In KSP1 (or in KSP 1 mods), those features have tons of issues with timewarp, but the 100 000x limit still is more or less manageable.

And on top of that, there is multiplayer, which add another huge range of constraints, although it will all depend on what is actually KSP 2 multiplayer.
Since we've got zero information on that, I won't go into technical details about what those constraints could be, but they are potentially non-trivial as well.

And finally, on a more conceptual level, and it is more my personal opinion than a technical issue, I have a problem with the whole interstellar aspect they are introducing.
IMO, the core concept of KSP, what make it an unique game compared to all other "space" games is that it is a relatively accurate, and realistic physics sandbox.
It is exactly in the sweet spot between a pure simulation (like Orbiter or MS Flight Simulator) and a "enjoyment focused" game.
It has a few simplifications, like 2 bodies orbital physics, abstracted fuel types, less constraints on engine usage (throttle, ignitions...) for the sake of gameplay, but not much.

By going into the realm of pure hypothetical, science fiction technologies, it breaks that fundamental contract.
On a surface level it doesn't change much, but it make all the dimension of attempting to model the actual, known, physical challenges of space travel and exploration almost pointless.
What's the point of a physically accurate thermal simulation if you introduce engines and energy sources of such magnitudes that they don't have an actual realistic solution in that regard ?
What's the point of a communication network with a range system when you work on distances for which there is no realistic solution ?
What's the point of a somewhat realistic ISRU/colony system when it is producing structures and technologies that are so enormous and advanced that all the current industrial capacity on earth couldn't do it ?
What's the point of representing any current space technology or goals if we are put in the realm of science fiction after a few hours of gameplay ?

Something that made me realize that is the interview with Nate Simpson and Scott Manley, where Scott Manley made the remark that SRBs can gimbal.
Why would they care ? They are focused on the color of science fiction engines exhaust plumes that make SRBs an irrelevant and obsolete technology.

That interstellar scope clashes fundamentally with anything we can relate in the current age of space exploration.
They could have done everything they are doing but with staying in a single planetary system.
There are tons of "near future" technologies they could have implemented, with actual real science and physics to back that.

So yes, I'm not thrilled.
I fear a lot of things will be very shallow, both because of the unrealistic interstellar scope, and because of the technical constraints.
I fear they are trying to much to have "exciting" features, and that in the process they will both fail at making a good game and a good space exploration simulation that is appealing to people that have an interest in relatable, current space technologies, programs and prospects.
It might be a better "wide audience" commercial strategy, and maybe they expect the modding scene to provide what they won't on that aspect.
But on the other hand, all the (speculative) technical issues I talked about might get in the way of that.
Modding is hard, it's time consuming and the difficulty increase exponentially when the features you're trying to implement have no solid ground in the base game.
Future will tell.

I know many of KSP's issues lied in the limited precision of available 32-bit datatypes, so this was something i was pretty worried about also. And you pretty much summarized why things like Metastable metallic Hydrogen rockets worry me so much. I do still think that they could've done "Interstellar" exploration right, and satisfied the hardcore and casual bases while doing so. But much of what's come out lately does have me wary....

So; thanks for sharing your thoughts yet again xD

[Gotmachine]

8 minutes ago, Incarnation of Chaos said:

I know many of KSP's issues lied in the limited precision of available 32-bit datatypes

That's much less relevant than what people usually think. No matter if you use 32 or 64 bit floating point precision, the distances in KSP are so huge that you have to adopt a floating origin system, and potentially even more complex implementations. It's a typical case of "if you're doing something special, you can't expect the simple generic solution to work".

[Pthigrivi]

I have almost no programming experience so I'm gonna throw out there that I'd love to see some level of automation. They've talked about some kind of supply line system where you connect up different colonies and then can share resources without the tedium of milkruns. If the game was coming out this spring I'd have guessed those would be more or less 'magic' resource dumps, but with another year and half to go it would be pretty cool if after building and flying a resource delivery the game could be scheduled to repeat that run. You might even be able to designate an area for resource gathering and have kerbals drive out and gather using harvesters you've built. This might be a tall order but if we've got colonies with dozens or hundreds of kerbals it be awfully cool if they looked active. 

[kirmie44]

On 6/1/2020 at 11:09 AM, Gotmachine said:

Yes. My main worries.... Long comment that I didn't want people to have to scroll through again.

Rebutting some points here. There are a lot of mods that add these things to the background and during time warp without much overhead or a drop in frame rates. The only mod I've seen that can't handle high time warp is Principia and that's only at the modded in higher timewarps of BetterTimeWarp. (Off the Top of my head Interstellar Extended, Kerbalism, and Background recourse monitor all add this complexity back for unloaded or timewarping vessels)

Also, IMO, the new things added by the game will be limited in there use. A lot of the new engines don't work in atmosphere, a lot of the new parts don't even fit on the ground. You have to use all the previous parts to build up to these new parts. It looks like what they have won't be really useful for anything that isn't gigantic. Also, I'm excited for different forms of propulsion. They are going for the Near Future vide so I can't see it being overpowered. They won't be too complicated either, we already have nuclear engines, Aerospikes & Rapier engines that are only slightly closer to the realm of possibility than what they are proposing. Hell, engines like the nuclear pulse engine would be a reality if we weren't worked about our planet or breaking treaties.

Disclaimer: (edit) not a proficient coder so that fist part is more of a question. I know coding but have developed nothing so take my words with a grain of salt

Edited June 6, 2020 by kirmie44
Disclaimer

[sao123]

I've been a software developer team manager for about 5 years and a developer for the 8 before that, mostly in data drive web applications.

I can tell you they will gain very few, if any opportunities with the extra time.

 

the disruption to the organization of the team, and the departure of some key members, is going to for sure make it take longer to get what you would have previously got under the prior team, you have less people doing the same amount of work.  Furthermore even if they hire new replacements immediately, it is going to take a lot of time for those new developers to get up to speed and become an effective part of the team.  Its more than just knowing how to program.  You have to understand the requirements, understand the architecture, understand the development processes of this specific team, get comfortable in a role and begin to be productive.  Most new hires usually take 8-12 months on the job before they are truly productive in the middle of a large project.

That doesnt take into account any changes that are being made to the requirements or design of the game as part of this reorganization.

 

Even though we are talking about replacing lost people instead of adding additional people, most of the principals and corollaries of the "Mythical Man Month" still apply.  Anyone interested in the topic should check out some brief youtube videos on the concept.

https://www.youtube.com/watch?v=Xsd7rJMmZHg

https://www.youtube.com/watch?v=Fp2GWaahvio

 

[K^2]

On 5/31/2020 at 3:13 AM, mcwaffles2003 said:

I remember early, soon after the game was announced, there was discussions of unity updates and what they could mean for the game. As far as general  improvements, increase in scope, added functions, and so on. Not much of a programmer but I recall discussions of multi-threading rigid body physics, the (im)plausibility of it being possible, mentioning of DOTS and BURST etc.

So instead of either being sad that we have to wait another year and a half at least for the game (oh god so long...) or simply cheering on "we can wait!" / "it's done when it's done"... As a layman I ask the more coding literate among us.. What new possibilities can be considered in bounds now? What future updates would this game have missed that might now be implemented?

First, let me address physics. I lead an engine team, and animation and physics are my focus areas. We have an in-house physics engine which can compete with what's on the market, and will probably surpass Unity in a few important ways. What I've seen from KSP2 development on physics is not encouraging, and it has nothing to do with the time they have, but the very approach they've taken. Kraken shouldn't be a thing in KSP. Never should have been even in the original version. Certainly should have been fixed by now. KSP2 was a new start that would allow them to build it correctly from scratch, and they clearly haven't made use of opportunity. Given that vacancy for physics engineer is open, I don't see how they'd change such fundamental thing as craft physics by release.

Lets start at the beginning. The fundamental concept in mechanics simulation is rigid body. It's an object that we take to be perfectly inflexible and incompressible. In KSP, pretty much every part is a rigid body. Some parts that have built-in joints have multiple rigid bodies, but if you think of things like fuel tanks and engines, each is a rigid body. You can't stretch them, can't bend them, and you can't break them into parts - only destroy the part entirely. (Which might spawn new rigid bodies for debris, but that's a separate story.) The rocket is built up of multiple rigid bodies, and there are several approaches of dealing with that. The most general approach is what game physics engines are all about and that is joints. If you want parts to stick to each other "solid", you use a weld joint. That's a joint that prevents relative motion and relative rotation of two rigid bodies. So if you attach two fuel tanks together, you can throw a weld joint in between, and now they behave like one fuel tank. Mostly. See, joints aren't perfect. They can't be, because there is finite precision in the simulation and the solver. I can read several lectures on details, but what it ultimately comes down to is that in pretty much every simulation used in games, any weld joint comes down to a very stiff spring. And that means that if you apply enough force, the joint will bend and stretch. And if you don't have enough damping, it can even have resonances. This is how the standard solver in Unity works, and Squad simply leveraged it for KSP. [Kraken is now following this thread.]

But we didn't have this problem with a single rigid body. We can simulate it as a perfectly rigid object and have no worries. Well, we can do the same thing when we join things together. Instead of treating two tanks stuck together as two rigid bodies and a weld joint constraint, we can treat the two tanks stuck together as a single rigid body. The mass is just a sum of the two, new center of mass is easy to compute, and there is a formula for how to combine the two moment of inertia tensors, so that the combined object responds to torques correctly. This has been known for hundreds of years. What's the problem? Well, real rockets aren't actually rigid. Technically, no part of them is, but the full rocket certainly flexes under enough stress. And it's also not indestructible. Apply enough stress and it will snap. Obviously, ability of the rocket to break is something we want to preserve for the game. Fortunately, this is still pretty easy. We can actually solve for the motion of the rocket as a rigid body and then use that solution to figure out what the forces on all the welds would need to be. This approach still gives us a rigid rocket, but it lets us find out when forces got too much and lets us break the rocket if that happened.

But what if we really want the flex? For a typical rocket, this really shouldn't make a noticeable difference, but if you look at wings of an airplane in flight, for example, the flex is quite visible. So if we want to be realistic, that should be accounted for. Fortunately, the amount by which any given part can deform before breaking is strictly limited. We can actually treat this as a linear problem. Compute stress on each part, and based on that, output the deformation. The simulation still treats the body as rigid for purposes of kinematics, as the shape hardly changes overall to a significant degree, but visual model and collision model would flex under stress. This would let the airplane wings flex under load, and even cause part collision if flex causes them to come in contact. The amazing bit is that all of this is computationally cheap and can be done in Unity entirely within C# component scripts. This can still cause destructive resonances, but only if you have forces that would oscillate with flex. So if you attach engines on long poles, the ship could shake itself apart, just like the real one would. But there would be no Kraken. Absolutely no way for a ship to just spontaneously explode, because there are no unbalanced internal forces! [Kraken has reported this post to moderators.]

An argument can be made that KSP was initially built to leverage Unity physics without building a custom system. Later, Squad chose not to completely redo the physics, so as to keep the game working roughly the same way. I question this somewhat, because Squad clearly tried to address Kraken with multiple joints thrown in on connections and tuning the system, changing craft physics and strut-to-tank ratio in the process, so they could have replaced the system entirely with a better one, but they chose to tune the existing model instead. And things got better, but never fully under control. Regardless, KSP is the way it is. KSP2 could have started from scratch and built that system right. A good physics engineer would have. I don't know if ST didn't have one, or if that engineer got overruled by people who don't understand how any of this works, but we clearly didn't get a replacement system. Early footage of KSP2 shows a regression to how KSP used to look early on, with boosters bouncing all over the place, causing self-collision problems. And that's a real shame. This is something that just shouldn't have been a thing in KSP2. At this point, even if they hire a good engineer tomorrow, I don't know if they have time to fully address it in a year.

 

On to other factors. KSP can have fairly complicated interactions between components. In KSP2, a lot of component code needs to be synchronized across network for multiplayer. There's a lot of custom code for UI, controls, and space center management. All of these things can use polish. They can always use polish. Lack of polish can cause performance issues, from bad framerate to lag spikes, and it can cause loss of network sync and crashes. The more time the team can spend on all of these the better the game will be. We aren't talking about game playing differently, but rather just players having better experience. Smoother framerate, smoother controls, less disconnects, less crashes. All good stuff.

Can we expect these improvements? Hard to say. On top of delay, we also have disruption of work due to team transition. And keep in mind that if the game is shipping on consoles, Intercept now has less than a year until they have to submit code. Yes, it takes that long. And they're still a bit short on staff, on top of making up for whatever uncertainty there was in the past few months. From perspective of general stability, they'll definitely at least make up for it by having pushed out the date this much and maybe even get a little ahead. I expect that UI will be more polished and responsive and possibly the game overall will run smoother as a result of additional time.

Multiplayer is a red light right now, because they did have to hire a new networking engineer and they are still looking for a multiplayer designer. Realistically, I'd expect some network stability problems at launch. Shouldn't impact single-player, hopefully, but you might want to be prepared to delay building that Mun base with your friends for a few months after launch to avoid disappointment. I'd like to be wrong on this, but I also think it's better to have low expectations that get exceeded in this particular case.

 

One more thing we can talk about is rendering. There's not a whole lot you can do about rendering engine - it's Unity. But you can do a lot with shaders, which is a kind of programming. I have a lot less experience with graphics than other parts of the engine, but typically, this is just the case of the more time you have the better. The early pre-alpha footage we've seen needed a LOT of graphics work. But a lot of that could have been lack of content. It looked like Star Theory spent a lot more time working on assets for the ships than environment early on, and maybe that makes sense in terms of getting to alpha, but I really hope they've been putting some work into environments since, as that really helps to make the game look beautiful. So long as there is not a lot of work having to be abandoned and restarted due to whatever changes, artists and technical artists should just be making the game better and better looking with every month. It also sounds like a lot more of their creative team survived the transition, so I think this is going to be a pure win.

 

On the net, if the game was to be rushed, I would expect Kraken special even on relatively small vessels with unplayable multiplayer, occasional lag spike, and some blandness or obvious flaws in graphics. If instead given sufficient development time, I think they'll tune the physics a lot better, but at release it's still probably going to be worse than KSP is right now, the network will probably be at least playable, but I still expect at least some stability problems, and the graphics is where I expect most gain due to delay. Both rockets and planets should look better for the wait.

What remains entirely unclear to me is how much of the delay is to cover the "the game's just not even finished", which at least some of it clearly was, and how much will go into polish. That will shift the balance between the two extremes above. I suspect, it will land somewhere in the middle and we'll get the rest of the way with patches.

 

And, of course, I'm basing all of this on VERY limited information, armed more with my experience with other studios and knowledge of Unity engine than facts about KSP2 development specifically.

Edited June 7, 2020 by K^2

[jimmymcgoochie]

I'm working in a software development team right now (as a tester, not a developer) and when we started this project the team lead thought we could have it done by June. LAST June. A year later and we're still working on getting a considerably reduced system out to the first users, mostly for a single reason.

Initially we had 200 or so word document templates that needed to be converted so that the new system could ask the user for data and insert it in the right places to then make PDFs. We thought we could get 10 done per week, maybe up to 20 a week for the simpler ones. Turns out, when you're dealing with legal notices from a government department, there are many many MANY different rules and regulations (written into legislation, too!) about exactly what you should send and when, so we'd need one version to a homeowner, another to a bank that homeowner had a mortgage from and yet another if it was an odd-numbered day of an even-numbered month and the four digits on the clock added up to a multiple of 3, 5 or possibly 19 but only if the moon was in its waning phase. (OK, that last one was made up, but it's a bit of a running joke in the project about the almost arcane rules we need to follow sometimes...)

The work was far more complex than we had first thought, so there was a big delay. KSP2 may well have run into a similar problem, and if development essentially ground to a halt last December and barely got restarted before the current pandemic, it's hardly surprising that there are substantial delays.

[K^2]

13 hours ago, jimmymcgoochie said:

but only if the moon was in its waning phase.

True story. I worked on a game, which shall remain unnamed to protect the innocent, where a bug was reported that was only happening on the full moon. After a few rounds of, "No way" - "But look at the crash reports," it was finally discovered that there was some old code for an event that was supposed to happen on the full moon years ago. The event was no longer happening, but the code checking for conditions and setting the variables was still getting called, and that change in state cascaded to an occasional crash due to unrelated mistakes in code. That bug got fixed, but since then, I take correlations between code stability and phases of the moon a bit more seriously.

[mattinoz]

15 hours ago, K^2 said:

First, let me address physics.....

And, of course, I'm basing all of this on VERY limited information, armed more with my experience with other studios and knowledge of Unity engine than facts about KSP2 development specifically.

Indeed how do we know they are still using classic rigid body physics?

When they started talking about KSP2 there was a lot of humble brags about the new things in the game that made me think they must be doing something very different to KSP1. Unique Snowflake explosions, reduce physical loads, bigger craft, LOD Physics to speed things up and to get larger craft, setting up for a decade of development. All of the above plus they have ruled out a save file importer. Yet they have said the core game is respected, maintained and expanded. Something in that doesn't add up to me. It sure sounds like some very core part of the game is radically different. 

I guess the only way to guess is if there was any member of team who would lead to thinking they were doing something different. Until they say we just don't know what the secret sauce might taste like. So far all the dev notes have been about reassuring the community while softly softly introducing ideas that might generate ire. 

We'll know when we know seems to be the take away. 

[Incarnation of Chaos]

49 minutes ago, mattinoz said:

Indeed how do we know they are still using classic rigid body physics?

When they started talking about KSP2 there was a lot of humble brags about the new things in the game that made me think they must be doing something very different to KSP1. Unique Snowflake explosions, reduce physical loads, bigger craft, LOD Physics to speed things up and to get larger craft, setting up for a decade of development. All of the above plus they have ruled out a save file importer. Yet they have said the core game is respected, maintained and expanded. Something in that doesn't add up to me. It sure sounds like some very core part of the game is radically different. 

I guess the only way to guess is if there was any member of team who would lead to thinking they were doing something different. Until they say we just don't know what the secret sauce might taste like. So far all the dev notes have been about reassuring the community while softly softly introducing ideas that might generate ire. 

We'll know when we know seems to be the take away. 

Because anything else would be more computationally expensive or require (More) custom code, so due to the time constraints it's really the only option. And the issue with saves wouldn't require some massive under-the-hood change; it literally could be just the names of parts and such being a single letter different and the lookup failing. And then on top of all the new systems they decided that instead of supporting a feature that wouldn't do anything but generate mounds of hard-to chase bug reports, along retaining all the old parts from KSP that they'd just say "No".

The file structure could also be different, and KSP2 wouldn't "Understand" a KSP save file and know how to load it.

But yes; much about KSP2 won't be known until we get actual production code in hand and play around with it.