Could KSP Switch To Using Unreal Engine 4?

[Adelaar]

On 25-1-2017 at 1:12 PM, Red Iron Crown said:

Unity can be quite good graphically, an engine change would not be needed to improve KSP visuals.

Wow, with what the most Unity developed games manage to achieve graphically wise, I find it hard to believe that this is from the Unity engine...

Still, would love to have such level of graphics in KSP... NASA would never want to fire off a real rocket, they'd just be playing KSP all day.

[radonek]

3 hours ago, Adelaar said:

Wow, with what the most Unity developed games manage to achieve graphically wise, I find it hard to believe that this is from the Unity engine...

Why? It's a freakin movie. It's easy to squeze most of engine with a movie - as a designer you have complete control over every frame and use models and effects to fullest. Its harder to do when player can go around at poke around dark corners and unexpected angles. And its completely, utterly, coreblowingly different to make creative game where player can affect scene directly, adding complexity (and rendered polygons) at leisure.

3 hours ago, Adelaar said:

Still, would love to have such level of graphics in KSP... NASA would never want to fire off a real rocket, they'd just be playing KSP all day.

Easy. Make all ships into one big, detailed model. Use simple "one number" (read: shields) instead of proper collision physics. In short, turn it into yet another stupid space shooter, and you will be left with lots of computing power to render something visualy impressive. But I doubt NASA folk would be fooled by that.

[Arugela]

Very old bump, but could Vulcan or similar be used to bridge such things and use multiple engine codes at once somehow. If you could get the engine makers to make vulcan code or have companies make their own maybe a way to get rid of the need to choose and engine could be found so you don't have to change code as much as try out different engines in one ecosystem. Then, if possible, pic and choose which part of which engine is best for your software and then get specialized engines to do different things like visuals vs physics?

Edited January 16, 2021 by Arugela

[Incarnation of Chaos]

4 hours ago, Arugela said:

Very old bump, but could Vulcan or similar be used to bridge such things and use multiple engine codes at once somehow. If you could get the engine makers to make vulcan code or have companies make their own maybe a way to get rid of the need to choose and engine could be found so you don't have to change code as much as try out different engines in one ecosystem. Then, if possible, pic and choose which part of which engine is best for your software and then get specialized engines to do different things like visuals vs physics?

Vulkan is a Graphics API, so not in the way you think.

Both Unity and Unreal support it, but they both might implement it differently. Plus there's code that is completely independent of the Graphics API that will be varied between them as well.

So the answer is "Yes...but not really as much as you'd think"

[Dr. Kerbal]

I’m mean. It would be nice but what would happen if the game crashed? And also. KSP take up a lot of space. The switch might not have enough space. If so barley. On the PS4 after I downloaded KSP my storage was the go 25% to 55%. Or something like that. It took a LOTTTTTTT OFFFFFF SPACEEEEE!

[Incarnation of Chaos]

15 minutes ago, Dr. Kerbal said:

I’m mean. It would be nice but what would happen if the game crashed? And also. KSP take up a lot of space. The switch might not have enough space. If so barley. On the PS4 after I downloaded KSP my storage was the go 25% to 55%. Or something like that. It took a LOTTTTTTT OFFFFFF SPACEEEEE!

You really think this is getting a switch port?

LEL

Also... that's pretty impressive considering the PC version is around 12GB. So even with a 500GB HDD that's hardly a jump from 120GB to 250GB.

Either the console versions are even more horrible than I thought, or you might need to recheck your numbers xD

 

 

 

[Dr. Kerbal]

Um. No. They would have to rewrite th PE game, and that takes a lot of work. Also I’m not sure but what if all your saves or gone or you have to buy a new KSP game?

On 1/16/2021 at 7:22 PM, Incarnation of Chaos said:

You really think this is getting a switch port?

LEL

Also... that's pretty impressive considering the PC version is around 12GB. So even with a 500GB HDD that's hardly a jump from 120GB to 250GB.

Either the console versions are even more horrible than I thought, or you might need to recheck your numbers xD

 

 

 

Wait, no sorry, but a chunk of space was taken last time I remember before I got KSP. It increased by some gigabytes. But that also might be my pictures on the PS4.

On 1/16/2021 at 7:22 PM, Incarnation of Chaos said:

Either the console versions are even more horrible than I thought, or you might need to recheck your numbers xD

 

There are also lots of bugs. 

[jastrone]

just wait to ksp 2 to get better graphics because I dont think the ksp team is going for graphics at all when creating ksp. they have redon the ttextures for some celestial bodies but that probably the most graphics youll get in a while

[Incarnation of Chaos]

20 hours ago, Dr. Kerbal said:

Um. No. They would have to rewrite th PE game, and that takes a lot of work. Also I’m not sure but what if all your saves or gone or you have to buy a new KSP game?

Wait, no sorry, but a chunk of space was taken last time I remember before I got KSP. It increased by some gigabytes. But that also might be my pictures on the PS4.

There are also lots of bugs. 

I knew about the bugs, but if it took more space on top that's even worse lel.

[Starhelperdude]

On 1/20/2021 at 7:34 PM, jastrone said:

just wait to ksp 2 to get better graphics because I dont think the ksp team is going for graphics at all when creating ksp. they have redon the ttextures for some celestial bodies but that probably the most graphics youll get in a while

I disagree, I would say they did 1. a great job in giving us new stuff and 2. made the graphics super nice on pretty much all stuff we've seen (and this is still early alpha)

[Grimmas]

I don't mean to beat on a dead horse but, as someone who has actually looked into this topic and worked a little bit on game code in UE4 at the scale of KSP - let me just say that UE4 is really not well suited for this sort of game. Some people managed to do it despite everything (Helium Rain was published on Steam for instance, and it's an UE4 game - open source, too) but the origin rebasing tech in UE4 isn't that great, it's more of an afterthought. So - like with Unity, I suspect - you quickly find yourself writing custom code (but now all in C++ mind you).

And all those great visual advantages you see in UE4 games? They work great for scenes a few km wide that have mostly static geometry - because you can pre-bake static lightmaps - but all that goes out the window when your scene is the size of a planet and/or has a lot of dynamic stuff. So again, you'll need completely custom code to handle planets. 

Most crucial for KSP though is that UE4 has almost zero support for mods. Imagine you had to download Unity and write a ModuleManager.dll (but in C++) every time you wanted to make a parts mod. It's basically that bad. You need the game creator's devkit (basically a custom version of UE4 that the developer has to package and maintain for you). Any mod support to be added has to be again - you guessed it - 100% custom code, and realistically it has to be code that actively circumvents UE4's packaging and virtual file system (which live in a fantasy console-style land where it's a valid assumption that all game files are static and will never be edited or added to by the player, so you can bake all content into one giant multi-gigabyte file, encrypt it so the player can't open it, and call it a day). But you don't need my opinion, just look at what a pain the butt it is to write mods for Satisfactory. 

So, it's obvious of course, but there are really zero advantages of porting KSP to UE4 and only a heap of trouble (not to mention it would cost at least as much as it already did to make KSP in the first place).

[pandaman]

The  'Unity sucks, shouldn't KSP use a different engine?' question seems to be one of those 'grass looks greener over the fence issues to me.  You may possibly get greener grass over there, but will the flowers in the borders grow as well?

Sure, all game engines will have their strengths and weaknesses, but changing to a different  one (apart from the immense amount of work involved) could just as easily create new unforseen issues  that are worse than those that are improved.

[Jack Mcslay]

Had KSP started in Unreal Engine, they would probably have had the exact same problems. Universal engines are not well-suited for games heavily relying on physics and constructing elements. Ideally a game such as KSP should have a ground-up custom engine, but I don't fault them for using a pre-built one given their limited budget.

It's a shame Godot wasn't a thing when KSP first started development, an open source game engine would have worked really well, anything they had a problem with could be fixed and customized at the source rather than fighting against the engine's limitations, but unfortunately the closest thing there was at the time that I know of was Irrlicht and Blender Game Engine, which really aren't as robust.

[Grimmas]

Open source engines are not some sort of panacea. Lack of licensing costs is a very small consideration when making a professional game (it is a much bigger consideration for indies of course). There are other hidden costs. And game developers usually are not in the business of pushing an FSF FLOSS agenda - they just want to make great games and get rich doing so :-)

When picking an engine or deciding to roll your own, the more interesting considerations are proven track record of commercially successful released games, availability of paid support, availability of free support, community size, a robust toolchain (including various editors, 3dmax/maya/blender exporters, etc), engine feature set (ie support for the latest goodies, today I guess that's PBR, ray tracing, and fur shaders?), and the availability of developers familiar with the engine (you don't want to train people to use it if you can hire someone who is already proficient with it).

[Incarnation of Chaos]

On 4/16/2021 at 8:26 PM, Grimmas said:

I don't mean to beat on a dead horse but, as someone who has actually looked into this topic and worked a little bit on game code in UE4 at the scale of KSP - let me just say that UE4 is really not well suited for this sort of game. Some people managed to do it despite everything (Helium Rain was published on Steam for instance, and it's an UE4 game - open source, too) but the origin rebasing tech in UE4 isn't that great, it's more of an afterthought. So - like with Unity, I suspect - you quickly find yourself writing custom code (but now all in C++ mind you).

And all those great visual advantages you see in UE4 games? They work great for scenes a few km wide that have mostly static geometry - because you can pre-bake static lightmaps - but all that goes out the window when your scene is the size of a planet and/or has a lot of dynamic stuff. So again, you'll need completely custom code to handle planets. 

Most crucial for KSP though is that UE4 has almost zero support for mods. Imagine you had to download Unity and write a ModuleManager.dll (but in C++) every time you wanted to make a parts mod. It's basically that bad. You need the game creator's devkit (basically a custom version of UE4 that the developer has to package and maintain for you). Any mod support to be added has to be again - you guessed it - 100% custom code, and realistically it has to be code that actively circumvents UE4's packaging and virtual file system (which live in a fantasy console-style land where it's a valid assumption that all game files are static and will never be edited or added to by the player, so you can bake all content into one giant multi-gigabyte file, encrypt it so the player can't open it, and call it a day). But you don't need my opinion, just look at what a pain the butt it is to write mods for Satisfactory. 

So, it's obvious of course, but there are really zero advantages of porting KSP to UE4 and only a heap of trouble (not to mention it would cost at least as much as it already did to make KSP in the first place).

 

On 4/23/2021 at 1:59 PM, Grimmas said:

Open source engines are not some sort of panacea. Lack of licensing costs is a very small consideration when making a professional game (it is a much bigger consideration for indies of course). There are other hidden costs. And game developers usually are not in the business of pushing an FSF FLOSS agenda - they just want to make great games and get rich doing so :-)

When picking an engine or deciding to roll your own, the more interesting considerations are proven track record of commercially successful released games, availability of paid support, availability of free support, community size, a robust toolchain (including various editors, 3dmax/maya/blender exporters, etc), engine feature set (ie support for the latest goodies, today I guess that's PBR, ray tracing, and fur shaders?), and the availability of developers familiar with the engine (you don't want to train people to use it if you can hire someone who is already proficient with it).

Gosh, I wish this would be stickied somewhere conspicuous in massive bold red text.  You actually get it.

[HebaruSan]

On 4/23/2021 at 5:43 PM, Jack Mcslay said:

an open source game engine would have worked really well, anything they had a problem with could be fixed and customized at the source rather than fighting against the engine's limitations

Making custom changes to any third party dependency makes things complicated. When your local copy (the one you're planning to ship) is out of sync with upstream, upgrading to a newer standard version becomes more difficult or impossible. For each change you've made, you have to figure out whether the need (bug or missing feature) still exists; if it was addressed upstream, you need to figure out whether and how to update your code accordingly. If it wasn't addressed upstream, you need to re-patch it into the newer version of the code (sometimes introducing new bugs along the way).

KSP has upgraded its version of Unity3d several times, gaining things like Win64 support, DirectX11 support, performance improvements (remember when people used to complain endlessly about "the stutter" from garbage collection?), etc., that are outside the team's primary focus of making art and mechanics for a game. This was a big effort even though they only used the standard releases of Unity; it would have been far worse if they also had a collection of source-level customizations to pull forward.

One solution is to pick a version, customize the heck out of it, and never upgrade it. This would probably have been a disaster for KSP. Imagine if the upstream project announced support for some cool new feature that everybody wanted in the game, and the response from the game devs was, "We'd like to, but we can't, because the differences with our custom engine are just too great."

Or you might limit the kinds of changes you allow; for example, we only fix bugs inside the existing functions, never changing public interfaces. But then you've lost the ability to make the bigger structural changes that you're talking about that have to do with what sorts of games the engine is designed to support well.

Another option is to assign somebody from your team to work to incorporate your changes into the upstream project. This could help, but now instead of just making content for your game, that person is also advocating for your team with whoever runs the other project, negotiating changes that all the other stakeholders can agree on, probably giving and receiving code reviews, etc. They effectively become a member of another team for whatever proportion of their work hours are required to do all this. And it still won't guarantee compatibility and easy upgrades, in those cases where the upstream project prefers a different approach than the one you've taken for a particular change in your local fork.

Considering these alternatives, I can appreciate why a team would decide to license the best "close enough" engine they can with their budget and then do the best they can to make it do what they need.

 

[Incarnation of Chaos]

2 hours ago, HebaruSan said:

Making custom changes to any third party dependency makes things complicated. When your local copy (the one you're planning to ship) is out of sync with upstream, upgrading to a newer standard version becomes more difficult or impossible. For each change you've made, you have to figure out whether the need (bug or missing feature) still exists; if it was addressed upstream, you need to figure out whether and how to update your code accordingly. If it wasn't addressed upstream, you need to re-patch it into the newer version of the code (sometimes introducing new bugs along the way).

KSP has upgraded its version of Unity3d several times, gaining things like Win64 support, DirectX11 support, performance improvements (remember when people used to complain endlessly about "the stutter" from garbage collection?), etc., that are outside the team's primary focus of making art and mechanics for a game. This was a big effort even though they only used the standard releases of Unity; it would have been far worse if they also had a collection of source-level customizations to pull forward.

One solution is to pick a version, customize the heck out of it, and never upgrade it. This would probably have been a disaster for KSP. Imagine if the upstream project announced support for some cool new feature that everybody wanted in the game, and the response from the game devs was, "We'd like to, but we can't, because the differences with our custom engine are just too great."

Or you might limit the kinds of changes you allow; for example, we only fix bugs inside the existing functions, never changing public interfaces. But then you've lost the ability to make the bigger structural changes that you're talking about that have to do with what sorts of games the engine is designed to support well.

Another option is to assign somebody from your team to work to incorporate your changes into the upstream project. This could help, but now instead of just making content for your game, that person is also advocating for your team with whoever runs the other project, negotiating changes that all the other stakeholders can agree on, probably giving and receiving code reviews, etc. They effectively become a member of another team for whatever proportion of their work hours are required to do all this. And it still won't guarantee compatibility and easy upgrades, in those cases where the upstream project prefers a different approach than the one you've taken for a particular change in your local fork.

Considering these alternatives, I can appreciate why a team would decide to license the best "close enough" engine they can with their budget and then do the best they can to make it do what they need.

 

Honestly I think the best solution would probably be something close to having the core functions (physics, planets, parts) in their own DLL and the source code on GitHub and open source. 

But I'm assuming that the goal from the beginning is high maintainability and the ability to make essentially endless modification to core game systems.

Setup like that, the game is essentially just a mod itself to the base engine and calls it's own code for most things.

This is incredibly labor intensive, requires people who have experience with writing custom plugins and takes much longer than just using Unity's base.

So basically, such a game is essentially a fantasy of nerds like me. Especially since you don't need to go through nearly as much to expose enough for the modding community to have a similar level of ability. Oh, and bonus for using the API approach is not having people downloading straight DLLs all the time xD

[Jack Mcslay]

5 hours ago, HebaruSan said:

KSP has upgraded its version of Unity3d several times, gaining things like Win64 support, DirectX11 support, performance improvements (remember when people used to complain endlessly about "the stutter" from garbage collection?), etc., that are outside the team's primary focus of making art and mechanics for a game. This was a big effort even though they only used the standard releases of Unity; it would have been far worse if they also had a collection of source-level customizations to pull forward.

Not really, no. It's generally about the same amount of code to be refactored, the only difference is that the portion of code that you would put into the engine goes into the gamecode instead.

In fact it might potentially reduce the amount of refactoring because when you need something so far off the engine's original scope you often times find yourself fighting against the engine creating workarounds that would not be needed if you just patched the engine to the behaviour you want.

[HebaruSan]

7 minutes ago, Jack Mcslay said:

the portion of code that you would put into the engine goes into the gamecode instead.

So now code relationships that previously would have been encapsulated / isolated by the engine's public interfaces, are now a free-for-all in which anything may have changed anywhere across both projects. That's why upgrading the engine to a new upstream release would be a nightmare.

7 minutes ago, Jack Mcslay said:

when you need something so far off the engine's original scope you often times find yourself fighting against the engine 

... except that KSP hasn't had to re-do, say, the KrakensBane solution (the paradigmatic example of "fighting against the engine", I think we can all agree). Since they wrote it according to Unity's public interfaces, and those interfaces still exist, it still works today. If they had patched Unity itself instead, they'd have to re-do that work whenever the upstream Unity project itself made changes to the same code.

[Grimmas]

The argument "it's just moving the refactoring around into engine code" does not hold water in the real world. There's a reason why engine programmers get paid more than gameplay programmers. That stuff is critical and hard and best left to senior employees who know what they're doing. You don't let the mechanic trainees tinker with your car's engine, and you don't let the starry-eyed interns tinker with your game engine. 

[Singhnaut]

they can but why would they do that when KSP 2 is right around the corner...hopefully

[Grimmas]

KSP2 is also made in Unity. I'm sure we'll rehash this whole thread again in 2022 or if/whenever KSP2 comes out :-)

[Kerminator K-100]

Yikes this thread

It just because Unity's asset store and asset flippers that give Unity its bad reputation. Unity is capable of amazing things, as are all engines. There is no "this engine is better", there is, "this engine is better for me". Unity is easier to learn than Unreal and is much better for simple projects. But you can add custom modules to Unity to make it even better.

[Incarnation of Chaos]

24 minutes ago, Kerminator K-100 said:

Yikes this thread

It just because Unity's asset store and asset flippers that give Unity its bad reputation. Unity is capable of amazing things, as are all engines. There is no "this engine is better", there is, "this engine is better for me". Unity is easier to learn than Unreal and is much better for simple projects. But you can add custom modules to Unity to make it even better.

Yep, and honestly most issues in KSP are from the lack of a custom implementation instead of the stock one. No engine or API would change that, and thus is why we have KSP2.