Unity 5.2.... optimized UI.... coming NOWISH.

[StarStreak2109]

[...]Because we see potential that isn't happening, and that's just frustrating and disappointing. It's the same as watching a film and thinking it was OK but it could have been so much better.[...]

Then make it better.

Correction: hasn't happened yet.

What is a bit frustrating is that one the one hand the game is pretending to be finished (1.x and out of early access), while on the other hand it clearly is not finished and Squad acknowledges that. It's as though they made the bungeled releases of some recent AA titles into a formal development strategy.

I think some criticism there is fair, but to conclude that KSP never will be as nice as it can be (or close to that), is taking it to far.

Agreed.

[Darnok]

Do a google search. Performance of the "physics" system goes down brutally depending on how many tanks or batteries you have. This is a LOT more brutal than physics.How long do you play?

It is well documented that ressource distribution is a performance hog. Among the issues being that the list of all containers for a resource is regenerated every frame.... It is in their bug list.

http://bugs.kerbalspaceprogram.com/issues/5136

So, it is not "physics" that is slow per se. Not with something as trivial as a 200 part ship

What? They can't be that bad... it would be as bad as:

while(true){

i+=1;

}

hard question what this code will do?

As for update IMO it is too late for U5.2 in KSP 1.1. Some optimizations are not on coders side, you just need design properly your features.

[Alshain]

Unless the programmer either does pointless multithreading of a non-parallel algorithm, or does something really weird and stupid with forcing core affinity or similar, a multithreaded application will run on multiple cores at once. And KSP is already multithreaded and will use more than one core, but the single physics thread dominates the CPU load.

Yes, except multiple threads can run on a single core as well. I've covered this before. They are related but not the same. Unity 4 can not multi-core, so ANYTHING that uses the Unity API can not be. That isn't to say other calculations can't be threaded by your program that also uses Unity, but that isn't going to be much because practically everything uses the API, and because of thread safety anything that uses the API must be run on a single core.

- - - Updated - - -

Correction: hasn't happened yet.

See that is the issue. They complain it hasn't had this or that and they can do it better, I say they need to prove it. The guys at Squad are not bad programmers, they just can't do everything at once like the unrealistic expectations in this thread suggest. Complaints about optimization are moot because the engine change is going to require a lot of code be reworked, so until we see that, there is no telling. The devnotes are constantly talking about reworking really old code, that is when optimizations happen. The biggest complaint I see (in other threads) is people that want textures loading on demand and that simply isn't likely to happen so people need to get over it.

[softweir]

Hey.

Obsidian already released a game written in Unity 4. (Pillars Of Eternity)

- 34 gigs of assets

- multi-thread

- etc.

Unity 5.x cant help KSP.

Maybe a computer science book for their software team?

Obsidian used a custom-written version of Unity 4 to do this. The basic Unity 4 couldn't hack it.

Almost certainly Obsidian's Unity 4 would be useless for KSP.

[cantab]

Then make it better.

Even if I wanted to learn C# (which I don't really), there's only so much modders can do.

Yes, except multiple threads can run on a single core as well. I've covered this before. They are related but not the same. Unity 4 can not multi-core, so ANYTHING that uses the Unity API can not be. That isn't to say other calculations can't be threaded by your program that also uses Unity, but that isn't going to be much because practically everything uses the API, and because of thread safety anything that uses the API must be run on a single core.

For me top on Linux routinely reports KSP as using 120% of a CPU core or the equivalent thereof. Sometimes as much as 150%, notably when loading the game. In other words KSP is using more than one core simultaneously. (And I have a Phenom II X3 so there's no worrying about stuff like hyperthreading messing the figures up, it's just a straight tri-core CPU.)

[magnemoe]

First, multithreading and multi core are two different, albeit related, things. If it is Unity 4, it isn't multi-core. Second of all, that game is nothing close to KSP, so comparing them is drastically fallacious.

That remains to be seen.

Or perhaps a computer science book for you...

Unity 4 don't have multithreading physic, it can have other multithreaded parts including your own code for stuff like AI who I assume pillars of eternity uses a lot of.

KSP uses physic a lot so its limited by physic.

[Alshain]

Even if I wanted to learn C# (which I don't really), there's only so much modders can do.

Translation: I like complaining about it more than doing something about it.

We have a idiom where I'm from... "Put up or Shut up". You think you can do better than Squad? You think their programmers and artists are "mediocre"? Go make your own game and prove it, otherwise stop talking. It is getting really old, the dead horse has been beaten, now you are beating the dust that used to be the dead horse. Squad knows you disapprove.

[cantab]

We have a idiom where I'm from... "Put up or Shut up". You think you can do better than Squad? You think their programmers and artists are "mediocre"? Go make your own game and prove it, otherwise stop talking.

Ah, the old stock argument to shut down any criticism of creative works. It never has and never will be remotely convincing.

[Darnok]

Translation: I like complaining about it more than doing something about it.

We have a idiom where I'm from... "Put up or Shut up". You think you can do better than Squad? You think their programmers and artists are "mediocre"? Go make your own game and prove it, otherwise stop talking. It is getting really old, the dead horse has been beaten, now you are beating the dust that used to be the dead horse. Squad knows you disapprove.

You think you can do better than put-any-car-making-company-name? You think their engineers are medicore? Go and make your own company and make better cars...

I do understand that some critics are written because people like to criticize, but this argument is terrible.

[Alshain]

You think you can do better than put-any-car-making-company-name?

No.

You think their engineers are medicore?

No.

Go and make your own company and make better cars...

I do understand that some critics are written because people like to criticize, but this argument is terrible.

Don't worry, it's only terrible when you counter it with a strawman argument.

- - - Updated - - -

Ah, the old stock argument to shut down any criticism of creative works. It never has and never will be remotely convincing.

I'm not trying to shut down criticism, I'm trying to shut down the hatred. It's one thing to say "here is how I think it could be better" it is a completely other thing to say "Squad is mediocre". One is helpful, the other is not.

[cantab]

Do you feel there's evidence to the contrary? Do you believe that the models and textures in KSP are all the work of excellent artists? Do you believe the game's performance and number of bugs is the work of excellent developers? One cannot be helpful without first recognising the problems. I'm not hating on Squad specifically, I acknowledge that in pretty much all fields of work mediocrity - or if you prefer "averageness" - is the norm and excellence a rarity.

[Temeter]

The tone of these threads can get rather negative and sometimes toxic, that's the issue.

People getting frustrated about minor issues, or maybe just enjoying to rant on a forum. It's kinda ridiculous at times, KSP is one of the games which you'd expect to have no issues, considering how much input the devs took from the community. Not that taking notes from mods won't be countered with even more negativity.

This kind of toxicity is also the reason why communication with the userbase is very limited for most game developers, even independent ones. KSP also limited communication, and relies rather on stuff like the devnotes (which is still miles above average). You can't even present concepts or ideas, which is a lesson many small developers took. The resource concept that flew around a few years before the actual implementation? How could they dare not to follow an obviously completely unworkable concept by the letter! That's gonna be answered with rage that will last for years! >_>

And all of that because of some whiny minorities...

Edited September 9, 2015 by Temeter

[EladDv]

while i agree that squad staff is not the best of the world it's quite competent and even good- yes there are a few questionable design and coding issues but that's a part of human nature and what they see as a good way to be doing thing might not be our perspective, i understand criticism but make it constructive- saying "they have for much of KSP's development been getting by with mediocre programmers and artists." is just disrespectful- i am sure that if i said that you are mediocre in your field of expertise you'd feel a little hurt. And really saying that you can but dont want to learn how to help yourself while complaining is not the way to gather people by your side- yes i am bothered with how the physics engine works so i am working on it i had to learn the entire API of KSP in order to get to where my project is today, just saying f*** it it's too hard is giving up and then you have no excuse to complain

[godefroi]

First, multithreading and multi core are two different, albeit related, things. If it is Unity 4, it isn't multi-core. Second of all, that game is nothing close to KSP, so comparing them is drastically fallacious.

He didn't say anything about multi-core. He only said it was multithreaded, and it very well may be. In fact, my copy of KSP here is running 29 threads, and if I know anything, 29 is more than one, and therefore "multi". It's only the PhysX that is single-threaded in Unity 4. The game overall can be as multithreaded as the developer wants. Whether or not a different threads are run on different cores is (normally) up to the operating system, not the developer, but that's neither here nor there.

To be clear, here: in general, software is singlethreaded or multithreaded. Hardware is single-core or multi-core. While it is possible for a software developer to tie specific threads to specific cores, it's not very common. You would never speak about a piece of software as multi-core.

Edited September 9, 2015 by godefroi

[Alewx]

Dreamer, they are working on Unity5.0 or 5.1 converting the project right in the process again is total nonsense and doubles the work.

[xtoro]

This is why I wish the game was open source. Those who say "do something about it" don't realize that we can't. If we had code to work with, we COULD do something about it. There are plenty of hobby and professional programmers who play KSP and could help make the game run better. Look at any software or OS that became open source (WebOS) and how the homebrew community made improvements that would have probably never happened had it remained closed source.

[Alshain]

Do you feel there's evidence to the contrary?

Yes.

Do you believe that the models and textures in KSP are all the work of excellent artists?

Yes I do. Can they be better? Sure, there is always room for improvement, but that doesn't change the fact that KSP's current artwork is still beautiful.

Do you believe the game's performance and number of bugs is the work of excellent developers?

Yes I do. The only real way to judge this is by comparison. We have an indie game that started in early access so we have to look at other successes in that same category and I've seen way worse. Minecraft for example, it is considered to be one of the great examples of indie games. It's easy to look at it now and marvel at the success but Minecraft's 1.0 version was horrific. You literally could not play for 5 minutes before getting kicked, and that persisted all the way to 1.3.

One cannot be helpful without first recognising the problems. I'm not hating on Squad specifically, I acknowledge that in pretty much all fields of work mediocrity - or if you prefer "averageness" - is the norm and excellence a rarity.

The problem is, mediocrity compared to what? If you were expecting this to be like a BioWare title, or an UbiSoft title, or a Microsoft title, or a Nintendo title, you came in with unrealistic expectations. It is an indie company and they are performing above average for indie game companies. There will always be room for improvement, I don't deny that. You aren't recognizing the problems by stating they have 'mediocre programmers'. In fact you have no idea how good their programmers are, because you don't know programming. You yourself admitted you have no desire to learn C#. Do you even realize how many programmers games like this usually take? From where I'm sitting, Squad is working miracles every day.

[Champ]

You think you can do better than put-any-car-making-company-name? You think their engineers are medicore? Go and make your own company and make better cars...

I do understand that some critics are written because people like to criticize, but this argument is terrible.

Why ? This (what you say) is exactly how Lamborghini was born.

Yes, some people have guts. Enough to stop complaining and prove they can do better.

[Kobymaru]

Translation: I like complaining about it more than doing something about it.

We have a idiom where I'm from... "Put up or Shut up". You think you can do better than Squad? You think their programmers and artists are "mediocre"? Go make your own game and prove it, otherwise stop talking.

That's a really really stupid argument. If noone can criticize you and your product, then nothing will EVER improve.

Can you imagine how this would be in real life?

"I don't like the food in this restaurant." - "Well go and become a chef, then you can complain!"

"The roof is dripping and the walls are askew" - "You think you're better than the architect? Go and build a house, lets see how you build it!"

"You crashed the airplane into the ground" - "You think you're a better pilot? Come on, go fly a plane and do it better!"

This argument is ridiculous. Since 10.000 years B.C. humanity started to specialize into different "jobs" based on skill sets. But that does not mean that people doing one job are exempt from criticizm from the other jobs. That would be so stupid.

Edited September 9, 2015 by Kobymaru

[Alshain]

That's a really really stupid argument. If noone can criticize you and your product, then nothing will EVER improve.

Can you imagine how this would be in real life?

"I don't like the food in this restaurant." - "Well go and become a chef, then you can complain!"

"The roof is dripping and the walls are askew" - "You think you're better than the architect? Go and build a house, lets see how you build it!"

"You crashed the airplane into the ground" - "You think you're a better pilot? Come on, go fly a plane and do it better!"

This argument is ridiculous. Since 10.000 years B.C. humanity started to specialize into different roles based on skill sets. But that does not mean that people doing one role is exempt from criticizm from the other rules. That would be so stupid.

But you are using specific examples of criticism. This thread is not, it's using meaningless rhetoric. The "put up or shut up" argument works against rhetoric, but as you say is stupid when used against real criticism.

This thread is just going in circles, I'm done here.

Edited September 9, 2015 by Alshain

[Darnok]

Don't worry, it's only terrible when you counter it with a strawman argument.

What are you talking about? If you want to produce cars you need company, if you want produce software (game is software) you also need company... now look at your argument, we can't criticize software if we can't make better software is same as we can't criticize car if we can't make better car.

Your argument is nonsensical and it doesn't matter on what kind of company we are talking about. Every customer has right to say his opinions of course those opinions should be constructive not insulting.

Also I don't understand why people are overreacting and think criticism is hostile attack on their work. Criticism is good, it helps your product to get better, of course if decide to listen your customers, but if you ignore them or think they are attacking you or have no idea what they are talking about, because they don't have experience, you won't make any use of customer opinions and fail in your business. Remember if everyone would be able to make their own game nobody would pay Squad for their game, this rule apply to any business

Problem of lots of critics is IMO result of "early access" development path. Look at Fallout or Baldurs Gate two epic or even legendary games, how they were made?

Their producers had great idea, but their development path was different they just made investment, released 1.0 and risk paid off.

Today we have many early access games, that starts in same way as those two great games... with a very unique and brilliant idea, but people are too afraid to risk money on their ideas. This is sad, because if you think your dreams are not worth to risk your money, why I should risk my and buy results of your work?

KSP started same way as those two great games, but its development path is different, Squad didn't risked money to create finished product and then release 1.0, so KSP is not yet optimized and polished.

Instead they started to create and release step by step unfinished product... alpha versions, people noticed potential and uniqueness of KSP and started to play it.

This is path where all of early access indie game starts and this way many fails, because at some point old players, that were playing game for years since 0.1 version, are going to get bored with game (its content and features), they will want more or in different way (more realistic, less realistic, more sandbox, more carrier mode etc etc), while game is still far from being finished. Of course that is not game creators mistake, you can't make players happy, in early access game, if they are impatient.

New players are still coming, due to adverts or friends sharing informations about "cool games"... they see game first time and ask for new things.

Now what game owners should do, listen old-players and add new features and content or finish, polish and optimize game for brand new-players that will buy it and play for the first time?

IMO early access development path is pitfall... very easy start, without risk of losing money and resources, on wrong idea, but you have more problems over time than in classic game development path. Time is also factor, because software is getting old very fast, same as UI designs and graphics. How to finish game with both groups, old and new players, being happy after years of development?

Also any dev guides I've seen saying you don't polish and don't optimize unfinished software, so Squad should make one update without new features, just spend all time at fixing bugs and optimizations, after they will feel game is finished.

Edited September 9, 2015 by Darnok

[godefroi]

Yes, except multiple threads can run on a single core as well. I've covered this before. They are related but not the same. Unity 4 can not multi-core, so ANYTHING that uses the Unity API can not be. That isn't to say other calculations can't be threaded by your program that also uses Unity, but that isn't going to be much because practically everything uses the API, and because of thread safety anything that uses the API must be run on a single core.

This is wrong. Sorry, Alshain, you understand some of the issues surrounding this, but clearly not all of them. By default, multithreaded software will run on multiple cores if they're available, but this is managed by the operating system. You can instruct the operating system to restrict a specific thread to a specific set of logical processors (SetThreadAffinityMask), or restrict a whole process to a specific set of logical processors (SetProcessAffinityMask) but it's not generally recommended, and doing so is extremely uncommon.

[EladDv]

let me put it as simple as it gets.

PhysX cant divide linked rigidbodies(parts) between threads thus single vessels will not be multithreaded operations.

They will however be able to get multiple vessels on different threads in a way that optimally 1 vessel per thread(although it might increase as their number grows).

In addition Unity 5 also automatically offloads non-physics stuff to other threads available and the overall overhead of the new PhysX 3.3 is lower.

[juanml82]

The problem is, mediocrity compared to what? If you were expecting this to be like a BioWare title, or an UbiSoft title, or a Microsoft title, or a Nintendo title, you came in with unrealistic expectations. It is an indie company and they are performing above average for indie game companies. There will always be room for improvement, I don't deny that. You aren't recognizing the problems by stating they have 'mediocre programmers'. In fact you have no idea how good their programmers are, because you don't know programming. You yourself admitted you have no desire to learn C#. Do you even realize how many programmers games like this usually take? From where I'm sitting, Squad is working miracles every day.

As far as I understand, this isn't a problem of not enough man-hours. It's a problem of coding a lot of unnecesary stuff. Squad didn't need to code the whole electrical thing the way they did it. They don't need to run physics calculation when there is no change affecting a vessel. How many man hours would it take to cut all that code from the game and do it in a simpler, less resource intensive way?

[Terwin]

Also I don't understand why people are overreacting and think criticism is hostile attack on their work. Criticism is good, it helps your product to get better,

*Constructive* criticism is good and can help a product get better.

This involves pointing out specifics and making recommendations on how to improve that facet.

This is not in any way constructive:

"This game is slow and the developers are mediocre"

This identifies a specific issue and makes a recommendation that may fix the issue under consideration should it prove to be a viable approach:

"Reconstructing the resource tree for every resource request(which happens multiple times per frame) requires a lot of CPU cycles, a better option would be to use a buffer type system where the size of the buffer is based on the available storage(such as batteries and fuel tanks), then as you cycle through the parts you can update the buffer for each resource producer or consumer in turn. When you have finished with a cycle, you can update the storage with the change in the buffer.

This should be much faster, and while it may cause problems when your producers and consumers are on a larger scale than your storage, such problems are hardly unrealistic.

The primary down-side is that you need to either calculate the tree each cycle(once as opposed to the current multiple times) or you will need to track vehicle changes so you can update the tree when things attach/detach/explode"

Do you see the difference?

One is whining and complaining, serving no purpose than to potentially make the whiner feel better, the other is offering helpful suggestions, and while those suggestions may not work, it is clear that the the intent is to be helpful.

One is also much easier than the other.

If you are not offering specific steps to address the issue, you are not being helpful, just negative. (Note: 'Fix it' and 'Make an optimization pass' are not specific steps, they are cop-outs that mostly ignore the difficulties involved)