Kerbal Space Program

[Burning Bridges]

You just don't write real time, high performance applications in that language.

Written by someone who has optimized C# for ca 15 years. i.e. I can make it fast but not fluid.

 

[dbx]

C# in Unity is used as a scripting language, not for the performance heavy parts. The problem lies in shit programmers using Unity's scripting language to do heavy stuff instead of developing C/C++ external plugins.

 

[Prime Junta]

You just don't write real time, high performance applications in that language.

Written by someone who has optimized C# for ca 15 years. i.e. I can make it fast but not fluid.

That's why most software nowadays is written in two languages: C++ for the performance-critical bits, a high-level language for everything else. In KSP's case, Unity should deal with the real-time stuff, and it's written in C and C++. It should be adequate if you know what you're doing. (You might have to write a few bits -- atmospheric flight model maybe? -- in C++ if it turns out to be a bottleneck.)

Again: KSP's major performance issues have nothing to do with the language, it's the logic. There simply is no excuse to cycle megs of memory per second in normal flight, and garbage collection is not an excuse.

 

[Burning Bridges]

Name 1 application that is written in C# that exemplifies your statement?

What you write is snake oil that you can smear into your hair. The results of this type of game development can be seen in KSP: input lag, pauses, unnecessary loading times and so on.#

C# is a middleware that is not under the control of the programmer. Unity is another. Both is detrimental to the response times of almost everything surrounding your program. If you want a game that reacts instantly you write your own framework in C# so you can exclude major logic running outside of your control (even that is not completely direct but much superior to virtual machines)

We can argue back and forth but show me your result - I program both C# and C++ and shake my head about your half knowledge. Better post about things you understand, like watches

That's why most software nowadays is written in two languages: C++ for the performance-critical bits, a high-level language for everything else.

Most shit software, yes.

 

[Prime Junta]

The iPhone, including Apple's default apps for it. (Okay, not C# but a comparable high-level language.)

You name one recent game or other large-scale high-performance real-time software that's written entirely in C or C++.

 

[Burning Bridges]

DCS. Arma 3.

Now you

The iPhone, including Apple's default apps for it. (Okay, not C# but a comparable high-level language.)

So I need C# to be able to get an iPhone? WTF

 

[Prime Junta]

I said "not C# but a comparable high-level language." Used to be Objective-C, now is Swift. Jesus.

Nokia's MeeGo phones were written in C and Python FFS, and they performed great. I know some devs who worked on them.

High-level languages are a tool. They make it possible to do stuff faster and on a lower budget than would otherwise be possible. Like anything else, they can be used well or badly. Choosing to go entirely with C or C++ will give you a different set of headaches. It's also a lot harder to find good enough programmers to do the work, and badly-written C or C++ is way worse to deal with than badly-written C#, Java, Lua, or even Python. Remember when games used to crash to desktop constantly? Yeah, me too.

 

[Burning Bridges]

My Vostok Amphibia is arriving today or tomorrow, that's why I can't argue with you I need your input! but I can smell from a mile that you learned all that stuff also the "high level way" ie in some seminar, and not in practice.

 

[dbx]

DCS. Arma 3.

Now you

The iPhone, including Apple's default apps for it. (Okay, not C# but a comparable high-level language.)

So I need C# to be able to get an iPhone? WTF

ARMA3 does have a scripting language. Actually at one point it had 2: SQS/SQF and Java if i remember correctly (later i think java was canned).
DCS World uses LUA as scripting language.

 

[Burning Bridges]

The engines are C++, that's what matters. What you mean by scripting language is actually comparable to modules that make use of an engine, whereas in Unity's case it's the entire game that is crammed in this structure, meaning one part of the program is accessible to the programmer, and another is a black box.

Also I give up you guys are too far removed from reality. Enjoy your Unity games with 2x2 km maps.

 

[Prime Junta]

I can smell from a mile that you learned all that stuff also the "high level way" ie in some seminar, and not in practice.

Nah, I learned everything I know about this craft the hard way.

Code is code. It can be well-structured, maintainable, and well performing, or impenetrable, inefficient spaghetti, regardless of the environment or language it's written in. When it comes to performance, about 99% of the time the problem is with the logic, not anything inherent to the environment you're working in.

That 1% of course can be completely critical, and if you do identify one of those cases then yeah for sure you need to do whatever it takes to fix it, which may mean writing a piece of highly-optimised C++ for it. But wanting to write the other 99% in a low-level language because of that is just as myopic and naive as thinking that you don't need to worry about performance because the environment/framework/middleware takes care of it for you.

(Oh, and, you can write C++ modules for Unity if that's what you need. And Unity itself is written in C and C++, but I'm sure you knew that.)

 

[Burning Bridges]

Nah, I learned everything I know about this craft the hard way.

Then you wouldn't write what you have written bcause it shows a lack of experience.

Code is code. It can be well-structured, maintainable, and well performing, or impenetrable, inefficient spaghetti, regardless of the environment or language it's written in. When it comes to performance, about 99% of the time the problem is with the logic, not anything inherent to the environment you're working in.

Code != program

This has nothing to do with source code, that's completely off the topic here.

A Unity game is not 1 program but several. It has a small core of shitty high level instructions, a C# runtime with a garbage collector etc that is not even documented by Microsopft, and so on, as well as large Unity blobs of which probably only 1% is used and understood. ie instead of building houses from bricks the Unity developer all too often builds them from entire pre-fabricated rooms. That's why the programs all look the same and run like shit.

I already wrote that C# is good for fast programming, the remaining % of overhead compared to native code are negligible. I have written programs in C# that are pretty fast, in fact I made replacements for older programs that were in the magnitude of several 1000s of times faster than previous solutions - among many mistakes they used COM automation for stuff that could be calculated within the program itself, just because they were highly efficient modern "high level" programmers, and a lot of sloppy programming, horrible use of dictionaries intead of arrays and ill constructed foreach loops instead of for (int i=0;i<x;i++), and suddenly tasks which took minutes were done in under 1/10 of a second. I can make them as fast as you want, but I cannot control what goes on inside the computer because the VM prevents me from that. An analogy would be because I am basically just remote controlling a Lunochod vs driving a car.

I can also make them unmanaged and use inline assembler but then you reach a point where you should ask yourself why you are not using C++ already. Just ask yourself why in one program it takes 100s of milliseconds when you just click buttons while the same solution in lets say Qt - which is anything but low level - happens instantaneously.

(Oh, and, you can write C++ modules for Unity if that's what you need. And Unity itself is written in C and C++, but I'm sure you knew that.)

Again, this is not even about languages it is about the architectures behind. You can make shittier programs in C++ than you could ever do in C#, but you can't make better programs in C# than you could in C++.

 

[Prime Junta]

Hm, it sounds to me that you're contradicting what you were saying earlier, or else I misunderstood it. Because what you're saying now isn't all that different from what I've been saying: use C/C++ for low-level stuff that needs to be highly optimised, a high-level language for everything else.

TBF I do have zero experience with Unity (and near-zero with games programming in general -- we do highly scalable client/server systems). Perhaps it really is an irredeemably shitty framework. Even so I'm fairly confident that KSP's stuttering problem has nothing to do with Unity. It's directly related to the number of flights you have up at any time, and they ought to be easy to track with a simple in-memory map: all you need is the orbital info (body, Ap, Pe, inclination) and current position, and you don't even need to update them all that frequently -- once an hour would be enough for distant stuff flying high, once every ten seconds for anything not within RV range. That's, like, five longs per ship. A hundred ships should take up less than 32 kB. So there is no reason you'd have to cycle megs of memory for something like that, however bad your framework is. A garbage collector is a garbage collector, you rarely even need to know exactly how it works. If you create and dispose objects carelessly you will trigger it a lot; if you manage and recycle them sensibly, you won't.

I.e. it sure smells like sloppy code, and "do the whole thing over in UE" is not a realistic solution.

 

[Burning Bridges]

TBF I do have zero experience with Unity (and near-zero with games programming in general -- we do highly scalable client/server systems). Perhaps it really is an irredeemably shitty framework.

The results speak for themselves. Unity games are generic, shitty, limited. There are some well programmed games in Unity like The Long Dark but even they could be 100 times better. Whereas programs in the early 2000s simulated entire worlds, with Unity we are now back to square kilometers which personally drives me nuts. the only exceptions are programs written in the East bloc like the sims I mentioned before and they show that computers of 2017 can simulate entire countries without problems, whereas eg Subnautica can't even render 200m in front.

Also I dont give a shit either way, because the games that I play are usually not made with Unity. The fact that I somewhat took one side is that KSP is one of the better programs in Unity and at least simulates a large world, something that most Unity programmers simply skip because they run against an invisible wall which is performance of the overall system.

Even so I'm fairly confident that KSP's stuttering problem has nothing to do with Unity. It's directly related to the number of flights you have up at any time, and they ought to be easy to track with a simple in-memory map: all you need is the orbital info (body, Ap, Pe, inclination) and current position, and you don't even need to update them all that frequently -- once an hour would be enough for distant stuff flying high, once every ten seconds for anything not within RV range.

..

I.e. it sure smells like sloppy code, and "do the whole thing over in UE" is not a realistic solution.

Well of course you could should have. Saying that you could program a space simulator with a huge persistent world and great performance in C# is of course not wrong, just as you could say that a 1,50m guy could win the gold medal in pole vault.

I.e. it sure smells like sloppy code, and "do the whole thing over in UE" is not a realistic solution.

Usually both. Some part perhaps, some other parts like the terrain engine for example is pretty good actually.

The thing is just you can do something about sloppy code, but not about your architecture.

 

[Burning Bridges]

Hm, it sounds to me that you're contradicting what you were saying earlier, or else I misunderstood it. Because what you're saying now isn't all that different from what I've been saying: use C/C++ for low-level stuff that needs to be highly optimised, a high-level language for everything else.

The reality: use high level code for the little stuff that you understand, and entrust everything else to some magic going on in Unity. Then tell the users that is not possible to have a larger world because it brings every computer to its knees.

I.e. it sure smells like sloppy code, and "do the whole thing over in UE" is not a realistic solution.

Especially not when all your capable programmers already left in disgust because you are nothing but a sweatshop. There were stories that some guys went to Mexico to work on KSP because it was their dream and were paid like a 1000$ a month. For this they delivered pretty good code I think.

 

[Prime Junta]

Saying that you could program a space simulator with a huge persistent world and great performance in C# is of course not wrong, just as you could say that a 1,50m guy could win the gold medal in pole vault.

A space simulator would be much easier than, say, a walking simulator, methinks. Space is mostly empty, and you're just tracking coordinates and vectors; the number of objects entering and leaving physics range is also going to be quite limited.

The hard part would be a reasonably believable planetary surface and atmosphere, and with that the problems are the same as with a walking simulator. KSP's planets are rough, simple, and sparse, but IMO adequate -- having really cool scenery to see when landing would be rad, but it wouldn't fundamentally change the gameplay experience.

(Those stories were quite well attested BTW. It really was a sweatshop and the owners were altogether shitty people. And yes, from where I'm at KSP overall is very good considering what they had to work with.)

 

[Burning Bridges]

I have written a space engine on Ogre3d ca 10 years ago, and got as far as perlin noise generated asteroids, a few screenshots are still here http://spacesimcentral.com/forums/topic/on-using-libnoise-for-asteroids-and-small-moons/

Rendering a planet is the tricky part. It begins with spherical subdivision and spherical mapping which is almost counter intuitive (and the KSP implementation is good), and then gets into unfamiliar terrain like shaders for realistic light scattering in the athmosphere. And shaders was the thing that completely broke my neck, because I don't understand shit about them, and a really good looking athmosphere isn't possible without them. The orbital code etc can be done in an afternoon, even complex elliptical orbits are calculated with simple formulas (you need to dig a bit in geodesy and rocket science, but it's all done via matrices and some fourier series which games like KSP probably skip (that's for stuff like precession and nutation which isn't even completely understood on Earth, because they are periodic over 20,000 years).

 

[Prime Junta]

yeaah baby

Made a plane that flies on Duna. Like flies flies. Landing was still a handful as it started to skid after touching down but no pieces fell off so that counts as a win. Stalled out at around 45 m/s and remained controllable all the way.

 

[Burning Bridges]

When I still played the game, someone (may have been Ulminati) made a plane that could fly practically forever on Duna. It used solar cells and ion drive. Yours looks good but is probably wasteful with the opportunities of Duna gravity.

 

[Prime Junta]

When I still played the game, someone (may have been Ulminati) made a plane that could fly practically forever on Duna. It used solar cells and ion drive. Yours looks good but is probably wasteful with the opportunities of Duna gravity.

Not that wasteful because I also want to take off and get back into orbit. Ion propulsion doesn't have the TWR to do that although it would certainly work fabulously for exploring the planet in the atmosphere in one go without landing. (Also this is a career mode plane and I don't have ion propulsion yet.)

A Terrier might have ended up more efficient but not much. It's lighter and has sliiiightly better Isp but would've given me a much lower TWR which means bigger gravity and drag losses. (If I really was an efficiencywhore I would drop some of the convenience features on the craft first -- the reaction wheel, the airbrakes, and about 300 m/s of safety margin. But I like my craft to be fun to fly and to let me screw up from time to time so I didn't want to do that.)

Edit: fuuu now I want to make an ion plane for Duna... I wonder if it'd better to RTGs or even fuel cells rather than solar panels though? They don't work so great on Duna and ion drives need a ton of power. I've tooled around a bit with fuel cell-driven ion drives and you get a surprisingly good effective Isp with them.

 

[Mech]

Here is the rocket I made which could successfully get back into orbit from the surface of Eve.

 

[Prime Junta]

Impressive. How did you land it?

 

[Mech]

Impressive. How did you land it?

One inflatable heat shield on the bottom and one on the top to keep it from flipping over during rentry. Also a fuck load of sepratrons to move the shields out of the way enough when I decoupled them. Also lots of a parachutes and it also has (had) landing gear.

EDIT: Actually I think it had 4 inflatable heat shields on the bottom. Been awhile.

 

[Hellraiser]

When I still played the game, someone (may have been Ulminati) made a plane that could fly practically forever on Duna. It used solar cells and ion drive. Yours looks good but is probably wasteful with the opportunities of Duna gravity.

That one was mine. Can't find the original one that started it all (and even flew to the poles from the equator) but here's a later model that's actually manned:

Prime Junta RTGs are too heavy, Duna solar power is actually quite good. Or was. Not sure if the flat panels were not nerfed too much after 1.0.

Also Kethane-electric prop planes for Duna used to a be a thing (I think Firespitter killed off the engine parts I used). This one used the large B7 spaceplane parts:

Nowadays the only worthwhile electic props are from USI exploration pack, but they got nerfed hard. Also landing on Duna is ridiculously dangerous with planes.

 

[Prime Junta]

Duna solar power is actually quite good. Or was.

They had the physics wrong. Solar radiation declined relative to distance, rather than the square of distance. They fixed it in 1.2 or 1.3. Currently, solar cells produce about 40% as much power on Duna as on Kerbin. That's enough for low-power applications but I don't know if it'll power an ion plane.