Ein Release Candidate ist eine potentiell fertige Spielversion, die vor dem Gold Master intensiv getestet wird. Werden kritische Bugs gefunden, folgt der nächste Release Candidate – RC1, RC2, RC3 und so weiter, bis einer alle Tests besteht. Diese finale Testphase dauert typischerweise zwei bis acht Wochen und liegt zwischen Polishing und Gold Master. Der Begriff stammt aus der Software-Entwicklung und markiert den Moment, wo ein Team hofft, dass es endlich geschafft hat.
Release Candidates sind die finale Qualitätskontrolle vor dem Launch – die letzte Chance, kritische Fehler zu finden, bevor Millionen Spieler das Spiel in den Händen halten.
Was genau ist ein Release Candidate?
Ein Release Candidate ist der Moment in der Spieleentwicklung, wo man sich nicht mehr sicher ist, ob man noch einen Tag, eine Woche oder einen Monat braucht. Das Spiel könnte fertig sein – es könnte aber auch nicht fertig sein. Genau diese Unsicherheit definiert die Phase. Der Build ist potentiell release-bereit, aber das „potentiell“ trägt enormes Gewicht. Jeder im Studio weiß: Wenn dieser RC alle Tests besteht, wird er zum Gold Master und das Spiel geht in Produktion. Wenn nicht, beginnt alles von vorne.
Die Nummerierung der Release Candidates verrät oft mehr über den Zustand eines Projekts als jedes offizielle Statement. RC1 bedeutet Hoffnung. RC5 bedeutet, dass etwas grundlegend schiefläuft. Der letzte Release Candidate, der ohne kritische Bugs aus dem Testing kommt, wird zum Gold Master – das ist die eiserne Regel der Branche.
Wo liegt der Release Candidate in der Entwicklung?
Nach monatelangem Polishing und nachdem Content Complete längst erreicht wurde, kommt der Moment wo ein Studio den ersten Release Candidate erstellt. Alpha und Beta liegen Monate zurück, die großen Features sind implementiert, die Performance ist optimiert, die Assets sind final. Jetzt geht es nur noch darum zu beweisen, dass das Spiel wirklich fertig ist.
Diese Phase zwischen dem letzten Polishing-Tag und dem Gold Master ist typischerweise zwei bis acht Wochen lang, aber die Zeit fühlt sich anders an als der Rest der Entwicklung. Es ist nicht mehr „wir bauen etwas“, sondern „wir prüfen, ob das, was wir gebaut haben, hält“. Die Stimmung im Studio schwankt zwischen Erschöpfung und Hoffnung, zwischen „Endlich geschafft“ und „Was wenn wir noch einen kritischen Bug finden?“
Die Nummerierung: RC1, RC2, RC3…
Die Nummerierung der Release Candidates erzählt die Geschichte eines Teams, das gegen die Zeit und gegen Bugs kämpft. RC1 ist der erste Versuch, die Hoffnung, dass es beim ersten Mal klappt. Das Development-Team reicht den Build an QA weiter, an die Plattform-Betreiber bei Sony, Microsoft und Nintendo, und wartet. Das Testing dauert Tage, manchmal eine Woche. Und dann kommt die Nachricht: Crash beim Speichern. RC1 ist abgelehnt.
Also zurück an die Arbeit. Der Bug wird gefixt, ein neuer Build wird erstellt – RC2. Wieder testen, wieder warten. Diesmal kommt ein Audio-Bug in Level 5 zum Vorschein. RC2 ist abgelehnt.
RC3. Die Bugs sind behoben. Das QA-Team testet jeden Winkel des Spiels. Die Plattform-Zertifizierung läuft durch. Keine kritischen Probleme. RC3 wird zum Gold Master. Das Spiel ist offiziell fertig.
Wie viele Release Candidates normal sind, hängt von der Komplexität ab. Indie-Spiele schaffen es manchmal mit einem oder zwei Durchläufen. AA-Titel brauchen typischerweise zwei bis fünf. Bei AAA-Games mit Multi-Plattform-Support und komplexen Online-Features können es zehn oder mehr werden. Manche Projekte haben fünfzehn Release Candidates gesehen, bevor das Studio aufgab und verzögerte. Andere haben Glück und RC1 ist gleichzeitig der Gold Master – aber das ist selten genug, dass es im Studio gefeiert wird wie ein kleines Wunder.
Beta, Release Candidate, Gold Master – die Unterschiede
Die Begriffe klingen ähnlich und werden oft durcheinandergeworfen, aber sie markieren fundamental unterschiedliche Momente in der Entwicklung. Beta ist die Phase, wo das Spiel funktional komplett ist, aber noch aktiv daran gearbeitet wird. Bugs werden gesucht, Features werden getweakt, Performance wird optimiert. Die Beta kann Wochen oder Monate dauern, und große Änderungen sind noch möglich.
Der Release Candidate ist etwas anderes. Wenn ein Build zum RC erklärt wird, bedeutet das: Das Studio glaubt, es ist fertig. Die Frage ist nur noch, ob diese Einschätzung stimmt. Nur Bugfixes sind erlaubt, keine Features mehr. Das Testing ist nicht mehr explorativ wie in der Beta, sondern gezielt: Funktioniert alles? Sind alle kritischen Systeme stabil? Bestehen wir die Plattform-Zertifizierung? Die RC-Phase ist kürzer als Beta – zwei bis acht Wochen typischerweise – aber die Intensität ist höher. Jeder gefundene Bug ist potentiell der Grund für einen weiteren RC.
Gold Master ist der Moment, wo alle Fragen beantwortet sind. Das Spiel ist definitiv fertig, keine Änderungen mehr, keine Tests mehr. Der Build geht in Produktion, die Discs werden gepresst, die digitalen Stores werden beliefert. Es gibt nur einen Gold Master pro Release, aber es kann viele Release Candidates geben, bevor man dort ankommt.
Das Testing eines Release Candidates ist systematischer und gnadenloser als alles, was vorher kam. Das Ziel ist nicht mehr, Bugs zu finden und zu fixen – das Ziel ist herauszufinden, ob das Spiel wirklich release-bereit ist. Kann man es komplett durchspielen, ohne dass die Story abbricht, ohne Softlocks, ohne Game-Breaking-Bugs? Das QA-Team spielt jede Mission, jeden Pfad, jede mögliche Verzweigung durch. Sie versuchen aktiv, das Spiel zu brechen.
Performance ist der zweite kritische Bereich. Läuft das Spiel mit stabiler Frame-Rate auf allen Ziel-Plattformen? Gibt es Crashes beim Speichern oder Laden? Memory Leaks, die nach drei Stunden Spielzeit zum Problem werden? Ein AAA-Spiel, das auf PlayStation 5 mit 60 FPS läuft, muss auch auf der Xbox Series X stabil sein – und auf der Switch vielleicht mit 30 FPS, aber eben stabil. Jede Plattform wird separat getestet, jede kann ein RC ablehnen.
Dann kommt die Plattform-Compliance. Sony, Microsoft und Nintendo haben jeweils eigene Technical Requirements Checklists – hunderte von Punkten, die ein Spiel erfüllen muss. Controller-Unterstützung muss vollständig sein, alle Buttons müssen funktionieren. Achievements und Trophies müssen korrekt implementiert sein. Das Spiel muss das Suspend-Resume-Feature der Konsole unterstützen. Accessibility-Standards müssen erfüllt werden. Ein einziger Punkt auf dieser Liste, der nicht erfüllt ist, kann zur Ablehnung führen.
Localization ist oft die versteckte Zeitbombe. Das Spiel funktioniert perfekt auf Englisch – aber wie sieht es auf Deutsch aus, auf Französisch, auf Japanisch? Passen die Texte in die UI-Elemente, oder brechen sie aus den Boxen? Stimmt der Audio-Sync bei synchronisierten Cutscenes? Funktionieren alle Subtitles? Ein Spiel, das in zehn Sprachen erscheint, muss in allen zehn Sprachen getestet werden.
Und schließlich die Edge Cases – die extremen Situationen, die nur ein Bruchteil der Spieler erleben wird, aber die trotzdem funktionieren müssen. Was passiert, wenn jemand hundert Stunden spielt ohne das Spiel zu beenden? Was wenn das Inventar vollkommen voll ist und der Spieler versucht, noch mehr Items aufzuheben? Was wenn alle Nebenquests gleichzeitig aktiv sind? Was wenn mitten in einem Multiplayer-Match die Internet-Verbindung abbricht? Diese Szenarien werden alle getestet, weil sie alle passieren werden, sobald Millionen Spieler das Spiel in den Händen haben.
Wer testet eigentlich?
Das interne QA-Team ist die erste Verteidigungslinie. Diese Tester kennen das Spiel bereits aus den Beta-Phasen, aber jetzt wird es ernst. Vierzig bis achtzig Stunden investiert jede Person in den RC, spielt verschiedene Playstyles durch, dokumentiert jeden Bug minutiös. Sie wissen genau, wo die Schwachstellen liegen, welche Systeme in der Vergangenheit problematisch waren, wo man genauer hinschauen muss.
Parallel dazu geht der RC an die Plattform-Betreiber. Sony, Microsoft und Nintendo haben eigene Zertifizierungs-Teams, die jeden RC gegen ihre Standards prüfen. Das dauert ein bis drei Wochen pro RC – Zeit, die das Development-Team nutzt, um bekannte Issues zu fixen und sich auf mögliche Ablehnungen vorzubereiten. Wenn Sony grünes Licht gibt, aber Microsoft ablehnt, geht es zurück zu RC-Nummer-plus-eins.
Bei großen Publishern wie EA oder Ubisoft kommt noch eine dritte Schicht dazu: Publisher-QA. Die haben eigene Testing-Teams, eigene Standards, eigene Checklists. Sie überprüfen nicht nur technische Funktionalität, sondern auch Marketing-Aspekte – sind alle Trailer-Szenen im Spiel tatsächlich spielbar? Funktioniert die Localization in allen Ziel-Märkten? Gibt es irgendwelche kulturell sensiblen Inhalte, die Probleme bereiten könnten?
Manchmal werden auch ausgewählte Closed-Beta-Tester noch einmal herangezogen – vertrauenswürdige Community-Mitglieder unter NDA, die eine zusätzliche Perspektive bieten. Aber das ist die Ausnahme. Die RC-Phase ist üblicherweise komplett intern.
Die RC-Phase folgt einem vorhersehbaren, aber qualvollen Rhythmus. Montag morgen wird der erste Release Candidate erstellt und an alle Testing-Instanzen geschickt – internes QA, Plattform-Betreiber, Publisher-QA falls vorhanden. Die nächsten Tage verbringt das Development-Team in einem seltsamen Schwebezustand. Die Arbeit geht weiter, bekannte Minor Bugs werden gefixt, aber niemand weiß, ob das alles umsonst ist, weil vielleicht nächste Woche ein kritischer Bug gefunden wird, der alles über den Haufen wirft.
Nach einer Woche kommen die ersten Test-Reports zurück. QA hat einen Crash in Mission 5 gefunden – reproduzierbar, kritisch, RC1 ist abgelehnt. Das Team analysiert das Problem, findet die Ursache (ein Memory Leak in einem bestimmten Script), fixt es, und erstellt RC2. Wieder geht der Build raus, wieder beginnt das Warten.
RC2 läuft besser. Der Crash ist weg. Aber dann meldet sich die Localization-Abteilung: In der deutschen Version fehlt der Audio in einer wichtigen Cutscene. Nicht kritisch genug für eine sofortige Ablehnung, aber groß genug, dass es gefixt werden muss. RC2 ist abgelehnt.
RC3. Die dritte Iteration. Die Bugs aus RC1 und RC2 sind behoben. QA testet intensiv, findet kleinere Issues – ein Texture Pop-In hier, ein verzögerter Sound-Effekt da – aber nichts Kritisches. Diese kleinen Probleme werden dokumentiert für einen Day-One-Patch, denn dafür ist jetzt keine Zeit mehr. Ende der Woche kommt die Bestätigung: RC3 wird zu Gold Master. Das Team feiert, manche mit Erleichterung, manche mit Erschöpfung, und am nächsten Morgen beginnt die Arbeit am Day-One-Patch.
So läuft es im Idealfall – sechs Wochen, drei RCs, fertig. Aber es gibt Projekte, die bei RC10 sind und immer noch nicht durch. Es gibt Spiele, die bei RC7 abgebrochen wurden und um Monate verzögert. Die RC-Phase ist unvorhersehbar, weil man nie weiß, welche Bugs sich noch verstecken.
Was ist kritisch genug für eine Ablehnung?
Nicht jeder Bug tötet einen Release Candidate. Die Hierarchie ist klar, aber die Grenzfälle sind kompliziert. Crashes sind immer kritisch – ein Spiel, das abstürzt, kann nicht released werden. Softlocks ebenfalls – wenn ein Spieler in einer Mission feststeckt und nicht weitermachen kann, ist das game-breaking. Corruption von Speicherdaten ist vielleicht das Schlimmste von allem: Spieler verlieren dutzende Stunden Fortschritt, und das wird nie vergeben. Wenn ein RC auch nur einen reproduzierbaren Corruption-Bug hat, ist er sofort abgelehnt.
Dann gibt es die Major Bugs, die Grauzone. Ein schwerer Grafik-Bug, wo Spieler durch die Welt fallen können? Wahrscheinlich kritisch. Ein Audio-Bug, wo wichtige Dialog-Zeilen fehlen? Kommt drauf an – in einer Story-fokussierten Cutscene ja, in einem nebensächlichen Ambiente-Sound vielleicht nicht. Performance-Issues unter zwanzig FPS? Definitiv ein Problem, aber wenn es nur in einem einzigen, seltenen Scenario auftritt, wird es vielleicht für den Day-One-Patch aufgehoben. Online-Features, die nicht funktionieren? Bei einem Multiplayer-Spiel ist das kritisch. Bei einem Single-Player-Spiel mit optionalem Multiplayer-Modus vielleicht weniger.
Die Minor Bugs sind die, die durchgehen. Texture Pop-In ist ärgerlich, aber nicht game-breaking. Ein UI-Button mit falschem Text kann gepatcht werden. Ein verzögerter Sound-Effekt stört, aber verhindert nicht das Spielen. Diese Bugs werden alle dokumentiert, priorisiert für Post-Launch-Patches, aber sie halten den RC nicht auf. Die Entscheidung, was kritisch ist und was nicht, liegt letztlich beim Studio-Management in Absprache mit QA-Lead und den Plattform-Betreibern. Und manchmal wird diese Entscheidung politisch – ein Bug wird als „nicht kritisch genug“ eingestuft, weil eine weitere Verzögerung finanziell untragbar wäre. Das sind die Momente, wo Cyberpunk 2077 passiert. ✅ UI-Issues – Button-Text falsch ✅ Kleine Audio-Bugs – Sound verzögert ✅ Balancing – Waffe zu stark
Minor Bugs werden notiert für Day-One-Patch oder spätere Updates.
Die Geschichte von The Last of Us Part II ist die Geschichte eines Studios, das keine Kompromisse macht. Naughty Dog verzögerte das Spiel mehrfach, weil RC nach RC nicht den eigenen Standards genügte. Das Team testete rigoros, RCs wurden abgelehnt, Bugs wurden gefixt, neue RCs wurden erstellt. Als das Spiel schließlich erschien, war es technisch fast perfekt – ein Beweis dafür, dass die RC-Phase funktioniert, wenn man sie ernst nimmt. Aber der Preis war hoch: Monate von Crunch, Veteranen verließen das Studio, das Team war ausgebrannt.
Red Dead Redemption 2 ist ein ähnlicher Fall. Rockstar Games verzögerte zweimal, nahm sich Monate extra für die RC-Phase. Das Resultat war ein beeindruckend poliertes Spiel, aber vermutlich viele abgelehnte Release Candidates auf dem Weg dorthin. Rockstar ist bekannt dafür, Perfektion über Deadlines zu stellen – was großartige Spiele produziert, aber auch eine Crunch-Kultur kreiert.
Dann gibt es Cyberpunk 2077, das Gegenbeispiel. CD Projekt RED stand unter enormem Druck – finanziell, von Investoren, von der Community. Die RC-Phase war vermutlich zu kurz, Management-Druck führte wahrscheinlich dazu, dass RCs durchgewunken wurden, die hätten abgelehnt werden sollen. Das Ergebnis war ein katastrophaler Launch, besonders auf Last-Gen-Konsolen. Die PlayStation-Version war so buggy, dass Sony das Spiel temporär aus dem Store nahm. Das ist der Beweis: Einen RC zu früh zu Gold Master zu erklären, kostet mehr als eine Verzögerung jemals kosten würde.
No Man’s Sky ist der dritte Lehrfall. Hello Games unter Zeitdruck, eine viel zu kurze RC-Phase, und eine Launch-Version, die definitiv nicht release-ready war. Viele versprochene Features fehlten, Bugs waren überall. Es dauerte Jahre von Updates, um das Spiel in einen akzeptablen Zustand zu bringen. Die Lehre: Ein RC sollte nur zu Gold Master werden, wenn er wirklich, definitiv fertig ist – nicht wenn der Release-Termin es verlangt.
Wenn Gold Master doch nicht Gold ist
Normalerweise ist Gold Master final – die Entscheidung steht, das Spiel geht in Produktion, es gibt kein Zurück. Aber es gab seltene, peinliche Ausnahmen. Gran Turismo 5 verkündete 2010 „Gone Gold“, wurde dann aber doch noch verzögert. Möglicherweise wurde ein letzter RC nach der Gold-Ankündigung abgelehnt, oder das Management musste zurückrudern. Sehr ungewöhnlich und ein PR-Desaster.
Cyberpunk 2077 hatte denselben Fehler – „Gone Gold“ im Oktober angekündigt, dann doch verzögert auf Dezember. Entweder wurde Gold Master zu früh ausgerufen, oder Management überstimmte eine RC-Ablehnung für die Ankündigung und musste dann doch zurück. Diese Fälle zeigen: Die RC-zu-Gold-Entscheidung ist manchmal politisch, nicht nur technisch. Und das ist ein Problem.
Unterschiede zwischen Studio-Größen
Bei AAA-Studios wie Rockstar, Naughty Dog oder Nintendo läuft die RC-Phase anders als bei kleineren Teams. Diese Studios haben die Ressourcen für fünf bis zehn oder mehr Release Candidates, Monate für Testing, kein Budget-Druck der einen RC durchwinken lässt. Sie können sich leisten, Perfektion über Deadlines zu stellen. Das produziert bessere Spiele, aber oft durch Crunch erkauft.
AA-Studios wie Focus Entertainment oder Devolver Digital haben weniger Luxus. Zwei bis fünf Release Candidates, drei bis sechs Wochen Testing, und dann muss es raus. Die Balance zwischen Qualität und Deadline ist enger. Solides Testing ist möglich, aber nicht endlos.
Indie-Studios arbeiten oft komplett anders. Ein oder zwei RCs, ein bis drei Wochen Testing, limitierte QA-Ressourcen. Viele nutzen Early Access statt formeller RC-Phase – die Community testet, Bugs werden gemeldet und gefixt, und irgendwann kommt Version 1.0. Es ist eine andere Philosophie, aber für kleine Teams oft die einzige praktikable.
Live-Service-Games bei Entwicklern wie Epic Games (Fortnite), Bungie (Destiny) oder HoYoverse (Genshin Impact) haben kontinuierliche Release Candidates für jedes Update. Schnelle Iterationen, oft nur Tage statt Wochen, automatisiertes Testing wo möglich. Der Druck ist anders – nicht ein großer Launch, sondern dutzende kleinere Releases pro Jahr. Und wenn ein Bug durchrutscht, kann er gepatcht werden, ohne Discs neu zu pressen.
Die RC-Phase hat sich in den letzten Jahren durch Automatisierung verändert. Moderne Studios nutzen Unit Tests, die einzelne Code-Funktionen bei jedem Build prüfen und Regressions-Bugs sofort fangen. Integration Tests checken das Zusammenspiel komplexer Systeme. Performance Tests messen Frame-Rates automatisch, erkennen Memory Leaks, tracken Ladezeiten. Und Smoke Tests – die schnellsten von allen – beantworten innerhalb von Minuten die Basisfrage: Startet das Spiel überhaupt?
Der Vorteil dieser Automatisierung ist offensichtlich. Ein RC1 mit einem offensichtlichen, systematischen Problem wird innerhalb von Stunden gefunden, nicht erst nach einer Woche manuelles Testing. Das spart Zeit, Geld und Nerven. Aber Automatisierung hat Grenzen. Kein automated Test findet ein „Feel“-Problem – wenn eine Waffe sich nicht richtig anfühlt, wenn ein Jump nicht responsiv genug ist, wenn das Pacing eines Levels nicht stimmt. Edge Cases sind schwer zu automatisieren. Und manche Bugs zeigen sich nur unter spezifischen, unvorhersehbaren Umständen, die kein Test-Script abdeckt. Deshalb bleibt manuelles Testing essentiell, selbst in hochautomatisierten Studios.
Crunch in der RC-Phase
Die RC-Phase ist berüchtigt für Crunch, und die Gründe sind systemisch. Das Release-Datum steht fest, öffentlich angekündigt, Marketing-Kampagnen laufen, Retail-Slots sind gebucht. Eine Verschiebung kostet Millionen. Wenn RC2 abgelehnt wird, arbeitet das Team Überstunden für RC3. Wenn RC3 abgelehnt wird, arbeitet das Team noch mehr Überstunden für RC4. Die Mentalität ist: „Nur noch ein Bug, dann sind wir durch.“ Aber ein Bug wird zu drei, drei werden zu zehn, und plötzlich sind es achtzig bis hundert Stunden pro Woche über Wochen.
Management-Druck verschlimmert es. Produktions-Leiter sagen: „Wir müssen diesen RC akzeptieren, wir können nicht mehr verzögern.“ QA-Teams werden unter Druck gesetzt, Bugs als „nicht kritisch genug“ einzustufen. Entwickler werden emotional erpresst: „Willst du, dass das Spiel scheitert?“ Die Kombination aus fester Deadline, endlosen Bugs und Management-Druck führt zu Team-Burnout, Gesundheitsproblemen und hoher Fluktuationsrate nach Release.
Studios wie Insomniac Games zeigen, dass es anders geht. Realistische Planung, Buffer-Zeit, und die Bereitschaft, Features zu streichen statt das Team zu crunchen. Aber Insomniac ist die Ausnahme, nicht die Regel. Die RC-Phase bleibt eine der härtesten Perioden in der Spieleentwicklung.
Studios wie Insomniac Games zeigen: RC-Phase kann ohne Crunch funktionieren – mit guter Planung.
Fazit: Der Release Candidate als Qualitäts-Gatekeeper
Fazit: Die letzte Hürde vor dem Release
Ein Release Candidate ist die letzte formelle Qualitätskontrolle vor dem Launch – der Moment, wo ein Studio hofft, aber nicht sicher ist. Es ist ein potentiell fertiger Build, der durch intensives Testing gehen muss, und wenn er scheitert, beginnt der Prozess von vorne. RC1, RC2, RC3 und so weiter, bis einer ohne kritische Bugs durchkommt und zum Gold Master wird. Diese Phase dauert zwei bis acht Wochen, manchmal länger, und sie ist entscheidend für die Launch-Qualität.
Was ein Release Candidate nicht ist: eine Garantie, eine Formalität, etwas Optionales. RCs werden ernsthaft getestet, ernsthaft abgelehnt wenn nötig, und die Studios, die diesen Prozess respektieren, liefern polierte Launches. Red Dead Redemption 2 und The Last of Us Part II sind Beispiele dafür – Spiele, wo die RC-Phase funktioniert hat, auch wenn sie Monate gedauert hat. Auf der anderen Seite stehen Cyberpunk 2077 und No Man’s Sky – Spiele, wo RCs offensichtlich durchgewunken wurden, weil die Deadline wichtiger war als die Qualität.
Der Unterschied zwischen diesen Outcomes ist nicht technisch, sondern organisatorisch. Ein Release Candidate ist nur so gut wie die Disziplin, ihn abzulehnen wenn nötig – auch unter massivem Druck von Management, Investoren, Community. Studios, die diese Disziplin haben, releasen bessere Spiele. Studios, die sie nicht haben, zahlen den Preis in schlechten Reviews, refunds und zerstörter Reputation.
Als Industrie verdient die RC-Phase mehr Respekt. Sie ist der Moment, wo Qualität über Deadline siegen sollte, wo technische Standards vor Marketing-Timelines kommen sollten. Und als Spieler sollten wir Verzögerungen feiern, wenn ein Studio sagt „der RC ist noch nicht bereit“. Das ist kein Scheitern – das ist verantwortungsvolle Entwicklung.
