Verfasst von Jessica Mulligan:
In der Entwicklungs-Section auf der Webseite, diskutierten wir kürzlich Änderungen, die wir an den Respawn Raten und Wander/Patrol-Zonen einiger Named Kreaturen vornehmen wollten. Einige von euch fragten, warum es bis zu 6 Wochen dauern würde, diese Änderungen in das Spiel einzubauen, obwohl sie doch aussehen als wären sie, nunja, einfach zu machen.
Ich dachte mir daher, es wäre eine gute Idee, diesen kompletten Prozess mal in allgemeinen Schritten zu diskutieren. Dies passt momentan besonders gut, da wir gerade daran arbeiten die Patchnotes für den letzten Frühjahrsputz-Patch vorbereiten, welcher ein sehr großer werden wird (intern sind es nahezu 35 Seiten mit Elementen des Patches, wir werden das noch irgendwie kürzen bevor wirs veröffentlichen
).
Euch wird vielleicht aufgefallen sein, das unsere kürzlichen Patches wesentlich stabiler waren und weit weniger neue Bugs einbrachten. Ich schreibe das im wesentlichen 3 Dingen zu: wir haben eine verdammt gute Test-Abteilung; geben der Test-Abteilung volle Kontrolle Ja oder Nein zu einem Patch zu sagen, und; der spezielle Test-Prozess dem sie folgen um die Patches zu testen.
Wie auch immer, die Qualitätskontrolle der Patches beginnt bereits wesentlich früher, bevor wir der Test Abteilung den Patch zur Prüfung geben. Wenn wir uns entschließen, eine Änderung an einem bestehenden Feature oder System vorzunehmen, beispielsweise das Monster-Verhalten, und nicht in einer kritischen Situation stecken (beispielsweise bei einem Crash-Bug), sieht der Prozess in etwa folgendermassen aus:
1. Diskutieren der Änderungen und Schreiben von spezifischen internen Dokumenten
2. vorgeschlagene Änderungen werden in den "In Überlegung" oder "In Entwicklung" Bereich für Spieler Feedback gestellt
3. Diskutieren des Spieler Feedbacks und Einfügen notwendiger Änderungen, dann erneutes Veröffentlichen falls etwas geändert wurde
4. Spezifikationen werden durch die Leitung abgesegnet
5. Plazieren der Punkte auf dem Arbeitszeitplan und Zuweisen von Programmierern, um die Arbeit zu erledigen
6. Nach Abschluss der Arbeit, weiterleiten des Codes an die Test-Abteilung
7. Bereinigen von gemeldeten Bugs, anschliessend geht alles wieder an die Test-Abteilung
8. Sobald die Änderungen als stabil bezeichnet werden können, Aufspielen des Codes auf den ATS Test-Server
9. Ausführen weiterer Debug- und Testprozesse
10. der "Weiße Handschuhtest" der Änderungen
11. "OK" der Test-Abteilung
12. Zuweisen der Punkte zu einem angesetzten Patch
13. Finaler Test des ganzen Patches
14. Hinzufügen des Codes auf die Server
15. Start des Patches
Wie ihr seht, kann sogar eine kleine Änderung eine bedeutende Zeitspanne benötigen, um den gesamten Prozess zu durchlaufen. Wenn wir über einen reinen Bugfix von einfacher oder mittlerer Schwere reden kann der Prozess etwas abgekürzt werden, abhängig vom Bug, aber der Test/Debug/Retest-Kreislauf bleibt derselbe. Die minimal benötigte Zeit vom Start bis zum Ende eines solchen Prozesses beträgt in etwa 2 Wochen, aber nur wenn wir bereit sind, einige der Testkreisläufe auszulassen und ein bedeutendes Risiko eingehen, Bugs zu übersehen. Wir versuchen das zu vermeiden.
Schritt 13 benötigt im Normalfall mehr Zeit denn wenn der Code zu einem existierenden Patch hinzugefügt wird, muss die Integrität des Ganzen überprüft werden, da man nicht immer weis, ob und wie sich eine Änderung auf den anderen Code auswirkt. Wenn Mehrfachbugs auftreten und einige Zeit benötigen um gefunden und gefixt zu werden, dauert die gesamte Aufgabe länger. Wenn es etwas ist, das einen sorgfältigen Check bezüglich des Gameplay Balancings benötigt, brauchen die Tester noch länger um so viele mögliche Varianten durchzuspielen wie sie können.
Es gibt einen Grund für all das Zeitraubende: Qualitätskontrolle. Die ganze Idee des kompletten Testkreislaufs mit mehrfachen Testläufen besteht darin, das Risiko zu reduzieren, neue Bugs oder nicht ausbalancierte Features in einen Patch einzubauen. Sicherlich könnten wir recht einfach die Zeit verkürzen, dies wäre aber nur möglich wenn man riskiert, einen Bug oder ein Balanceproblem zu übersehen. Wenn das passiert, kommen wir in die Situation, einen Notfallpatch einbauen zu müssen und wir alle wissen wie aufregend das sein kann.
Wir schliessen diese Notfallpatches daher als Option lieber aus,
. Ab und zu werden sie natürlich nötig sein, niemand ist schliesslich perfekt und MMOs gehören zu den kompliziertesten Zusammenstellungen von Anwendungen die ihr jemals sehen werdet. Das ist jedoch kein Grund, sein Schicksal herauszufordern, indem man Patches mit der Tür ins Haus fallen lässt, bevor sie fertig sind.
Dies ist die Nußschalen-Version des Prozesses. Ich bin sicher, das ihr Fragen haben werdet, wir werden soviele beantworten wie wir können.
-------------------------------
Gar nicht so einfach, aber ich habs einfach mal versucht
Gruß Sorenal
