Why Unity?

[Alshain]

1 hour ago, Red Iron Crown said:

Do any of the modern game engines use doubles for their physics calcs? I suspect not but don't really know.

I doubt it, but I do not know either.

Earthly physics simply don't need them, and most games are nothing but earthly physics.

[Curveball Anders]

Most, if not all, indie development programs starts on a wing and a prayer.

KSP is no different but still started under a bit special circumstances.

HarvesteR was given a limited amount of time and a sliver of budget to present his backers (actually his employers) with a business plan and a proof of concept.

And that is exactly what Unity delivers better than most other engines (and better than writing from scratch (unless possibly if you're both a borderline genius _and_ your own boss)).

The only reasonable time to switch away from Unity was when the project got final go ahead from the backers.
But that would have meant throwing away much of the work done and restart from close to zero and that it had been included in the accepted business plan.

I believe that every project lead in history have screamed "Why did we base our project on this scrap of turd!" but very few have actually decided to redo from scratch in a new environment (unless forced by extreme external circumstances).

So the answer to "why Unity" is "it worked".

Edited May 8, 2017 by Curveball Anders

[Corw]

What is HarvesteR up to these day anyway?

[Xavven]

To be honest, I hope that either Squad makes a KSP 2 on a different engine, or another developer makes their own competitor to KSP on a different engine. My wishlist for this new engine would include:

1. High-end graphics. KSP is made to be accessible to lower-end systems. I have a gaming PC and I want to USE IT. 
2. Axial tilt. I'd love to see a planet with ~90 degrees of axial tilt, like Uranus.
3. Realistically sized planets/moons/star. KSP is about 1/10th scale.

[Cucco-Master]

41 minutes ago, Xavven said:

 

1. High-end graphics. KSP is made to be accessible to lower-end systems. I have a gaming PC and I want to USE IT. 
2. Axial tilt. I'd love to see a planet with ~90 degrees of axial tilt, like Uranus.
3. Realistically sized planets/moons/star. KSP is about 1/10th scale.

Someone really has to say it now: There are mods for that.

For 1.: Stock Visual Enhancement, Stock Visual Terrain, Window Shine, Engine Lighting and many more ...

For 2.: Principia (I have not used this one myself, but I believe it can do axial tilt as well)

For 3.: Real Solar System, various rescales for the stock system and some others

If you are on a gaming pc, mods are a valid solution and even if they were not, they would still show that everything you want is possible on the current engine, in the current KSP. No KSP 2 or even a rival game needed for this.

[Curveball Anders]

3 hours ago, Corw said:

What is HarvesteR up to these day anyway?

I hope he is:

• Chilling.
• Pondering his future.
• Twiddling with stuff he likes.
• Having a generic good time.

[HebaruSan]

5 hours ago, Curveball Anders said:

But that would have meant throwing away much of the work done and restart from close to zero and that it had been included in the accepted business plan.

I've been debating whether to post this, but hopefully it'll be worth mentioning.

It's possible to write any software so as to minimize the amount of code that relies on any given dependency. How? Create a GameEngine abstract base class that uses only your types in its public interface, use that class whenever you need something from Unity, then derive a UnityGameEngine class from it and allow only that one class to use Unity-specific types, functions, etc. When the program runs, your Main function creates an instance of UnityGameEngine and passes it to the rest of the program. If any class needs more services to be provided by Unity, you add them first to GameEngine in an abstract way, then put the Unity-specific implementation in UnityGameEngine.

Later, when you get tired of Unity, you derive a new UnrealGameEngine class from GameEngine, and the code needed to finish the port corresponds to the abstract class members to implement. After you finish that class, you still have to check for things that Unity gave you "for free", and probably add those to GameEngine and its child classes as well. But it's still going to be far easier than stripping out all usages of, say, UnityEngine.Transform from random spots distributed throughout tens of thousands of lines of code.

Of course, this assumes all the engines you'll want to be able to choose from are available in the same programming language. And it doesn't work for certain code patterns such as inheriting from base classes provided by the engine; such classes would have to be included in the engine-specific part of the code (maybe generics could help there somehow).

Note, I'm not complaining that SQUAD didn't do this or even saying that they "should" have; just pointing it out as an option for anyone that has to choose something like a game engine for a future project.

[Alshain]

5 minutes ago, HebaruSan said:

I've been debating whether to post this, but hopefully it'll be worth mentioning.

It's possible to write any software so as to minimize the amount of code that relies on any given dependency. How? Create a GameEngine abstract base class that uses only your types in its public interface, use that class whenever you need something from Unity, then derive a UnityGameEngine class from it and allow only that one class to use Unity-specific types, functions, etc. When the program runs, your Main function creates an instance of UnityGameEngine and passes it to the rest of the program. If any class needs more services to be provided by Unity, you add them first to GameEngine in an abstract way, then put the Unity-specific implementation in UnityGameEngine.

Later, when you get tired of Unity, you derive a new UnrealGameEngine class from GameEngine, and the code needed to finish the port corresponds to the abstract class members to implement. After you finish that class, you still have to check for things that Unity gave you "for free", and probably add those to GameEngine and its child classes as well. But it's still going to be far easier than stripping out all usages of, say, UnityEngine.Transform from random spots distributed throughout tens of thousands of lines of code.

Of course, this assumes all the engines you'll want to be able to choose from are available in the same programming language. And it doesn't work for certain code patterns such as inheriting from base classes provided by the engine; such classes would have to be included in the engine-specific part of the code (maybe generics could help there somehow).

Note, I'm not complaining that SQUAD didn't do this or even saying that they "should" have; just pointing it out as an option for anyone that has to choose something like a game engine for a future project.

That likely wouldn't change the cost of it all though.  While that might make it easier to locate all the game engine code, you would still have to completely rewrite the wrapper, plus it would have been a lot of work to write that wrapper in the first place, basically duplicating functionality of the engine classes on the assumption that you might one day want to change the engine.

Edited May 8, 2017 by Alshain

[JAFO]

23 hours ago, Red Iron Crown said:

Do any of the modern game engines use doubles for their physics calcs?

Oolite does.. but its use as a game engine is rather limited. (though recent changes to the API have made it considerably better than it used to be)

[Xavven]

12 hours ago, Cucco-Master said:

Someone really has to say it now: There are mods for that.

For 1.: Stock Visual Enhancement, Stock Visual Terrain, Window Shine, Engine Lighting and many more ...

For 2.: Principia (I have not used this one myself, but I believe it can do axial tilt as well)

For 3.: Real Solar System, various rescales for the stock system and some others

If you are on a gaming pc, mods are a valid solution and even if they were not, they would still show that everything you want is possible on the current engine, in the current KSP. No KSP 2 or even a rival game needed for this.

I appreciate you pointing out those mods and they do help. They can only do so much, though. Think of what a sequel or competitor could do if they started from scratch. Here's an album showing a KSP Kerbin shot with a bunch of visual enhancements, vs a screenshot I just took in DCS A-10C out my cockpit over Georgia. Then a KSP screenshot of Mun vs. an asteroid from Space Engine.

 

 

Edited May 9, 2017 by Xavven
Fiddly Imgur embeds

[Alshain]

45 minutes ago, Xavven said:

I appreciate you pointing out those mods and they do help. They can only do so much, though. Think of what a sequel or competitor could do if they started from scratch. Here's an album showing a KSP Kerbin shot with a bunch of visual enhancements, vs a screenshot I just took in DCS A-10C out my cockpit over Georgia. Then a KSP screenshot of Mun vs. an asteroid from Space Engine.

 

You are mis-attributing design decisions of KSP as faults of Unity.  KSP does not fully utilize the graphical capabilities of Unity and that is not Unity's fault.  KSP could have visuals like that, but KSP has so much else going on and the intent of the game was always space, so most of the time you wouldn't be able to see that kind of detail.  They made the choice not to invest heavily in terrain details when developing KSP.

 

Unity itself is capable of quite a lot.

 

Edited May 9, 2017 by Alshain

[Xavven]

Yep, that looks great. Make my KSP look like that. Show me a mod that does that. Or develop a KSP 2 or competitor that looks like that. Either way I'm happy.

[Alshain]

13 minutes ago, Xavven said:

Yep, that looks great. Make my KSP look like that. Show me a mod that does that. Or develop a KSP 2 or competitor that looks like that. Either way I'm happy.

It could probably be done if you don't need any more than about 5 parts per craft, and 10 parts total ever in physics range.

[Xavven]

1 minute ago, Alshain said:

It could probably be done if you don't need any more than about 5 parts per craft, and 10 parts total ever in physics range.

Is that a limitation of KSP, Unity, or current computing power?

[softweir]

10 hours ago, Xavven said:

Is that a limitation of KSP, Unity, or current computing power?

The limit of current PC computing power. At that level of detail, even with as much of the load thrown on to the GPU as possible, the CPU is still pretty much wacked-out generating data for the GPU to render. Those demos were restricted to limited maps with a lot of map data loaded into ram, but to render world-sized maps of that quality you need a heck of a lot of algorithmic detail generation, and that takes CPU power. Top-end CPUs with 8 cores or so may well be able to cope, but there aren't enough of them out there to justify making the code to achieve that.

Another problem is that the system would still need to have a lot of pre-computed data to ensure that every player's planets looked the same. KSP needs coarse-detail heightmaps and biome maps for each world (with smaller details filled in algorithmically) to ensure consistent world-appearance. (Different CPU brands and models tend to have slight numerical inconsistencies that can cause bizarre differences in algorithmic world generation, and even operating systems can cause inconsistencies!) As the developers add more facets to the world-generation, so they have to add further levels of data to the world-maps. This amplifies the effort required in creating the world maps during development, and expands the distribution size. The PC also has to do more fetching of map-data from disk as the player's vehicles move about, increasing the lag problems which are already an issue even with the existing levels of detail.

I think it quite likely that as KSP matures and Squad start to think of maybe a KSP 2, so they will work on increasing the detail levels to create more eye-candy for aviators and buggy-drivers, but they will always have an eye on CPU load and ensuring that the physics engine is doing its job, which in this game is the priority!

[Alshain]

11 hours ago, Xavven said:

Is that a limitation of KSP, Unity, or current computing power?

Depends on how you look at it. It's a limit on computing power due to the design of KSP.  Most games treat a vehicle as a single piece, KSP handles physics on each individual component of a vehicle.  The fact is KSP pushes the boundaries of what game engines are designed to do. As an example, a 100 part space station in KSP would be like having 100 cars on screen and physically interacting with each other in a game like GTA.  No game engine ever made was designed with a KSP type game in mind.

Edited May 9, 2017 by Alshain

[Xavven]

I thought that KSP's physics calculations were CPU intensive, whereas drawing more polygons with higher textures, better lighting, and volumetric clouds, etc. are more GPU intensive. My graphics card isn't even breaking a sweat on KSP. Couldn't the right developer with the right engine (whether it's Unity or not) conceivably better maximize the resources available on my PC to improve graphics while keeping framerates high?

Even Elite Dangerous, which is two and a half years old, looks better than KSP, and I still get smooth framerates from space down to landing on a planet or moon surface (though there is a pause to load textures one time when you reach a certain altitude). Whether it's the engine or design decisions, I doubt that KSP 1, with its tiny development studio, will ever come close to what a bigger studio could build with their own engine, or a number of other engines out there optimized for space and planetary landscapes at huge scale.

Unity is not specialized. Its purpose is to enable a small team to crowdsource a lot of their assets, but it's not especially good at any one thing. Case in point... look how long it's taken to squash orbital wobble because of how floating point integers are handled. Specialization is why The Witcher III uses REDengine and Forza uses ForzaTech. Just imagine if a car racing game like Forza used whatever wheel plugin Squad bought for KSP's rovers for version 1.2 -- it's a laughable prospect.

We need more people to love games like KSP so that this admittedly niche market attracts the attention of bigger budget studios that can bring their own take on near-realistic space exploration games with orbital mechanics. I for one can't wait to see what a large team of career-programmers and artists could do for this genre. Sign me up for KSP 2 -- I'll be the first to pre-order.

[Alshain]

@Xavven

Graphics Cards process visuals for display, but they do not add detail (except in the case of GPU accelerated physics, which afaik is limited to Nvidia, and doesn't do much).

Elite dangerous uses single model physics.  Again, your whole ship is one object.  Each space station is one object. etc.  It's not calculating the physics colliders that KSP asks of Unity.  It only has to calculate when your ship hits something else, it doesn't have to calculate if your engine or cockpit is going to fall off the rest of the craft due to stresses.  Also, KSP is older than Elite Dangerous.  No, a small indie studio will not likely ever come out with a game that looks like a AAA game on their own.  That isn't big news.  However, that has nothing to do with the game's engine.

Again, KSP uses Unity far above what it was designed to do.  It wasn't designed to calculate orbits, but neither are most other game engines.  These problems would likely exist on Source, Unreal, or Cry as much as they do on Unity.  There is no other engine out there that would be better suited for all the tasks that KSP does.  Some may be equivalent, but certainly not better. 

Comparing it with Forza is a another example of how KSP is pushing the envelope of what game engines are designed for.  In Forza they can assume that only the bottom of the wheel will touch the ground. So only that part has the collider... the invisible thing that simulates contact, friction, etc.  Your wheels in Forza are actually not wheels at all, they are flat surfaces with decorations that make them look as if they are wheels.  In KSP we can turn wheels in all directions (there is no "bottom"), and that led to issues because the conventional wheel systems didn't work when the wheels were upside down.  Once again, KSP is not your typical game.  Forza and Elite Dangerous are both drastically more simplistic than KSP, that allows them to spend more efforts on other areas, like terrain and detail.

Edited May 9, 2017 by Alshain

[Shadowmage]

6 hours ago, Alshain said:

Most games treat a vehicle as a single piece, KSP handles physics on each individual component of a vehicle.

And KSP only does this because they actively want floppy joints between the parts.  Remove that top-down directive, and suddenly, craft in KSP are no longer nearly as limited by part count or CPU.  There is no low-level technical reason that craft in KSP can't be treated as a single rigidbody.
 

1 hour ago, Alshain said:

In Forza they can assume that only the bottom of the wheel will touch the ground. So only that part has the collider... the invisible thing that simulates contact, friction, etc.

That is the same thing that Unity and KSP do as well.  Unity's WheelColliders are merely a raycast with some added functionality to simulate suspension and friction.  Well, actually, that is PhysX wheel-colliders; they are simply what Unity uses.  Try to use a KSP wheel upside down.... they don't work.  They even have problems when mounted with angle/camber, with the outside edges of the wheel clipping into the ground....  (no, KSP does not use any form of actual 3-d wheel simulation).

Not intending to argue, just adding a bit more information to the discussion.  Most of the rest of the points are spot on, including the fact that Unity is perfectly capable of 'current gen' graphics.

[Alshain]

33 minutes ago, Shadowmage said:

And KSP only does this because they actively want floppy joints between the parts.  Remove that top-down directive, and suddenly, craft in KSP are no longer nearly as limited by part count or CPU.  There is no low-level technical reason that craft in KSP can't be treated as a single rigidbody.

If you make your craft a single rigid body, it would drastically alter gameplay.  There is no technical reason, true, but I wouldn't want to play that game.  It would take away a lot of the design challenge.

33 minutes ago, Shadowmage said:

That is the same thing that Unity and KSP do as well.  Unity's WheelColliders are merely a raycast with some added functionality to simulate suspension and friction.  Well, actually, that is PhysX wheel-colliders; they are simply what Unity uses.  Try to use a KSP wheel upside down.... they don't work.  They even have problems when mounted with angle/camber, with the outside edges of the wheel clipping into the ground....  (no, KSP does not use any form of actual 3-d wheel simulation).

I think the VPP package they use change that though.  I could be mistaken, I just thought I read that somewhere.

 

[HebaruSan]

2 minutes ago, Alshain said:

If you make your craft a single rigid body, it would drastically alter gameplay.  There is no technical reason, true, but I wouldn't want to play that game.  It would take away a lot of the design challenge.

Do you think an acceptable middle ground might be possible? For example, joints might be selectively marked as rigid if the craft mass is below a certain threshold based on the size of the contact surface. So a 0.625m joint could be rigid in a 2 ton craft but a weak point in a 200 ton craft.

[Alshain]

7 minutes ago, HebaruSan said:

Do you think an acceptable middle ground might be possible? For example, joints might be selectively marked as rigid if the craft mass is below a certain threshold based on the size of the contact surface. So a 0.625m joint could be rigid in a 2 ton craft but a weak point in a 200 ton craft.

I think a better solution would be to offer the 'welding' option in a limited fashion as it would typically be in the real world.  Having several fuel tanks as individual pieces to form one rocket with wobbly joints between them isn't realistic, having a space station composed of many components docked together is.  I feel like anywhere there is a decoupler or docking port should be separated physics as well, but two fuel tanks stacked on one another can definitely be joined into a single rigid body.

However, all of this is a bit off topic as this is a KSP design issue and not a Unity issue.

Edited May 9, 2017 by Alshain

[RocketBlam]

The fact that they could get any existing game engine to do what KSP does boggles my mind. Other than writing their own game engine (which would be much harder than even recoding for a different engine) I don't see them changing.

[Fearless Son]

I sense a few unspoken assumptions among some commentators in this thread that I would like to address.  

First, there seems to be an assumption that Unity is a crap engine.  As @Alshain pointed out, this is not true.  Unity is actually quite a capable engine.  Unreal or Cry Engine might be a little better optimized for super-high end rendering, but the differences are not all that much.  I think this perception comes from the fact that Unity is one of the most accessible engines, which is a big point in its favor.  It is very easy to develop for, very inexpensive to license, and very easy to mod for as well.  However, its low barrier to entry means that Sturgeon's Law applies more liberally: it means that the crap does not get filtered out if someone decides to make crap using it.  That is not Unity's fault.  

Second, there seems to be an assumption people are making about how optimization works.  First of all, it is never a matter of "just tighten up the graphics on level three."  Performance optimization is like a kind of careful balancing act.  A seemingly minor enhancement to graphics in one part could lead to a massive performance hit somewhere else, or taking a seemingly "little" item out of memory might result in a drastically smoother framerate.  So if someone says "I want better graphics!" the developers have to balance that against everything else they have going on in the game, which might have an impact outside of what the person asking for it thinks it will.  Likewise, if someone says, "I want better perf!" they have to understand that might mean giving up something else that might otherwise be important.  Sometimes you can make a few code tweaks that, on balance, gain you more than you lose, but those are the low-hanging fruit, and the gain is not always big enough relative to the effort it would take to make them.  And sometimes what is being traded away to get it is stability, and I doubt anyone wants less of that.  

Finally, a lot of these kinds of complaints are from people who tend to use a lot of mods.  Everything I said above about Unity and performance?  That goes double for mod-makers.  Unity's ease of developing for means that mods are easy to make, but that can also mean a lot of neophytes can end up making mods, and they might not be cognizant of everything they are trading to add what they put in the mod.  Someone who loads a bunch of high-resolution textures for example could have a drastic effect on performance, especially if combined with other mods that do more of the same.  Squad knows what they put into KSP and they limit it to a budget for a reason, but mod-makers do not have to fit themselves into that.  And further, you cannot hold Squad responsible for what other people do to their game.  Any mods you install are done at your own risk (to performance/stability) and Squad can only do so much to facilitate them.  Unfortunately, the more they do the more likely mod makers are going to try and push the envelope.  This is true virtually every time a piece of underlying technology gets better.  

Having both worked in Unity and worked on performance optimization for a major multi-platform AAA release, I felt the need to frame these things appropriately.  

[Shadowmage]

15 minutes ago, Alshain said:

I think the VPP package they use change that though.  I could be mistaken, I just thought I read that somewhere.

Nope, VPP just uses the stock Unity/PhysX wheel colliders under the hood.  With all of their limitations and quirks.  I really wish it were otherwise (as I could have saved myself months of work by not needing to create KSPWheel).

What VPP does add is an entire 'vehicle simulation system', including stuff like engines, gearboxes, transmissions, differentials, and anti-roll functionality (none of which is actually used by KSP).  Knowing the package... I'm mostly lost as to why KSP is using it at all, unless they were really desperate to save themselves a few hours of writing wrapper classes (which they had to do anyway in order to even make VPP usable in KSP).  Probably something that I'm missing/not seeing given the limited view of the KSP API and code that I have access to (really hope so, otherwise the entire VPP thing is a huge head-scratcher).

Ahh... I think I remember now.  VPP does do its own friction forces calculation.  However it uses the Unity/PhysX wheel colliders for suspension forces calculation/raycast functionality.  So I guess there is some net gain from that in KSP, as the default Unity/PhysX wheel friction is.... lacking.

 

13 minutes ago, Alshain said:

I think a better solution would be to offer the 'welding' option in a limited fashion as it would typically be in the real world.

That would be my preferred alternative to floppy rockets.  It makes sense for there to be joints between docking ports for example.  Less so for decouplers (as those are quite rigidly joined until the explosive bolts are fired).  Even just removing the joints between stacked tanks (and the tanks and back-side of the docking port/decoupler) would go a long way to improving the situation from my viewpoint.  But I've never considered the floppy-rockets to be a 'problem that needs to be solved', more of just a bunch of extra steps I need to take to make my rockets do things that they logically shouldn't.  Others have differing views on this.

But yeah, this is all a bit off topic of the 'Why Unity' question.  If anyone really wants to know answers to some of these trivial technical details, feel free to send me a MP...

On-topic, I think the answer has been hashed out several times.  In a nutshell, accessibility.  Especially in the days when KSP was first being created, it was one of the only 'freely available' (with limitations) game engines for smaller amateur developers, it also has a smaller level of pre-knowledge/training needed to get things working, and has one of the most rapid development-to-use/testing cycles that I've seen in any game engine (not that I've played with too many).