Is KSP2 still coming on PS4?

[Dr. Kerbal]

2 hours ago, DunaManiac said:

I don't believe that is even possible, it's been discussed before in other threads, and I think (don't hold me to this) that was the conclusion.

My thoughts on this is a hard maybe. It's wouldn't be very commercially viable to release it on the PS4 and Xbox 1, but they did promise it.

It would be back for Take Two just to break a promise. i mean, lots of consoles players are expecting it on PS4 and XBox1. Since 2019.

Just now, Dr. Kerbal said:

It would be back for Take Two just to break a promise. i mean, lots of consoles players are expecting it on PS4 and XBox1. Since 2019.

IT ALSO MIGHT HURT THERE SALES DEPENDING.

[steve_v]

6 hours ago, kspnerd122 said:

IS IT THAT HARD

Yes.

Multithreading is hard to begin with, and it doesn't work at all (or doesn't bring any benefit) for some applications. The physics engine KSP uses is one of those, and I expect KSP2 will be the same.

Aside, shouting is obnoxious. Please stop.

Edited January 6, 2021 by steve_v

[K^2]

1 hour ago, steve_v said:

Multithreading is hard to begin with

I don't know if I'd say that it's hard. More like different. I mean, you could say that programming in general is hard, and for somebody new to it, sure, but if it's your job and you spent decades doing it, it's pretty straight forward. There are hard problems, but you wouldn't expect software engineer to think of it as hard in general.

Multithreaded programming is different. Becoming good at it is mostly about learning new patterns and getting rid of bad habits. Once you're used to the new paradigms, it's no more difficult than just programming in general. Unfortunately, most people don't learn to write multithreaded code, so for them it's difficult to write something that's both efficient and stable.

1 hour ago, steve_v said:

The physics engine KSP uses is one of those, and I expect KSP2 will be the same.

It's even simpler than that. KSP uses Unity's version of PhysX, and that's simply not written to make good use of multithreading. So you're stuck with what you have. And yeah, I expect, KSP2 will be much the same.

It is, however, quite possible to let PhysX have the main thread pretty much to itself by moving all the component updates to jobs. And that would allow much better use of all the cores in the game. I suspect physics will still be the bottleneck in a lot of cases, but in KSP, you have several potential bottlenecks, and they can all happen on the same thread at the same time, which really kills the framerate. KSP2 does have potential to do better.

We've also had a discussion in another thread about the fact that, in theory, you can use Havok in new versions of Unity instead, but that would require pretty big changes to how the game is written, and all indication is that KSP2 will be architected same as KSP. So the only opportunity for reducing congestion is moving component updates to other threads.

[Dr. Kerbal]

I'm assuming KSP2 will need a better game engine. Again, KSP was first made as a simple projects. Keep that in mind.

[K^2]

3 minutes ago, Dr. Kerbal said:

I'm assuming KSP2 will need a better game engine.

KSP2 will still be running on Unity. An updated version, but there is nothing fundamentally new there. As I've pointed out above, there is an opportunity to use different physics system, but that requires new DOTS workflows and conversion to Entity Components. There is no indication that any of that has been done.

Edit: DOTS is new and largely untested. Features are still being added to this new workflow. So it's extremely unlikely that a game that entered development a while ago would be using stack that was still in beta at best. Even now, starting new development with DOTS would come with risks.

Edited January 6, 2021 by K^2

[Dr. Kerbal]

Just now, K^2 said:

KSP2 will still be running on Unity. An updated version, but there is nothing fundamentally new there. As I've pointed out above, there is an opportunity to use different physics system, but that requires new DOTS workflows and conversion to Entity Components. There is no indication that any of that has been done.

Thats what a mean. A really good high end game engine that can slay krakens. Imagine, it would be funny if we found a Kraken in KSP2.

[K^2]

2 hours ago, Dr. Kerbal said:

Thats what a mean. A really good high end game engine that can slay krakens. Imagine, it would be funny if we found a Kraken in KSP2.

I don't think you understand. KSP2 runs on the same engine as KSP.

And no, I wouldn't call Unity a high end engine. It caters to indy/mobile niche.

[Dr. Kerbal]

I guess so. Im just saying that KSP2 is running on unity. With a few enhancements here and there and wa la. Unity may notbe the best, buts its enough. I actully. Dont have anythingt o say about this. No comments about this on me anymore.

[runner78]

On 1/6/2021 at 7:07 AM, K^2 said:

Edit: DOTS is new and largely untested. Features are still being added to this new workflow. So it's extremely unlikely that a game that entered development a while ago would be using stack that was still in beta at best. Even now, starting new development with DOTS would come with risks.

Games that use ECS are already being developed, for example:
https://store.steampowered.com/app/1272320/Diplomacy_is_Not_an_Option/

In the Unity forum I also reported that other games with ECS are in development, but Unity could not or was not allowed to say anything.

On 1/6/2021 at 7:04 AM, Dr. Kerbal said:

I'm assuming KSP2 will need a better game engine. Again, KSP was first made as a simple projects. Keep that in mind.

KSP1 has started with Unity 3.x, Unity has evolve since them. One problem of KSP1 is the core of the game is build of that old Unity version and cannot simply be fundamentally changed. Unity has now new tools, newer C# version/framework.

PhysX in Unity is multithreaded since Unity5.

[K^2]

9 minutes ago, runner78 said:

PhysX in Unity is multithreaded since Unity5.

Good. That should help. Even if its' only going to be collision tests that will fully benefit from it in KSP2.

[runner78]

22 minutes ago, K^2 said:

Good. That should help. Even if its' only going to be collision tests that will fully benefit from it in KSP2.

KSP1 use Unity 2019.2 so it also use a newer PhisX version. the problem for KSP is that the vessels are on big joined "thing", so multithreading is limited.

KSP1 started with PhyX 2.x, newer Unity version have PhyX 4.x with more performance and options.

[K^2]

19 minutes ago, runner78 said:

the problem for KSP is that the vessels are on big joined "thing", so multithreading is limited.

Exactly. But you can still farm out collisions regardless of how complex the scene is. So long as you're not trying to do BVH updates at the same time, it's completely thread safe. And a lot of the steps in BVH update can be parallelized rather trivially as well. It's only re-balancing that's hard to split up.

So the big chunk of work that's kind of stuck on a single thread is the constraints solver, and while splitting it up is almost certainly more trouble than it's worth, you can always move the whole thing off main. Now, a clever thing that a lot of engines do, but I don't know about recent versions of PhysX, is that you start all your collision jobs early in the frame. You gather these up, set up contact joints, and you kick off the solver either on a dedicated thread or as one long job. At the same time, main moves on and starts running component updates. Some of these may spawn additional jobs to keep the load even. These can query collision results and contact points but not modify them, as that stuff's out in solver already. You can also run additional intersection probes, of course, as needed. But any forces that get generated are simply accumulated. Once the component updates and solver are done, you do the actual rigid body updates by using solver results. Here, you have an option to either apply accumulated component forces directly or save them for the next frame. Either way, in practice, the results are pretty good.

What I don't know is whether the constraints solver has been moved off main in Unity 5, and can, in fact, run in parallel with component updates. In the past, the whole thing ran on main, and that sucked really bad. If the solver still runs on main, there is not much Intercept can do about that other than going with custom solver. (Not going to happen, obviously.) The other part, though, is entirely on Intercept. Utilizing additional cores during component updates. Technically, this was available to KSP as well, as you can always set up your own jobs system, but it does require rather more work. And even in KSP2, I don't suspect it's going to be a freebie. If aerodynamics, heating, engines, fuel and resources, and all the junk on rails is all still updated on main, then the KSP2 core load won't look much better than it did in KSP. This is one place where Intercept actually has an opportunity to make KSP2 run way better than KSP did.

I'm also used to in-house engines where you run a perf capture on the game and just see if any threads are idling and then you move some things around. This is a lot harder to do if you have no control over the frame loop and the order in which the game engine is kicking things off. But you can get most of the available savings by just planning things out and delegating as much work to jobs as possible.

[runner78]

I have to look at the unity profiler to see how PhyX behaves.
It would be ideal if PhsX would generally run in its own thread.

Apart from PyhsX, a problem with KSP is the partmodule system, basically a component system inside of unity GameObject components. If you have a vessel with 200 parts with average 3 modules, you have 600 modules update per frame. (There are also other methods, but I haven't modded KSP for a long time and I've forgotten)
Depending on the action of the part module, this can quickly lead to performance problems.

The 600 modules are also affected by GC, Unity GameObject not, they have a native counterpart and are created / deleted native.

  

[Dr. Kerbal]

I think if Take 2 said they break their promise on releasing on PS4 and Xbox One it might hurt their sales. And that would be bad. Players wint want to buy KSP2 and you know.

[Guest]

18 hours ago, Dr. Kerbal said:

I think if Take 2 said they break their promise on releasing on PS4 and Xbox One it might hurt their sales. And that would be bad. Players wint want to buy KSP2 and you know.

A year from now the PS4/Xbox One market will be a much smaller one, even further if they keep they're original plans and release only on PC first before porting the game to consoles.

And I sincerely doubt that anyone not playing on an old console will be mad if they don't release on them.

[Incarnation of Chaos]

I think it's also important to keep in mind how much KSP has been through

It started as a 32-bit application, then the 64-bit came along and was so unstable on windows (Penguins were laughing at us though) that it had to be avoided for a while. Then they updated the Unity version several times, and then in 1.7.3 or 1.8 (I can't ever remember which) they moved completely over to DX11 instead of DX9 (Penguins got ****). So you have a game where in the beginning it was essentially designed to use 4GB of RAM, and was far, far smaller in scope than today. That now has become much larger, can access much more memory, and uses a completely different version of the Graphics API it began on.

There are very few games i know of that have seen such sweeping and broad changes over their lifecycle, and that were identified and sold as the same product the entire time. In fact about the only one i could think of would be Skyrim, but Special Edition was only free to PC players, and only to those that owned all DLC. They effectively deprecated the "Legendary Edition" and now it's fairly difficult to buy the OG Skyrim (Which in effect means they're selling them as two entirely different products).

KSP2 has to deal with NONE of this, and i think many people are severely underestimating how much that alone will help performance. And the developers themselves understand that performance is a major issue for players, and actively working on solutions to address it.

Now that all could be lies, but we have absolutely no idea how KSP2 will perform until we get copies in hand. But considering all of the above....

I'll be extremely surprised if KSP2 on the lowest settings is not much, much more performance-friendly than KSP on the lowest settings on the same machine.

 

[Lord Aurelius]

On 1/8/2021 at 5:23 AM, Master39 said:

A year from now the PS4/Xbox One market will be a much smaller one, even further if they keep they're original plans and release only on PC first before porting the game to consoles.

And I sincerely doubt that anyone not playing on an old console will be mad if they don't release on them.

Agreed.

On 1/7/2021 at 10:24 AM, Dr. Kerbal said:

I think if Take 2 said they break their promise on releasing on PS4 and Xbox One it might hurt their sales. And that would be bad. Players wint want to buy KSP2 and you know.

Also consider that when Take 2 originally made its statement regarding console support KSP2 was still scheduled to launch in early 2020, prior to the current console generation. At that point it would have been a no-brainer to attempt to support that console generation, but with all the delays it makes less and less sense IMHO, especially given how slow the CPUs in those systems are. I really don't want to see KSP2 gameplay limited to what the CPU in an OG Xbox One/PS4 can handle.

Edited January 9, 2021 by Lord Aurelius

[Sesshaku]

I would save for a PC. My problem with Kerbal on a console is the same I have with games like Skyrim: WHAT'S THE POINT WITHOUT MODS?

Like seriously, I wouldn't even touch KSP with a stick if it wasn't for mods. Even small mods like PreciseManeuver make a HUGEEEE quality of life difference.

[K^2]

This is a slight tangent, but I've stumbled on this comparison. The author admits that because it's a conversion from GameObjects to ECS that it's not exactly the cleanest of tests, but I think that actually makes it apply even more to KSP2 discussion, since if, in theory, KSP2 was to go with ECS/DOTS, they'd probably take a similar route.

The performance losses in pretty much the best case scenario you can have are way worse than I expected. And it looks like multi-core utilization is still quite poor.

@runner78 You seem to have some experience with Unity perf analysis, so if you have criticism of approach used in this video, I'd actually be very curious to hear about it. On the bespoke side, the comment that it's the "polish" that takes the most time, rather than core features, rings very true from my experience working with in-house engines.

 

[runner78]

I think its an unfai comparison. This is just a quick assessment of the lack of time, but the Unity project is only intended to show what performance is gained through porting GameObject to DOTS, the excample itself is generally not optimized. Presumably unoptimized DOTS/Hybrid versus optimized native example? The question is also which version of the ECS render he is using, there is V2  version which is faster than the old one, which is more for static object optimizer, back then it was created for the megacity demo. (A mobile version of it was also shown once)