0.23 should focus on performance

[Guest]

New category or not, optimizing code that could change drastically is at best a complete and utter waste of time, and at worst will bog down your efforts in the future.

"Alpha" is not an excuse. It's a state of being and an insurmountable fact. You sound like someone falling through the sky saying that the "gravity" excuse just isn't cutting it anymore.

I don't see how trying to maintain quality through the development process being used in this circumstance is a waste of time, especially when there are so many new players coming on-board. I'm not trying to be a pain in the butt on purpose here, that just comes naturally for me. When I say that we, the community in general, should stop using "alpha" as an excuse, it's because I believe that with this "pay as you go" type of development, maintaining quality should be a priority as much as adding new features. Alpha suggests a closed process, where the only people that see the effects of new features are select chosen testers. This is not the case here. I want the game I paid for to be just as good in .23 as it was in .19. Is that so wrong?

[Superfluous J]

I don't see how trying to maintain quality through the development process being used in this circumstance is a waste of time.

Optimizing takes a LOT of time and resources, far more than it takes to code the process in the first place. Let's say it takes twice as much but it can easily take more.

So if you code something that takes 5 hours to code, it would take 10 to optimize. That's 15 hours. Now, if you keep that item and never interact with it, the optimizing is done and you're all good. However, nothing in this game is separate from anything else, so things require changing and when you change them, you lose any optimizing you did on the things that change. So, your 5 hour project that you spent 15 hours on, you spend say 2 hours integrating it with something else but then need to optimize that, for 4 hours. Later, something else comes along and you spend say 1 hour on that and 2 more optimizing it.

If you'd skipped optimizing until everything is in place, though, you have that base 5 hour project, so you still need just 10 hours of optimizing. You're essentially saving the time you would have spent optimizing the stuff that you ended up not needing, changing, or reworking. Your 5+10 hours plus 2+4 hours plus 1+2 hours is actually 5+2+1 or 8 hours, plus 10 to optimize. You just saved 6 hours.

Of course that doesn't sound like much, but that's out of an 18 hour coding project. That's like 33%. So if you spend 1000 hours on something you just saved over 300 hours of work.

Note: These numbers are totally made up.

Alpha suggests a closed process, where the only people that see the effects of new features are select chosen testers. This is not the case here. I want the game I paid for to be just as good in .23 as it was in .19. Is that so wrong?

I agree in principle. They likely should have kept the game to themselves until it was in actual Beta. I however am INSANELY glad they didn't.

[Guest]

I am also thankful that we have this great game. It's unlike anything I've played yet, anywhere on anything. I have not tried minecraft yet, but plan on it. I really like astronomy and space exploration in general, so this is more my thing. Squad is onto a great thing here that has enormous potential. I understand the need to get the most for the time they put in. I am convinced in my mind that the rules are different now because the game is out in the public arena. I think they are making enough money to pay themselves from just the sales that are going on with this current version. I am an extremely patient person overall, something I've had to learn a little bit about in the last 15 years of truck driving. I'm willing to wait for new features. I would rather wait longer on new releases that run just as good or better than the last at this point. My main gripe is the sound. The music is a big part of the overall artistic value of the project. They can fix that. The map audio is a big part of the gameplay. They can fix that too. I'm not asking for any major overhauls. I just want too see results in so far as quality being maintained with each new release.

[Killerdude8]

It's not optimization it's keeping the game in a condition to accept new content, as it is right now, KSP is getting slower and more inefficient with the more features we add. 64bit and Multicore support is what KSP needs in order to continue to add these new features and keep it playable.

[Surefoot]

I add my vote for 64 bit support. This will push KSP to the next stage of awesomeness. Multi core is the next logical step after that.

[John.E]

Just thinking about optimization and leaving it to the very end. It occurs to me that if you ignore major performance issues till the day before release (figuratively) you may not be able to perform a decent optimization on the product as you have built yourself into a corner. Some optimisation along the road is no bad thing. Is it really such a bad thing to include looking at code performance and bottlenecks with each release to ensure the latest 'feature' has not gutted a package?

[Outlander4]

Oh come on, people. The game is in early alpha, which means that not only the content of the game, but also a lot of under-the-hood machinery are either place-holders or partial implementations or first iterations of the system that was planned. I guess that in many cases it's not really about optimisations, it's about putting the most efficient code in place of the current implementation that will be both faster and allow for new features to be added.

For example, terrain system in KSP is really gorgeous (I've seen a video from recent Unite conference I believe where devs explain how it works) but it still requires a lot of work if we are ever to see things like season variations, running water, canyons, more realistic mountains, swamps, cities, underwater stuff etc. Since KSP is (in part) an exploration game more terrain variety could give potential years of gameplay, but to make that happen some serious work on terrain system will be needed.

Squad just happened to like less memory-hungry solutions which is a real blessing for the community. For example, craters were added only when Harvester figured out the way to make them without significant performance drops. Or remember how we were all moaning about docking not coming for a very long time? Well, it was because the whole content sub-system was being re-written to accommodate the new parts system which allowed for merging and splitting of vessels and allowed for many other gorgeous things we have today (like the ease of modding and creating whatever new parts and resources we need), and eventually brought us the docking system we have now. Conceiving such efficient implementations takes time and creativity and knowledge and hours of work.

That being said - there is much to optimise but also a lot to actually implement in the game in a non-place-holder way, and I'd prefer developers to work on that rather than on catering for people who just can't keep their imagination in check.

PhysX implementation is a Unity problem and Squad can do little to fix it. Of course using other physics engine may help, but I'm not in the position to judge how well other physics engine would work in KSP. After all, we are talking about the whole solar system to simulate...so...what about sending angry letters to Unity instead of bothering Squad?

[Sochin]

What would greatly help is if the Devs would post a schedule of upgrades over the comming releases.

[boomerdog2000]

What would greatly help is if the Devs would post a schedule of upgrades over the comming releases.

They don't want to do that because then people would be expecting features that they might not be able to do. They get less complaints from the community if they don't tell us until they've got it started and know what they can do.

[Caelib]

What are your system specs? I think the performance improvements in .22 have made a world of difference.

[Guest]

Oh come on, people. The game is in early alpha, which means that not only the content of the game, but also a lot of under-the-hood machinery are either place-holders or partial implementations or first iterations of the system that was planned.

This from KSP Wikipedia : The first public alpha was released on June 24, 2011 and updates have been continually released since.

Just how long do you think KSP should be considered an "early alpha"? Has there ever been an "early alpha" that has sold as many copies as KSP? I believe it's time for us to start asking Squad to maintain quality with new releases. I paid for the game back in .18.2, and while I have more than got my money's worth, I would like to see more effort put into keeping the game's overall quality, including audio and visual performance both, at a level that is just as good or better than the previous release. Putting a release out that has audio bugs that are noticeable in the first 5 minutes of gameplay, some of which did not exist in earlier versions, just so you can start gauging public reaction to career mode, while at the same time rendering most mods incompatible(forcing mod makers to update), is not cool IMO.

[Nuke]

I add my vote for 64 bit support. This will push KSP to the next stage of awesomeness. Multi core is the next logical step after that.

i kinda disagree with this order. id use this roadmap if it were my game:

dxt* textures - its quick, easy and will save truckloads of ram and lets us postpone x64 support for quite a while. 1/6th to 1/4th less ram used on textures (the biggest chunk of data you have to worry about putting into ram) for similar quality is nothing to scoff at. 4gb is a lot, not many games use that much, so compressed textures lets you implement the x64 later on, when the unity issues have been resolved. the extra ram allows for more stock parts to be made, and more mods to be used simultaneously to keep people happy while we wait for performance improvements. load times will be less, since the textures are 1/6th to 1/4th the size. this will also eliminate crashes due to ram limits, unless you install an insane number of mods.

multicore support (possibly including gpu physics**) - its a good idea to get this down as early as possible to avoid coding yourself into a hole you cant get out of. many an open source engine has trouble with this one, because it usually requires "a rewrite from scratch". wait too long, and the amount of code to be rewritten goes up. this will probibly also give you a better performance gain of all of these. this fixes poor framerates and lag.

x64 builds - this gives us memory and a little bit of performance. memory is the immediate benefit though. the performance part probibly wont come out until you start optimizing your maths in beta. with more memory means more content, higher res textures, more textures, and so on.

bandaids - all the stuff like procedural parts (i dont think we should prioritize this but its still a valid suggestion to improve performance, so il mention it) would go here, maybe also part physics merging (if not already in), and better culling for collision detection. and you might do this before x64 if memory is not an issue when you get to that point. you get minor to moderate performance improvements.

post alpha architecture optimizations - after all features are in and the game moves to beta***, support things like avx, or latter sse* implementations, do your x64 optimizations too. this will be the point where the game becomes a finally tuned beast.

planned features will probibly be implemented throughout, but most should probibly be put off till after multicore stuff is done. stuff that doesn't really depend of performance critical areas (science/economy/resources) would probibly not be effected much by multicore code, so those are candidates for early implementation.

**gpu physics is determine by whatever library is used. physx that comes with unity is horribly crippled, if implemented the right way would only support nvidia. you could use other physics libraries, like bullet or havok. you could do everything on the gpu with opencl, or you could also write your own code and run it in multiple threads on the cpu. but thats a whole other can of worms.

***i know there is some debate about whether or not the game uses the alpha->beta->release methodology or not, so beta/post alpha in this case means the point at which all features are final and the focus turns to bugfixing and optimization.

Edited November 1, 2013 by Nuke

[Outlander4]

This from KSP Wikipedia : The first public alpha was released on June 24, 2011 and updates have been continually released since.

Just how long do you think KSP should be considered an "early alpha"? Has there ever been an "early alpha" that has sold as many copies as KSP? I believe it's time for us to start asking Squad to maintain quality with new releases. I paid for the game back in .18.2, and while I have more than got my money's worth, I would like to see more effort put into keeping the game's overall quality, including audio and visual performance both, at a level that is just as good or better than the previous release. Putting a release out that has audio bugs that are noticeable in the first 5 minutes of gameplay, some of which did not exist in earlier versions, just so you can start gauging public reaction to career mode, while at the same time rendering most mods incompatible(forcing mod makers to update), is not cool IMO.

Well, it's how this 'early access'-type thingie work, more or less. With most of the systems inside the game being place-holders there are bound to be some bugs and compatibility issues. After all, there are new features and under-the-hood game code changes being added. Most open-source games have the same problem, I believe, because they were operating on the same model from the very beginning. Having access to alpha allowed us to give some great feedback and brought many changes to the game; these days it's much more difficult to be heard because of all the new players who came in asking the same questions and giving the same requests over and over again. Most useful things were already said back in 2011-2012 by people who really know a lot about space exploration. Still, for such a massive project (the whole solar system to explore, and possibly quite a few others) our feedback is needed and (hopefully) appreciated. So I'm sure audio is going to get fixed, and mods are going to be updated very soon

All being said, I'm not happy with the career mode, it's way too arcade for me. How possibly analysing a rock from the Mün could bring in the new parts for a rocket? What is it, a xenoarchaeology or something? Analysing münar rocks should give us information about the Mün itself (water deposits, probability of finding metals etc.) and allow to start development of say an automatic soil probe or drills or boring machines or technology for extracting water from the regolith, as well as giving some nice (and better interactive) pictures of münar geology (structure, mineral composition, etc.) in the in-game database. That'd be much more educational. Also, starting the game with solid fuel boosters and rocket engine but with no aeroplanes nor even the simplest batteries and space probes whatsoever is ridiculous even by the kerbals' safety and engineering standards. But then again, it's a first iteration of such a system, so I'll reserve my final judgement for later, while giving my opinion on the subject now.

Edited November 2, 2013 by Outlander4