The game failed because...

[steveman0]

27 minutes ago, kerbiloid said:

From scratch with blind eyes. While KSP-2 already had a working and mostly debugged prototype with almost 10 year long player experience, and their bug tracker.

This is assuming the base was fundamentally strong enough to rely on to build up a sequel directly on top of it.  I don't think you'd find many who would agree with this.  There were several technical limitations that required rework from the ground up.  It's this kind of work that takes time.

[PDCWolf]

10 minutes ago, steveman0 said:

This is assuming the base was fundamentally strong enough to rely on to build up a sequel directly on top of it.  I don't think you'd find many who would agree with this.  There were several technical limitations that required rework from the ground up.  It's this kind of work that takes time.

This has always been the nasty part for me: As prettier, funnier and maybe more modern than KSP1 as some might be convinced it was... The foundations KSP2 was built on are objectively worse, and the devs never bothered to communicate any sort of long or short term solution for a system that's designed from the ground up to crumble under very light pressures.

• Heating had to be gimped to reduce the performance hit of off-loaded vessel simulation.
• Parts had to be coalesced into all in 1 solutions to cut on part counts, even something as basic as science. And they tried to sell this as a revolutionary "you've gotta built around the a payload now".
• Logistics was to be a magic number crediting and debiting system because you've gotta keep vessels out of the simulation as much as possible.
• After all this, they somehow wanted to add physics to colonies... they failed to answer basic questions like "why?" and "how does this not kill performance further for very little benefit?"

Add to that not having seen a single hint of colonies except the map interface and whatever loose change happens to be in the files already... I don't think colonies ever existed. The game PLAIN AND SIMPLY was not gonna work with even a couple 100 part colonies scattered around, let alone be able to keep track of Kerbals and logistics without exploding. And I say this with utmost security: that system had no fix other than a major rework of how KSP2 saves and loads data.

Not only was it broken, it was not fixable.

[cocoscacao]

50 minutes ago, PDCWolf said:

I don't think colonies ever existed

I don't think any of the roadmap steps exist. Posting this answer yet again, notice the last words "under construction". Same was said for heating. Nate often told us that teams are working in parallel on each roadmap update. Whatever happened in the first studio overturn, I bet only a few graphical assets survived. The rest was scraped and started over, which can explain the state of the game at launch.

I'm wondering if it's easier to implement and test these underlying systems as you go.

If all of the above is true, I believe they did try their best to deliver something in a reasonable speed, considering the circumstances.

[Kerbart]

1 hour ago, steveman0 said:

This is assuming the base was fundamentally strong enough to rely on to build up a sequel directly on top of it.  I don't think you'd find many who would agree with this.  There were several technical limitations that required rework from the ground up.  It's this kind of work that takes time.

59 minutes ago, PDCWolf said:

This has always been the nasty part for me: As prettier, funnier and maybe more modern than KSP1 as some might be convinced it was... The foundations KSP2 was built on are objectively worse, and the devs never bothered to communicate any sort of long or short term solution for a system that's designed from the ground up to crumble under very light pressures. […] Add to that not having seen a single hint of colonies except the map interface and whatever loose change happens to be in the files already... I don't think colonies ever existed. The game PLAIN AND SIMPLY was not gonna work with even a couple 100 part colonies scattered around, let alone be able to keep track of Kerbals and logistics without exploding. And I say this with utmost security: that system had no fix other than a major rework of how KSP2 saves and loads data.

That is the most incredulous part. It has become increasingly clear, as you state, that there were some serious performance issues with the game scaling up as everything is being recalculated all the time, followed by shortcuts (ie. heating) to deal with that.

Forgivable for KSP1 which started with rockets made of a dozen parts and only going to the moon. But if you're building it from the ground up knowing that people are going to have dozens and dozens of ships, many consisting of a hundred or even a thousand parts, how can you not take that into consideration?

[PDCWolf]

Just now, cocoscacao said:

I don't think any of the roadmap steps exist. Posting this answer yet again, notice the last words "under construction". Same was said for heating. Nate often told us that teams are working in parallel on each roadmap update. Whatever happened in the first studio overturn, I bet only a few graphical assets survived. The rest was scraped and started over, which can explain the state of the game at launch.

I'm wondering if it's easier to implement and test these underlying systems as you go.

If all of the above is true, I believe they did try their best to deliver something in a reasonable speed, considering the circumstances.

Yes, Nate also said that this parallel workflow was speeding up subsequent releases versus the cadence of bugfixes... and that didn't happen, with 2 proposed bugfix releases before colonies having failed to even show up let alone have a date for the first one 4 months down the road.

That's what I mean with "don't exist": They weren't there, even if under "muh parallel development" they were supposed to start working on stuff as soon as FS! left the dock. Once again, all they could show from colonies was static assets on editor scenes., same kind of hot air they were showing before release saying they had a full game.

1 minute ago, cocoscacao said:

The rest was scraped and started over, which can explain the state of the game at launch.

Allegedly, and that being considered only as a way to have some compassion to their work. Even if this is something they've actively denied and the people working on whatever was scrapped was... themselves still under the same leadership.

Sure you could talk licenses, but it's useless if we don't know how much really was lost, that's a magnitude order more conjecture than whether KSP2 is currently dead.

3 minutes ago, Kerbart said:

Forgivable for KSP1 which started with rockets made of a dozen parts and only going to the moon. But if you're building it from the ground up knowing that people are going to have dozens and dozens of ships, many consisting of a hundred or even a thousand parts, how can you not take that into consideration?

This + things like using the same middleware, and hitting the same walls as the prequel with the fuel flow calculations were heavily worrying.

[cocoscacao]

6 minutes ago, Kerbart said:

consisting of a hundred or even a thousand parts, how can you not take that into consideration?

Which is why I'm still baffled why (semi) procedural parts were never considered. Sure, progression unlocking 'n all, but oh boy, they had a golden opportunity to improve that.

[cocoscacao]

3 minutes ago, PDCWolf said:

it's useless if we don't know how much really was lost

I can spin that argument both ways. If a lot was lost, communicating that would remove a lot of frustration. On the other hand, if it wasn't, it would cause mass hysteria. Is lack of comms regular for T2 or not? I wish devs had more freedom to speak up.

[Fizzlebop Smith]

I never understood why KSP2 took the direction it did. I am largely illiterate in the nuances of code.

Outside editing the singular .ini or .json I am lost. But I loved the technical dev blogs that were released for various phases of KSP1.

I love the tech blogs for other games.. and the subsequent commenting from smart people has been what helped me understand a great deal more than before.

This is the kind of stuff that gets me invested in a game. Not only do I feel the developer considers me *valuable* but my time reading these things is time "invested" .. and strengthens that community connection.

KSP2 lack of fundamental technical discussions should have been a red flag. I should have listened to those with coding experience talking about this being doomed to be problematic.

I am now onto the stage of grief where I blame myself for getting too excited.

[cocoscacao]

27 minutes ago, Fizzlebop Smith said:

I am largely illiterate in the nuances of code.

For some (many) things, you really don't need it. Take MP for example. Can you explain it to me how it could function in a game like KSP?

MP is my biggest gripe with development decisions. Even Nate said many potential features we're dropped 'cause they were incompatible with it. Instead of scaling a whole game towards it, they could have scale the MP down. No time warp. You can race others with rovers, planes, rockets... That would be fun enough, and it would tone down complexity a lot. 

Edited May 10 by cocoscacao
rephrased that a bit more clearly

[Fizzlebop Smith]

26 minutes ago, cocoscacao said:

For some (many) things, you really don't need it. Take MP for example. Can you explain it to me how it could function in a game like KSP?

MP is my biggest gripe with development decisions. Even Nate said many potential features we're dropped 'cause they were incompatible with it. Instead of scaling a whole game towards it, they could have scale the MP down. No time warp. You can race others with rovers, planes, rockets... That would be fun enough, and it would tone down complexity a lot. 

Couldn't agree more.

I can see an Async mode or something but I largely do not see the NEED.

This is not a crafter like minecraft though that element exists... it's management game built around single player ideas. 

Trying to make that a staple feature of KSP2 (in my personal opinion) does not align with most player expectations. The only people I have largely screaming for multiple player are some old skool BD players & people mostly new to the franchise.

I may be mistaken, but too many code Gurus have expounded on the topic for me to believe it was ever a good idea to combine with a full scale open world / timewarping

Edited May 10 by Fizzlebop Smith

[PDCWolf]

1 hour ago, Fizzlebop Smith said:

I never understood why KSP2 took the direction it did.

I feel there was a balance they failed to hit (talking about direction as in the general sense of the finalized vision for the game). The heavy work on tutorials already tells you they were going for "we take this niche game and make it accessible to even more people, it'll definitely sell more." FS! followed on that by simplifying and linearizing the tech tree and having science be a single magic button, where you can absolutely skip even the timers so long as you hit it every time it flashes. Lastly, they also wanted to tell a semi-linear storyline through missions, discoverables and their lore. That part was really good, the new user onboarding was a magnitude better than KSP1.

On the other hand, the game really required a strong technical foundation because by the time the difficulty curve of rocket launches and SSTOs is over, almost every player just goes big. Here is where to me they completely failed, by making a game that doesn't support this second bit. Of course now it'll all be woulds and coulds, but it's not hard to see that even without colonies we were already still finding the limits very easily (another example, another one, another). 8000 parts might sound like a lot on that bug report, but that's about a constellation of satellites, a couple rover missions, and a Jool 5 vessel. Meanwhile the game was supposed to allow you to do that on multiple star systems, whilst supporting trust under timewarp... and just no, the game could never be able to do that with the foundation it has.

Also, as a last nail in the coffin, they forever handwaved the explanation of how Rask & Rusk (the binary system) were going to work. So yeah, we have a game built on flimsy foundations that they just outright refuse to talk about (remember the promises of HDRP and the system that'd replace PQS? I do), we have only the most basic stuff (yes, science and a tech tree is very basic, deal with it) implemented and none of the complex problems, and not just that but whatever little we have is already making those foundations quake... That's why you can google me saying "technologically bankrupt" multiple times.

The balance they failed to implement in game by only including stuff for new people and nothing for veterans, was the same thing behind the scenes: they were doing only the easy stuff whilst completely neglecting the complex stuff and much less having the stones to talk about it. At this point I doubt they even had a plan past "cut everything down as manageable as possible", which is what net us all in one parts, gimped heating, the horrible coordinate reset on ground vehicles, and so on.

1 hour ago, cocoscacao said:

For some (many) things, you really don't need it. Take MP for example. Can you explain it to me how it could function in a game like KSP?

MP is my biggest gripe with development decisions. Even Nate said many potential features we're dropped 'cause they were incompatible with it. Instead of scaling a whole game towards it, they could have scale the MP down. No time warp. You can race others with rovers, planes, rockets... That would be fun enough, and it would tone down complexity a lot. 

I doubt they dropped anything in favor of a feature that probably never existed (yes, I saw the screenshot). I'm closer to believing they used multiplayer as an excuse to drop anything too complex/deep that might've further gimped the game's performance.

[cocoscacao]

6 minutes ago, PDCWolf said:

I doubt they dropped anything in favor of a feature that probably never existed (yes, I saw the screenshot). I'm closer to believing they used multiplayer as an excuse to drop anything too complex/deep that might've further gimped the game's performance.

They'd eventually need to deliver that multiplayer with time-syncing capability. I can't imagine a more complex feature than that. Unless you're suggesting they intended to bail development before reaching MP, in which case... why bother with any roadmap step after release at all?

Edited May 10 by cocoscacao

[PDCWolf]

Just now, cocoscacao said:

They'd eventually need to deliver that multiplayer with time-syncing capability. I can't imagine a more complex feature than that. Unless you're suggesting they intended to bail development before reaching MP, in which case... why bother with any roadmap step after release at all?

Well... sadly there's history of that, SQUAD promised multiplayer for KSP1 before selling the franchise out.

Also, to clear it up: I do believe they were gonna do multiplayer, I do not believe for a second multiplayer was the real or only excuse to drop this or that feature, and I definitely don't believe the source of that screenshot has anything to do with the build of the game we were playing (tinfoil on: the blurred names were Star Theory devs and that's their build) . Multiplayer is probably the most complex thing they could've done for the game, so I don't see why they'd back away from whatever else. They already overpromised a lot.

[cocoscacao]

27 minutes ago, PDCWolf said:

I do not believe for a second multiplayer was the real or only excuse to drop this or that feature

Eh... now that I think about it, what can time-sync possibly mess up that isn't a complication already...? You might be right there.

29 minutes ago, PDCWolf said:

I definitely don't believe the source of that screenshot has anything to do with the build of the game we were playing

We never got gameplay footage for anything else on the roadmap, except for FS! a little before it was released.

[Kerbart]

3 hours ago, PDCWolf said:

This + things like using the same middleware, and hitting the same walls as the prequel with the fuel flow calculations were heavily worrying.

I don't know anything about game programming. I've seen claims that for the kind of physics simulation KSP is, Unreal or another engine wouldn't necessarily do better. But more importantly, it seems like micro-optimization to me. If another engine is 400% faster it just means that you'll run into the same issue at 2000 parts instead of 500. The real solution is to not brute-force it in the first place. We all agree that as far as we can see, no attempt was made for improvements in that direction.

[Infinite Aerospace]

5 minutes ago, cocoscacao said:

Eh... now that I think about it, what can time-sync possibly mess up that isn't a complication already...? You might be right there.

We never got gameplay footage for anything else on the roadmap, except for FS! a little before it was released.

I don't even personally understand why it was even advertised, and who actually wanted it. Anyone could see that multiplayer and Kerbal Space Program is an enormous can of worms. If they came along right now, as in Nate and said "Ok, look, we're having to crack on with this and multiplayer is going to be cut.", who would really care? I wouldn't to be honest, the rest of the game is where the value lies.

Just now, Kerbart said:

I don't know anything about game programming. I've seen claims that for the kind of physics simulation KSP is, Unreal or another engine wouldn't necessarily do better. But more importantly, it seems like micro-optimization to me. If another engine is 400% faster it just means that you'll run into the same issue at 2000 parts instead of 500. The real solution is to not brute-force it in the first place. We all agree that as far as we can see, no attempt was made for improvements in that direction.

A friend of mine that works with Unreal Engine said that exact thing, he doesn't really see how a physics simulation, with the time warp component can really function in multiplayer unless both players agreed to time warp at certain points.

[Flush Foot]

4 minutes ago, Infinite Aerospace said:

A friend of mine that works with Unreal Engine said that exact thing, he doesn't really see how a physics simulation, with the time warp component can really function in multiplayer unless both players agreed to time warp at certain points

Even with the 'expected' async style of warping many were proposing (I warp and you warp and eventually one of us chooses to 'catch up' to the other), I don't know how that would work in games where people had life-support mods (unless that warp was "resource-free") because if you plan your 'snack supply' for a 3-year round-trip to Duna and then warp-sync 5 years because the other person was doing a Jool mission, RIP to your Duna-crew?

And that doesn't even 'consider' the eventual^TM automatic delivery routes... Would they 'continue' through that same 5 year skip until all of your "warehouses/tanks" were completely full?

[Kerbart]

35 minutes ago, Infinite Aerospace said:

I don't even personally understand why it was even advertised, and who actually wanted it. Anyone could see that multiplayer and Kerbal Space Program is an enormous can of worms. If they came along right now, as in Nate and said "Ok, look, we're having to crack on with this and multiplayer is going to be cut.", who would really care? I wouldn't to be honest, the rest of the game is where the value lies.

Actually... there was (is?) a very vocal MP fraction of players. Back in the post 1.0 days, every updates would predictably result in "still no multiplayer" posts. They also were all very vocal about that "timewarp was a non-issue and the easiest of things to solve," although opinions on how timewarp should be treated seemed to differ. At the time, multiplayer seemed to be one of the biggest "why we need KSP2" selling points. Don't get me wrong, I don't care for it. But is is/was a major factor on the "what we need in KSP2" list.

[Fizzlebop Smith]

What meant by completely Async play.. is a sandbox style of game. There would be no life support or supply lines and that's the only way o see it realistically being viable.

As a game mode thag uses save share to load up into a sandbox playstyle.  It would add the appearance of instantaneous travel for onlookers.

 I thought it sounded ideal for KSP when a player suggestion for crew style play. 

You launch a single ship with multiple landers / craft and deploy when in system. Player time warps would be negligible amounts and basically there is no world timer.. just mission timersfrom when craft was launched

 

That was the only way I could picture it working In my mind.. but I never really wanted it

 

Edited May 10 by Fizzlebop Smith

[PDCWolf]

Just now, Kerbart said:

I don't know anything about game programming. I've seen claims that for the kind of physics simulation KSP is, Unreal or another engine wouldn't necessarily do better. But more importantly, it seems like micro-optimization to me. If another engine is 400% faster it just means that you'll run into the same issue at 2000 parts instead of 500. The real solution is to not brute-force it in the first place. We all agree that as far as we can see, no attempt was made for improvements in that direction.

As far as physics simulation, there's a couple problems to solve:

• Scene size, where you just can't simulate the full solar system 1:1 on any engine so tricks like the player-centric planetarium are used.
• The joining of parts.
• What do you do with ships the player isn't playing with.

Unity, Unreal or whatever off the shelf engine would face the same scene size limit at some point, meaning the whole planetary system needs to go through a scaled player-centered planetarium mode like it does in KSP1. I really don't think there's another solution for that. I don't know how for example Orbiter handles it to say if it's different, and I know other games like Space Engineer just use a static, heavily scaled down system and displace the active scene resetting coordinates (like KSP1/2 does with rovers on the ground).

As for the joining of parts, the particular problem with Unity, or rather how the devs used Unity in KSP1 and 2, is that they resorted to Unity's default joint system. That means when you put 2 parts together, they're not parent and child, but rather 2 nodes united by a joint. The flexibility this joint allows is what permits things like wobble and all other spaghetti effects... and creates phantom forces as well in some cases. Those joints are their own physical entity and can transfer forces along the connected rigid bodies. A secondary problem this causes is with collision detection, because if you allow elasticity on the joint, the 2 connected parts can collide and that's when a tank in the middle of your rocket explodes for no apparent reason, and thus the solution is to disable same-vessel collision. Every joint is an extra "part" that has to be serialized for saving, which is why autostrut is so toxic to performance.

Now, all of this carries over to the third aspect: What do you do with non active vessels. "Serializing and saving" isn't just for when you stop playing, but also quicksaves, swapping active vessels, docking and so on. In KSP1 (and if I remember correctly), the ISRU and heating systems work for unloaded vessels by saving the current rates of change in resources (as in, say, fuel is increasing X units per second, ore decreases by Y amount per second) and when you switch back to a vessel, those rates are calculated against the time since you last played with that ship and are credited or debited to all containers equally and almost instantly. They also had some shortcuts over EC rates not being updated so a solar panel always generates max energy for an offloaded vessel even at night.

In comes KSP2, and they promise trust on warp, real simulations for ISRU/Colonies and what not, except the way they do it is to serialize and dump even more data onto the save, and without any shortcut or optimization. Every aspect of a part in KSP2 is serialized and saved individually, and then recomputed pretty much live as you play with another ship someplace else. This means every solar panel, radiator, resource container, resource generator, resource debit, engine, SAS, and so on is continuously working and being recalculated even for vessels you aren't playing with. You might be launching a 20 part rocket, but that 100 part colony still will hit you like if you were launching it all in one piece right next to your new rocket.

And the way this side of the system is built, really has nothing to do with engine choice. Engine choice just adds onto this mess by virtue of how the Unity default joints work and how bad Unity is natively at multithreading. Sure, some engines might have better native multithreading not requiring the mess you have to do in Unity to get that working, but still, it's a very flimsy system that resolves into an O(n) algorithm where more parts cause a linear decay in performance.

 

[Fizzlebop Smith]

Well how in the hell would MP address something like the physics aspects... would each machine be crunching the whole system. 

If the game cannot split calcs efficiently between cores how would MP even work without unleashing the Kraken.

The more I see people break down certain things the more I am convinced that a lack of technical reports to the community is a direct result of nothing to show.

[pandaman]

2 hours ago, PDCWolf said:

2 hours ago, cocoscacao said:

 

Well... sadly there's history of that, SQUAD promised multiplayer for KSP1...

I could be wrong, but I don't recall it ever being 'promised'.  The most I remember were comments stating that they are 'thinking' about it and 'would like' to do it .  The only 'promises' seemed to be in the heads of those that didn't want to understand what was actually said.

Edit.  It would seem I didn't get my quote from the initial post it was in.

Edited May 10 by pandaman

[Icegrx]

2 hours ago, Fizzlebop Smith said:

Well how in the hell would MP address something like the physics aspects... would each machine be crunching the whole system. 

If the game cannot split calcs efficiently between cores how would MP even work without unleashing the Kraken.

The more I see people break down certain things the more I am convinced that a lack of technical reports to the community is a direct result of nothing to show.

They absolutely got caught in the act of spewing attention grabbing features without understanding what they were promising. From time warp to physics calculations. Full multiplayer support was never going to happen. 

This leads one to question the other features they highlighted, and why colonies is/was taking so long with so little to show. Intercept regurgitated a bunch of features that would do well in hype marketing without researching much of anything beforehand. There was little planning put into KSP2. Makes me question the team’s competency. 

[cocoscacao]

4 hours ago, Flush Foot said:

Even with the 'expected' async style of warping many were proposing (I warp and you warp and eventually one of us chooses to 'catch up' to the other)

Someone correct me on this one. The "official description" was similar to this. Each player has a separate timeline until two ships meet. Ignoring the problem of catching up (sending a crew to potential crash path), how do two objects meet? They need to be at the same place at the same time, but time isn't the same for both players.

[Cryptobux]

@PDCWolf makes a bunch of interesting points. I'm no software engineer but, referring to the thread title - is this sort of game actually not feasible given current- or next-gen hardware? Even with a bespoke engine, is the sort of calculation required to achieve what Simpson et al promised not actually possible?

Again speaking as a layman, is there some inherent limitation to how the numbers are crunched (floating-point accuracy?) or the way that is implemented that means there is no way to accurately place two craft next to each other when they are further than (x) distance from an origin. Or, is the Rask / Rusk / spacecraft construction a variation on the three-body problem? Or, do we need to actually do what KSP2 proposed and constantly compute everything all the time everywhere, and that's a fundamentally unsolvable issue?

Squad bravely tried and approximated it, IG repeated all the same mistakes only worse. Is there another way?

Edited May 10 by Cryptobux
typo