A big problem I foresee with KSP 2: pc resources

[K^2]

11 hours ago, Lisias said:

Some of the biggest companies on the World were born from garages, dude. And they shadowed most of the "reputable" manufacturer out there.

I don't think you understand how game development works. Or "garage" startups, for that matter. @Master39 hits the main points. The largest company I've worked for was Google. Smallest rented out office space from a law firm. The smallest game I shipped was considered huge success when it crossed a million registered users after a year of continued updates. Biggest was considered a flop when it only sold three million copies in the first month. And while I'm tempted to nitpick a few things in Master39's post, it overall matches my impression of what T2/PD is doing with KSP2 in contrast to original development.

Now, Intercept Games can still screw it up royally, but they are staffed with game dev veterans who know the tools they are working with, have the resources to do things right, and are on a very reasonable schedule to ship this game well engineered and well polished.

Things I have so far seen Intercept do in terms of graphics are very performance-friendly. If they are putting the same kind of consideration into components code, it should be fine. The person they have on physics is a little green on game-dev experience, but has excellent academic background, so as long as they are performance-conscious, it should be fine. Finally, KSP's approach to loading assets being, "screw it, we're doing it live," just isn't generally a thing in game dev. I'd be mightily surprised if Intercept doesn't have their own build pipeline and are going to serve baked assets, which will speed up loading tremendously, not to mention help with memory overhead and leaks.

At this point, the thing I'm worried about the most is networking/multiplayer, and I consider that to be optional for initial release, so that should help put my confidence level in perspective.

Edited July 14, 2021 by Vanamonde

[Lisias]

1 hour ago, K^2 said:

The largest company I've worked for was Google. Smallest rented out office space from a law firm.

The smallest company I worked was contracted by Nokia, at that time the biggest Mobile maker in the World. We also made games to Samsung (C3300 was one of the phones I targeted, if memory serves me well), and this game used licensed material from a really big Entertaining Company) to be bundled on a promotional models sold on the whole country. At 35USD, these cheap phones sold as water - but, obviously, I don't have a clue of how many were that promotional models I coded the game.

At that time, Android phones were still fighting for the limelight and were expensive as hell, so Nokia and Samsung were still a thing on the market.

I can tell  you in details how was to work for these two different companies.

The shop was localized over a bakery - hell, that (wonderful) smell on the morning, I must had earn 20 pounds at that time. Even by walking home at the end of the day trying to lose some.

You see, you guys are not the only ones in town. What I fail to understand, however, is where this liquiding context matters to the subject at hand.

 

1 hour ago, K^2 said:

Things I have so far seen Intercept do in terms of graphics are very performance-friendly.

Unless you have privileged access to the binaries (and so, please be cautions about the NDA you signed), what you have seen is the game running on developer's workstations.

 

1 hour ago, K^2 said:

If they are putting the same kind of consideration into components code, it should be fine.

As long they are aware of some some less than ideal decisions on Unity and had a workaround for them. Some decisions on how to handle multithreading are way less than ideal, and even beefier machines are being harmed somehow by them. And since the workarounds are terribly counter-intuitive, it's not impossible that they could be caught with their pants down on the subject.

Since I have notice that they are helping on KSP1 development, and since KSP1 is somewhat messed up on performance on some still popular architectures, I think the OP concerns are pretty valid.

 

1 hour ago, K^2 said:

Finally, KSP's approach to loading assets being, "screw it, we're doing it live," just isn't generally a thing in game dev. I'd be mightily surprised if Intercept doesn't have their own build pipeline and are going to serve baked assets, which will speed up loading tremendously, not to mention help with memory overhead and leaks.

On that, I agree with you (except by the leak).

However, it was exactly that extremely unorthodox  loading scheme one of the reasons for KSP's huge success. This is extremely modding friendly, and mods are (was?) one of the cornerstone of the game.

But there are some vast opportunities for improvement, no doubt.

However, I disagree about the memory leaks. Memory overhead  are tied to less than ideal coding (been that, screwed that) but also due that very multithreading bad decisions I mentioned, that ended up screwing the garbage collector itself. Some leaks appears to be related to this too - with less cycles available to the GC, it does a less than ideal job with the time it have. But usually leaks are related to coding problems, what I agree with you are not expected to happen on KSP2 (at least, until mods start to be made for it).

Edited July 14, 2021 by Lisias
brute force post merging

[Vanamonde]

A number of comments have been removed from this discussion. Please disagree with each other without resorting to sarcasm or accusations of dishonesty. 

[shdwlrd]

46 minutes ago, Lisias said:

Since I have notice that they are helping on KSP1 development, and since KSP1 is somewhat messed up on performance on some still popular architectures, I think the OP concerns are pretty valid.

Are you referring to Squad helping Intercept or the other way around? Or that Squad personnel is transitioning to Intercept?

Personnel transitioning from Squad to Intercept doesn't automatically mean the problems present in KSP1 will be present in KSP2. 

[LHACK4142]

4 hours ago, Lisias said:

NASA uses KSP1 for fast prototyping some ideas, just for starters.

Source?

[Lisias]

11 minutes ago, LHACK4142 said:

Source?

Whoops. It was not NASA, it was the University of Alabama. The paragraph immediately followed one talking about NASA and I ended up mixing the information.

Sorry for the memory failure.

Quote

In 2018, NASA released Open MCT, a telemetry data visualization software designed for operating spacecraft, to the public on Github. It’s costly and time-consuming to test these systems on real spacecraft, so some participants ran their programs through Kerbal instead.

For Sumontro Sinha, an aerospace engineer and fusion researcher at the Propulsion Research Lab at the University of Alabama in Huntsville, Kerbal is the go-to for testing out new ideas and training new engineers.

“Instead of Powerpoint slides and pages of equations, just make the ship and see how it works,” he says.  “If it works in Kerbal, then it has a good chance of working in real life.”

https://www.wired.com/story/test-out-next-gen-space-tech-kerbal-space-program/

 

43 minutes ago, shdwlrd said:

Are you referring to Squad helping Intercept or the other way around? Or that Squad personnel is transitioning to Intercept

The information I have is that they were supporting each other on development (ksp2 devs giving a hand on ksp1, and vice versa. It was published here on forum sometime ago.

 

45 minutes ago, shdwlrd said:

Personnel transitioning from Squad to Intercept doesn't automatically mean the problems present in KSP1 will be present in KSP2. 

But using the same engine does.

[K^2]

1 hour ago, Lisias said:

Unless you have privileged access to the binaries (and so, please be cautions about the NDA you signed), what you have seen is the game running on developer's workstations.

It's literally part of my job to make sure games run well, which includes engine work, build pipeline work, and asset budgeting. If I couldn't look at how the game runs on a dev machine and anticipate problems in ship, I'd be crap at my job.

1 hour ago, Lisias said:

As long they are aware of some some less than ideal decisions on Unity and had a workaround for them. Some decisions on how to handle multithreading are way less than ideal, and even beefier machines are being harmed somehow by them. And since the workarounds are terribly counter-intuitive, it's not impossible that they could be caught with their pants down on the subject.

Nothing in KSP requires that kind of heavy lifting. All of performance issues in KSP are from bad code, bad use of physics, or bad use of assets. Unless they want to try to get KSP2 onto mobile or Switch, they shouldn't need to worry about threading model.

Is it possible that Intercept is making just as much of a mess? In theory, but that would imply that Intercept somehow has total amateurs running their engineering, while design, art, and tech art all produce industry-standard work. That doesn't happen in practice. A good tech artist will spot a bad engineer and vice versa. This isn't an amateur project. Intercept clearly knows what they're doing. I don't have a reason to expect them to do great at cutting edge tech, but fortunately, they don't have to do any of that. Just a competent, well organized studio that has people on it with years of prior dev experience is all you need here.

1 hour ago, Lisias said:

However, it was exactly that extremely unorthodox  loading scheme one of the reasons for KSP's huge success. This is extremely modding friendly, and mods are (was?) one of the cornerstone of the game.

If that was the only way to make it work, sure. But you can also include the builder in your binaries and have the mods be baked. That would require a slow load once, and then go back to fast loading unless any of the mod files change.

I mean, that's literally how internal build tools work in every studio I've worked at or with. If your game starts with building every time you run it, it's a nightmare to develop on. Not only is it horrible for asset designers, but it's abysmal for debugging. Getting the dev build to load lightning fast is almost more important than getting shipped version to load fast. So a competent, well resourced team starts by making a build pipeline that works with this. For UGC, you recycle this behavior. Of course, it's an overhead. So if you never had an off-line build process to begin with, it's easier to ship as is, but what a nightmare it is to experience! That's amateur work, and as noted above, Intercept don't look to be staffed with amateurs.

I've taken a look at selection of LinkedIn profiles. It's a very reasonable collection of backgrounds. Managers seem well seasoned and developers have experiences in the right areas. I see no reason for concern.

[Lisias]

4 minutes ago, K^2 said:

Nothing in KSP requires that kind of heavy lifting. All of performance issues in KSP are from bad code, bad use of physics, or bad use of assets. Unless they want to try to get KSP2 onto mobile or Switch, they shouldn't need to worry about threading model.

You are wrong. Sorry.

Unity, now, it's my worst source of performance problems on KSP 1.12.

[shdwlrd]

1 hour ago, Lisias said:

But using the same engine does.

How does Unity play into bad gaming experience? There are many games that have good performance that use Unity. There are also many that have poor performance. (This also applies to UnReal Engine and custom inhouse engines too.) The difference between the two is knowing how to properly leverage the engine your using. Poor coding and improper usage of the tools provided/purchased will tank the games performance. (That applies to all software, not just games.) Your argument that Unity is the root cause of all of KSP's shortcomings and any future shortcomings in KSP2 is just false.

This seems to me to be a personal dislike for Unity. If that is the case, just say you don't like Unity and leave it at that. There is too much proof that Unity was used to create good performing games.

[Incarnation of Chaos]

47 minutes ago, shdwlrd said:

How does Unity play into bad gaming experience? There are many games that have good performance that use Unity. There are also many that have poor performance. (This also applies to UnReal Engine and custom inhouse engines too.) The difference between the two is knowing how to properly leverage the engine your using. Poor coding and improper usage of the tools provided/purchased will tank the games performance. (That applies to all software, not just games.) Your argument that Unity is the root cause of all of KSP's shortcomings and any future shortcomings in KSP2 is just false.

This seems to me to be a personal dislike for Unity. If that is the case, just say you don't like Unity and leave it at that. There is too much proof that Unity was used to create good performing games.

Yep, people need to seriously shake the idea that Unity is the beginning and end of all of KSP's issues.

KSP not providing it's own implementation where Unity's is lacking is where the issue resides, and intercept appears to have the roster of people to make it happen.

But, there is a major point i think Lisias is saying that everyone is missing. Which is that it doesn't matter how many impressive resumes Intercept has, how much money 2K puts in, and how long they spend on it. They need to direct those resources to the right places to see success, instead of focusing on the wrong things.

But i don't see any indication Intercept is squandering their resources, but that's a drum i've been banging since day one.

 

[shdwlrd]

1 hour ago, Incarnation of Chaos said:

Yep, people need to seriously shake the idea that Unity is the beginning and end of all of KSP's issues.

KSP not providing it's own implementation where Unity's is lacking is where the issue resides, and intercept appears to have the roster of people to make it happen.

But, there is a major point i think Lisias is saying that everyone is missing. Which is that it doesn't matter how many impressive resumes Intercept has, how much money 2K puts in, and how long they spend on it. They need to direct those resources to the right places to see success, instead of focusing on the wrong things.

But i don't see any indication Intercept is squandering their resources, but that's a drum i've been banging since day one.

 

No disagreement here. All I want to add is, if Intercept is doing a custom solution(s) to what problems that they are seeing, they won't announce or advertise that fact. Their modus operandi is not to show/say something until it's working and almost complete. (Probably why we haven't heard anything about multiplayer yet.)

Some people may find that frustrating. Nate was very blunt on that point, no information would be released until it was ready to do so. (Nate was much more tactful with his delivery.)

[K^2]

5 hours ago, Lisias said:

You are wrong. Sorry.

Unity, now, it's my worst source of performance problems on KSP 1.12.

Oh really? So you've ran performance captures, analyzed the results, and identified which portions of Unity engine are causing problems for KSP? Well, don't keep us waiting, do share.

Now, I happen to know that all of the real bottlenecks in KSP are in CLR code. Unity Engine runs almost no CLR. It's all native code instead. GameObject behavior code does, however. So all of the issues are contained explicitly in game code. I also know what the game needs to do under the hood, and I know how long it should be taking for these systems to run. Again, making sure a game engine runs well is kind of my job. And the games I've worked on are a bit bigger and far more computationally expensive than anything KSP needs to do.

Now, I'm prepared to break out the debug tools and we can start analyzing the code. I already know that fuel pathing is one of the bigger resource hogs, which means it's absolute garbage code. Updating debris in orbits is another - also shouldn't be wasting nearly as much time as it currently does. And I'm prepared to drag you through that source code line by line, 'cause "You are wrong. Sorry." is not the right answer.

[Lisias]

4 hours ago, Incarnation of Chaos said:

Yep, people need to seriously shake the idea that Unity is the beginning and end of all of KSP's issues.

TLA crashes, Joysticks not being recognized on Linux, random crashes, terrible performance (worked around by hacking the mono runtime) you name it. Unity is one of the worst problems KSP has for years already.

Granted, it's not the only one.

 

4 hours ago, Incarnation of Chaos said:

KSP not providing it's own implementation where Unity's is lacking is where the issue resides, and intercept appears to have the roster of people to make it happen.

Yep, on that there's no doubt. But, frankly, how useful is an engine where indy developers need to reimplement things in order to offer a good product? You see, Unity - AFAIK - aims to make things simpler for the developer. If the dude is going to reimplement the World, would not be better to use Unreal Engine, id Tech or something else?

On the other hand, Unity allows you to "easily" target Linux and MacOS - what is an edge for indie games.

 

5 hours ago, Incarnation of Chaos said:

But, there is a major point i think Lisias is saying that everyone is missing. Which is that it doesn't matter how many impressive resumes Intercept has, how much money 2K puts in, and how long they spend on it. They need to direct those resources to the right places to see success, instead of focusing on the wrong things.

Programmers are committed to the task, not to the product (or the users). They will gladly kill the product by "fixing" a problem completely disregarding if it will hinder the users - sometimes, users just want the "bug" - as the unorthodox assets loading used by KSP1. Make no mistake, a huge lot of add'on authors rely on this one.

And add'ons are one of the best features from KSP1 (see the Wired article I posted above).

Since KSP2 is aiming beyound the indie market, it's reasonable to believe that some of the "terrible" characteristics that KSP1 users love will probably be gone, so it's reasonable to have them worried about it.

Since programmers usually ignores users's wishes and demands, favouring technical details over user satisfaction (and we have some text book examples on this very thread), it's reasonable to believe that perhaps KSP1 lovers would not be completely satisfied on KSP2.

Mac and Linux ones will not for sure.

Since Unity plagued KSP1 for years with some really nasty bugs that appears to hit random users, and Unity bugs they are (this forum is plenty of evidences about it), and since it's reported on this forum that Private Division is (was?) helping Squad on some KSP1 issues, it's reasonable to believe that if PD was aware of such problems, they would be helping to fix them. Since the problems still happens on KSP 1.12 (worsen, by the way), it's reasonable to believe that PD is not aware of such problems, and so KSP2 may be plagued by them too.

It's really a surprise there're so many KSP1 users worrying about KSP2? These guys play KSP1 for almost a decade, give them some credit.

 

5 hours ago, Incarnation of Chaos said:

But i don't see any indication Intercept is squandering their resources, but that's a drum i've been banging since day one.

Neither do I. I'm liking what I'm seeing in their videos.

However it's what we are not seeing the source of concernings, see the OP.

[Lisias]

2 hours ago, K^2 said:

'cause "You are wrong. Sorry." is not the right answer.

Good. Please don's use it on me so.

[K^2]

1 hour ago, Lisias said:

worked around by hacking the mono runtime

Found your problem.

1 hour ago, Lisias said:

Programmers are committed to the task, not to the product (or the users). They will gladly kill the product by "fixing" a problem completely disregarding if it will hinder the users - sometimes, users just want the "bug" - as the unorthodox assets loading used by KSP1. Make no mistake, a huge lot of add'on authors rely on this one.

I'm very sorry that you've clearly worked only in software sweatshops and never had experience working at a proper studio. Outside of some really bad mobile houses, nobody works this way in games.

1 hour ago, Lisias said:

Mac and Linux ones will not for sure.

You'll notice that Intercept doesn't even claim to support these platforms.

I get that you're bitter that the system reqs say that Linux and OSX are supported by KSP, but they aren't. Not really. You are running an unsupported version in the most literal sense. Unity has, fortunately, improved CLR on non-Windows machines recently, but none of these changes are ever going to make it into KSP. KSP was built on an older version of Unity that doesn't really support 'nix platforms despite any claims to the opposite. It was bad form of Squad to release it as anything but experimental.

Intercept is already ahead of the curve by not claiming that they support Linux. Which is smart. If the version of Unity they settle on will have good CLR performance on additional platforms, they can easily port it. Otherwise, it's not a huge loss to them. Windows machines do not have this problem. Simple as. And your entire pages of complaints in this thread are basically just wining about a broken version. Could have saved a lot of time if you opened with that.

1 hour ago, Lisias said:

Good. Please don's use it on me so.

I won't. I'll tell you exactly why you are wrong. On every single point. In detail. Anything less would be exceptionally rude.

[Jack Mcslay]

9 hours ago, Lisias said:

You are wrong. Sorry.

Unity, now, it's my worst source of performance problems on KSP 1.12.

Have a 1000 objects in orbit and watch the frame rate in the map screen. That isn't the engine's fault in any way, but some terribly written rendering routine that, given the game is apparently going to retire without fixing it I assume it might be a nightmarish  piece of spaghetti code they didn't want to touch in fear of creating a lot of problems

If the game's performance can be improved by hacking mono that shows the developers weren't using it properly, not that Unity's at fault; if mono's or unity's overall performance could be improved that way mono's developers would have patched it by now

[Incarnation of Chaos]

6 hours ago, Lisias said:

TLA crashes, Joysticks not being recognized on Linux, random crashes, terrible performance (worked around by hacking the mono runtime) you name it. Unity is one of the worst problems KSP has for years already.

Granted, it's not the only one.

 

Yep, on that there's no doubt. But, frankly, how useful is an engine where indy developers need to reimplement things in order to offer a good product? You see, Unity - AFAIK - aims to make things simpler for the developer. If the dude is going to reimplement the World, would not be better to use Unreal Engine, id Tech or something else?

On the other hand, Unity allows you to "easily" target Linux and MacOS - what is an edge for indie games.

 

Programmers are committed to the task, not to the product (or the users). They will gladly kill the product by "fixing" a problem completely disregarding if it will hinder the users - sometimes, users just want the "bug" - as the unorthodox assets loading used by KSP1. Make no mistake, a huge lot of add'on authors rely on this one.

And add'ons are one of the best features from KSP1 (see the Wired article I posted above).

Since KSP2 is aiming beyound the indie market, it's reasonable to believe that some of the "terrible" characteristics that KSP1 users love will probably be gone, so it's reasonable to have them worried about it.

Since programmers usually ignores users's wishes and demands, favouring technical details over user satisfaction (and we have some text book examples on this very thread), it's reasonable to believe that perhaps KSP1 lovers would not be completely satisfied on KSP2.

Mac and Linux ones will not for sure.

Since Unity plagued KSP1 for years with some really nasty bugs that appears to hit random users, and Unity bugs they are (this forum is plenty of evidences about it), and since it's reported on this forum that Private Division is (was?) helping Squad on some KSP1 issues, it's reasonable to believe that if PD was aware of such problems, they would be helping to fix them. Since the problems still happens on KSP 1.12 (worsen, by the way), it's reasonable to believe that PD is not aware of such problems, and so KSP2 may be plagued by them too.

It's really a surprise there're so many KSP1 users worrying about KSP2? These guys play KSP1 for almost a decade, give them some credit.

 

Neither do I. I'm liking what I'm seeing in their videos.

However it's what we are not seeing the source of concernings, see the OP.

I can't think of one engine where writing custom code at some point isn't needed, doesn't matter if it's unity, unreal, lumberyard etc.

We're not talking about reimplementation of an entire world though, mostly just things that the stock engine isn't that good for. Wheels would be a good example, KSPs issues with them lie in using the unity implementation.

KSPwheel reimplements them, and it fixed the majority of the issues associated with them.

Using a different engine just changes what you end up writing custom code for in the end, unreal is better for FPS than RPGs or sandbox games for instance.

Mac and Linux I do think will get shafted, since no confirmation has been given of support for them either way.

And I don't think it's a bad thing to have concerns about KSP2, because now is the best time to bring them to the development team and have any chance of being heard.

And yes, there's a lot of add ons that rely on the way KSP handles things. There were also quite a few applications that relied on DOS giving them exclusive access to memory....

They managed to adapt, or workarounds were found to replicate the bugs. If we never switched to a shared memory model just because it would have made it a bit more difficult, modern computers really wouldn't exist.

KSP2 I suspect that for all of its flaws, will be similar. Learning curve for modders will be a bit steep, but that's the price for the capability to do more than they ever could Imagine in KSP1

I can easily be wrong, but only time will tell.

 

 

 

[Lisias]

11 hours ago, Incarnation of Chaos said:

I can't think of one engine where writing custom code at some point isn't needed, doesn't matter if it's unity, unreal, lumberyard etc.

But the less, the better!

It's a trade: features for problems. Too much problems, and the features doesn't matter anymore.

 

11 hours ago, Incarnation of Chaos said:

We're not talking about reimplementation of an entire world though, mostly just things that the stock engine isn't that good for. Wheels would be a good example, KSPs issues with them lie in using the unity implementation.

KSPwheel reimplements them, and it fixed the majority of the issues associated with them.

That's interesting - I really enjoyed the new wheel model. Way more plausible and fun to mess with (working suspensions! this is great!).

But I agree that they took a bit too much to iron out the idiosyncrasies on the new model - but guess what, it was not the wheels code, it was something else that ended up screwing up the wheel's code. Ultimately, also related to Unity (but, granted, not necessarily Unity's fault).

 

11 hours ago, Incarnation of Chaos said:

Using a different engine just changes what you end up writing custom code for in the end, unreal is better for FPS than RPGs or sandbox games for instance.

In the end, you need to use the right tool to do the job right. IMHO, KSP had grown bigger than Unity, and this is not the first time I say it. However, this doesn't means that using Unity for KSP1 was a bad choice at all (and this is not the first time I say it neither).

I sincerely doubt KSP1 would had reached this absolutely amazing success had it be built using a C++ centric 3D Engine. Point.

But I also think that at this stage, Unity is the thing pushing it back nowadays,

IMHO KSP really had overgrown Unity, and this is not KSP's fault. And probably neither Unity's, it never aimed to be a full feature space physics simulator to be used by Universities or by people  to run NASA's code.

It only happens that KSP is being used as a fast prototyping physics space simulator by Universities, and there's people really running NASA code on it. Sooner or later something will snap.

As I use to say, choose your poison: what matters more to you? What's going to matter more for KSP2?

(You can't have the cake and eat it too, after all).

 

11 hours ago, Incarnation of Chaos said:

Mac and Linux I do think will get shafted, since no confirmation has been given of support for them either way.

It's my feelings too. And one of the very reasons I don't see (at least for now) too much value for KSP2 on still use Unity.

If they have the intention to at least try to support other platforms, however, I may change my mind - but yet, Unity has competition on this niche, and I think it's time to people start to consider it (at least for indy projects, since Unity aims now to be "mainstream" nowadays, as it appears).

 

11 hours ago, Incarnation of Chaos said:

And I don't think it's a bad thing to have concerns about KSP2, because now is the best time to bring them to the development team and have any chance of being heard.

Neither on be wrong on have such concerns.

And when we manage to create an environment where concernings are tackled down instead of concerned people, things get even better.

 

11 hours ago, Incarnation of Chaos said:

And yes, there's a lot of add ons that rely on the way KSP handles things. There were also quite a few applications that relied on DOS giving them exclusive access to memory....

They managed to adapt, or workarounds were found to replicate the bugs. If we never switched to a shared memory model just because it would have made it a bit more difficult, modern computers really wouldn't exist.

Yep. Features versus problems. The new features we got with modern, preemptive task switching on a memory protected model are way more valuable than the efforts we had to expend learning how to cope with them.

And believe me,  it took a lot of time. Most people don't have the slightest idea the damage the first Pentium IV with Hyper Threads made to the marked, tons and tons of really bad code that were abusing the multi-thread model only worked on single core CPUs. And then lots and lots of really bad code were written that only worked on HT CPUs - not a really good idea when about 80% of the userspace was still using single core ones.

(been there, diagnosed that - that stunt was one of the reasons for the shutdown of a million USD project, by the way. And I'm talking 2008 USD here. Do you see some resemblance with some other problems we have nowadays?)

 

11 hours ago, Incarnation of Chaos said:

KSP2 I suspect that for all of its flaws, will be similar. Learning curve for modders will be a bit steep, but that's the price for the capability to do more than they ever could Imagine in KSP1

KSP2, as far as I know, aims to be pretty different. They told us they will implement an proper API for modding, and that hacking on the engine will not be necessary (and perhaps, not even tolerated).

And, frankly, this is one less reason to stick with Unity, IMHO.

 

11 hours ago, Incarnation of Chaos said:

I can easily be wrong, but only time will tell.

So do I.

Experience on the field tells me that I'm mostly right than wrong, but by all means this isn't the same of being always right.

And there's nothing wrong on being wrong, by the way. Sometimes, it's even preferable to be wrong (as in the current subject).

[K^2]

2 hours ago, Lisias said:

It's my feelings too. And one of the very reasons I don't see (at least for now) too much value for KSP2 on still use Unity.

Lets leave aside the fact that KSP2 was originally meant to be a much smaller game and recycle a lot more of KSP work, which influenced Unity choice greatly. But lets pretend that you could start from scratch. What are other options?

Well, Godot is just worse. It has great potential, but it will be years before it's even simply caught up to Unity in the best case scenario.

Unreal can be a decent engine if your team has the discipline for it. You get the advantage of running native code if you write custom components and that can be more performant, easier to debug, and is guaranteed to run clean on all platforms. Great! On the other hand, none of the features of Unreal are especially useful to KSP2. From perspective of engine utilization, there is really no difference. But what's worse, Intercept is content-heavy engineering-light kind of team. In teams like that prototyping will be done in Blueprints. And if you don't go back and replace all the Blueprints with custom component code, it's going to be more performance problems and more bugs than you would likely ever have with Unity. Intercept needs to be 3-4 times larger as a company to make good use of Unreal.

CryEngine/Lumberyard. One of the few I don't have first-hand experience with, but everyone I worked with who do say it's a nightmare. Content pipeline is, allegedly, very difficult to navigate, which is a death sentence to project like KSP2.

RAGE is T2, so maybe R* would share. But you'd have to basically re-write physics solver, because Bullet is the only thing that's even worse for KSP2 than PhysX, and build a new component model for all of the ship parts. It's just not built to handle the kind of game that KSP2 is. You really might as well be writing things from scratch at this point.

What's even left? id Tech? That one's actually not a terrible option if you could even license it. Zeni wasn't big on that in the past few years, and I don't know where MS stands on it. But you'd also be making glacial progress on new features. There is just no good path for designers to prototype parts. So again, you'd want a larger engineering team to be making progress efficiently. Source is basically in the same boat, as it's heavily inspired by id. Plus, we haven't seen a public update in a while, so it's hard to say what state it's really in as a 3rd party offering.

Everything else is proprietary. You do get some sharing occasionally, but you'd have to make your own deal, and none of them come without the same problems as either Unreal, CryEngine, id Tech, or all of the above.

 

So that really leaves one final option, which is to roll your own from scratch. You already need to roll your own asset system, effectively, to handle ship parts. Rendering for KSP2 is so simple that you can do a fixed renderer, rather than complex graph renderer. It's not best utilization of resources, but it'd make it very easy to create DirectX12, GNM, Vulkan, and even Metal versions of renderer. If you have an asset system, a renderer, and you slap Havok physics on top of it, you basically have a framework for KSP2-like game. You still need to figure out animation, FX, UI, and various I/O systems, but it's a manageable workload for a mid-sized team. The only options that get you to an Alpha faster are Unity and Unreal, and you aren't going to have the same Blueprint problems pushing it to release as with Unreal. So this is actually a really solid option. But it still requires a larger engineering team staffed with more experienced engineers, and you need a longer pre-production runway for engineers to build the foundation. None of this is available to Intercept, nor was it remotely likely that they'd be able to have these resources.

So that's basically it. It's Unity, Unreal, or custom engine, and both of the latter options would require a much larger investment. Unity is the only one that lets Intercept leverage art and tech art without investing in more engineering, leaving the later to focus purely on gameplay components. It's the only option that gets KSP2 funding to ever be made. Simple as.

[severedsolo]

21 hours ago, K^2 said:

I get that you're bitter that the system reqs say that Linux and OSX are supported by KSP, but they aren't. Not really. You are running an unsupported version in the most literal sense

I was with you up to this point. Mac OSX and Linux are definitely supported by KSP. Do we 'Nix users tend to get the raw end of the deal? Absolutely. The release day (platform specific) bugs are usually worse on Linux it's true, but to say it's unsupported is simply not true. I get why Intercept are keeping quiet on Linux support, but IMO they would be shooting themselves in the foot, as a fair number of the big modders use Linux.

On the other hand, I agree that "Unity Bad" is also a load of bunk. Most of KSP's problems come from the patchwork nature of development, the fact that no other game was doing things at the scale that KSP was so the tools to do this didn't really exist, (at the time, Simple Rockets might now) and that alot of the core code was written by someone who had never designed a game before.

Edited July 16, 2021 by severedsolo

[K^2]

1 hour ago, severedsolo said:

I was with you up to this point. Mac OSX and Linux are definitely supported by KSP.

Simply clicking export to Linux, then fixing most egregious problems after they are reported by the community is not what I call support. More importantly, I don't think Unity provided a lot of support for running on Linux.

Unity started out entirely in Mono. It sucked. I remember trying to just debug projects in Unity back when it was originally running in Mono and it was a bad experience. Half the time your breakpoints just won't even get hit. So Unity ditched it in favor of CLR on Windows, and that became the only version anyone cared about - both inside Unity and most of developers using it - for quite some time. Mono remained as the version that provides Linux and OSX compatibility, but it kept getting worse and worse, as it was clearly not properly maintained. Add to that the fact that C# 3.5 support was originally added via transpiling it to 2.0 in Mono, while it had native support on CLR side. And while all this mess is happening on the side, KSP is being developed and expands into a larger and larger game.

Recently, as in the past 4-5 years, this has been rapidly improving. Mobile games got larger and more complex, and the older versions of Mono were no longer cutting it. Mono project started getting better updates and Unity started pulling updates to their fork more often as well as adding more fixes to their private fork. Unity2017 had improvements, but it's really only with Unity2019 that things started getting significantly better. Last update to KSP, as far as I can tell, was in 1.8 with Unity2019.2, which is from over 2 years ago. And even this version was more about optimizations for OSX and Android than Linux specifically. Though, it's still way better than what it used to be.

This is all changing pretty rapidly. Apple is making big moves and has worked with Unity to make sure it runs well on M1 laptops. I don't know if it's anything that will make it into a public branch of Mono or will stay entirely within Unity, but either way, a lot of improvements have been made, and many are platform-agnostic. The most recent versions of Unity runtime are pretty dang well performant on both OSX and Linux. So there's still hope that KSP2 will be able to benefit from that. But KSP's almost entire life span coincided with what was the worst period for Unity games on Linux. So I don't even hold it against Squad too much. I just wish they didn't try to market it as fully equivalent build to the Windows version.

[shdwlrd]

4 hours ago, Lisias said:

it was something else that ended up screwing up the wheel's code. Ultimately, also related to Unity (but, granted, not necessarily Unity's fault).

Yes and no. There was an incompatibility between Unity and PhysX that started the whole ball rolling with the wheels.

Harvester explains in this post what happened to the wheels and using a custom, unreleased version of VPP to "fix" the issue and other physics problems caused by this incompatibility.

This is when they updated VPP help with the wheel problems

The whole wheel mess was a combination of Unity, PhysX, VPP, and Squad. 

[Lisias]

3 hours ago, shdwlrd said:

Yes and no. There was an incompatibility between Unity and PhysX that started the whole ball rolling with the wheels.

Harvester explains in this post what happened to the wheels and using a custom, unreleased version of VPP to "fix" the issue and other physics problems caused by this incompatibility.

This is when they updated VPP help with the wheel problems

The whole wheel mess was a combination of Unity, PhysX, VPP, and Squad. 

I think we are talking about different problems. The mess with the wheels is not mutually exclusive with the mess with the (lacking of) clamping on some physics values that ended up leaking into the parts and inducing spurious forces. Apparently some overshooting PIDs (or something similar) were also to blame (and this can be directly related to multithreading too, and so Unity is also implied).

And I think this is the reason the wheels took so much time to be fixed (assuming they are, I'm currently unable to test KSP 1.12 by many reasons, 100% of them related to Unity). They were looking on the wrong place, expecting to see a problem on something that was working fine (of the most fine it can), and forgetting that you don't need a lightning bolt striking twice the same place to get your house fried again.

I'm not telling you are wrong. I'm telling you are not the only one being right on this subject.

As already said by Linus Torvalds, "Reality is messy".

 

5 hours ago, severedsolo said:

Most of KSP's problems come from the patchwork nature of development, the fact that no other game was doing things at the scale that KSP was so the tools to do this didn't really exist, (at the time, Simple Rockets might now) and that alot of the core code was written by someone who had never designed a game before.

I, obviously, disagree.

Most of the problems derived from the development mishaps can be worked around, sometimes easily, sometimes not (see the KSP-Recall stunt).

But once Unity strikes, it's game over™  - the user is toast and there's no way out, he stops playing the game. See the TLA Crash thread (a text book example of catastrophic failure over a silly and superfluous feature). And, as most of people that waste their time reading what I write must already know, 

Quote

A whopping 96 percent of dissatisfied customers won’t complain directly to the company (though they will tell 15 of their friends about their experience)

Source.

Unity is brittle, to say the least. There's no graceful failures on this thing. And this is hurting KSP1.

 

5 hours ago, severedsolo said:

I was with you up to this point. Mac OSX and Linux are definitely supported by KSP. Do we 'Nix users tend to get the raw end of the deal? Absolutely. The release day (platform specific) bugs are usually worse on Linux it's true, but to say it's unsupported is simply not true. I get why Intercept are keeping quiet on Linux support, but IMO they would be shooting themselves in the foot, as a fair number of the big modders use Linux.

I would like to say that ignoring MacOS would be too, but hell - I'm a Mac users and I don't support this thing anymore, my less old rig is a MacMini 6,2, (mid 2012) and I don't plan to ever buy another Mac again. Newer Macs just don't worth the price. It's sad, as this were one of the finest machines on the market, but sometimes enough is enough. Not to mention that Mac now is two different machines, M1 and x86. each one with their own idiosyncrasies. (sigh)

However, this leaded me to another elephant on the room, and Unity is screwing up KSP (and other indie developers) on this too.

Recent Steam's hardware surveys states that the games machines are aging, a not unexpected effect from the current economical situation  - employment issues, inflation, electronics shortage, you name it. QuadCore machines like the one I own and can't run KSP 1.12 are still the most popular machines on Steam, and besides 6 cores CPUs are starting to catch up, it's reasonable to assume this will take at least a couple years more than everybody was expecting to happen.

It's 38% of the installed base, by Turing's sake. An Indie game like KSP just can't lose these guys (hell, even mainstream games, as it will be KSP2, can't afford to loose them).

 

6 hours ago, K^2 said:

Well, Godot is just worse. It has great potential, but it will be years before it's even simply caught up to Unity in the best case scenario.

Right now, from my developer point of view, Unity is a terrible option for any potential Indie project I could start. Godot may be even worse, but the "may" keyword implies that it's already a better option (as it at least gives me hope it may not, something that Unity does not), at least for my purposes: I don't aim to expend my free time trying to help users to survive Unity crashes forever, something this forum is virtually littered with.

Frankly, I expected Unity would have professionals working on these issues on their paid time, not random Internet dudes like me burning free time.

 

6 hours ago, severedsolo said:

On the other hand, I agree that "Unity Bad" is also a load of bunk

If by any chance this is related to the subjects I'm talking about, I'm afraid this "Unity Bad" statement is a gross misrepresentation of what is being said here.

[Incarnation of Chaos]

10 hours ago, shdwlrd said:

Yes and no. There was an incompatibility between Unity and PhysX that started the whole ball rolling with the wheels.

Harvester explains in this post what happened to the wheels and using a custom, unreleased version of VPP to "fix" the issue and other physics problems caused by this incompatibility.

This is when they updated VPP help with the wheel problems

The whole wheel mess was a combination of Unity, PhysX, VPP, and Squad. 

Honestly I'd probably ask shadowmage for what he did with KSPwheel to fix it, if anyone has a good understanding of the mess that KSPs wheels are it's probably him.

[K^2]

5 hours ago, Lisias said:

Right now, from my developer point of view, Unity is a terrible option for any potential Indie project I could start. Godot may be even worse, but the "may" keyword implies that it's already a better option (as it at least gives me hope it may not, something that Unity does not), at least for my purposes: I don't aim to expend my free time trying to help users to survive Unity crashes forever, something this forum is virtually littered with.

For a personal or indy project, absolutely. Go Godot. That would honestly be my first recommendation for anything a team of up to about 10 people or so can make. I didn't mean to make it sound like it's bad in general. It has some good features, solid roadmap, and admirable goals. Unity and Epic are horrible companies, and it's great to have Godot as alternative to dealing with either. But it's raw and still in early development by engine standards. You can't ship a large game on it right now. So it was never a viable option for KSP2.

Purely in context of KSP2, I don't see any engine on the market that would work better than Unity. Rolling their own, making good use of middleware, would be my second choice for it. And having maintained in-house engines, knowing how much work and effort goes into it, I'm not suggesting it lightly. Unreal comes in at solid third, but it'd probably force KSP2 into EGS exclusivity, potentially reduce ability to mod, and no guarantees that it'd end up performing any better. More uniformly across platforms, for sure, but I don't think Intercept would be able to avoid heavy use of bad Blueprints, which would tank any gains from a better engine architecture.

You can complain about Unity, and I'll pitch in my laundry list of grievances about engine, documentation, and company, but there isn't actually a good alternative for this size project with this size team.