About the beta patch routine.

[Zeba]

After this next official patch would it be possible to seperate the fixs to the game from the experimental stuff you do to try out new game mechanics or the testing of new expansions?

That way if something comes up after the official patch you won't get stuck in the endless loop of also testing out the new stuff along with getting the old stuff fixed.

Pretty please? 

[Mánagarmr]

You mean you should have one "Fix"-beta release and one "Experimental"-beta release, or? I think the general consensus is that when Arcen believe they have a stable enough release, they release it retail. That's the thing you are supposed to use if you aren't actively beta testing. It's supposed to be stable and bug free.

If you go into beta, you also have to endure the gimmicks of new mechanics and features, since that's what beta really is all about. Having two different releases isn't really feasible, I think...

[Lancefighter]

i think what he is saying is that some patches should be committed to 'public', like bugfixes, while the experimental new stuff should stay beta

[Mánagarmr]

So...essentially releasing bugfixes as retail releases? That would require Chris and Keith to extract only the fixes from the beta releases and apply them to the retail version and bugtest THAT...it sounds like a little too much work for comfort.

[Zeba]

i think what he is saying is that some patches should be committed to 'public', like bugfixes, while the experimental new stuff should stay beta

Yes. Take the shield bearer and merc changes for instance. That was expansion independant and should have been its own official public release instead of getting lumped into the mix with all the other stuff. So if you wanted to play a game with the fixed bearers and mercs on say only the base game with maybe an expansion enabled you wouldn't have to now get everything else too.

So...essentially releasing bugfixes as retail releases? That would require Chris and Keith to extract only the fixes from the beta releases and apply them to the retail version and bugtest THAT...it sounds like a little too much work for comfort.

No, it means keeping general fixes seperate from the other stuff as its done which should already be the case if proper qa routines are in place. It shouldn't really be any harder other than maybe figuring out what should be in the beta build and what is put in the public one.

[keith.lamothe]

Maintaining two separate builds would have a serious multiplicative effect on the time it would take us to get anything done, and so is basically not going to happen.  We've been more pressed for time than usual lately so the latest official has more bugs than, say, 3.120 did.  We're trying to have the next official be considerably more polished, both balance and bugfix wise.  But we don't have time to be splitting out changes and dealing with the inevitable extra headaches that would follow from such a thing.

[Invelios]

Can't you just get the latest beta and disable the expansions you don't have? I don't really see how having 2 separate patches is feasible, they would have to extract only the stuff they wanted in the other patch, and have a way for the game to know which of the 2 patches you installed last so it knew what new stuff it had to download for any new patches. If you don't want to deal with beta stuff, then just wait for official. If you don't want new expansion stuff, just disable it after installing the patch. Sorry, but what you are suggesting doesn't seem worth the trouble it would cause.

[Mánagarmr]

Keith pretty much just confirmed what I said before. It creates way too much overhead to maintain multiple releases (especially since the retail and betas aren't the same code, introducing fixes that work in beta might cause additional issues in retail)

[Zeba]

Maintaining two separate builds would have a serious multiplicative effect on the time it would take us to get anything done, and so is basically not going to happen.  We've been more pressed for time than usual lately so the latest official has more bugs than, say, 3.120 did.  We're trying to have the next official be considerably more polished, both balance and bugfix wise.  But we don't have time to be splitting out changes and dealing with the inevitable extra headaches that would follow from such a thing.

Interesting. So its that difficult to seperate things like a performance boost or a graphics glitch fix from the other stuff without effecting the other stuff? Well you guys are the devs so do what you think is best after all.  

[keith.lamothe]

Interesting. So its that difficult to seperate things like a performance boost or a graphics glitch fix from the other stuff without effecting the other stuff? Well you guys are the devs so do what you think is best after all.  

Well, first we have to have two separate codebases and three separate public versions (official, "maintenance beta" that would frequently be turned into the next official, and "experimental beta" that would have a longer cycle).  We would get thus get three separate sets of bug reports since the "maintenance beta" could get all new bugs (let alone balance issues) of its own from changes "backported" into it without the context of the other stuff in the experimental builds.  It also takes a non-trivial amount of time to package up an official release, get it to our distribution partners, etc.

It's not like we _can't_ do it, or that it's not a good thing to do, but we have to do everything we can to keep our development overhead low or we're going to have a tough time staying above the financial water line

[Zeba]

Well, first we have to have two separate codebases and three separate public versions (official, "maintenance beta" that would frequently be turned into the next official, and "experimental beta" that would have a longer cycle).  We would get thus get three separate sets of bug reports since the "maintenance beta" could get all new bugs (let alone balance issues) of its own from changes "backported" into it without the context of the other stuff in the experimental builds.  It also takes a non-trivial amount of time to package up an official release, get it to our distribution partners, etc.

It's not like we _can't_ do it, or that it's not a good thing to do, but we have to do everything we can to keep our development overhead low or we're going to have a tough time staying above the financial water line

Awesome. Thanks for the clarification. 


Now if only CCP was as forthcoming and transparent. 

[keith.lamothe]

Now if only CCP was as forthcoming and transparent. 

Why would they be?  They like the kind of world Eve is, and are happy to make their own corner of the real world more like it

[Zeba]

Why would they be?  They like the kind of world Eve is, and are happy to make their own corner of the real world more like it

Because we wish it and we are also looking for an edge too being the dastardly inhabitants of said world. I blame ccp for making a game that is so attractive to our kind.

[Mánagarmr]

Why would they be?  They like the kind of world Eve is, and are happy to make their own corner of the real world more like it

Because we wish it and we are also looking for an edge too being the dastardly inhabitants of said world. I blame ccp for making a game that is so attractive to our kind.

Assholes?


*also an EVE player*

[Zeba]

Assholes?

No.*

Predators.

Arcen is filled with them too. I mean do you really think you are playing the AI in AI Wars?

Nope. Your are playing against the Arcen devs who cackle just like an eve pirate at every 'omg I got comp stomped' thread. 



*well actually yes as we have plenty of them too.