Did the developers take the wrong approach to KSP2?

[CMDRennie]

Disclaimer: While I have not yet purchased KSP2, I have been following the development and launch though the dev’s own promotional material and player reviews. The following are just some personal views and observations.

Being a long-term player of KSP, I was excited at the announcement of a sequel. But I was also apprehensive as to the direction the game would be taken. I had been playing flight sims on and off since 2004, so when I came across KSP it was the perfect union between a simulation game and physics sandbox I didn’t know I needed.

KSP2 has the potential to take that unique formula and expand it, unshackled by it’s predecessors roots as a simple unity project. It is my understanding that KSP2 was written from scratch, and does not borrow source code from KSP1 (please correct me if I’m wrong). This should have left the doors wide open for a radical re-imagining of what KSP (and space sims as a whole) could be. Instead, the developers chose to make Kerbal Space Program, again. Albeit, with some very welcome quality of life improvements and graphical upgrades. Because of this approach, I’ve seen bugs and physics problems have either been solved or alleviated in the original for years, re-appear in the sequel. For example, wobbly rockets, which is an inherent problem of a vehicle made from dozens of interconnected parts, was worked around in KSP1 using struts and later auto-struts. KSP2 presented the developers with an opportunity to redo the vehicle assembly and parts physics from the ground up. But instead, in an attempt to stick with the familiar ‘pick and place’ building method, they have given themselves the same obstacles they already overcame years ago.

The tutorials, while not a big deal for plyers like myself, are an important part of making an otherwise technical game accessible. But if the developers felt that the accessibility of the first game is lacking, I see no reason why that tutorial system could not have been added in an update.

The feature set to come to KSP2 during its early access development are exciting, but it’s hard to ignore the fact that most, if not all of these features are already available though KSP1’s modding scene. And while I’m sure that these feature can be well implemented by the devs, to me, it still doesn’t justify the sequel on its own.

I would have liked to see an overhaul of the vehicle assembly system, including: Fully procedural parts like fuel tanks, engines and even habitation and command modules. N-body physics instead of sphere of influence orbital mechanics (even if it is just for the currently active craft). And maybe even control of kerbals inside spacecraft and habitation modules. But It's looking like we're not going to get the next generation space sim we've been hoping for.

Thanks if to made to the end of my ramble, I needed to get this off my chest. Fly safe!

[J.Random]

36 minutes ago, CMDRennie said:

N-body physics instead of sphere of influence orbital mechanics (even if it is just for the currently active craft).

My understanding is that it's impossible to have both in a consistent, reliable way. They don't transform into one another, so you either integrate all the time, or you have patched conics. Which is why I'm very suspicious of devs' claims that the 3-body will be implemented for the binary (and only there and nowhere else), and that it won't be done through barycenter hack.

[CMDRennie]

Quote

My understanding is that it's impossible to have both in a consistent, reliable way. They don't transform into one another, so you either integrate all the time, or you have patched conics. Which is why I'm very suspicious of devs' claims that the 3-body will be implemented for the binary (and only there and nowhere else), and that it won't be done through barycenter hack.

With other space games like Universe Sandbox and Children of a Dead Earth having 3 or N-body physics, it makes KSP feel dated and simplistic by comparison. I know it’s not an easy problem to solve, but it’s one of the many mechanics which KSP2 could have used to become more advanced than KSP1. Personally, I wanted to see a lot more realism from the game mechanics to give veteran players of KSP some new and interesting challenges.

Edited February 25, 2023 by CMDRennie
Quote other comment

[RayneCloud]

31 minutes ago, CMDRennie said:

With other space games like Universe Sandbox and Children of a Dead Earth having 3 or N-body physics, it makes KSP feel dated and simplistic by comparison. I know it’s not an easy problem to solve, but it’s one of the many mechanics which KSP2 could have used to become more advanced than KSP1. Personally, I wanted to see a lot more realism from the game mechanics to give veteran players of KSP some new and interesting challenges.

 

I imagine building colonies and orbital shipyards to build interstellar starships will give us older folx quite the challenge.

 

[garwel]

I know what you mean. I have also complained elsewhere about KSP2's lack of interesting new mechanics, although I was talking more about things like life support, reliability, radiation, heat management, signal delay etc. They might also for example make kerbals more individual or autonomous (add some sort of AI). Planetary weather could be a very interesting addition.

I'm also disappointed that the developers basically took the easy road of just adding more celestial bodies and parts, something this community could have done very well on its own (and perhaps even better). There is still hope that some new features will be introduced later, but then the devs should think outside the box and try to not just create a remake + visual uplift.

[tstein]

14 hours ago, J.Random said:

My understanding is that it's impossible to have both in a consistent, reliable way. They don't transform into one another, so you either integrate all the time, or you have patched conics. Which is why I'm very suspicious of devs' claims that the 3-body will be implemented for the binary (and only there and nowhere else), and that it won't be done through barycenter hack.

No need to be all the time.. only when you are accelerating  and then you cache forwards  a few thousand points and interpolate with a quadratic in between them (up to weeks ahead is easy to cache, problem is  trajectories that take years) . It can be done with reasonable performance if you are writing an engine made to do that, but... well  integrate with unity  AND the issue of the interface can get into the way.

[dazoe]

KSP2 was NOT a re-write. Looking at the disassembled code it is clear that KSP1 was used as a starting point and they just added more on top. I believe that is why you can see the early KSP1 issuses popping up again. There is even KSP1 code that's not even used by the game, old dead code. At least i'm like 85% sure of that, my opinion is based off of just a quick browse through so I could be wrong.

Also reverse-engineering/disassembling is against the eula, which will hamper modding the game in the way KSP1 was modded. Funny thing is I decompiled the code before even launching the game and being presented with the EULA and I've decided to refund the game as I consider it a major step backwards from KSP1

 

[tstein]

3 minutes ago, dazoe said:

KSP2 was NOT a re-write. Looking at the disassembled code it is clear that KSP1 was used as a starting point and they just added more on top. I believe that is why you can see the early KSP1 issuses popping up again. There is even KSP1 code that's not even used by the game, old dead code. At least i'm like 85% sure of that, my opinion is based off of just a quick browse through so I could be wrong.

Also reverse-engineering/disassembling is against the eula, which will hamper modding the game in the way KSP1 was modded. Funny thing is I decompiled the code before even launching the game and being presented with the EULA and I've decided to refund the game as I consider it a major step backwards from KSP1

 

Well copy paste of functions (including names) will happen,   developers will do it by themselves. That does not mean that is not  a different project with a  different structure. All is possible at this stage. Interestingly  if they did copy code they managed to copy the  bad part of KSP and elave the good part out

[CMDRennie]

27 minutes ago, garwel said:

I know what you mean. I have also complained elsewhere about KSP2's lack of interesting new mechanics, although I was talking more about things like life support, reliability, radiation, heat management, signal delay etc. They might also for example make kerbals more individual or autonomous (add some sort of AI). Planetary weather could be a very interesting addition.

I'm also disappointed that the developers basically took the easy road of just adding more celestial bodies and parts, something this community could have done very well on its own (and perhaps even better). There is still hope that some new features will be introduced later, but then the devs should think outside the box and try to not just create a remake + visual uplift.

Yeah, these features are on my wish list too. I didn’t include them for brevity. I feel allot of KSP players have gone looking for that space sim that offers a more realistic setting. Games like Orbiter, Re-entry, Rogue System and the upcoming Alliance Space Guard all offer something new in terms of realistic space sims, but have there own limitations. And most of them are niche projects that don’t have the same wide appeal and support of KSP.

[J.Random]

3 hours ago, tstein said:

No need to be all the time.. only when you are accelerating  and then you cache forwards  a few thousand points and interpolate with a quadratic in between them (up to weeks ahead is easy to cache, problem is  trajectories that take years) . It can be done with reasonable performance if you are writing an engine made to do that, but... well  integrate with unity  AND the issue of the interface can get into the way.

I don't mean "all the time" as "infinitely into the future", I'm saying that you can't have both and switch between them arbitrarily.

[Missingno200]

4 hours ago, dazoe said:

 Looking at the disassembled code it is clear that KSP1 was used as a starting point and they just added more on top. I believe that is why you can see the early KSP1 issuses popping up again. There is even KSP1 code that's not even used by the game, old dead code.

First off, they share an engine. They're going to have a lot of overlapping code just from that alone.
Second off, wasn't KSP2 done with IL2CPP? I may be totally wrong though. However, if this is the case, then it means your statements are completely wrong because you couldn't possibly have gotten the same names or the same functions. That said, I may be very wrong, and I accept that.
Thirdly, if this whole "using KSP as a base" business is the case, then they must've had to rewrite the core fundamentals anyways. For example, NONE of the loading systems are the same, and those likely would've taken months to change. Why do that when you could've just started from scratch?

Edited February 25, 2023 by Missingno200
Third reason...

[mattihase]

As both a programmer and a game designer, N-Body would not have been a good choice for KSP2. Performance wise, polling an already calculated ellipse  with the current game time is leaps and bounds less computationally expensive than actually doing physics sim for each vessel in the save, and with KSP there can be 100s of vessels or bits of debris built up in a save before too long. There's also not much point having a hybrid system as what's the poing of lagrange points if they disappear the moment you go on rails anyway.

If the binary planet stuff they've mentioned before is gonna actually subject crafts going through it to 3 body physics, that thing's gonna be a lag trap if more than a couple vessels end up in there.

Plus you have to consider that for the average player, babysitting hundreds of satellites from unexpectedly changing orbits isn't going to be fun. Hell, getting stuff (especially repair contract targets) flung off out into the ether by moons already isn't fun in KSP1 but at least there are orbits you can leave stuff in where you know they'll be safe indefinitely.

KSP is not a 100% realistic spacesim, and from a scalability perspective and a gameplay perspective, I think it's better off for it.

[CMDRennie]

1 hour ago, mattihase said:

As both a programmer and a game designer, N-Body would not have been a good choice for KSP2. Performance wise, polling an already calculated ellipse  with the current game time is leaps and bounds less computationally expensive than actually doing physics sim for each vessel in the save, and with KSP there can be 100s of vessels or bits of debris built up in a save before too long. There's also not much point having a hybrid system as what's the poing of lagrange points if they disappear the moment you go on rails anyway.

I agree 3+ body physics would be a huge challenge to implement, but it serves as an example of the kind of changes which could have been made to increase the technicality and depth of the gameplay. Other ideas that have been mentioned like radiation, transmission delay, surface scanning and life support would also be good fits.

[GregA]

29 minutes ago, CMDRennie said:

3+ body physics would be a huge challenge to implement

Indeed that is the three body problem, it would be impossible to implement in a deterministic way.  That is the nature of the three body problem.  Three-body problem - Wikipedia

[CMDRennie]

10 minutes ago, GregA said:

Indeed that is the three body problem, it would be impossible to implement in a deterministic way.  That is the nature of the three body problem.  Three-body problem - Wikipedia

In the context of KSP, it wouldn’t technically be the n-body problem as all but one of the bodies would be on rails. But I digress, I didn’t intend for this topic to be about n-body physics (interesting though it is). Maybe that’s a topic for another thread.

[mattihase]

30 minutes ago, CMDRennie said:

I agree 3+ body physics would be a huge challenge to implement, but it serves as an example of the kind of changes which could have been made to increase the technicality and depth of the gameplay. Other ideas that have been mentioned like radiation, transmission delay, surface scanning and life support would also be good fits.

I think it's important to understand that from a design perspective, realism, technicality and depth != good game design, especially when it comes to making people steer ships with realistic lightspeed delay, and double especially when that's over (even at 1/10th scale) interstellar distances.

 

I can see those other things (integrally or optionally) making their way into the game at some point in the road map though, in some form or another. I mean... I don't expect they'll want to implement a way for jeb to slowly and horribly die of radiation sickness, but more instant deaths (like with the KSPIE fusion engines) and other intresting gameplay stuff could be found.

[GregA]

I wasn't being argumentative, I just wanted to make sure other thread readers who maybe don't have an education in math to understand why planets are on rails.  

It seems to me that the game could have defined regions on rails around the planets and large moons where effects like Lagrange points exist, and there could be clumps of game content in those regions and open the Kerbol system up to lots of additional destinations/navigation hazards.    For example, passing Tylo on a particular trajectory to get in orbit around Jool...  Putting a telescope in a particular Lagrange point around Kerbol, but it only being able to stay there for as long as it has fuel.  etc.

[GregA]

9 minutes ago, mattihase said:

 realism, technicality and depth

One of my favorite developments of the original KSP was the communication satellite story line.  It necessitated building bigger more complex rockets so that constellations of satellites could be built to establish reliable communication with the outer planets.  

If I were to gamify the original KSP with the original economy/science mission system, I would start by giving the player 1 Kerbol to work with, get rid of the classes, and make the player save kerbols in order to use as probe cores.  With more advanced tech being found scattered around the kerbol , and not purchasable with money.  

I also found enough challenge with the technical requirements of the missions, that MechJeb landing component should have been included with the base game, rather than always save scumming the landings.

[Daniel Prates]

9 hours ago, garwel said:

although I was talking more about things like life support, reliability, radiation, heat management, signal delay etc

 

Health hehehehe...  you should know.

100% agree. It was a golden opportunity to insert, from the start, some things flagrantly missing in ksp1 like all of those.

Guess it will be up to mods, again. Garwel are you feeling up to it?

[garwel]

8 minutes ago, Daniel Prates said:

Health hehehehe...  you should know.

100% agree. It was a golden opportunity to insert, from the start, some things flagrantly missing in ksp1 like all of those.

Guess it will be up to mods, again. Garwel are you feeling up to it?

For now, I'm waiting for KSP2 to take shape, at least. Will probably buy it when the Science mode is in (or maybe a big discount). Then I'll see what gaps there still are to fill with mods. I have some ideas, but it's really early to say.

[TheOtherDave]

12 minutes ago, GregA said:

I wasn't being argumentative, I just wanted to make sure other thread readers who maybe don't have an education in math to understand why planets are on rails.

I understand some of the math, and I think planets/moons being on rails is an entirely reasonable compromise. As is ships ignoring the gravity of other ships. Otherwise, I'd prefer they'd do the full n-body simulation for how each ship is affected by the planets/moons/asteroids. Or I guess at that point it'd be "the partial n-body simulation" since the vast majority of the total gravity from those n bodies would be from objects which are on rails.

There's also the possibility of running planets/moons on some sort of "partial" rails, where their motion is calculated using n-body physics, but without including the spaceships (or maybe just without anything below some mass ratio, since an asteroid wouldn't meaningfully affect the orbit of a planet but it might do so to a small moon) so that their motion can be calculated asynchronously in the background, separate from the gravity part of the "main" physics engine. I mean, on the scale of a planet vs even a large spaceship, the ship is, at most, a rounding error. Such an approach would probably require the devs/modders to run some calculations on solar systems before publishing them to ensure they'll have the desired stability on the timescale a game is likely to encompass (emphasis on the word "desired", since unstable systems could make for some interesting "maintain the resource networks after everything falls apart" late-game challenges), but that doesn't seem like the end of the world to me.

I'm not sure where asteroids would fit in... Compared to the mass of spaceships and on the timescales of a fly-by, they're huge, but it's clearly not the same thing as the mass of a planet vs the mass of a spaceship. However, on longer timescales the gravitational influence of the spaceship on the asteroid can really add up (to the degree that, AFAIK, a "gravity tug" is considered to be a plausible way to get asteroids off a collision course with Earth). Plus, given the success of the DART mission, it's pretty clear that "player-sized objects" can affect the trajectory of an asteroid even on short timescales when impacts are involved. So you can't really just ignore the interaction between asteroids and spaceships, either, but maybe you can if there's not some minimum distance between them? I'm not sure.

[GregA]

6 minutes ago, TheOtherDave said:

stuff...

 I think it comes down to limited developer time.  Would you rather the developers be spending their time making a good space ship simulator, or a solar system simulator?  For a truly dynamic system like you are describing the developers would spend a bunch of time tuning it and getting it right, and those are resources that would be better spent making a good space ship simulator.  For the time being I think most folks reading and posting would rather the developers be working on their spaceship simulator, if forum thread titles are to be believed.  

I have been playing with Unreal Engine a lot recently, it would be almost trivial to make a gravity orbit tool toy thingie in UE with blueprints.    Maybe I do that tonight and post some screen caps of what I come up with.

[Yakuzi]

31 minutes ago, GregA said:

I have been playing with Unreal Engine a lot recently, it would be almost trivial to make a gravity orbit tool toy thingie in UE with blueprints.    Maybe I do that tonight and post some screen caps of what I come up with.

Please let this be the KSP themed origin story of what Cities: Skylines was to Sim City 5

[Opus_723]

I don't get why everyone is acting like the number of *vessels* is a big hurdle to the use of N-body physics. The very obvious approximation to make would be to have the planets on rails through a long pre-calculated N-body trajectory and vessels just responding to the resulting time-dependent field. It's not like our spaceships are gonna move the planets (or each other) appreciably anyway.

The *real* problem with N-body physics is not having an easily referenced analytical solution for vessel trajectory previews, especially with dynamically adjustable maneuver nodes. You'd never be able to calculate trajectories fast enough to use maneuver nodes as we know them.

This is also why I think Rask and Rusk are doable though. Give them their own SOI, then put them on rails and then you can tinker around with the well-studied restricted three-body problem for the vessel trajectories.

Edited February 26, 2023 by Opus_723

[dragonart777]

 i thank it is more the advertising that failed more then all.   not so much the devs.   people reading all this hype on things we going to be getting  but  when the game came out  they only got a fue rocket parts.  along with bugs like bad fps and parts locking on pods and so on.  so yes paying 50$ for a game that is hardly playable to some. was a big fail on the day 1.   i did say some  not everyone. but again  people where yelling before the game even came out.  

for me it is working kind of ok.  i am loving this game and having a lot of fun. 28 hours in already.  i wish there was a fuel mix  lesson for the game tho.  cause i keep burning to fast ?? ..   

 i thank once the devs start dropping in them updates. and showing there support and promises then the reviews well change.   people or scared that you all going to cash grab and run.  them comments where said long before day 1.  this happens a lot with beta games.    so once they see your support and activity  there minds well change.