Design goals for Alpha, Beta, and Final versions?

[timfire]

As I work on my first draft for my new game, I was wondering what should be my goals for each phase of my design? What am I trying to accomplish with each phase, what should be included in each phase, and what should I not worry about?

First, I'm assuming 3 phases before production: Alpha>Beta>Final (>Production). Is this the model most people use? I realize that each phase will be edited/revised a number of times before moving onto the next phase.

This is what I think goes into each phase:

Alpha: Just try to get everything down on paper. Make sure the basic Premise/concept is clear, but don't worry about having a fully developed setting/characters/system/color/situation.

Beta: Decide if the game plays the way you want it to, and whether or not certain systems support the Premise. Make sure the Premise, as well as setting/characters/system/color/situation are fully developed.

Final: Tweak any gameplay/balance issues. Write the text, add art and layout.

[Clinton R. Nixon]

Tim,

I think you're on the right track here. I've got an alternative model for you, though, that I've found useful when writing my newest game.

Alpha: Write the whole game. I'm not saying to write an incredibly detailed game that will take a long while, but write everything you need to play. This should take 2-4 weeks, max. (It took two on my alpha version.) Play this game a few times: it will be broken.

Beta: Take what you learned from your alpha play and re-write the game as it should be. Neat mechanics in your head don't often work out that way in play, and you'll have to re-jigger them. This should take the longest of all. I've spent a year on it now, although there's been long swaths of doing nothing on it at all.

Final: After it's written, and playtested more, with only minor changes, do the layout and be done with it.

[Valamir]

For me, I treat Alpha as a "proof of concept" stage.

Pretty much everything in there should be entirely up for grabs at that point.  The primary purpose of an Alpha is to get as much as you need to actually play the game down.  I'll caveat Clinton's remark a little (he may have meant this himself) by emphasising "as much as YOU need to play the game".  This doesn't have to be every detail that someone else might need, although it should at least be intelligible to others if you're hoping for feedback.

The point to the Alpha is to make sure the game EXPERIENCE in play delivers the actual experience you want.  Search and handling time is a key thing to observe.  Cool modifiers and rule tweaks have a way of blossoming during the writing stage.  Making sure they are actually useable in play at the pace of play you're shooting for is important.


Beta I think comes in two parts.  Early Beta is where you confirm that the changes you made after the Alpha actually worked.  If not, it becomes a second Alpha and you try again.  Late Beta is where you do the final tweaks and balancing and judging whether the modifier should really be +3 instead of +2 and things like that.

For Late Beta you want 2 things.  1) rules that are pretty close (at least 80%) of their final text, and 2) people not you running games and giving you feedback.

Then you have a last stage of tweaking and adjusting before sending it for proof and layout.  If you wind up doing more than just tweaking and adjusting you probably need to go back to late beta...though production schedules (if working against a desired release date) often preclude this, which is why so many games wind up with errata shortly after release.

[Jack Aidley]

What are the different versions for? Why attach names to them at all?

Questions I feel need answering; and in answering them I suspect you'll answer your own question.

I don't like the names Alpha, Beta and Final. Partly because of the association with my Games Programmer days; mostly because they tell me nothing about what the release is supposed to be.

With Great Ork Gods, I'm currently finishing off what I'm calling a 'playtest version'. It's clear then what I need; I need enough that I can give it to folks and have them playtest from it.

After that I might produce a 'proof reading' version to give to a few enthusiast to check over before my 'final' version.

[Valamir]

Well, technically, Alpha and Beta ARE just playtest versions.  So no real confusion there.

I like the terms to differentiate different stages in the process for 2 reasons.

1) Benefit of the reader.  Most gamers are familiar enough with stages of computer publishing to know that something that says "Alpha" is a long way from being released and expect it to be very buggy and subject to change.  "Beta" on the other hand indicates something much closer to release and much closer to the final form.  Its still likely to be buggy but there should be a viable fun and almost complete game visible underneath all the final tweaking.

2) Benefit of me.  A newly learned (or rather oldly learned and newly appreciated) rule for me is "if it says Alpha, nothing is carved in stone yet".  A simple reminder that all or part of it may turn out to be crap that needs changed, or good stuff that needs changed anyway.  When I slap a "beta" label on it, that's me telling myself "almost ready for prime time".


YMMV of course, as to the utility you get out the differentiation.  I find it useful, but its hardly required.

[Clinton R. Nixon]

For me, I treat Alpha as a "proof of concept" stage.

Pretty much everything in there should be entirely up for grabs at that point.  The primary purpose of an Alpha is to get as much as you need to actually play the game down.  I'll caveat Clinton's remark a little (he may have meant this himself) by emphasising "as much as YOU need to play the game".  This doesn't have to be every detail that someone else might need, although it should at least be intelligible to others if you're hoping for feedback.

Ralph's right. What I meant, more succinctly is this: Alpha = your playtest version; Beta = playtest version for others. Both forms of feedback are necessary, and I think the concept of cleaning it up as much as you can, then sending it to others works very well.

[Alex Johnson]

Alpha = your playtest version; Beta = playtest version for others.

To use another computer software naming convention, I prefer to substitute D and RC and use integer versions rather than "dot" versions.  Often I see Alpha 0.1, Beta 0.95, Game v0.9.3.24beta....  My way is Game D1 and Game RC3.  Where D stands for Development [version] and RC stands for Release Candidate.  They still have the same meanings as Alpha and Beta, namely that D1, D2, D3... are for incomplete versions and private testing while RC1, RC2, RC3... are for complete versions sent out for public testing and tweaking.

Of course in reality, I seldom number the products either way.  I usually dedicate the first page of the document to the project goals and revision history, where I will list revisions by month/year with an explanation next to each.

[timfire]

I only asked about Alpha/Beta because I had heard others use it, and assumed it was the standard model.

Alpha = your playtest version; Beta = playtest version for others. Both forms of feedback are necessary, and I think the concept of cleaning it up as much as you can, then sending it to others works very well.

Thanks alot, that idea is extremely helpful.

I usually dedicate the first page of the document to the project goals and revision history, where I will list revisions by month/year with an explanation next to each.

I had already started a "goals" section, but reading your post I think a
"revisions" section might be helpful as well. Thanks.