(This post was split off from a previous post on Rob Pardo's keynote at the Austin Game Conference.)

I'm intrigued by Mr. Pardo's remarks about polishing:

Finally Pardo discussed the famous Blizzard polish and dispelled a misconception about the way it works. "There's this big assumption with polish that it's something you do at the end, that the reason Blizzard is successful is because we get 6 to 12 months more than everybody else and at the end of that process we just spend a whole lot of time polishing, polishing, polishing," Pardo said. "We do get more time, but that's not where we do all the polish. We do the polish right from the beginning. It's a constant effort. You really have to have a culture of polish. It's something that everyone has to be brought into; it's something you really have to preach."

Pardo said Blizzard emphasizes the polish every step of the way--from design through production and beta testing, the company strives to make everything just right. And while he admitted a lot of the tweaks made are things that would almost never get noticed on their own, the sum of thousands of such tweaks creates the very noticeable polish on the end product.

I can easily imagine a scenario which goes against the idea of good project management, where you build an initial version of something, polish it, then decide that it has a fundamental problem and you scrap it. Many of the advances in software / game project management in the last decade or so involve selectively implementing fundamental parts or aspects of the game you're trying to make, for instance by building a prototype, in order to make sure those parts or aspects are as good as you hoped they would be before you pump another couple of million dollars into the project. If you don't, you will likely either go over your deadline and budget (a classical software development problem), or end up with a game that is not fun (a classical game development problem), or both. The key to this approach is to spend your effort on the most important part or aspect at every moment in your project. Premature polishing, like premature optimization, goes against this approach.

There are two exceptions I can see. First of all, a useful distinction can and must be made between the gameplay of a game and the overall end-user experience (this is sometimes reflected in the job descriptions of the game designer and producer, respectively). You can evaluate the gameplay, including controls and camera, using very simple boxes and placeholder art. But it's a lot harder to evaluate the end-user experience, for instance using early tests by non-developers, without a certain amount of audio-visual polish.

The second exception is that some people seem constitutionally incapable of judging the abstract. They will always reject clunky placeholder art, and will always be comforted by something that looks shippable, even if the former has rock-solid gameplay and the latter is deeply flawed under the hood. Often, the people who have the power to cancel your project or stop funding are of this kind. It doesn't necessarily mean they're stupid.

Although it can be irritating from a pure development point of view, it is practically unavoidable that you will polish something that you know you will throw away. It might be a demo for a publisher, for a trade show, for release on the internet, or all of the those. Instead of avoiding the issue or nursing reluctance, it's better to face the issue head-on, and really focus on the polishing, while at the same time making sure the negative effects on the final game are minimised.

Polishing a demo can have great advantages too:

• You are forcing your team to integrate their efforts. Effectively, you're doing a dry run of the end of your project. This will allow you to test your team, your processes and your technology under real-world conditions. Ship, celebrate, then do a post-mortem, identify your trouble spots, and fix them. You'll be much better prepared for the next big milestone.
• You will make a version of your game that can be evaluated directly, as opposed to in the abstract. Once you have a version of the game that is both playable and polished, you can get a huge amount of good feedback, and you are able to judge the gameplay much more accurately than from a document.
• A polished demo can get your project funded, or stop it from being cancelled. Polished demos won't help you make a good game if you're in an environment where glitz is rewarded over solid fundamentals, but on the other hand a cancelled game is no fun.

(Clayton Kauzlaric comments on visual polish when demoing to a publisher here.)

To come back to Mr. Pardo, I wonder how hard it was to create a culture of polish at Blizzard. I am not an expect on Blizzard's history, but I do remember very long development times and pretty big changes made late in development of several titles. Although it may seem ideal to ship a game 'when it's done', anyone who has ever worked on project that was going to ship 'next month' for a year knows how absolutely soul-destroying it can be. Asking people to give their all to attain a certain well-defined goal ('Get rid of this list of issues and make the game as good as you can by this date'), then repeatedly moving the goal posts is a guaranteed way of destroying morale. (I think it works if you do it once.) It is also counter-productive. If you have one month to do something, you will do it differently than if you have six months. (The corollary to that is: the thing you will do if you have six months will take seven months. But that's another story.) Moving the deadline in small steps will generate hack upon hack, slapped-on band-aid on top of slapped-on band-aid.

To sum up: Polishing is great (it's probably better to think of it as being end-user quality oriented). Making sure you can and will polish is crucial. But it is possible to pursue quality in a way that destroys morale, wastes resources and makes your game worse.

I don't know how Blizzard works. Maybe they have, or had, some of the problems listed above, maybe they didn't. It would be interesting to know.