One of my clients recently complained to me that a developer he had contracted was planning to deliver an Alpha milestone but that it would not be composed of final art. When I told my client that it was common for Alpha builds to have some amount of placeholder art, he replied, “I spoke to several people in the game industry, and I was told that an Alpha is essentially the game minus possibly a few features and is not bug free, but the gameplay and final art are there.”

I tried explaining to my client that, regardless of what others may have told him, he was confusing the Alpha milestone with a Beta milestone. Unfortunately, the most authoritative reference to which I immediately could think of directing him was Wikipedia:

Alpha is the stage when key gameplay functionality is implemented, and assets are partially finished.
Beta is feature and asset complete version of the game, when only bugs are being fixed.

“Assets”, I further explained, were the game’s text, audio, and, yes, art. So an Alpha milestone is comprised of art that is only partially finished.

But what does “partially finished” mean? Generally, when I am negotiating milestone definitions with a developer, we specify the percentage of art that may be placeholder (temporary assets taking the place of actual artwork until it is finalized). For example, an Alpha might be permitted to be composed of 50% placeholder art, while a Beta might required to have no more than 90% placeholder art.

However, I do like to have some artwork completed and approved well before the Alpha is due, so I usually specify an early milestone composed of final or near-final artwork early in the production so that the game’s art style and quality can be nailed down before art production begins in force.

Then there is the question of what “key gameplay functionality” means: what’s key, and what are the minor details that do not need to be implemented until Beta? Certainly the main game engine should be operational by Alpha (if not before), whereas it may be no big deal if one of the hidden bonuses in level 99 is not implemented until Beta. But there might be dozens of features in between about whether a publisher and developer may honestly disagree are key.

Ideally this should be determined up front, but usually many game features are not even determined until a preproduction phase that does not even being until after the contract is signed. However, a detailed milestone delivery schedule should be mutually agreed upon long before the milestone is to be delivered. Few things can sour a development relationship more than ambiguity or disagreement about what a developer is supposed to be delivered when a developer needs to get paid for that delivery to meet his payroll.

Another questions is “what does ‘implemented’ mean?” Does it mean that the developer only need to make a first pass implementation of a feature, or does it need to be fully debugged? To answer this question, I often have my milestone definitions specify the degree of “bugginess” that is permitted in a milestone. I categorize bugs as follows:

• A: Renders the game or feature inoperational
• B: Everything not classified as A or C
• C: Purely cosmetic bugs

I may then specify that an Alpha milestone can have no A Category bugs, and that a Beta Milestone may have no A Category Bugs and only a specific number of B or C Category bugs.

Of course, how strict you make your milestone definitions will vary upon the needs of the individual project. What matters is deciding upon mutually agreeable definitions with your developer before you sign your contract.