On the topic of 0.22

[llamatoes]

A while back (0.18) the devs said that they were moving away from larger updates, when 0.19 would contain resources, new aerodynamics, repairs, reentry effects, wheels, seats and a few new planets for good measure. While yes, I agree that 0.17 a d 0.18 were uneccersciarlly turgid, and I quite like the little bite sized updates, they give me pretext go in and check out the new features. I feel that the devs are going back into olds habits, and when this update is done, we should go back to updates that are quicker until the aerodynamic model and resources have to be implemented.

[suzin.felipe]

Usually complex systems cannot be implemented in parts, like a tech tree in one release, experiments in another and scientific equipment in the next. They are all part of a functioning pack and would be useless separately.

What would be the advantage in having fast update of useless stuff?

[The Destroyer]

I like the big updates, they give me tons of fun stuff to do, even though they take longer.

The smaller ones were kinda "meh" sometimes. 0.19: Re-entry effects, that's nice, wheels for custom rover, still "nice". 0.20: New crew management, and new space center, which looks good.

0.17: A whole solar system to explore! IVAS! 0.18: Electiricty! New GUI! PROBES! New everything! Docking!

0.15: Hey planes, neat. But since I had C7 already it wasn't that much of a change for me.

0.16: EVAS, fun for doing things like... bowling.

[llamatoes]

I'm just saying that the smaller updates were more exciting, but yes, we do need SCIENCE!

[The Destroyer]

More exciting, how is that? To me the bigger the update, the longer it has a chance to build up hype and make an awesome new update.

[stupid_chris]

Right before 0.21 came out, Harvester made a post about it:

I was meaning to do a post about just that in fact.

We tried to do faster-paced smaller updates on 0.19 and 0.20, but it didn't really work out. The problem is the time we have to spend focused on maintaining stability.

On each update we've done, we've noticed the demand to keep the game stable and bug-free is always higher than before. That means we need to devote more and more time to testing and bugfixing.

That's something we expected. We started the project doing 3-week cycles with no testing at all between them (before publishing), and after the first public release, found we had to do 4-week updates with one for testing, and later 6-week updates with 2.5 for testing...

That's fine, that's a natural part of the game's growth I think. The problem is when you try to scale it back. The testing phase, as it turns out, is incompressible. Every time you put a build out, regardless of the number of features, you're going to spend a couple of weeks cleaning up issues.

So doing shorter releases doesn't really work. It's like trying to build a house while having to make sure you're cleaning up every bit of sawdust for every board you nail to a wall. It's far more efficient to do it all in one go, and clean up the whole mess afterwards.

That's what happened. We learn as we go, in much the same way Kerbals do... Fiery destruction and all.

Currently, we're back to our old cycle we had for 0.17 and 0.18. It does seem to work out a lot better in terms of what we can get into the game in the time available.

Cheers

You can find it in the second page of the July 23rd's KSP Weekly comments

[Awaras]

I kinda always assumed that the announcement that they were switching to 'faster-paced small updates' was a 'cover story' for the surprise steam launch, because that update came early just as the steam version was launched and then everything went back to normal... Not implying any conspiracu here, they wanted to release a new version quickly, saw that the short development time wasn't working out and went back to the old model.

[allmappedout]

Cheers for that Chris, I'd missed that announcement!

[jfx]

It is no secret that KSPs development pace is very slow.

As a software engineer two points stand out to me:

1) SQUAD seems to be sidetracked easily by non-critical stuff like spaceport 2.0 or by doing stuff like throwing out AWS. As indy with extremely limited ressources you usually don't touch stuff like this with a ten foot pole because there are a thousand things that can go wrong (see: patcher, spaceport, pre-aws content delivery). So using stuff like AWS is a blessing because it is ready to go, proven to work, reliable and requires minimal effort on the developers side.

2) There is still no schedule at all (patch or release )after more than two years of KSP. At this point you should have at least some basic understanding what your team can do and how long it will take you. by not doing so you leave the impression that they either have little confidence in their own talent or no real mission statement for the project "KSP". If you do stuff like this there has to be an ultimate goal, with a date put next to it. Otherwise you get what we see under 1), "some neat side feature? yeah we can add that, it won't take long!".

Obviously many will disagree with the above statement, stating stuff like "development takes time", "the last 90% take the other 90% of dev time" ... yes you are right. But you consider that SQUAD has been at this for over 24 months. They are no longer newcommers in the indy game dev sense - puppy license: gone.

Its all fun and games until the money runs out and you spent your time bugfixing spaceport 2.8 instead of shipping the finished base game.

[Technical Ben]

It's not like building a house. It's not tried and tested. So no, there is little schedule as to "when" things get finished.

[allmappedout]

Bear in mind that this is the first game SQUAD have created. They weren't formed to do this, and they probably aren't doing it the best or most efficient way, because they're learning every time they do something. There's obviously talented staff there, but you have to bear in mind their background is primarily in advertising, not game project management.

Also, I remember saying that they work to the philosophy that every release is the final release (ie: the project got cancelled), so there's a lot of QA going on to make sure that at least, if the project did die for whatever reason, there's still enough of a game to let people continue to play what it is that they have put out.

[Proxima]

Even with all the waiting, I am really looking forward to the 0.22 Science update. IT WILL BE AMAZING! I mean it has been ages since science was updated, and even with the data you collect from the SIX science instruments, you can't do anything with it. The new items will bring new incentives to do things in KSP!

[TMS]

SQUAD seems to be sidetracked easily by non-critical stuff like spaceport 2.0

Nah, I get the impression that they have people who are specifically employed (in some form) for that kind of work, rather than game development. It makes good business sense, I think, as the game's appeal and the mod scene have become so intertwined that there really ought to be a good, centralised platform for its delivery. Open-world games like this really thrive on modifications and the more Squad can do to organise that and (perhaps) even connect it to the game installation itself, the better.

2) There is still no schedule at all (patch or release )after more than two years of KSP. At this point you should have at least some basic understanding what your team can do and how long it will take you. by not doing so you leave the impression that they either have little confidence in their own talent or no real mission statement for the project "KSP". If you do stuff like this there has to be an ultimate goal, with a date put next to it. Otherwise you get what we see under 1), "some neat side feature? yeah we can add that, it won't take long!".

I agree, but for slightly different reasons. I do like the fact that the schedule is somewhat flexible as I believe it allows the development team to invest time where they think it's necessary, when they think it's necessary, rather than firefighting the expectations of a load of whiny fans who base their lives around a developmental Gantt chart of release dates.

However... I do agree that (for Squad's own sake), they really need to lay down a firm description of project scope (what are you buying and not buying) before those expectations get screwy. I don't think it's unreasonable for them to put out some tentative final release dates. This would also have the advantage of giving people an approximate idea of how close to 'complete' the game is and modifying expectations in the process.

[jfx]

It's not like building a house. It's not tried and tested. So no, there is little schedule as to "when" things get finished.

Its not so different from building a house. There is a reason it is called "Software Architecture" and "Software Engineering". Much of it depends on reusing "tried and tested" methology, concepts and if possible code. If you want to build a wall, there are a couple of ways that have been proven valid. The same thing applies to a wide range of problems you run into when developing software. 90% of them are already solved and documented.

[Garek]

Well, you're right about the "tried and tested" stuff. But quite like building a wall, that stuff only provides the building blocks. Especially since KSP isn't some more-or-less generic FPS where there are hundred out there (some even with source code available) from which you learn, recombine stuff and maybe add one or two innovations of your own and pretty much know what to expect. KSP is something really unique, so they have to expect parts not working out as thought when they throw the blocks together (similar to how the (honest) schedule of a building gets more and more vague the less normal it is). Also, I think you either misunderstood or dislike Squads general development approach (as I understand it, in turn). I don't think they got together, made the specifications for the final release, and then started working towards that. It seems like a more flexible approach, where they have a general direction, but no set specifications. Instead, they will continue to develop, regularly shipping new updates, until they one day declare KSP to be finished. The benefit here is that they can react to the loads of feedback from us players much more flexible then if they did a full specification at the start (which would be required to give any reasonable approximation of a release schedule). It's a different development cycle: instead of specify everything->develop->test->release it's specify the next bits->develop->test->early access->repeat. Also, I remember there being a dev post a bit after .21 release where one of the devs gave some estimates of how finished the game is.

[rkman]

1) SQUAD seems to be sidetracked easily by non-critical stuff like spaceport 2.0

How can you know that and not know it's essentially one guy at Squad busy with Spaceport?

until the money runs out and you spent your time bugfixing spaceport 2.8 instead of shipping the finished base game.

Grossly exaggerated.

Its not so different from building a house.

It is different. Bricks are a lot simpler than code.

[jfx]

One guy still costs money. With a team sized like squads "one guy" is a large share of manpower devoted to a side feature of uncertain success.

Interest in KSP is already waning due to the prolonged development process, so the assumption is not exaggerated at all.

[llamatoes]

Interest in KSP is already waning due to the prolonged development process, so the assumption is not exaggerated at all.

Should we be worried?

I've already got a KSP tshirt and bumper sticker. which cost about twice what I paid for the game.

Interest is still here, KSP remains one of my favorite games ever.

You've made me sad now.

You monster.

[Millie]

How do you know, for sure, that:

a) the amount of times something is Googled is the best metric of "popularity" (whatever you mean by this)

that any waning amount of Googling is due to the long development time?

"Prolonged" is relative and subjective. "Popularity" is relative and subjective. All that matters, really, is that there's a prospect of Squad making more money over the next few quarters than they spend. Yes, popularity will be a factor in that. But I'd rather have a quality - relative and subjective concept! - game than something rushed through because I'm impatient.

I am impatient - a relative and subj... bleh - but that's beside the point...

[jfx]

If people are interested in something, they google for it.

The validity of this data is pretty clear - stuff like this is built on top of it. Google has enough reach to make a good representation of what bothers and fascinates people.

[Guest]

It's easy to tell when people are getting anxious for an update. The armchair quarterbacking and "authoritative" doomsaying begins in earnest. Makes me chuckle, it does.

[regex]

It's easy to tell when people are getting anxious for an update. The armchair quarterbacking and "authoritative" doomsaying begins in earnest. Makes me chuckle, it does.

Confirming that EVE KSP is dying.

[rkman]

If people are interested in something, they google for it.

Until they know enough about it that they don't need to google for it anymore. What is waning is the growth of pre-release interest in KSP, which was to be expected.

[TMS]

Interest in KSP is already waning due to the prolonged development process, so the assumption is not exaggerated at all.

Isn't that time series scaled to the highest data point which, coincidentally, was the month of the 0.21 release and the sh!t-tonne of media coverage it had?

I'd take another look in two months time. Also worth noting that Google's data doesn't always seem to be real-time on these analytic dashboards. Even the non-partial data seems to show some fluctuation.

[stupid_chris]

One guy still costs money. With a team sized like squads "one guy" is a large share of manpower devoted to a side feature of uncertain success.

Interest in KSP is already waning due to the prolonged development process, so the assumption is not exaggerated at all.

Please bear in mind that N3X15 is a web developer. Each member of the team is assigned to a spot because it's where they are the most useful. Would you want the team to put Artyom to web development if they really needed it? Or to put Romfarer to animation instead of DanRosas? They are capable all around, but they are all better in one spot. Rob is developing the Spaceport because the current Spaceport really needs a replacement and this is the place where he'll be the most useful.

The team is only composed of three coders, two part time content designers, two web devs, and one animator/artist, they're doing the best they can.