How do you feel they've handled the BtS patching process so far?

[Psyringe]

I think one of the reason why bigger patches (that take longer) might be preferred to smaller patches (that might be released faster) is the multitude of versions of the game. There is a DVD version (Europe), perhaps a CD version (in the US, not sure about that), there's a D2D version and a steam version, and there's Civ Gold which has some different path names. All of this has to be taken care of when a patch is released. This means, each time they decide that they do release a patch, they have to make a installer for the CD version, one for the DVD version, one for the D2D version, one for Steam, and one for CivGold. Note that each patch involves reapplying the copy protection, which is different for every platform mentioned. And all these installer have to be tested to make sure that they work. This is a lot of overhead that has to be paid for.

Hence, it might be considerably cheaper to produce two "big" patches than to produce three smaller ones with (in rthe end) the same content. As a result, it might even be better for the fans if Firaxis/Take2 release fewer (bigger) patches, because that means that for the same budget they can spend more time patching the game instead of wrapping up installers and testing them.

However, keep in mind that I'm only guessing here. I don't really know *who* does (and pays for) the patch wrap-up for Steam or D2D, so I might be wrong. I just thought that the thought itself sounds plausible enough to throw it in.

 

[Lobsang1979]

My only frustration throughout the past month has been the fact that, having bought the Direct2Drive version of BTS at start of September, I can't actually roll back from 3.03 as that is the version of the installer.

I have been holding off on playing a game since not because BTS is some hugely bugged game (i believe others when they say it isn't), but because the game just feels 'clunky' to me compared to my last Warlords game. It just felt as if it wasn't polished to the same high standards I enjoyed previously.

As for the patch, I have no problem with however long it takes to be released as I take the view that, for every day it remains being worked on, the final result should be better delivered.

As for Alexman's communication, I take everything I read with a pinch of salt anyway. That's the great thing about being an eternal cynic: I'm rarely disappointed!

 

[Angst]

HRE!!! POLAND!! !HITLER!! !!1



...

well, as long this thread wont turn into a stove with alexman inside...

 

[Slobadog]

Here is an idea how about instead of complaining about the patch delay we simply make our own patch. Just like Solver. We already know what fixes and changes are supposed to be in it.



Edit: Alright bad idea. We would likely end up complaining about our own patch getting delayed due to new bugs popping up.

 

[Atwork]

A better way of handling this in the future would be to address easy fixes first and then take as much time as needed to address cosmetic, interface, balance, or AI behavior issues. Obviously it takes more time to deal with the coding that, with each change, sets off a chain of results that must be addressed accordingly. In the end, I would prefer that the coders take their time to get the overarching issues right. But, there were plenty of glaring problems that seem like quick fixes: such as the Marathon-poison water problem. Keep the community patient with quick fixes prior to big overhauls and communicate accurate information. That's my two cents.

 

[bob_x]

Then again, I don't want to sound like I'm blaming Firaxis; it is quite possible Take2 said they get one more patch for BtS and that's it, or some other constraint we are unaware of.

This explanation is possible, but it reflects a bogus managerial constraint on the process.

It would be more efficient to release beta patches to advanced players via an optional download. The advanced players would report bugs on this website. Firaxis gets free beta testing and everyone gets a better game.

Having worked in software development (but not game development), I definitely noticed a managerial preference for fewer big releases, because many small releases somehow seems to management to be a process that's "out of control." Managers often tend to be irrational control freaks. Managers have absolutely no idea what programmers are doing, and some feel the need to exert any sort of control over them.

A lot of the QA I had to deal with was pretty bogus and a big waste of time. It was all about following a process, no matter how time consuming, rather than trusting the word of the programmer that a certain code change would have no effect on other areas of the program.

 

[Quagga]

It would be more efficient to release beta patches to advanced players via an optional download. The advanced players would report bugs on this website. Firaxis gets free beta testing and everyone gets a better game.

Would these advanced players be the same beta testers that didn't find the bugs prior to the BtS release? If so, I think we can skip this step.

 

[Colossian]

Firaxis' programers make many bugs. In fact, it isn't a bug. It's a quality of a game company. I bet the new patch will have many bugs, again again again and more!

Moderator Action: Warned! - Flaming
Please read the forum rules: http://forums.civfanatics.com/showthread.php?t=422889

 

[Loopy]

Firaxis' programers make many bugs. In fact, it isn't a bug. It's a quality of a game company. I bet the new patch will have many bugs, again again again and more!

Please don't bash Firaxis -- it's counter productive and not the point of this thread. If you'd like there to be fewer bugs, please make some sort of suggestion as to how they might go about doing so.

I'd like to think that releasing a patch to "advanced users" would identify more bugs than just those prerelease testers. First off there'd be a much larger install base with more variety in play style, installation method, and hardware. Of course when you identify more bugs, that's just that many more to fix, potentially leading to even more delays.

And I wonder if they'd be better off with a "firm release schedule" of three planned patches. The first one 6 weeks after launch, targeting immediate fixes that can be implemented in that short time frame. The second one, 12 weeks after launch, with more involved fixes, balancing issues, stuff that couldn't be finished in time for the first patch, and new quick fixes that have popped up. A "final" third patch could come 6 months after launch, hitting anything remaining. Ideally coding would be done concurrently, not unlike how the Catalyst Driver team (admittedly with in all likelihood, many, many more staff).

With a "fixed" schedule, end users would be happy knowing around when patches would be done. Managers might be able to schedule staff better and budget accordingly. This might appear to cost more, but given the current situation of scope creep, delays, and loss of goodwill, it might balance out.

 

[jray]

I don't care about the 3.13 delay. That's just the unpredictability of software development. But leaving 3.03 out there for weeks was a major goof, considering that downloadable versions did not have the capability to revert back to 3.02, and many customers haven't checked the forums to learn that 3.03 was a disaster. They really should have released a 3.04 the next day, considering that they immediately diagnosed the problem and could have immediately remedied it.

I wish there was even MORE time between patches, because it's a ton of work to update mods and modpacks whenever there is a patch.

 

[ButSam]

This explanation is possible, but it reflects a bogus managerial constraint on the process.

It would be more efficient to release beta patches to advanced players via an optional download. The advanced players would report bugs on this website. Firaxis gets free beta testing and everyone gets a better game.

Having worked in software development (but not game development), I definitely noticed a managerial preference for fewer big releases, because many small releases somehow seems to management to be a process that's "out of control." Managers often tend to be irrational control freaks. Managers have absolutely no idea what programmers are doing, and some feel the need to exert any sort of control over them.

A lot of the QA I had to deal with was pretty bogus and a big waste of time. It was all about following a process, no matter how time consuming, rather than trusting the word of the programmer that a certain code change would have no effect on other areas of the program.

I completely agree with you, on all counts. Managers tend to think we are running low on electrons or something...

Releasing a software patch isn't like modifying hardware. It takes a few megabytes of website space, which is dirt cheap these days. Funny how managers will remember that when they decide a version is ready for prime time and can skimp on the testing phase, but they forget it when it comes time to fix those bugs!

I would gladly sign up for a beta testing program. I have no problem at all reporting bugs I find in software.

Sam

 

[Loopy]

With both the patch and Bhruic's patch to the patch out for a couple of days now, anyone else who hasn't chimed in yet care to make a suggestion or offer constructive criticism?

 

[Arlborn]

And I wonder if they'd be better off with a "firm release schedule" of three planned patches. The first one 6 weeks after launch, targeting immediate fixes that can be implemented in that short time frame. The second one, 12 weeks after launch, with more involved fixes, balancing issues, stuff that couldn't be finished in time for the first patch, and new quick fixes that have popped up. A "final" third patch could come 6 months after launch, hitting anything remaining. Ideally coding would be done concurrently, not unlike how the Catalyst Driver team (admittedly with in all likelihood, many, many more staff).

With a "fixed" schedule, end users would be happy knowing around when patches would be done. Managers might be able to schedule staff better and budget accordingly. This might appear to cost more, but given the current situation of scope creep, delays, and loss of goodwill, it might balance out.

Oh, I don't think it works! Sometimes one bug is fixed and more bugs appear from the fix itself! Hardly smart to have dates and just throw the patch on those dates with whatever bugs there are inside the patch!