1.0 development split!

[quasarrgames]

So since this 1.0 update will probably take a very long time (i'd guess about 6 months, if not more) and this wonderful game hasn't really had a beta, I'd suggest splitting up the 1.0 release into 3 smaller updates. These updates could maybe go something like this:

0.91: aerodynamics, more wing parts, extraplanetary resources

0.92: Female Kerbals, Re-entry heat, some nice balances

1.0 update: LOTS AND LOTS of bugfixes and balances, and an update to unity 5 (since it will probably be out by then)

It could be different. This is just a rough plan from me.

Basically, i think multiple releases would be good for everyone. It would be better for us the players, as we'd have more of a beta period to play with, and we could be more involved in the development, by getting a few new features each time and therefore being able to give more accurate feedback on what needed balances and bigfixes. I think it would also be good for the devs, since it wouldn't take much extra time to quickly bundle up and test each beta release, and they could more easily tune the game based on our feedback.

so, what do you think?

Edited February 3, 2015 by quasarrgames

[Slam_Jones]

There are only Cheese Sandwiches.

Assimilate or perish.

Honestly, I couldn't care less. KSP has been one of the few games that has enough merit on it's own that I'm not constantly wishing for updates. KSP is great how it is, and I don't care too much how long future patches take... let them polish em and put em out in their own time.

"Alpha," "Beta," and "Release" are just labels in my eyes.

Edited February 2, 2015 by Slam_Jones

[Alshain]

I don't think it matters what we think. Squad seems set on this path.

[Sirrobert]

Concidering that parts of the team are all working on different parts of the update, it'd mean either diverting everyone to 1 part at a time, thus not using the full potential of talent (can't do much with an animator in the aerodynamics update). Or have everyone work on their own thing anyway, and having everything finish at the same time it was going to anyway

[SkyRender]

I'm of the opinion that, if they can get enough of the aspects they want for 1.0 in place for an interim release, they should consider it. Sort of like how the 0.18 series added new content for the interim releases (Pol and Eeloo were added in 0.18.1 and 0.18.2, respectively). Of course, it's up to the development team to decide.

[Technical Ben]

I would assume with the final game setup, wanting to balance them in tandem is desired. So doing the few things left at the same time.

A bit like painting the inside of the house at the same time as the outside, then you can let the paint dry at the same time, and do it in half the time as each after the other.

[Wallygator]

Snip

0.91: aerodynamics, more wing parts, extraplanetary resources

0.92: Female Kerbals, Re-entry heat, some nice balances

1.0 update: LOTS AND LOTS of bugfixes and balances, and an update to unity 5 (since it will probably be out by then)

I would reverse this. bug fix and unity focus first, then aero, then parts, heat and balances. Keep the female Kerbals to the end and let them be the messengers of the final production release.

[Caelib]

As somebody who works in the software industry I can say that I don't like this idea. While you might like this as a consumer of said product, it's really difficult for the life-cycle of the project because each release adds A LOT of overhead (read: cost). A lot more will get done in less time if the block of development time per release is, say, doubled.

[Engineer of Stuff]

It would let them be a little more relaxed on 1.0, and Squad might feel less stress. But I really don't care.

[Snarfster]

To me, the target is set and the team is working on reaching that target.

Splitting things up doesn't necessarily speed up development. There may be several different teams working on things simultaneously. Also, splitting the release increases overhead. Basically, you might get release 1.0 a couple of months later with the same content, just from creating this split. This due to building of release candidates, testing software, building the release, etc.

[GoSlash27]

I like the idea of beta testing prior to release, but that's not what they're gonna do. So... *shrug*.

Best,

-Slashy

[Renegrade]

I like the idea of beta testing prior to release, but that's not what they're gonna do. So... *shrug*.

Why would you test code? The bugs are the best part of a game.... BEST. PART. My personal favorite is that old one where if you got frisky with symmetry, eventually you'd try to place a part, there'd be no click sound, and a NaN would appear in the log and the ship would be completely corrupted (and the .craft file too if you saved at that point).

Er.. what's the vB code for sarcasm tags again?

If Squad wants to go ahead with a full release, that's fine, it's their choice anyways, but they really should roll out a few release candidates for full-scale testing.

[razark]

1. Add things as they are ready, test the hell out of it, release, test the hell out of it.

2. Fix the bits that need fixed, test the hell out of it, release, test the hell out of it.

3. Repeat step 2 until everything except very minor issues are fixed.

4. Test the hell out of it.

5. Fix the bugs.

6. Test the hell out of it.

7. Slap a 1.0 sticker on it.

[vexx32]

Moved to Suggestions.

[mattinoz]

I wonder if Squad just decided that the KSP community has gotten to big for it to be a public beta.

They did put out a call for more experimentals a few months back, I'm wondering if they are doing 0.9x releases on a short cycle to just the experimentals teams so they can get more directed and controlled feedback during the beta.

[Sirrobert]

1. Add things as they are ready, test the hell out of it, release, test the hell out of it.

2. Fix the bits that need fixed, test the hell out of it, release, test the hell out of it.

3. Repeat step 2 until everything except very minor issues are fixed.

4. Test the hell out of it.

5. Fix the bugs.

6. Test the hell out of it.

7. Slap a 1.0 sticker on it.

Yea, you missed just 1 tiny step:

Take time away from finishing things to test the hell out of the things you just finished.

It'll be faster to test everything in 1 go

[razark]

It'll be faster to test everything in 1 go

If you add Part A, test it, and find a problem, you fix Part A.

If you add Parts A, B, C, D, E, F, G, H, I, and J, then test and find a problem, it's much harder to find the solution.

If getting it right at 1.0 adds six months to the dev time, I will not complain too loudly.

[pincushionman]

You know, I wonder if Squad's different approach to Beta was somebody saying "hey, we have a dedicated testing group now (and have for several releases)…that means we can control the release-test-patch cycle more tightly now." They didn't have that option in the early days.

If they're really into a quick turnaround during the Beta stage, a public release could turn into an enormous mess. With the test group they can say "okay, we did X. Focus on that, please."

That said, I was hoping for a few beta releases of the "resource system." "Improved aero." "bugfix focus." "part balance." nature. We did, after all, pay them for the opportunity to be beta testers.

Edited February 3, 2015 by pincushionman

[magnemoe]

Concidering that parts of the team are all working on different parts of the update, it'd mean either diverting everyone to 1 part at a time, thus not using the full potential of talent (can't do much with an animator in the aerodynamics update). Or have everyone work on their own thing anyway, and having everything finish at the same time it was going to anyway

This, and yes its something people don't understand people has skills, you can not put an animator doing core coding. He can do testing but that it fairly low skilled work you do if you have nothing else to do.

This causes updates and patches to get released with stupid stuff like: random crash to desktop not fixed but flickering tail animation on a rare low level monster is fixed.

[Sirrobert]

If you add Part A, test it, and find a problem, you fix Part A.

If you add Parts A, B, C, D, E, F, G, H, I, and J, then test and find a problem, it's much harder to find the solution.

If getting it right at 1.0 adds six months to the dev time, I will not complain too loudly.

Have you ever developed anything? Cause there's someone in this very thread that HAS experience, and explains that it doesn't work like that (actually, multiple people).

Also, those 6 months extra? They cost ALOT OF MONEY

As somebody who works in the software industry I can say that I don't like this idea. While you might like this as a consumer of said product, it's really difficult for the life-cycle of the project because each release adds A LOT of overhead (read: cost). A lot more will get done in less time if the block of development time per release is, say, doubled.

[Frozen_Heart]

I really find it amusing that we are getting re-entry heat and resources in one update... That was the plan in 0.19 that we were all patiently waiting for and which never materialised.

Now we're all waiting for the exact same thing 2 years later...

[Superfluous J]

Actually if I had my say, it would be:

0.91: aerodynamics, more plane and aerodynamic parts, extraplanetary resources, Female Kerbals, Re-entry heat

0.92: balance, content (contracts, better science tree, more biomes and/or planets), and bugfixes.

0.93: more balance, content, and bugfixes.

0.94: more balance, content, and bugfixes.

0.95: Almost nothing. Everybody wonders why they didn't just put out 1.0

1.0: Almost exactly what 0.95 was.

[JimmyAgent007]

Personally I think that they should do what they plan, just call it .99 then check in case they really messed anything up or missed something big. Some hotfixes later and then 1.0

That being said, ive never run into most of the bugs people seem to complain about the most. The rest just seemed kinda flaky but I moved on. So if the last thing they do before 1.0 is a big internal bughunt then everything should be fine.

A customizable tech tree/web would be nice though. How hard is it to mod the tech tree yourself? Never tried but I have programming experience. There a good link to read?

[NWM]

But sincerely - 3 or 4 such (as promised for 1.0) is needed to make this game ready!

1/ At first - no - and the promised 1.0 too - for interplanetary travel you don't need superior tech to the münar travel, just a bigger rocket!

2/ Is there any reason of using the more advanced antennas?

3-100/ ....

[basic.syntax]

An extra public beta before 1.0 seems unlikely.

HarvesteR wrote about the problem of frequent public releases, before the .21 update came out.