Do

13

Dez

2012

Insights: Und ab in die Entwicklung!

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.

Impressum | Datenschutz | Sitemap

©2005-2015 northworks Software GmbH

Mit Sitz in der vermutlich schönsten Stadt der Welt:       Hamburg