Jump to content

How long before a performance increase?


Motokid600

Recommended Posts

Multiplayer has nothing to do with it. There are major differences in process, length, order, and complexity between a simulation's development cycle and an MMO's.

Then, I'm back to asking what that has to do with changing the engine? Are you pointing out the fact that Squad would have to rewrite all of the physics, whereby MMO's would have to rewrite all of the quests?

Link to comment
Share on other sites

Then, I'm back to asking what that has to do with changing the engine? Are you pointing out the fact that Squad would have to rewrite all of the physics, whereby MMO's would have to rewrite all of the quests?

The difference is income and time. I'm not sure what part of this I have not made clear?

Link to comment
Share on other sites

The difference is income and time. I'm not sure what part of this I have not made clear?

Maybe you and I are thinking of two different things here.

I am thinking in terms of the programming involved. That is to say, I don't see why differences in genre would create a large enough change in how the game itself is coded, that an engine change would be harder for one genre than another. You seem to be pointing out the more... logistical problems involved, which now that you actually mention them, makes sense.

However, it could be said that KSP would be easier to change engines, since it is much smaller and has no multiplayer system (and thereby no servers)... right?

Link to comment
Share on other sites

The complexity of KSP as compared to an MMO is such that there would be more backend work. Engines simply don't come with the scripts to do orbital calculations heh. Where as an mmo has much less code and much more >text< which CAN be simply copied to a new engine. MMO's often use databases for both data and functionality making porting them to a new engine have much less backend work due to you only needing to make the new engine understand your old tables and reference them. EVE is a VERY good example of this.

Link to comment
Share on other sites

The complexity of KSP as compared to an MMO is such that there would be more backend work. Engines simply don't come with the scripts to do orbital calculations heh. Where as an mmo has much less code and much more >text< which CAN be simply copied to a new engine. MMO's often use databases for both data and functionality making porting them to a new engine have much less backend work due to you only needing to make the new engine understand your old tables and reference them. EVE is a VERY good example of this.

But orbital calculations are simply lots of equations, which given that you aren't switching languages (which could cause data type issues), can't you just copy and paste?

Link to comment
Share on other sites

The complexity of KSP as compared to an MMO is such that there would be more backend work. Engines simply don't come with the scripts to do orbital calculations heh. Where as an mmo has much less code and much more >text< which CAN be simply copied to a new engine. MMO's often use databases for both data and functionality making porting them to a new engine have much less backend work due to you only needing to make the new engine understand your old tables and reference them. EVE is a VERY good example of this.

I suppose the main problem is that vast majority for KSP code is written using Unity's scripting engine, and this code will be useless for any other engine. The only useable part would be algorithms, some concepts, which may prove useful for new engine.

Link to comment
Share on other sites

But orbital calculations are simply lots of equations, which given that you aren't switching languages (which could cause data type issues), can't you just copy and paste?

Most engines use proprietary language, making porting it to another nearly impossible. For instance, Unity script is very similar in syntax to XML, and Java in structure. There are no other engines that share it. MMO's very often use engines that use raw code (EVE uses python, with plenty of proprietary additions, CryEngine uses a C# basis but is much more general)

Link to comment
Share on other sites

But orbital calculations are simply lots of equations, which given that you aren't switching languages (which could cause data type issues), can't you just copy and paste?

Yes this is a problem. If the code is written specifically for one engine (and it seems they've used the Unity Engine) then switching to a better one would be a massive update. Granted, it would be much better to do this in an Alpha stage than leave it till last and have to re-write the whole game, but it's still a massive thing as it stands that would take a long time. They could be working on it right now. O_O

Link to comment
Share on other sites

Most engines use proprietary language, making porting it to another nearly impossible. For instance, Unity script is very similar in syntax to XML, and Java in structure. There are no other engines that share it. MMO's very often use engines that use raw code (EVE uses python, with plenty of proprietary additions, CryEngine uses a C# basis but is much more general)

Ah, that clears that up.

EVE uses python? Eww... I've heard Python is really inefficient code (specifically, my friend told me that you needed two IF statements whereas C++ would only need one to do the same thing. Kinda sounded as if Python doesn't have AND and OR statements).

Link to comment
Share on other sites

For instance, Unity script is very similar in syntax to XML, and Java in structure. There are no other engines that share it. MMO's very often use engines that use raw code (EVE uses python, with plenty of proprietary additions, CryEngine uses a C# basis but is much more general)

Unity can use C# (infact KSP seems to be written exclusively using C#).

Link to comment
Share on other sites

Python has some advantages, and some downsides. It's very simple to use for many things, but in others it is very unwieldy. It's primary advantage is that it is modular and can import those modules into it's matrix very easily. It is very effective for "simple" code that doesn't require heavy backend calculations. It suffers greatly when asked to do those complicated number and list crunches. C# is the opposite. It's great at those heavy crunches but eats up unnecessary compute cycles to do the simple things.

Unity can use C# (infact KSP seems to be written exclusively using C#).

Actually it uses Mono not C#, Mono is an open source based on .Net. It's largely compatible but not always, there are some interesting differences, and how it's applied in Unity is different that how it is applied in other engines. The engine itself is written in C/C++. I'm not aware of any other game engines using mono offhand but that doesn't mean they don't exist.

Edited by Sir Nahme
Link to comment
Share on other sites

Actually it uses Mono not C#, Mono is an open source based on .Net. It's largely compatible but not always, there are some interesting differences, and how it's applied in Unity is different that how it is applied in other engines. The engine itself is written in C/C++. I'm not aware of any other game engines using mono offhand but that doesn't mean they don't exist.

Mono is runtime, C# is language. Libraries built for Mono are completely binary compatible with MS CLR 4.0 (sans some proprietary components like WPF).

P.S. I develop using .NET/Mono technologies for living ;)

Link to comment
Share on other sites

Hmm pardon my ignorance then. I'm not as familair with C# as I am with C or python. I was just going off the easily searchable information on the unity website. Either way I know that how the code is applied to objects in unity doesn't match the other engines I've used

Link to comment
Share on other sites

Hmm pardon my ignorance then. I'm not as familair with C# as I am with C or python. I was just going off the easily searchable information on the unity website. Either way I know that how the code is applied to objects in unity doesn't match the other engines I've used

It's just particulars. The main problem is that it's the libraries that are unique per engine. During my career I had to learn and use a lot (over 20) of different languages, and so learning another syntax is easy. The hard part is learning runtime.

Link to comment
Share on other sites

But orbital calculations are simply lots of equations, which given that you aren't switching languages (which could cause data type issues), can't you just copy and paste?

The issue is the low level optimizations.

Now "some really bad programmers" will preach "portable code" which operates pathetically on all systems because it doesn't take advantage of anything the individual system can do. Have you heard the term "Bad Port"? It is the same concept, you get the game running on an engine that has zero optimizations for the PC... but the engine was designed to make it easy to transition from console to pc (for the sales, of course.)

KSP has undoubtedly entwined itself in the operations of unity such that a large number of it's algorithms are based on Unity's restrictions, strengths, and weaknesses.

Changing programming languages isn't actually that difficult. Stupid, yes; but if you followed standards you can write a program to change the mnemonics to the appropriate versions and restructure the program accordingly. (http://www.developerfusion.com/tools/convert/csharp-to-python/), you'll have to manually rewrite some of the code for portions that don't have a direct overlap of course... but yeah.

Edited by Fel
Link to comment
Share on other sites

I'm actually depressed about this performance issue because, as others have already pointed out (http://forum.kerbalspaceprogram.com/showthread.php/25508-The-Future-of-KSP-and-Unity3D?p=311677&viewfull=1#post311677), it could be KSP's eventual death knell.

I already break the boundaries of common sense with my humongous (1000+ parts) lifters and pay the price with low FPS. However, even with the self inflicted low FPS I still enjoy the game. But, as the KSP dev's add more and more functionality (Alpha-Beta-Release) to an already over stressed physics engine even conservatively designed rockets may stutter to a <1 FPS grave.

I'm not smart enough to know what the answer is other than to suggest capping rocket/station parts count (don't kill me). But I'm fairly certain that Squad dumping Unity would be way too expensive because it essentially would mean starting over ($$$). I truly hope for all of us KSP junkies, and Squadites alike, that there'll be a workable solution discovered for this nagging problem.

Perhaps some really smart folks can create an "Optifine" (Minecraft) solution for KSP. I know at one point I nearly quit Minecraft until Optifine came along and restored my FPS levels.

Edited by Ming
Link to comment
Share on other sites

To sum this up, there is definetly a problem which needs to be resolved one way or another. If even on my hi-end computer (6 core i7 3930K, 32Gb RAM, dual 680 GTX SLI) KSP drop FPS below comfortable 50 for vessels with 400+ parts, I can only imagine what it looks like on slower systems. There is no other game in existence that could do that to my computer (for example BF3 shows stable 120+ FPS in 1920x1080 all maximum settings).

Edited by asmi
Link to comment
Share on other sites

Entropia was rereleased with a new engine and is effectively closer to a sequel than than a "project that switched engines"

You also have to remember that there are STILL aspects of that game that worked before the engine switch, that are still non-functional to this day. and the engine switched happened shortly after I cashed out and quit playing, and that was like... 2005?

Link to comment
Share on other sites

Changing programming languages isn't actually that difficult. Stupid, yes; but if you followed standards you can write a program to change the mnemonics to the appropriate versions and restructure the program accordingly. (http://www.developerfusion.com/tools/convert/csharp-to-python/), you'll have to manually rewrite some of the code for portions that don't have a direct overlap of course... but yeah.

And then you suggest Python? I know it's fashionable and all, but unless you're doing highly parallel stuff on a cluster with Stackless and most of the really computationally-intensive stuff farmed off to C, C++ or (shudder) Assembler libraries, it's not exactly, uhm, fast. It's also a (usually) interpreted language. It'll never win any speed contests, and speed is what KSP really needs right now.

Edit: No, this does not tell you "how fast a language is", it tells you "how fast the programs that implement certain algorithms are for each language", but nonetheless, benchmarksgame.alioth.debian.org is always a fun place to look for this sort of stuff.

Edited by technicalfool
Link to comment
Share on other sites

Well , while I dont expect Squad to try the home brew engine route, its not out of range and scope of a small indie team ... just highly unlikely.

Unknown Worlds use a homemade engine for their indie title Natural Selection 2, and it has been praised for good visuals and effects and is reasonably good in performance and COULD be a lot better but the devs opted for massive mod support so hinged a lot of the engine on LUA scripts to allow easier modifications.

Took them about 4 years but the main engine programmer had started on the engine before they dumped Source for Spark, so give or take 5 years to code that engine.

Possible, but highly unlikely.

Oh yeah, now that game in development took ages before the game was in a playable state...even after launch there was a lot of work to optimise it and most of the optimisation came about 2 - 3 builds prior to release.

Alpha version was so slow it ran about 5 FPS at lowest settings on the top end machines, build 156 got it so more machines could run it at about 30 FPS, but it was near release that the game hit 60+ FPS.

Point is that optimisation is a late comer to the development stages, as developers are still fiddling with the insides of the code spending time to optimise it is really a waste as often parts are simply ripped out and replaced or discarded.

UE and / or Cryengine is a commercial product and is designed for multi platforms and much more variation for usage than say a home made engine for a single game, so it takes longer to make a master of all trades than a master of one trade.

Another interesting thing about coding I learned from UWE that might have some merit here.

I know not of coding.

I genuinely want to know what is the difference and (or dis) advantages between codes like C' date=' lua, and other computer languages? [/quote']

Luckily Hugh wrote an article a long time ago for the rest of us plebs who do not understand jack about coding

http://www.ns2hd.com/2012/04/performance-where-is-it-now-and-where.html

The parts that answer your question:

"Lua is 'high level' programming language. Imagine a spectrum. On one end of the spectrum is ones and zeros, or 'Binary' code. This is the language that your PC speaks. Every calculation it makes is done in Binary. At the other end of the scale is the English/French/German/other spoken language. This is what you use to communicate with other humans, and can most readily understand. Programming languages act as intermediaries between Binary and our spoken human languages, so that we can tell computers what we want them to do.

A 'high level' programming language sits further towards the English/French/German end of the spectrum, while a 'low level' programming language sits further towards the Binary end of the spectrum.

Lua sits very far towards the spoken language end of the spectrum. It is very easy to understand, and that is why I was so easily able to create my little spectator mode mod. Natural Selection 2 is entirely written in Lua, so that people can modify it very, very easily. It can be modified with a simple text editor such as Notepad, and does not need to be 'compiled' before it can be executed.(roughly, to compile a program means to prepare it to run, and takes time).

In fact, it is perfectly accurate to call Natural Selection 2 a mod of the Spark engine. Spark is the in-house engine developed as the brain-child of Max 'm4x0r' McGuire. Spark is written in C++, a fast low level language. NS2 sits on top of Spark, written entirely in easily accessible Lua. It is possible to mess with the game without ever having to deal with the C++ engine.

So far, this sounds really cool. Why don't all games run in languages like Lua, on top of low level language engines? Let's go back to the spectrum. The further a language is towards the Binary end, the faster it runs on your computer. The further it is towards the spoken language end, the slower it runs on your computer. This is not to say that Lua is absolutely slow, only that it is relatively slow compared to a low level language such as C++. It is relatively slow because it takes more effort to move all the way from the spoken language end of the spectrum to the Binary end of the spectrum, where the computer can understand and execute the game code.

In summary, Lua trades some execution speed for ease of access, and therefore ease of modding. Not just ease of modding, but ease of writing.

Right now, Lua takes up around 50% of the CPU cycles that NS2 goes through to produce ever frame. This is, on its own, almost entirely responsible for the limited framerates that people experience when playing in the NS2 Beta. Rendering in Spark is actually very fast. This is why turning down graphics options, or playing on a more powerful GPU, yields negligible performance benefits."

Of course it's not in beta anymore so things have improved since then.

So the synopsis of that was codes towards the binary end of the spectrum like C runs better but is much harder to work with due to complexity, while codes towards the human end like lua are slower because of more information needing to be processed, but is more user-friendly in return.

So if I got my facts right, assuming (although a highly unlikely engine change) a low level language would be better the choice for ksp to run faster, but in return make it harder to mod and update, and more expensive because of the higher skill needed to code, correct?

Edited by WhiteWeasel
Link to comment
Share on other sites

Yes, no.... most won't. We rarely use Unity to actually do anything with Mods, except when KSP's API fails to provide us with the mechanisms we want.
If by KSP's API you mean the .cfg files only.

The scripting API is almost the same as Unity's so we can't say it can stay the same after an engine switch, most likely it can't. And I don't see why KSP's API has to provide mechanisms that are already available with Unity.

Link to comment
Share on other sites

Another interesting thing about coding I learned from UWE that might have some merit here.

So the synopsis of that was codes towards the binary end of the spectrum like C runs better but is much harder to work with due to complexity, while codes towards the human end like lua are slower because of more information needing to be processed, but is more user-friendly in return.

So if I got my facts right, assuming (although a highly unlikely engine change) a low level language would be better the choice for ksp to run faster, but in return make it harder to mod and update, and more expensive because of the higher skill needed to code, correct?

To be accurate : Assembly is the low level language (machine level code), C is a high level language and LUA is a script.

Assembly is hyper fast but is NOT portable between makes of CPU (even AMD and Intel PC CPU's) and is extremely difficult to read even with years of experience.

C is a human readable language that tries to make fast code but also portable code, but is slower than assembly.

LUA scripts are very slow but offer the ability to change parameters in the game without needing to compile the code each time you try a new change... like say you have a variable that controls the ISP of a engine, var_Engine_ISP = 220 but something isnt quiet right, in C you would change that value in the code and recompile and then run the program, in LUA you would simply change the value in the script and run the program again. Scripts also allow you to change parameters without access to the source files, and without needing to provide command line options to adjust each setting.

*mind you I am not a coder (budding hobbyist game programmer) so it is possible I am entirely wrong, but thats how I understand things.

Link to comment
Share on other sites

You can't talk in absolutes when discussing language performance.

A well maintained, tested and optimized library in some script language likely will always be faster (better, stronger wub wub) than something you hack together with c in an afternoon. Same goes for java or other "notoriously slow" languages.

Link to comment
Share on other sites

Has there been any direct developer response to this issue ever?

With their sales clearly through the roof now that they're on steam a lot more people are going to start getting rather frustrated when their creativity is extremely stifled by a game that doesn't appear to make use of the hardware sitting in their box. We can all agree that it's no small matter to fix this but the more burning question in my mind is: will they?

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...