Why Unity as the game engine (this thread is established off my lack of understanding)

[Stocky]

HI all,

I'm genuinely curious from those who have or do work in the game dev space or even know something about an array of different game engines.

Is there a reason why the devs would choose Unity as the game engine for KSP2 over say a different game engine? Does it offer more functionality in certain areas that allow this kind of niche game to be created?
Is it the best in the market for creating such game? Is it to do with the easy mod support?

I want to know out of curiosity and ignorance why Unity is the devs preferred engine given the known issues and limitations with KSP1 which was also off a unity engine (although a different iteration of it)

Let us know!

[Will]

1. it's generally the easiest to get started
2. the first one used Unity, a lot of the code can just be copied over
3. it is cheap
4. Custom code for Unity use C# which is easier to write, but 3x slower than C++

[Stocky]

Originally posted by Will:

1. it's generally the easiest to get started
2. the first one used Unity, a lot of the code can just be copied over
3. it is cheap
4. Custom code for Unity use C# which is easier to write, but 3x slower than C++

Thanks for the response. Is it safe to say then that the answer to the question is basically because it suits the devs better and not the game as a whole?
Or is it equally as fair to say that the game would probably still be in development for another 3-4 years if it were a different game engine

[Alshain]

5. The problem has never been Unity. Unity gets a lot of flak because it's accessible, but because it's accessible it's often used by inexperienced coders and games on it often exhibit issues stemming from being developed by inexperienced coders. This was the case with Harvester as well. A brilliant person, but he basically learned to code while making KSP. That's not Unity's fault. The truth is Unity is a powerful game engine.

[Will]

Originally posted by Stocky:

Originally posted by Will:

1. it's generally the easiest to get started
2. the first one used Unity, a lot of the code can just be copied over
3. it is cheap
4. Custom code for Unity use C# which is easier to write, but 3x slower than C++

Thanks for the response. Is it safe to say then that the answer to the question is basically because it suits the devs better and not the game as a whole?
Or is it equally as fair to say that the game would probably still be in development for another 3-4 years if it were a different game engine

yes
depends on the skill of their programmers obviously, low skill programmers may never get it done.

There is no game that supports map size of billions of kilometres, rendering objects from a million km away, or physics for custom build rocket. All of these require custom engine, or heavy modification of existing engine. The first KSP hit many limitations because of Unity, common sense would suggest that the second one would avoid those limitations.

They chose to be cheap and easy instead.

[Stocky]

Originally posted by Alshain:

5. The problem has never been Unity. Unity gets a lot of flak because it's accessible, but because it's accessible it's often used by inexperienced coders and games on it often exhibit issues stemming from being developed by inexperienced coders. This was the case with Harvester as well. A brilliant person, but he basically learned to code while making KSP. That's not Unity's fault. The truth is Unity is a powerful game engine.

That provides some hope then. So in saying that there is still huge potential there to get this game running really well whilst also achieving everything mentioned in the marketing schemes?

That being said, its probably fair to say that the dev team isn't "experienced" (lack of a better word) in an ideal enough way to pull it off? Or are we just being picky ♥♥♥♥♥ and should let it slide for a while lol

[Will]

Originally posted by Alshain:

5. The problem has never been Unity. Unity gets a lot of flak because it's accessible, but because it's accessible it's often used by inexperienced coders and games on it often exhibit issues stemming from being developed by inexperienced coders. This was the case with Harvester as well. A brilliant person, but he basically learned to code while making KSP. That's not Unity's fault. The truth is Unity is a powerful game engine.

it has always been Unity because for starters you're forced to use a language that's 3x slower than C++

sure you can technically, do a lot of things in Unity, problem is it'll run like ♥♥♥♥. So usually you only use it for games that would have huge performance headroom anyway so that performance is not a concern.

[Kilo_60]

The unity engine causes persistent frequent stutters due to its garbage collection dump which was never resolved with KSP!

[Crescens]

Originally posted by Will:

Originally posted by Stocky:

Thanks for the response. Is it safe to say then that the answer to the question is basically because it suits the devs better and not the game as a whole?
Or is it equally as fair to say that the game would probably still be in development for another 3-4 years if it were a different game engine

yes
depends on the skill of their programmers obviously, low skill programmers may never get it done.

There is no game that supports map size of billions of kilometres, rendering objects from a million km away, or physics for custom build rocket. All of these require custom engine, or heavy modification of existing engine. The first KSP hit many limitations because of Unity, common sense would suggest that the second one would avoid those limitations.

They chose to be cheap and easy instead.

Out of curiosity, where is the documentation stating that Unity is actually affected by this kind of thing? It would obviously be a floating point issue, so it makes sense that all you would have to do is change the frame of reference and cut things into chunks, which Unity is capable of.

[Will]

Originally posted by Crescens:

Originally posted by Will:

yes
depends on the skill of their programmers obviously, low skill programmers may never get it done.

There is no game that supports map size of billions of kilometres, rendering objects from a million km away, or physics for custom build rocket. All of these require custom engine, or heavy modification of existing engine. The first KSP hit many limitations because of Unity, common sense would suggest that the second one would avoid those limitations.

They chose to be cheap and easy instead.

Out of curiosity, where is the documentation stating that Unity is actually affected by this kind of thing? It would obviously be a floating point issue, so it makes sense that all you would have to do is change the frame of reference and cut things into chunks, which Unity is capable of.

any game is affected by this, some games use 64-bit double float to alleviate the problem that allows you to have planet scale, but still not system scale. The trick KSP1 used, which is also copied to KSP2, is to move the universe rather than your vessel, so that the area around your rocket is always in the high percision region of whatever floating point representation you're using. But this is custom code Unity does not do by itself, which heavily affects performance.

As for stuff far away, they're actually rendered separately, again with custom code and then layered ontop of the final image, again major performance impact.

[Skorj]

Your two choices are Unity and Unreal. For most purposes they are interchangeable if you're stating from scratch. Unreal is better for third-person shooters and for whatever the latest semi-experimental stuff the GPU vendors are pushing (DLSS right now), not really relevant to KSP2. The main difference is they use different programming languages.

Since KSP1 used Unity, sticking with it for KSP2 is an obvious win. Not just for the dev team, but importantly for all the modders, It's not just the KSP1 code that would be easier to port over, sticking with the same programming language helps modders adapt to the new game.

Originally posted by Will:

The first KSP hit many limitations because of Unity, common sense would suggest that the second one would avoid those limitations.

They chose to be cheap and easy instead.

They did avoid the limitations of Unity that hurt the first game. The first game used the Unity physics engine. That's an obvious mistake that no one who knew game dev would make - despite the word "physics", it's entirely the wrong tool for actual physics sim. KSP1 was started buy a web developer with no clue about this stuff, and so saddled all future development with trying to make Unity physics work. The first thing the new team did was write a proper physics engine for KSP2.

It wasn't really a limitation of Unity, it was a limitation of a terrible architectural mistake that could never be fixed without a complete re-write.

[Auger]

In unity it's called origin shift. You basically shift to new origin and then use that as your base (0,0,0)

[Will]

Originally posted by Skorj:

They did avoid the limitations of Unity that hurt the first game. The first game used the Unity physics engine. That's an obvious mistake that no one who knew game dev would make - despite the word "physics", it's entirely the wrong tool for actual physics sim. KSP1 was started buy a web developer with no clue about this stuff, and so saddled all future development with trying to make Unity physics work. The first thing the new team did was write a proper physics engine for KSP2.

It wasn't really a limitation of Unity, it was a limitation of a terrible architectural mistake that could never be fixed without a complete re-write.

they used it again, in case you've been living in a cave

[Alshain]

Originally posted by Will:

Originally posted by Alshain:

5. The problem has never been Unity. Unity gets a lot of flak because it's accessible, but because it's accessible it's often used by inexperienced coders and games on it often exhibit issues stemming from being developed by inexperienced coders. This was the case with Harvester as well. A brilliant person, but he basically learned to code while making KSP. That's not Unity's fault. The truth is Unity is a powerful game engine.

it has always been Unity because for starters you're forced to use a language that's 3x slower than C++

sure you can technically, do a lot of things in Unity, problem is it'll run like ♥♥♥♥. So usually you only use it for games that would have huge performance headroom anyway so that performance is not a concern.

Not sure where your getting that stat from but I can assure you it is false.

[Crescens]

Originally posted by Will:

Originally posted by Crescens:

Out of curiosity, where is the documentation stating that Unity is actually affected by this kind of thing? It would obviously be a floating point issue, so it makes sense that all you would have to do is change the frame of reference and cut things into chunks, which Unity is capable of.

any game is affected by this, some games use 64-bit double float to alleviate the problem that allows you to have planet scale, but still not system scale. The trick KSP1 used, which is also copied to KSP2, is to move the universe rather than your vessel, so that the area around your rocket is always in the high percision region of whatever floating point representation you're using. But this is custom code Unity does not do by itself, which heavily affects performance.

As for stuff far away, they're actually rendered separately, again with custom code and then layered ontop of the final image, again major performance impact.

Mhm, so they are changing the frame of reference.
They are also platform invoking into quite a few C++ libraries, is this counted in your 3x slower?

[Alshain]

Originally posted by Skorj:

Your two choices are Unity and Unreal.

CryTek would like a word with you.