The game failed because...

[Scarecrow71]

1 hour ago, Icegrx said:

This leads one to question the other features they highlighted, and why colonies is/was taking so long with so little to show.

For the same reason that it took months after launch for heat:  they never did any actual work on it.  Keep in mind that the only things they've shown us regarding colonies are models in an editor environment.  No actual gameplay.

[Icegrx]

25 minutes ago, Scarecrow71 said:

For the same reason that it took months after launch for heat:  they never did any actual work on it.  Keep in mind that the only things they've shown us regarding colonies are models in an editor environment.  No actual gameplay.

I think we got a few actual gameplay screenshots of a “Colony Space Station” but honestly, it didn’t showcase a single new mechanic. Just new large models attached to an otherwise vanilla craft. Wouldn’t take much work at all, nor did it address any actual mechanics. 

don’t think we got a single screenshot of a stationary colony ground base in real gameplay, like you said. 

[cocoscacao]

45 minutes ago, Cryptobux said:

is there some inherent limitation to how the numbers are crunched

Yes. Some things need to be simulated step by step. There's no shortcuts. Faster processor will yield better results, but more vessels will make more computational load on cpu. Some stuff can be computed in parallel, others, not so much. Depends on which feature you're asking for

[Cryptobux]

The only feature I'd ask for (and it should go without saying in this game) would be rock-solid orbital behaviour, prediction, and control with acceptable performance. Stability on the ground and in flight.

Once that foundation exists, everything else can be built out. Without that foundation, which from what you're saying may not be possible, the project's stuck on the launchpad with the countdown on hold.

[PDCWolf]

4 hours ago, pandaman said:

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.

Funnily enough, the news article about it is still up. To me the wording sounds pretty committing, but hey, I'm not about to have another discussion centered on whether they literally said or implied "we promise".

2 hours ago, Cryptobux said:

@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?

It's not about the hardware. There's a lot of games more complex than KSP/2 out there, even without being spaceflight simulators (please don't believe that's the hard part, it's not). This is just them choosing, probably by virtue of needing to GET GAME OUT FAST, the worst possible way to do things, in an engine known for not being good at using multiple cores of modern CPUs.

Regarding multiplayer itself, it's achievable with some caveats like the delegation of collision calculations. Say we're playing on a server and I launch a missile at you: for most of the interaction, your craft would probably be just a single rigid body to my machine, and me and the missile would be the same to you. At the moment of computing the impact, I need to stream the craft data to the server (or to you, depending on architecture), for proper physics calculation of the impact. This is how you avoid all clients having to do all the calculation work. There's a myriad of engineering/crafting games that work just fine regarding this, even to really big scales.

As for coordinate accuracy, it's irrelevant. In the same way my PC calculates my own physics and not yours, your craft would be a protovessel on my side, condemned to a single point in the scaled-space planetarium (remember that for a single player, the universe revolves around them). Right now the only problem is coordinate resets at like 2500 meters which is the point where unity begins to drop precision, and so the scene is moved to recenter the rover in it, causing it to jolt a bit or even just to get flung away. Again, in multiplayer it'd still be me doing my own calculations so you'd see my rover bugging out but they wouldn't affect your rover.

Rask & Rusk... yeah, no idea how they were gonna do that without either a half-baked SoI abuse implementation, or actually making the jump to proper numeric integration. Orbits inside a binary system can get pretty complex and there's a ton of cases a simple SoI spaghetti wouldn't solve. I'm really pretty sure this is why we never heard of those two past promotional material.

Do we need to compute every part of every vessel at every point? Probably not. KSP1 worked believably enough except for solar panels not getting updated as the sun left them. Trust under warp could probably use some logic shortcuts if we can put up with fuel drain being not perfectly realistic for example.

At the end of the day we can speculate endlessly but if nobody is actually sitting down to solve those problems, there's no point collectively bashing our heads to think of solutions that won't be implemented anywhere.

 

[cocoscacao]

22 minutes ago, PDCWolf said:

Trust under warp could probably use some logic shortcuts

Can it? That's a textbook example of losing precision when scaling up simulation.

[PDCWolf]

7 minutes ago, cocoscacao said:

Can it? That's a textbook example of losing precision when scaling up simulation.

One thing that comes to mind is saving fuel as a single pool, drain from that if the vessel is thrusting off-loaded, and then redistributing it back to tanks on vessel load. It'd probably not look that good unless you use some fancy math to regulate that distribution instead of making it equitative for example, but it's better than calculating fuel flow and drain from N tanks.

You could also just force the player to pre-calc a burn for burn-during-warp, and not let them touch the vessel until that is done, thus you already have done the math whilst the vessel was loaded, and you just need to move it on rails when the user looks at it or sets it as active.

There's probably many solutions and shortcuts I'm overlooking though, this is just back of the napkin stuff.

[KerikBalm]

@PDCWolf

The thrust on rails should have been something that happens in the tracking station, where the craft is a single point, no physics simulation for individual parts, just total fuel, total thrust, total mass.

As you said, it can be pre-computer when making the maneuver. Children of a Dead Earth managed this, allowing for burns in the mili-G's (or even less) over ver long periods of time (using the Magnetoplasmadynamic thruster, powered by nuclear reactors [as almost everything was in that game, the only other option being RTGs]). The map view there (without focusing on the active ship/fleet) would auto execute burns

I was hoping for something similar in KSP 2, allowing constant thrust trajectories with very low thrust - not just for interstellar travel, but also inter-system travel with current -tech ion/mod thrusters and solar/nuclear power.

It would have been a new gameplay experience to do brachistichrone trajectories, having ion-propelled probes spirally outward from Kerbin as they pick up velocity, etc.

Instead, it seems they still only planned for impulse trajectories, and all the imprecision related to those burns actually taking significant time to complete (especially for low-thrust, high Isp engines and/or high dV burns).

CoDE handled it just fine, along with N-body physics.

Simplifications were made in other areas (for maneuvering, ships were modeled as one piece with pre-competed moments of inertia)

[Fizzlebop Smith]

14 hours ago, Scarecrow71 said:

  they never did any actual work on it.  Keep in mind that the only things they've shown us regarding colonies are models in an editor environment.  No actual gameplay.

Did you forget about all the Sprint Planning?

/s

Edited May 11 by Fizzlebop Smith

[linuxgurugamer]

All, Shadowzone did an excellent dive into the KSP2 development story here: