December 3 update from Constantine H. on IG MOO3 board

[Xentax]

I can't answer most of this speculation, but I will say this: QSI *can not* sit on the title if IG is demanding it from them, *especially* given how (arguably) releaseable it is in it's current state.

Remember, IG owns the rights to the project, and we're well past whatever time the game was originally supposed to be delivered. Any delays since can only happen with IG's approval.

Now, you can argue that the game *could* be in such a bad state that IG has little choice but to let QSI keep plugging away on it. But, given that IG seems willing to accept fairly buggy games (PTW, heck, UT2k3 and NWN even), I'm not buying that as a potential reason if I didn't know better (which, as a Beta Tester, I do).

[Gooberman32]

As a beta tester Xentax is MOO3 ready for release?

[Rantz]

Originally posted by booje
While jimmytrick may certainly be talking out of this ass i had a conversation about the delay of the game with my boyfriend who worked at Disney for quite some time. There are some parallels here since games are also entertainment. In any case, he was surprised the release had been so sloppy and that if it were a movie, the suits and execs would have fired all the people and finished production to rush it out if they had missed as many dates as MOO3 has. As incentive they might've refused to cut checks before firing them.
Sorry to say but the current scenario makes sense even if jimmytrick is making it up. Hence also the massive leaks about the game since it really is code complete and it also explains a lead developer leaving before publishing. While I do respect the developers, it's hard to believe the investors would let Xmas sales slip by. The developers probably won't care to miss Xmas sales since they've already been paid (mostly under this scenario). In the end, QSI can scrape together cash and release it anyway leaving Infrogrames out in the cold.
This is the current state of the gaming industry. Crap.

Let's just cut to the chase here... Markos, if I'm outta line here, you're more than welcome to delete my post. You, are talking out of your ass about things you have to clue about.

Having worked in film, TV and games, the biggest mistake that folks in Hollywood make (and continue to do so after years of failure) Is that games and software is just like the production of a film or TV show. just as quantifible.

A more accurate analogy (if you want to go the film route) is to compare current software to the film industry of the early 1900s when each studio was using different film stock, sound methouds, building their own cameras... in other words, not only inventing the content but the tools with which to create the content.

Film and TV is a very well-define production path at this point. There are few undefined varibles, and hence it's easy to manage risk and possible schedule slip. Even then it happens. Case in point, Disney.

Fantasia 2000? Originally scheduled for release in 1996. Dinosaur? Scheduled for 1998. Emperor's New Groove? Scheduled for 1998 and titled Kingdom of the Sun, over which 2 years of animation and audio work was trashed out of fear of competeing with Dreamworks El Dorado.

See, I worked at Disney as well, for 3 years in the interactive division, and if there is ANY company that makes the software industry look like it has it's act together, It's the Walt Disney company.

So, as they say, you're wrong. In about 100 ways. There isn't one piece of truth I could find in your assumptions, and that's really saying something.

[Xentax]

Gooberman32: In my *opinion*, compared to most game releases these days, MOO3 is more than up to par for release.

However, there *are* things that are worth fixing, and if IG wants to delay (for whatever reason), and if QSI fixes some of those things during that timeframe, so much the better.

I mean, if nothing was happening during this delay, I'd be STEAMED, believe me; but I know for a fact that things are getting polished and improved day by day -- and it's easier and faster to fix those sorts of things before release than afterwards, to be sure -- it can be done to the will-be-original build, rather than having to do it through the mechinations of a patch.

[Xentax]

I generally agree with Rantz, but I'd add a cautionary note that not all of that applies to the *entire* software industry, though I suspect it applies to most if not all of the PC Gaming software industry.

Basically, there is a whole additional set of tools that come into play when creating games, tools that I (as a business software developer) don't need -- I don't need graphic engines, I only sometimes need a complete client/server layer (for either OR both ends), and the dependence on external asset files (e.g. textures, models, audio and video) tends to be an orders of magnitude fewer and simpler.

Hopefully, those sorts of areas are the limits of those the gaming industry is still "home-growing" their toolkits, while creating works using them at the same time. The tools for "pure" software development -- integrated development environments (that means the source editor, a visual debugger, etc.), source control, change control and management, deployment, and so on -- ARE getting fairly mature and are commercially (and even freely) available.

Though I've yet to meet a COTS problem-tracking system I was happy with...they all seem to either stink, or cost WAY too much.

[TCO]

I think there has to be more to it than this. A lot of the delay with Moo was from the redesign after the Alan screwup. Not from bugs. Also, I find it hard to believe that it is impossible to use traditional program manaagement. Also, why are the overruns always to push the project to the right? If the project restults are uncertain, they ought to go both ways. Estimates would be right on average but have high variability.

I wonder if part of the problem has to do with the publlisher/developer system. Maybe things work more smoothly when you have an integrated shop.

[Gooberman32]

Thanks Xentax. Really this argument is starting to get old. MoO3 is getting close to release by the sounds of things and what is the point of debating the efficiency of various software companies? Maybe QS works differently? you dont know. whats the point about whining about the screw ups in the past they happened and no matter how much whining is done its not going to fix the mistakes that have happened.

[Grumbold]

Originally posted by GP
Also, why are the overruns always to push the project to the right? If the project restults are uncertain, they ought to go both ways. Estimates would be right on average but have high variability.

My educated guess would be because many tasks the publisher arranges with other companies take place at the end of the process, like production of the manual, box, purchasing advertising space etc. Unless the software is as perfect as it can be well in advance of the anticipated dates for initiating all the other stages its probably convenient and cost effective to stick to the original deadline. I can recall a few times that a magazine has commented that a publisher has revised their release date downward, but that's always been about halfway through development, not in the last couple of months.

[Zed-F]

Targets for these sorts of things tend to be aggressive. The theory is that you're more likely to get a better result faster if you shoot for an aggressive target and miss, than if you shoot for an under-aggressive target. While there is some truth to this, as a target that's too easy often is a demotivator (people don't always work their best unless there is SOME pressure to produce results,) it can be a challenge to figure out how aggressive you can afford to be. The risk is if you shoot for something too aggressive, you will wind up throwing away a lot of time on work that will ultimately be cut. There are ways to mitigate this to some degree (e.g. work on the most important things first and leave things that are less core for later, so if you need to you can cut them) but you have to spend at least SOME time on everything you're considering doing, even if only to know how important/feasible it is. And, too much stress is a demotivator too, so it's a fine line to walk.

The overrun due to the redesign was not due to a flaw in the design process so much as a natural consequence of having an very complex and somewhat experimental design to begin with. This complexity was mandated at the requirements level by the people that brought Alan on board in the first place -- again, an example of an aggressive target that can be scaled back later. They knew they were going to have to cut some stuff well before they announced the redesign, but until they had some semi-playable code they could try out, they were not sure exactly what changes they were going to make. The original dates were probably based on not having to do a redesign, which was a bit unrealistic, but again, dates are usually set to be aggressive... in IG/QS's position, I would have thought that they would not publish any of their internal targets to the community until they were close to completion (like within 3 months) so they could be reasonably sure not to slip published dates more than once, but I suppose they are trying to generate anticipation for the game as well.

The most recent delays are only indicative that there were more bugs and/or they were harder to find than usual -- hence Rantz's surprise that they haven't gone gold yet. You can usually do some statistics and get pretty good guesses as to how long QA is going to need to find and design to fix bugs, but they are just that: guesses. Some padding is usually added to the esitmates as insurance, but that's usually the first thing to go when time pressure starts to mount, and even if it's not there's no guarantee that the padding will be enough.

Things go more smoothly when you have less requirements churn. If you know exactly what you want to build to start with, it's easy to get a relatively accurate schedule. If you're deciding what you want to build as you go, it's much more difficult. Traditional program management doesn't handle requirements churn very well.

This is all my opinion of course, based on my experience working in software design, but I'm sure Xentax or Rantz will let me know if I'm off-base. None of this stuff makes it any easier for the people waiting for the game to come out, of course.

[Apocalypse]

Originally posted by MarkG
[q]they could try the smac model though: release a demo, gather bug info, release final fixed version two months later.
but then again, they are closer than 2 months from geting where they want to get...

That isn't the SMAC model. It was less than a month between the SMAC demo release and when it went gold. It just took a little more time to get it out because the gold CD broke twice. Don't forget it was also released in SE Asia/Oceania before the US and Europe to counter against warez.

I thought you'd remember this. Maybe Dan was doing the updates. It is hard to remember almost 4 years ago.

[MarkG]

the smac demo came out a little before christmas and smac was released on the first days of february

[MarkG]

http://apolyton.net/about/oneyear/yearheadlines.shtml

-19/Dec. Brian Reynolds announces that SMAC is finished. The demo will appear on Christmas day and the game will eventually be released on February 9th

[Apocalypse]

I said less than a month between when the demo was released and when it went gold, not released. I'm saying not much was changed. The two largest changes made was a gamma corrector and color blindness support. Nothing major.

Also, you told me we never had a joint chat. I was sure we did....

-16/Jan. Apolyton and Sidgames hold the First Civers Chat

[TCO]

Sidgames has been erased from memory. Poly uber alles.

[DaShi]

Well, I cancelled my preorder for Moo3. I was looking forward to it for Christmas and amy have held out for mid-Jan, but Feb 28 is far too long. That doesn't mean I won't buy it. I'll just see, if I'm still interested when it really does come out.

[MarkG]

Nothing major.

there were lots of bug fixes from the deom to the released game. bugs that the big masses never saw thanks to the feedback from the demo. there were some many fixes that they even had an update(patch) to the demo

anyway, 1 month or 2 months, it doesnt matter. the point is that there was demo not days before the release but several weeks before, and that feedback from it was used to produce a more stable release version

Also, you told me we never had a joint chat.

when did i tell you that???

[Apocalypse]

Originally posted by MarkG
there were lots of bug fixes from the deom to the released game. bugs that the big masses never saw thanks to the feedback from the demo. there were some many fixes that they even had an update(patch) to the demo

anyway, 1 month or 2 months, it doesnt matter. the point is that there was demo not days before the release but several weeks before, and that feedback from it was used to produce a more stable release version

Well there was a patch out shortly after SMAC's release that fixed many bugs, but there wasn't that much changed from the demo version and the release version. I mean, it went gold less than a month after the demo. That isn't several weeks. It is 4 at most.

Originally posted by MarkG
when did i tell you that???

I don't remember, and the search thing doesn't seem to be working.

[MarkG]

4 weeks of bug fixing is one patch that the grand masses(and the reviewers who gave their scores based on the release version, not the demo version)) didnt have to download