Das ist schonmal eine gute Idee Das es Testreleases wie Gamma-Epsilon gibt wusste ich noch nicht. Ich dachte ich ergänze das mal hier, da ich sowas irgendwann mal im Internet gesucht hatte (Am Ende noch eine Ergänzung aus eigener Erfahrung):

Eine Software-Anwendung durchläuft parallel zum Entwicklungszyklus einen Testzyklus mit verschiedenen Phasen, die den Enwicklungsstand einer Anwendung widerspiegeln.

Prototyp
Der Prototyp ist die erste Version einer Anwendung. Bei der Überprüfung stehen hauptsächlich konzeptionelle Fragen im Vordergrund. In diesem Stadium wird überprüft, inwieweit die im Pflichtenheft festgelegten Vorgaben umgesetzt wurden und ob diese Vorgaben noch einmal überdacht, überarbeitet oder optimiert werden sollten. Inwieweit ist das Interface-Design der anvisierten Zielgruppe angemessen, in welchem Bereich ist es verbesserungswürdig, wie kann eine Optimierung aussehen?

Test Release(s) (TR)
Bei den Test Releases handelt es sich um die zum Testen freigegebenen "Zwischenversionen" des Produkts. Umfang und Intensität der Testläufe an dieser Stelle sind produkt- und konzeptionsabhängig. Zu Beginn jedes TR-Tests findet ein First Check statt. Es wird angenommen, dass verschiedene Programmabbruchtypen zu diesem Zeitpunkt noch üblich sind. Die Grundfunktionen des Programms laufen nicht stabil. Entsprechende Testergebnisse können noch zu verbessernden Umstrukturierungen führen.

Alpha-Version
In der Alpha-Testphase des Softwaretestens sollten die Grundfunktionen des Programms bereits reibungslos ablaufen, d.h., die Haupt-Programmierung sollte aus der Sicht der Entwickler abgeschlossen sein. Diese Testreihe umfasst meist eine globale Funktions- und Systemanalyse und deckt in der Regel noch diverse Fehler auf.

Beta-Version
In der Beta-Testphase müssen die Fehler, die das Produkt in der Alpha-Phase noch beeinträchtigt haben, komplett behoben sein: spätestens ab dieser Phase sollten z. B. keine Programmabstürze mehr vorkommen. Außerdem dürfen zu diesem Zeitpunkt keine groben oder mittleren Funktionsstörungen im Programmablauf mehr auftreten. In dieser Testphase wird verstärkt die Anwender-Perspektive eingenommen.

Release Candidate (RC)
In der letzten Phase der Produktentwicklung, in der das Produkt kurz vor Produktionsfreigabe steht, wird der Release Candidate getestet. Hierbei handelt es sich immer um einen potenziellen Golden Master.
Das Testen des RC, auch Master-Test genannt, stellt insofern den Testabschluss einer Produktentwicklung dar, als die Software produktionsreif vorliegen soll und daraufhin überprüft wird.

Golden Master
Der Golden Master ist die CD-ROM oder DVD, die zur Vervielfältigung an das Presswerk geschickt wird und somit der letzte Schritt vor der Publikation ist.

[Quelle: Mediavision]


Als Ergänzung dazu kenne ich noch das "Final-Release", was bei Projekten die als Bezeichnung verwendet wird, die nicht gepresst werden bzw. nur Online vertrieben werden. Und vor dem Prototyp gibt es eigentlich noch einen Vorgang den man "Design" nennt, bei dem so eine Art Storyboard für die Programmierung zeichnet/schreibt (UML-Design, Software- bzw. Gamedesign, nicht zu verwechseln mit der Story des Spiels)

Zwischen "Beta" und "Release" Kandidaten kenne ich noch das "Pre-Release" welches bei kostenlosen Spielen meistens an alle zum testen freigegeben wird.

Für den Stand der Software nehmen viele das Versionssystem. Bei den meisten Projekten sieht man, dass Version 1.0 100% aller Grundfeatures implementiert und so eine Art "First Final" oder "Release Candidate" (RC) ist. Versionsnummern von 0.1 bis 0.9999... geben dann so ungefähr den prozentualen Stand der Dinge an wie weit es ist zur fertigen Software. Versionen über 1.0, also 1.1, 1.2, ... geben dann an ob neue Extrafeatures implementiert wurden sind (Patches, New Releases, ...)
Aber gibt auch viele die ihre Produktion der Software bei v1.0 beginnen und dann hochgehen, gibt eben verschiedene Arten.

Öhm. Der erste Post ist völlig erfunden, eh?
Es gibt keine Delta-, Epsilon- und Omega- oder Wasweißichnoch-Stadien. Und du meinst, dass man in der Alpha die 'Zero'-Version verbessern sollte - die allerdings aus einer Testmap und einem Testchar besteht, wenn man deiner Anweisung folgt. Also hat man dann am Ende einen Raum und einen Char mit toller Grafik. O_o

Ähmja. Man sollte deinen Anweisungen lieber NICHT folgen - man sollte nämlich weder Alphas noch Betas veröffentlichen sondern nur das fertige Produkt. Eventuell eine Demo. Eine Demo ist allerdings ein TEIL des fertigen Spiels - keine inkomplette, verbuggte Vorabversion, sondern ein fertiges Kapitel des Endprodukts.

surfmastas Version klingt da wesentlich plausibler.

@BassDriver6000

dein schema mit bugs und glitches können nur in den
quellcode eines programmes sein.

sagen wir mal gothic3

nein aber jetzt mal echt.
bei einen rpgmaker projekt kann man höchstens
sachen vergessen,das sind aber dann keine richtigen bugs

wie gesagt nur im quellcode können "richtige" Bugs
enthalten sein.

Ich habe fertig.
Au revoir

jo, bei der versionierung eines spiels/programmes gibt es eben die frei wahl, man kann eben sogar nen eigenes system entwickeln um sich so zu organisieren. man kann auch noch weiter gehen und alpha,beta,gamma,...,chi,psi,omega als version nehmen. gibt ja einige die ihre sub-releases auch mit buchstaben kennzeichnen (also keine neuen features, nur bugfixes) wie z.b. 1.2a, 1.2b, 1.2c, ... oder was man oft sieht 1.5_rc1, 1.5_rc2, 1.5_rc3, ... (wobei das rc fuer Release Candidate steht, also ein Release der Version 1.5 schon draussen ist und mit eingespielten Patch nochmal released wurde).

Mir persönlich gefällt das System von 0.1, ..., 0.99... wobei die Nachkommastellen im ungefähren die Fertigstellung in Prozent angeben. Also kann man schon sehen wann ein Spiel volle Funktionalität erlangt (Version 1.0) und wieviel neue Extra-Features/Patches dannach implementiert wurden (1.1, 1.13, ...)
Also z.b. 1% = 0.1, 2% = 0.2, 3% = 0.3, ..., 99% = 0.99, 100% = 1.0
Dann kann man nen "b" ranhauen um die Version zum testen an ausgewählte Leute zu geben, z.b. 0.4b
Wenn man dann ein Release macht, dann z.b. 0.6rc

Naja, jedem das seine :-)))

PS.: Sieht ja aus wie nen Mathe-Posting, *lol*

@ omg_a_sana

Die Stadien die er aufgelistet hat sind denke ich mal von jedem selbst frei definierbar. Ich zum Beispiel gehe beim erstellen von Grafiken auch immer nach solch einer Liste, welche aus selbst gewählten Bezeichnungen und Ziffern besteht.

@ BassDriver6000

Solch eine Liste muss meiner Meinung nach viel ausführlicher sein und dem Leser ein paar genauere Vorgehensweisen und Kniffe zeigen, insbesondere was die Handlung eines Spieles angeht, weil hier schon viele scheitern. Oft kommt es dazu das Leute einen Grundbaustein ihrer Geschichte haben und einfach drauf los arbeiten, ohne genau zu wissen wie, wo und was überhaupt noch passiert. Desweiteren ändern sie während der Produktion ihres Spieles immer wieder die Story, weil da mal etwas nicht makellos ist, da etwas besser sein könnte und und und. Deshalb solltest meiner Meinung nach noch den Punkt "Gamma" unter "Construction" einordnen, damit das ( noch unvollständige / mangelhafte ) Wissen hinter der Geschichte nicht dem Scripten/Coden in die Quere kommt.

<M.>