posted 08-10-99 10:24 AM ET        

Q:
Will there be any fixing of original SMAC bugs in Al. Cr (assuming that any is needed)? Speaking of which, do you plan on making a "Patch 5"? If so, has a timeline for
it been discussed at all to date?

A:
We have no plans for a patch 5 at this time. That's not to say we would never do one, but other than a possible problem with missile ranges that I haven't had time to
check out yet, I'm not aware of any major outstanding bugs in V4.

I don't have the comprehensive list, but I can name one bug that is bugging the heck out of me... the fact that maintenance is miscalculated at transcend level. This makes the game much easier than it should be (to compensate, I don't build energy banks).

The problem here is the complete denial of defects BY THE PRODUCER OF THE GAME!!!! How can we expect Firaxis to fix anything if they are not convinced that problems exist. How can we expect them to adjust gameplay effects if they won't even admit to blatent provable problems!!!

I've been a lurker and silent supporter of the development team since this project was made public almost two years ago, and I'm quickly losing faith in their committment to producing a quality gaming experience.

I've got plenty more to say on this topic, but since I'm at work I don't have time to properly compose my ideas.

In closing, Tim Train, if you read this message, get your head out of the sand and get control of your project! You have completely lost touch with what is going on. Your group has "next project syndrome"... they are so excited about doing something new that nobody wants to perform maintenance tasks on existing products. I manage a software development shop, and I can spot this syndrome from a mile away. This syndrome will cause your existing customer base to erode, but you won't know it until sales of new products don't meet expectations.

posted 08-10-99 02:02 PM ET            

So, are you saying you think its the designers or management that is possibly suffering from "Next Project"-itis.

And do you think there is a significant difference in that your shop works in something OTHER than entertainment (games). And it seems that historically, a game is only supported until the next product's income is over-taking the first. That means Civ3 is published, in this specific case.

posted 08-10-99 04:35 PM ET            

Unfortunately I believe that Firaxis management, read Sid and Brian, are suffering from a much worse malady... overinflated egos! This has not always been the case. Sid was very responsive to gameplay issues when Civ1 was first released... in fact many of the "drone"/happiness rules are a result of discussions that happend in Compuserve's gamers forum many years ago. Just one short year ago, Brian was here interacting with gamers and getting a feel for what we wanted... many suggestions were actually implemented in SMAC! Now it seems that the attitude is "We are the game design gods, you guys are insignificant to us. Play the game and be happy that you have it".

As far as there being a difference in the way my shop works over an entertainment software shop... I think the rapid pace of tech change and the "sexy" nature of computer games enhances the effects of nextprojectitis. But, this syndrome is evident in the entire software industry. Most programmers don't or won't do maintenance programming... they want to code the first release, grab their accolades, and go to the next "big high-profile" project. They typically leave vast wastlands of crappy code in their wake. (maybe in a later message I'll relate a couple of good stories from the perspective of the lowly maintenance programmer)

In my shop I use a modified cradle-to-grave ownership concept. The team that does the original design and implementation will own the project, and they will do all of the maintenance on the code. The only way to get assigned to a new project is to excel at both the orignal programming AND the maintenance programming. Those who are the best at both disiplines will be project leads on the higest-profile sexiest projects. The theory is that the quickest way to a new project is to minimize the amount of maintenance on your current project, and the easiest way to minmize the amount of maintenance on a project is to DO THE JOB RIGHT THE FIRST TIME! This seems to work... I get a good first release, rapid updates, and highly maintianable code.

As far as egos go... I haven't found a sure-fire way to deal with them yet. Big egos usually get tossed out the front door. I've lost a couple of really, really good coders because they could not accept that they had made mistakes, or they wouldn't "lower" themselves to write maintenance code.

In a game development shop, I'd probably institute a "maintenance training" program. This is where one of the orignal programmers will retain ownership of the product, and he would lead a small team of "new hire's". This team would do all of the late patch maintenance. This would give the newbies some experience with game code, and it would give the maintenance lead some experience as a supervisor. It would also mean that the product does not rot on the vine.

Back to my original point... I think the SMAC team is so enamored with SMAX that nobody has bothered to do the maintenance. Nobody cares about SMAC... it is last year's program. I cannot beleive that they don't have at least one person dedicated to verifying all of the bug reports for V.4, and subsequently fixing the bugs. I cannot believe that they are going to release companion product that will contain the same defects as the base product. This is just poor management, and clearly the producer is completely to blame for this lapse in judgment.

posted 08-10-99 06:17 PM ET            

Hehe. Why talk about bugs when we can pick on JKM's article.

Seriously, you make some great points. And I'd say you're right on the money timing wise. It was pretty clear starting at the beginning of May that FurXs had close to zero resources assigned to patch v4.0.

This jives with the results we got: IRM still not fixed and massive increases in load times for the game itself and .SAV files.

Heck, if I was a SMAC tester and had to sit through loading the game over and over, I would have been howling to find out why it was taking so darn long with v4.0. The load time thing is enough to convince me that serious testing was not done by ANYONE who was already familiar with the game. Yet another short shrift to us the consumer.

Nothing worse than lip service testing.

posted 08-12-99 07:35 AM ET         

1) It was apparent to me from my very first game at Transcend something was up with the energy. Any testing at all should have spotted this, and tried to find its source.

2) Forum member found it, and yet Tim Train still claims ignorance of it.

3) From JKM's article, he obviously isn't interested in fixing bugs. From the complete lack of any statement by FIRAXIS< it's apparent they agree with him. (I don't care if other people didn't take it that way - many of the loyal fan base did. All FIRAXIS needed to do was issue a statement either saying "Jeff's views aren't ours, and he's expected to follow our views when working" or "Ooops- a terrible misunderstanding, Jeff didn't mean that!" and they would have avoided alienating this key market. Simple business logic).

So, Sid has lost a fan. Despite my dedication to Civ games, I won't be buying Civ3 until I see what the online crowd find wrong with it. If things go as they went with SMAC, I'll never buy it. It's a great shame, because I think this whole genre is a brilliant concept that has so much potential for expansion. And so many avid fans full of ideas and possibilities. It breaks my heart to see the legacy so thrown away.

posted 08-13-99 10:23 AM ET            

Unfortunately, this program will not cure the problem of nextprojectitis. Unless the original developer retains ownership of the code, then he has no incentive to create solid maintainable code. Most "star" programmers will jump from one high profile project to the next collecting accolades and pay increases all along the way. Typically their work is judged on timliness, sexiness, and sometimes budget... but very rarely is it judged on quality. This is because the "star" programmer has already jumped to another high profile project (sometimes with a different company) by the time quality defects are discovered.

If it sounds like I have an axe to grind, I do... and it is a big one! I've piloted my career behind many supposedly top-notch programmers. I've been the one to clean up their messes, sometimes rewriting over 75% of the code. I've also managed to have my salary remain at about 70% of what these "rising stars" earn. One would ask why I haven't taken on some of these high profile programming projects... well I have. The last time I did this, my superiors told me that I'd budgeted too much time for the project, they told me that "Joe" could write the program in two-thirds the time I'd budgeted. I told them that "Joe" was a complete idiot who couldn't write his name without creating at least two major bugs. That didn't matter to them. So I grabbed a roll of duct tape (in the finest Southern tradition) and taped-up a bunch of crappy code. I delivered the program on their accelerated schedule and ran out the back door as fast a I could. It probably took some poor slob twice as long to fix the mess as it would have taken me to do it right the first time.

I'm now in a position where I can formulate and test a few theories about software development... specifically focusing on quality. My main premis is that a programmer will retain ownership of his code well into the maintenance cycle; this way the programmer will have to own-up to his mistakes, hopefully learning something in the process.

I've digressed, I guess. In closing I'd just like to state that the commercial software industry is the only retail industry that I know of where they are allowed to take your money and are not legally bound to deliver anything. Take some time to read the End User License and Warranty in your software. In fact when you buy software, you've haven't bought anything. You've paid for "right" to use the software. Some EULAs state that the software is "non-transferrable"; this means that you cannot legally sell it to someone else!!! I'm waiting for some bone-headed software company to take issue with the used software market. I guess when I buy a book, I've actually bought a license to read the words contained within!

posted 08-13-99 12:10 PM ET         

The point is, if this team is now moving on to three new projects (Antietam, SMACX, and Civ3) there probably isn't anyone left to work on a patch to AC.

However, since SMACX is on the list, you'd think they'd want all the info they could get about AC to make sure they had everything fixed in SMACX.

posted 08-13-99 01:21 PM ET            

I used to be the "Hired C Gun". Companies payed me outrageous sums of money to come into at the middle or later of one of their projects, and finish it for them on time. Maintainability was not an issue. Any bugs short of fatal crashing the product 1 out of 4 times in 10 minutes was not an issue. They paid through their behinds to get me, and the prices always rose. I always felt sorry for the poor slobs that had to try and maintain my code though. But it wasn't my problem... and I always had another 3 contractors begging for my time whenever I wanted a job. Life was good.

And then, through a quirk of Fate, I found myself in need of guaranteed pay for a period of time. Contracting is a lot of things, but it's not guaranteed. So I took a "permanent" position. And through that position, I got to see the nastiest, ugliest beasts that someone else wrote. Some by "Hired Guns". Others by those that came before. You know what I mean. It was very educational.

Unlike many Hired Guns, I had worked a lot in teams (and actually had ran teams of Hired Guns), so I am proud to say that my overall coding level was a bit higher for most Codeslingers. But that means that I only commented once in a few hundred lines, (or all the comments was about previous code, and not applicable in the slightest to the final code) and was still making code that was quick to write, and quick to run. That was still a bit of a nightmare for maintainence and upgrades though, unless you knew the reason it was the way it was and was there when it was written.

From a software services point of view, you find its worth the time to add the comments. You or a team-mate is very liable to have to go back into that code and make an enhancement to meet new customer requirements. You find it very efficent to take the time, and write it proper the first time... to make any code you use twice a function that gets called, to make constants a global in one spot... to sit and think through EVERY request and detail and interaction before opening a keyboard. As a wild, wooly codeslinger, you learn to skip writing lines of code that the optimizer is just going to toss. As a Maintainer/Long Term Enhancer, you learn to put those in, for clearness and readibility.

What it all boils down to though, is that there are 2 priorities in Software Engineering. 1) Getting it done on time, and 2) Getting it written for maintainability (debugging), enhancability (expansion), and trouble shooting customer problems. Unfortunately, Objective 1 is counter to Objective 2. The reason? Time. #1 is all about doing what you have to meet the hard deadline to get the product out the door and out to manufactoring. You hope you can finish with enough time for the product to get a good QA, but that's someone else's problem. Generally, QA and the idiot Management that shortened the development time too much to allow a quality product, but left enough in for a panicked product. #2 is one where Time is a luxury. It's more important to have a Quality Product. Customer needs and requirements are the item in stone.

Games are throw-away products. You are only going to get 1, maybe 2 for an ultimate game, expansion. If its a great game, by the time you can crank out a 3rd expansion, the market is going to have been flooded with cheap imitators, good innovators based on yours, and the market demand for your "type" of game is going to be dead or dieing. Only the super-tremendous break out hits can get away with anything more. And if it was a good money maker, than rather than EXPAND the original code, a sequel will be commissioned based of the original game concept/play. But with the competition for the game consumer buck, there will probably be new standards and new fads that have to be incorporated, leaving little to none of the original code for re-use.

As a throw away product, you drop the need for maintainability, enhanceability, and trouble-shooting right out the window. The only thing left is making the schedule. Since is quickly written and quickly running code, if you don't do an expansion quickly, your original team forgets what it was they did and why. The Expanders have to struggle through the slime and mud to hook in the new bits...

The other side of the coin is the Custom App Developing shops. You have a customer that has a set of requirements that have to be met. They are paying you as they have a need to be filled. Odds are, you will have to maintain this product for them for some time. This is often seen with Government Contractors, Financial Software Groups, Utility Companies, etc, etc, etc. This applications are anything BUT throw away products, so its in the Software Authoring Company's best interest to make sure the code is has all the 3 points of long life span quality (Main/Enhance/TroubleSht.) listed previously. If you deliver a low quality product (say SMAC/CtP/Etc), your customer will go to another contractor. And you won't pay the mortgage, or the electric, or the food bill.

That's the difference. It's capitalism at work. In software game writing, maximizing profit is to minimize development time, and to spend the least possible on QA to make the product acceptable to the market. It's inefficent cost-wise to do anything more. In the customer specified needs software authoring, maximizing profits is to deliver the highest quality product that is best fit for a long term of service to a customer that may at any time pay for new options to be added, or a rewriting of current option functionality. Any problem they have, and they will expect your people, or people trained by you, to be able to determine exactly what it is they MISUNDERSTOOD and be able to walk them through what it is they INTENDED to do.

Its really the difference between quality services, and mass product. Too completely different games. The only thing in common is we both use the same base toolsets.

The way to make the software entertainment authoring companies to slow down and invest in QUALITY is to make QUALITY of the product a true concern. As it is now, it's not percieved as a permanent hot issue. And that is what I have been trying to correct and educate my fellow game consumers about.