Der Tag ist also gekommen: Das neue Feature kann endlich online gehen und ist allen Usern zugänglich! Es hat einen weiten Weg hinter sich gebracht und doch ist die Mühe und Arbeit damit noch nicht beendet, denn nun steigt die Spannung: Verhält sich auch beim Ansturm der Usermassen alles wie geplant? Was passiert, wenn sich ein User vor lauter Kreativität und Spielfreude nicht so verhält, wie es die Entwickler vorhergesehen hatten? Stimmt die Balance der einzelnen Faktoren? Manchmal steckt der Teufel im Detail.

Auch die User erwarten am Tag eines Updates das neue Feature voller Spannung und stürmen das Spiel, sobald es wieder freigegeben ist. Erste Taktiken, Meinungen und Rückmeldungen im Forum und bei den Supportern lassen nicht lange auf sich warten. So weiß man direkt, wie das Feature bei den Spielern ankommt.

Jetzt sind der Support und unser QA-Admin gefragt, Rückmeldungen zu sammeln, zu sortieren und aufzubereiten.

Alles, was trotz langer Testphase und Entwicklungszeit im Livebetrieb noch nicht passt, wird durch den QA-Admin direkt an die Entwickler gemeldet, die sich dann schnellstmöglich um eine Behebung und Lösung der Probleme kümmern. Gelegentlich kann es natürlich auch zu Missverständnissen kommen. Dann heißt es für die Supporter, dem User das Feature genauer zu erklären, zu helfen und einen Weg zu finden, wie das Feature in den „goalunited Answers“ – unserer Anleitung zum Spiel – oder direkt im Spiel noch besser erläutert werden kann.

Sobald die Entwickler dann Erfolg vermelden, wird die Behebung des Problems auf schnellstem Wege über den QA-Admin an den Support und von dort direkt an den User weitergeleitet.

So kann das neue Feature von Usern, Admins, Supportern und Entwicklern in vollem Umfang genossen werden. Allerdings ist die Arbeit auch dann noch nicht beendet. In unserem nächsten Beitrag beschäftigen wir uns mit dem Thema „Der Spieler ist König“.

Wieder einmal ist es so weit. Aus einer fixen Idee, die im Gamedesign zu einem ausgefeilten Konzept gereift ist, wird wie aus Zauberhand – also durch Grafiker und Entwickler – ein tolles Feature. Bevor der User das Feature nutzen kann, muss natürlich eine Qualitätskontrolle erfolgen. Unsere Qualitätskontrolle wird von vielen verschiedenen Personen vorgenommen. Es sind weit mehr als 30 Personen an dem Prozess beteiligt. Neben den Entwicklern, dem Product Director, dem Product Manager und dem Gamedesign, testen auch Administratoren und Moderator das Feature auf unserem Beta-Server.

Das Testen eines neuen Features macht unglaublich viel Spaß, aber es steckt mindestens genauso viel Arbeit darin. Je komplexer ein Feature ist, desto aufwendiger ist auch das Testen. Denn jeder Bug - so werden in der Entwicklung von Computerspielen die Fehler genannt - muss genauestens protokolliert werden, so dass er später reproduzierbar ist. Alle Spielfehler werden von einem QA-Admin zusammengeschrieben und landen dann bei uns im Produkt-Management. Hier werden die Bugs priorisiert und anschließend an die Entwickler verteilt. Die Entwickler versuchen den Bug mit Hilfe der detaillierten Fehlerbeschreibung nachzustellen, um ihn im Anschluss zu fixen.

Das finden von Mistkäfern, wie die Bugs auch liebevoll genannt werden, in einem neuen Feature ist die eine Seite der Medaille. Die andere Seite sind die Verbesserungen. Kein Feature ist von Anfang an perfekt. Es gibt unterschiedliche Arten von Spielern, wie zum Beispiel die Casual-Player, die sich gelegentlich einloggen oder die Hardcore-Player, die sich jeden Tag – teilweise auch mehrmals am Tag – einloggen. Beide Gruppen nehmen ein Feature unterschiedlich wahr und unser Ziel ist es, beiden Gruppen gerecht zu werden und einen guten Kompromiss zu finden.

Deshalb sind wir auch bei den Verbesserungen auf unsere fleißigen Tester angewiesen. Auch hier werden die Hinweise und Tipps gesammelt und an das Produktmanagement weitergegeben. Zusammen mit dem Gamedesign bewerten wir, welche Vorschläge in die Umsetzung zu den Entwicklern gehen.

Nach einer Testphase, die normalerweise zwischen zwei und vier Wochen liegt, kann das Feature endlich live gehen und den Gamern vorgestellt werden. In unserem nächsten Beitrag setzen wir uns mit dem Thema „Endlich online - was nun?“ auseinander.

Montagmorgen, Stahltwiete 23, Konferenzraum.

Wir sitzen an einem großen Tisch im abgedunkelten Konferenzraum. Jeder hat einen dampfenden Becher Kaffee vor sich, wie sich das für uns Entwickler eben gehört.

Heute ist Scrum-Meeting: Fünf Entwickler, der Product Director und der Product Manager planen den kommenden „Sprint“ - also die Aufgaben für die kommenden zwei Wochen. Auf dem Plan stehen mehrere Features, die zuvor wochen- oder häufig monatelang durch die Hände der Game-Designer, Grafiker, des Product Directors und Product Managers gereicht und von ihnen konzipiert und mehrfach überarbeitet wurden.
In den nächsten Stunden schätzen wir Aufwände ein und priorisieren die Aufgaben. Natürlich liegen in einem solchen Sprint nicht nur Features, die umgesetzt werden sollen. In jedem Sprint müssen auch diverse  „Bugs“ (Fehler) und Unschönheiten behoben werden, die sich bei der laufenden Weiterentwicklung des Spiels immer wieder einschleichen.

Zurück am Arbeitsplatz öffnen wir das Planungsprogramm, auf das alle Entwickler Zugriff haben, und setzen die ersten Aufgaben, die noch nicht vergeben sind, in den Status „in progress“.
Handelt es sich um ein neues Feature, gilt es zuerst das Konzept zu lesen, zu verstehen und eventuelle technische Hürden festzustellen.
Gibt es Probleme oder Fragen, klären wir diese mit den Game-Designern. Handelt es sich um ein großes Feature wie etwa die „International Masters“ oder das „Merchandising“ bei goalunited, erstellen wir zuerst ein technisches Grobkonzept. So schaffen wir uns eine gute Übersicht und erkennen Probleme bereits im Voraus.
An einem Feature arbeiten meistens ein Backend- und ein Frontend-Entwickler zusammen, welche sich laufend miteinander abstimmen müssen. Die Frontend-Entwickler sind für die grafische Oberfläche des Spiels zuständig, in welcher der Spieler sich bewegt. Sie setzen die von der Grafik erstellten Layouts technisch um, programmieren die Bedienlogik und hauchen dem Konzept durch Animationen und Effekte Leben ein.
Die Backend-Entwickler hingegen programmieren das Rückgrat des Spiels. Ihre Aufgabe ist es die  Spiellogik technisch umzusetzen, die Spielwelt am Leben zu halten und dem Frontend einen Zugriff auf die Spieldaten zu ermöglichen. Sie sind dafür verantwortlich, dass die Daten in die Datenbank geschrieben und daraus ausgelesen werden können. Eine anspruchsvolle Aufgabe im Backend ist es, Lösungen zu finden, die performant arbeiten – also schnell ausgeführt und abgearbeitet werden können – damit hunderttausende von Spielern gleichzeitig spielen können.

Nachdem das technische Konzept von einem anderen Entwickler überprüft wurde und mit Frontend, Game-Design und Grafik alle Unklarheiten beseitigt sind, taucht der Entwickler in die Welt des Codes ein, für die wir von nicht-Entwicklern meistens als völlig verrückte Spezies abgestempelt werden: Geeks! Nerdtalk ist garantiert.
Wir schreiben Zeile um Zeile ausgewachsene Skripte, hämmern Befehle und Kommandos in unseren Editor und tickern kryptische Befehle in unsere Konsole, um unseren Programmcode zu testen. Dabei bauen wir Stück für Stück das Feature zusammen, bis es aus unserer Sicht schließlich fertig für die Veröffentlichung ist. Das Ganze – viele mögen das nicht glauben – ist ein durchaus interessanter und kreativer Prozess.

Um sich als „nicht-Techniker“ vorstellen zu können, wie ein solcher Programmcode funktioniert, muss man sich die Welt in Objekte einteilen. Bei goalunited ist beispielsweise ein Spieler aus dem Fußballteam ein Objekt. Außerdem ist die Aufstellung für ein anstehendes Liga-, Freundschafts- oder Pokalspiel ein weiteres Objekt und auch der Trainingsplan ist ein Objekt. Alle Objekte in unserem Spiel arbeiten miteinander und greifen aufeinander zu. Der Trainingsplan beispielsweise „greift“ sich alle Spieler der Mannschaft und wendet den heutigen Trainingsplan auf diese an. Ein Pflichtspiel greift sich die aktuelle Aufstellung und die Spieler der Mannschaft, die aufgestellt sind oder auf der Ersatzbank sitzen. Verletzungen oder gelbe und rote Karten während eines Spiels werden wiederum auf das Objekt des Spielers angewendet und so weiter.

Je nach Größe des Features kann die Umsetzung mehrere Tage, Wochen oder auch Monate dauern. Ist die Entwicklung abgeschlossen, wird sie von einem anderen Entwickler überprüft. Denn die Qualitätssicherung darf in der Entwicklung nicht fehlen!
Nun darf das Feature endlich in den Beta-Test! Hier können das Game-Design, der Product Director, der Product Manager und einige Beta-Tester das Feature auf Herz und Nieren im Betrieb testen während wir Entwickler die Bugs und Unstimmigkeiten beheben, die uns gemeldet werden.
Ist das Feature zur Zufriedenheit aller umgesetzt, kann es zum geplanten Starttermin in den Livebetrieb übernommen werden. Hier ist dann die
Systemadministration gefordert, die den Livegang des Features und damit eine eventuelle Downtime des Spiels planen muss. Denn für neue Features müssen häufig viele Änderungen an den Datenbanken vorgenommen werden, bei denen mehrere Millionen Einträge in der Datenbank angepasst werden müssen, was trotz extrem leistungsfähiger Server schon mal ein paar Stunden dauern kann.
Für die Downtime wird eine Wartungs-Seite angezeigt auf welcher die Spieler informiert werden, wie lange das Spiel abgeschaltet bleibt.
Mit Spannung erwartet nun das gesamte Entwicklerteam den Start des Features, überwacht die Datenbankaktivität und hält ständig Rücksprache mit Systemadministratoren, Product Director und   Product Manager.
Und dann ist es endlich soweit: Die Wartungs-Seite wird von den Systemadministratoren abgeschaltet, das Spiel und das neue Feature sind live. Und sofort loggt sich das gesamte Team ins Spiel ein, um das Feature endlich im Livebetrieb spielen zu können, während weltweit zigtausende Spieler das Gleiche tun.