Recommended Posts

Recently, @ShadowZone has released a video about the future of KSP, and as I personally agree with the points he has made, so I decided to spread the word. @UomoCapra and other developers, please hear me and him out:

 

  • Like 3

Share this post


Link to post
Share on other sites

Software has bugs, literally nothing can solve that.

Also, I stopped taking this guy (whoever he is) seriously when he was complaining about lag while building a 1,000 plus part vessel. I mean, seriously? We won't even get into the fact that he's playing a heavily modded save.

Typical YouTube "armchair game developer" talk. Mostly a bunch of buzzwords he found on the internet intermixed with a vague and incomplete understanding of how game development works.

Edited by Rocket In My Pocket
  • Like 2

Share this post


Link to post
Share on other sites
31 minutes ago, Rocket In My Pocket said:

Software has bugs, literally nothing can solve that.

Also, I stopped taking this guy (whoever he is) seriously when he was complaining about lag while building a 1,000 plus part vessel. I mean, seriously? We won't even get into the fact that he's playing a heavily modded save.

Typical YouTube "armchair game developer" talk. Mostly a bunch of buzzwords he found on the internet intermixed with a vague and incomplete understanding of how game development works.

I understand what you mean. I wouldn't be surprised if my game would lag with a big vessel. However, I do start experiencing multiple bugs myself, that is mostly why I found his video relatable

  • Like 3

Share this post


Link to post
Share on other sites
2 minutes ago, Rover6428 said:

I understand what you mean. I wouldn't be surprised if my game would lag with a big vessel. However, I do start experiencing multiple bugs myself, that is mostly why I found his video relatable

Well, of course; no one likes bugs; and every effort should be made to fix them but at the same time it just kind of comes with the territory.

Any large, or complicated enough program will have bugs, look at Skyrim or Fallout! Sure it's easy enough to make a mostly bug free "boring bog standard shooter", but anything more ambitious than that is going to be plagued by bugs as a matter of course.

Let us also not forget that despite KSP's success; Squad is far from a triple A developer.

Share this post


Link to post
Share on other sites
39 minutes ago, Rocket In My Pocket said:

Well, of course; no one likes bugs; and every effort should be made to fix them but at the same time it just kind of comes with the territory.

Any large, or complicated enough program will have bugs, look at Skyrim or Fallout! Sure it's easy enough to make a mostly bug free "boring bog standard shooter", but anything more ambitious than that is going to be plagued by bugs as a matter of course.

Let us also not forget that despite KSP's success; Squad is far from a triple A developer.

I don't know. In my opinion a game shouldn't want to aim to be buggy or broken (e.g Oblivion) just because it can be fun. In my opinion it is even frustrating. I don't agree with Shadow-zone on every point, but I support his final idea: KSP needs to do some housekeeping before adding new stuff. :targetpro:

This is mostly due to the game becoming more unstable as the bugs build up. :/

Share this post


Link to post
Share on other sites

There definitely are too many bugs. There should be fewer bugs. 

My hope is that the new features and art passes are not just being 'tacked on' but are part of a deep revamp of old sins and a good way to replace lots of inconsistent and even hastily done work from the past. 

The previous developer posts dealing with the green line, runway bumps, and font styling show there's a current appreciation for 'the little things'. 

My hope may be misplaced, but the game it too much fun to quit on. 

Share this post


Link to post
Share on other sites
28 minutes ago, Phreakish said:

There definitely are too many bugs. There should be fewer bugs. 

"Too many people die, less people should die."

"There are definitely too may homeless people, less people should be homeless!"

Wanting it is one thing, making it happen is another. Bugs are constantly fixed, but more are created at the same time. It's unavoidable, no one likes it; least of all Squad but it's part of life.

Edited by Rocket In My Pocket

Share this post


Link to post
Share on other sites
Just now, Rocket In My Pocket said:

"Too many people die, less people should die."

"There are definitely too may homeless people, less people should be homeless!"

Wanting it is one thing, making it happen is another. Bugs are constantly fixed, but more are created at the same time. It's unavoidable.

Analogies aren't thinking, and yours are entirely off-point. Unavoidable doesn't mean unfixable, either.

No one thinks there should always be zero bugs, but right now even the bugs are buggy. It's high time for substantial improvements, and I stand by my hope that the breadcrumbs we're being shown are part of a deeper dive into root causes. 

  • Like 1

Share this post


Link to post
Share on other sites
12 hours ago, Rocket In My Pocket said:

Software has bugs, literally nothing can solve that.

Also, I stopped taking this guy (whoever he is) seriously when he was complaining about lag while building a 1,000 plus part vessel. I mean, seriously? We won't even get into the fact that he's playing a heavily modded save.

Typical YouTube "armchair game developer" talk. Mostly a bunch of buzzwords he found on the internet intermixed with a vague and incomplete understanding of how game development works.

You're right, I only have a vague understanding of "game development". I was too busy delivering working enterprise software for the past years to look into that. One dev in my team was once developing games for a small publisher, though. He says it was hell.


How about we skip the ad hominem and get to the facts:

A bug breaking something that has already worked in a previously released build should not happen. No matter if it's a game or any other software. But it happens every time with a new KSP version. It has become custom to wait for the first hotfix after a release until you can actually play. This should not be necessary.

There are multiple ways to mitigate the risk of introducing new bugs or breaking existing features. Even more to prevent them from being released. Some are organizational, some are technological. Automated testing, pair programming, mob programming, pair review, regression testing, exploratory testing are just a few of them.
What works best? The Agile tenet holds true here: Inspect and adapt. Find out what fits for your circumstances and implement it. But: the inspecting has to begin at some point.

538 issues in KSP's bugtracker have not even been looked at. Ever.
Maybe half of them aren't even bugs or are outdated. Who knows? Well, nobody, because nobody seems to take the time to analyse them. For me this is an indication that not enough resources are spent on quality. I am not even talking about code quality, I am talking about taking the reported income and acting on it.

Yes, I build gigantic vehicles in KSP, it's kinda my thing. But I was able to build 1600 part battlecruisers in KSP 1.0.x without ever experiencing the amount of memory grab KSP performs nowadays. The problem lies with fairings and the new structural panels. As soon as a decent amount of them are in play, the game goes into nightmare mode. Especially if you work with subassemblies and delete and load parts of your vehicle. One quick fix could be to disable the fairing preview animation or the many attachment nodes on the new panels with the press of a button.
To re-iterate, this type of problem was not present in previous versions, even with significantly more mods. I know of other KSP players and YouTube creators that stick to version 1.3.1 due to this and many other issues.

And as I mentioned in the video, bugs are only part of the issue. The problem with technical debt is that over time a development team starts to work itself into a corner if they do not get rid of it.
You chose one library over the other because it's faster to implement but you know that the other one would have been better in the long run. You hack your code and leave //TODO comments that will never be looked at again. You hardcode stuff instead of doing it the right way.
All of these things enable you to get your product out on an arbitrarily set release date. But it's like taking up a loan with high interest rates. In the long run it will cost you more. And if you don't pay it off, the debt will pile up.
Usually it's mismanagement - not believing developers when they say they need more time to get rid of tech debt - that leads to the mentioned flatline in my video.

Don't just take my word for it, maybe the father of the Wiki, Ward Cunningham, might convince you:

https://youtu.be/pqeJFYwnkjE

I would very much like to know how KSP development is organized nowadays. Are the team or teams colocated? How is testing set up? Is testing (and in what form) part of the definition of done (if such a thing exists)? How is the release validated before shipping? How is bug reporting handled? Is this also the job of the developers (it shouldn't be) or are there dedicated support/quality engineers looking tat the new income and analyzing it?

There are so many ways software development can be improved. But as mentioned above: somebody has to start the inspecting before the adapting can begin.

Edited by ShadowZone
Added Ward Cunningham video explaining tech debt
  • Like 15

Share this post


Link to post
Share on other sites
13 minutes ago, ShadowZone said:

A bug breaking something that has already worked in a previously released build should not happen.

This can not be stressed enough.

  • Like 1

Share this post


Link to post
Share on other sites

The way KSP works now is kind of like this.

There's the main game. Physics, "basic" parts, and environement. This is what I pay for, and I have a higher quality expectation.

And then, for extra parts, skins, visual enhencements, there are mods. Modders are volunteers. I won't ever blame them for taking time to update, fix bugs, or add features. 

Now back to stock. There are bugs. The developpers know about them. What's the solution ? I'm no programmer. But I'd love to see more updates that focus on bug fixes and performance improvements. I don't have a high end computer, but when the game freezes in the VAB..... well....

  • Like 3

Share this post


Link to post
Share on other sites

I'm not happy with the updates after 1.3.1, because they causes a lot of problems with the mods (even if you decided to not update the game, you can have problems updating the mods and using new mods), and take time and energy from the modders to make new content. The mods are the only reason I still play.

About bugs, they don't annoy me all that much, and I'm not aware of any game-breaking bug in my install and play-style, but that was only after upgrading my PC.

My 1.3.1 install folder have 5 gb in total, but I could only run it very stable with 16 gb of RAM. For many people having problems, this could be a possible solution, you probably are underestimating how many RAM you really need. My 5 gb install make my RAM usage go to 12 gb, puts almost all the rest in "standby", and takes 3 minutes to load with a SSD. This don't seem very reasonable to be...

Share this post


Link to post
Share on other sites
On 12/8/2018 at 12:49 PM, MaximumThrust said:

I'm not happy with the updates after 1.3.1, because they causes a lot of problems with the mods (even if you decided to not update the game, you can have problems updating the mods and using new mods), and take time and energy from the modders to make new content.

You can't have the cake and eat it too. Had Squad stayed on the 1.3.1 code-tree, we would had a huge amount of performance leaks and unsolvable bugs. Leaking Abstractions and Interface Brakes are a pain in the SAS, I agree and recognize it, but that's it or freezing the product into a bugged, unsellable situation.

Now that I have near a year of KSP overseeing, I have some ideas about the reasons they are doing it, as well about the objectives. And besides getting really angry sometimes with the breaks, now that I understand the reasons, the angry vanishes fast - it's that or loosing KSP itself, this forum and everything else.

All of this costs money. They need to feed the cash cow, otherwise they capsize with everything and the kitchen's sink going kaput.

 

On 12/8/2018 at 12:49 PM, MaximumThrust said:

The mods are the only reason I still play.

They know it. And this is the reason that sometimes they take some not exactly best decisions, that back fires and blow up on everybody's faces. I'm a professional software developer by trade and by formation, first played 1.3.1 and immediately 1.4.0 came, and I saw things happening (what include things that for the user are invisible), so please give me some credit on this: their lives would be insanely easier if they choose to drop the support they do for mods. They need to sell KSP for new users, but yet they compromise with features they didn't sold neither maintain in order to do not jeopardize (too much :P ) the legacy.

Not for the faint of heart.

 

On 12/8/2018 at 12:49 PM, MaximumThrust said:

My 1.3.1 install folder have 5 gb in total, but I could only run it very stable with 16 gb of RAM. For many people having problems, this could be a possible solution, you probably are underestimating how many RAM you really need. 

I agree. KSP is a memory hog. My advice is to monitor the virtual memory size or, better, the swapfile size. If it reaches about 10% of your physical RAM, you are abusing your rig and performance will be sad.

 

On 12/8/2018 at 12:49 PM, MaximumThrust said:

My 5 gb install make my RAM usage go to 12 gb, puts almost all the rest in "standby", and takes 3 minutes to load with a SSD. This don't seem very reasonable to be...

It's a design decision that works for the stock game: due some Unity idiosyncrasies, it's better (and easier) for they to just load everything into memory. The game is a open universe, and they didn't wanted you to get lags when flying your vessels around. When you cheat your vessel to be in the orbit of any body, there're no loading time, because everything is already in the memory.

Load On Demand is possible, but not with the same user experience. Games like Assassin's Creed can do it because you are on a open world, but only the visible fraction of it is needed - A.C. don't need to load anything else but what's immediately visible to you.

On KSP, on the other hand, you can send vessels to any place in the universe, and switch to them, and even build telescopes to see bodies beyond the immediate sight. Loading on Demand would render these somewhat annoying.

For the sake of comparison, Orbiter does the same: you need to build a scenario file where everything you want to use is declared, so it doesn't have to load anything else (but the "Universe", that must be loaded anyway). Some scenarios I made took some time to load… But yet, I didn't had to load everything and the kitchen's sink at once, since we don't build new vessels once the game is started.

IMHO, what you are asking should be handled by the modders. At least, while Squad don't cook something for them - what will take some time, as the Stock are still being loaded in a reasonable time.

What leads me to another issue: KSP supports XBox and PS4 too, where memory constraints are tougher and not negotiable. Until the moment, KSP had a manageable footprint on them, but with MH and possible new DLCs coming, this is going to change fast - so I expect they would be working on something sooner or later.

But this will be a point of inflection for KSP ecosystem, as the whole GAMEDATABASE subsystem will have to be reworked somehow - I foresee a huge breakage on the legacy mods (that can or cannot be easily fixed).

As I said, you can't have the cake and eat it too.

Edited by Lisias
My God! It's full of tyops….
  • Like 5

Share this post


Link to post
Share on other sites
15 hours ago, ShadowZone said:

538 issues in KSP's bugtracker have not even been looked at. Ever.
Maybe half of them aren't even bugs or are outdated. Who knows? Well, nobody, because nobody seems to take the time to analyse them. For me this is an indication that not enough resources are spent on quality. I am not even talking about code quality, I am talking about taking the reported income and acting on it.

I agree. And I think you nailed the reason: not enough resources are being spent. However, resources must be earned before being spent, and this is the reason I think things are this way for now. They need to feed the cash cow, so they can have the milk to feed Q/A.

This is, still, an indie game

 

15 hours ago, ShadowZone said:

Usually it's mismanagement - not believing developers when they say they need more time to get rid of tech debt

I could not agree more.

Edited by Lisias
hit "Save" too soon. again.
  • Like 1

Share this post


Link to post
Share on other sites
18 minutes ago, Lisias said:

Had Squad stayed on the 1.3.1 code-tree, we would had a huge amount of performance leaks and unsolvable bugs.

Indeed.  Now we have other, more different performance leaks and unsolvable bugs.  Engine updates shouldn't be the go-to bug spray for game companies.

1.3.1 worked quite well.  Solidifying the code base and hammering out the remaining bugs would have been fantastic.  Instead, we get regressions and new memory leaks, and some mods that are now stock.

I just wish game companies would actually work toward finishing their games instead of the current trend of "milk it 'til it dies" and hope the final gasping version is still worth playing.

  • Like 3

Share this post


Link to post
Share on other sites
4 hours ago, klgraham1013 said:

Indeed.  Now we have other, more different performance leaks and unsolvable bugs.  Engine updates shouldn't be the go-to bug spray for game companies.

I could not agree less. Most of the hacks you complained before was due Unity's ones at that time.

Switching Unity version was unavoidable, Squad was already on a corner. Almost all of the breakage came from getting rid of the hacks they had to do to cope with old Unity's idiosyncrasies, but also from the hacks they have to do to cope with new Unity's idiosyncrasies.

Unity is a hell. I agree. But… Don't think that the other engines are so that better. Unreal Engine has its idiosyncrasies, and you should talk to someone that works with Frostbite. :) 

The main difference between KSP and the others is that KSP is 'program driven software', where most games are 'project driven'. On a project, once a game is ready and kicked out through the doors, you close shop and that's it. New game version is a new game project, with a new budget, and everything can be rewritten from scratch if needed (and money allows). Try to run Quake2 mods on Quake3. ;) 

KSP is a program, like Windows or MS Office. The dynamics are different. I can't run all of the Win95 programs on my Windows 7 - but I can run some. Looks similar to KSP? Well, it is. :) 

 

4 hours ago, klgraham1013 said:

1.3.1 worked quite well.  Solidifying the code base and hammering out the remaining bugs would have been fantastic.  Instead, we get regressions and new memory leaks, and some mods that are now stock.

I have a proposition for you. Gather people, fork the mods you want to use on 1.3.1, and back port the bugfixes. The license of most of them allows. Create a parallel ecosystem focused on 1.3.1.  It's possible, all you need to do is to hack into some code.

You will see that most of the problems are not exactly from KSP changing something, but from KSP getting better and everybody that relied to work on a idiosyncrasy needing to rethink things.

And some of that most wanted mods (as KJR) is working flawlessly with the same binary on every KSP version I tested it since 1.2.2 (yeah, the very same binary, not even a recompile). This is something to think about.

 

4 hours ago, klgraham1013 said:

I just wish game companies would actually work toward finishing their games instead of the current trend of "milk it 'til it dies" and hope the final gasping version is still worth playing.

Believe me. Squad is one of these companies you wish. And the problems you are facing are the exact consequences of that. You can't have the cake and eat it too.

Edited by Lisias
ugh.. bad grammars...
  • Like 4

Share this post


Link to post
Share on other sites
On 12/7/2018 at 10:45 PM, ShadowZone said:

(...)

You chose one library over the other because it's faster to implement but you know that the other one would have been better in the long run. You hack your code and leave //TODO comments that will never be looked at again. You hardcode stuff instead of doing it the right way.
All of these things enable you to get your product out on an arbitrarily set release date. But it's like taking up a loan with high interest rates. In the long run it will cost you more. And if you don't pay it off, the debt will pile up.
(...)

That IS the stuff! 



:::::::::::::::::::::::

Well, at least they´re not going the same way it has been happening with Battletech, which gets ten bugs fixed but other Tons created every darn time they release an update - THAT is a quick way to screw a 30+ years franchise (and I´ve been playing it for almost 30 years....).

Edited by Cataclism

Share this post


Link to post
Share on other sites

How about focusing 1.7 release exclusively on performance and bugfixing?

How about doing that with every odd-numbered release?

  • Like 4

Share this post


Link to post
Share on other sites

This discussion bugs me :(

Can't we all be happy over the great steps SQUAD is taking with regards to KSP's future? I know some of it questionable, but still, can we a bit more optimistic about stuff?

I mean there's the absolutist solution that solves everything if you're patient enough -

existential_bug_reports.png

 

Edited by Xurkitree
  • Like 1

Share this post


Link to post
Share on other sites

Maybe soon they switch to another Engine, maybe Unreal 4?

Or like they create their own Engine?

I don't know, but I wanna help!

Share this post


Link to post
Share on other sites

What other engines could support KSP? My understanding is they adopted Unity in the first place because it was best able to deal with the large volume of part-to-part physics calculations needed for a game like this.

Share this post


Link to post
Share on other sites

We need bug fixes. This game is getting to a point where it is nearly unplayable. I can list off hundreds of bugs, but I will say only one:

The Kraken. 

A large patch of just bug fixes is all the game needs. There is a great video about technical debt and the problems plaguing the game here: https://www.youtube.com/watch?v=TUXChw_6plE

Players are thinking of moving to a new game, Simple Rockets 2. The community wants to stay, but if the game stays as it is, I and many others will leave.

Fix the game and stop adding fuel tanks.

 

Share this post


Link to post
Share on other sites
11 hours ago, MrJoolian said:

Maybe soon they switch to another Engine, maybe Unreal 4?

Or like they create their own Engine?

I don't know, but I wanna help!

I'm pretty sure the engine isn't the problem.  It's the type of game KSP is trying to be.  No engine supports the things KSP is asking for.

10 hours ago, kmMango said:

What other engines could support KSP? My understanding is they adopted Unity in the first place because it was best able to deal with the large volume of part-to-part physics calculations needed for a game like this.

I thought it was because it was cheap?  Remember KSP started out on a 2D plane and with a scope far smaller than what it's become.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now