Lebenszyklus eines FIFA-Problems - Teil 3

7. Dezember 2020

In dieser Serie schauen wir uns die Phasen an, die ein FIFA 21-Problem üblicherweise bis zu seiner Behebung durchläuft.

Hallo, FIFA-Fans!

Mein Name ist Joel Doonan, ich bin der Lead Producer des Player First Operations-Teams, das zum FIFA Live-Team gehört.

Dies ist der dritte Artikel unserer detaillierten Pitch Notes-Serie zum Lebenszyklus eines durchschnittlichen FIFA 21-Problems.

In dieser Serie erkläre ich euch die verschiedenen Schritte, die ein Problem in der Regel durchlaufen muss, damit es in der Live-Version von FIFA 21 bearbeitet und behoben werden kann. 

Diese 4-teilige Serie umfasst:

• Teil 1 - Identifizierung
• Teil 2 - Untersuchung
• Teil 3 - Lösung (dieser Artikel)
• Teil 4 - Veröffentlichung

In diesem Beitrag schauen wir uns die Lösungsphase des Lebenszyklus an. Diese Phase kann, je nach dem Problem, mehrere Schritte umfassen, die ausgeführt werden müssen, bevor eine Problembehebung oder eine Änderung bereitgestellt werden können.

Bevor wir loslegen, noch eine kurze Anmerkung: Ich werde hier und da einige Fachbegriffe verwenden. Sobald ich einen Fachbegriff verwende, mit dem Leute außerhalb der Spielentwicklung vielleicht nicht so vertraut sind, füge ich eine Fußnote ein und erkläre euch in dieser Fußnote, was der Begriff bedeutet. Legen wir also los und schauen wir uns an, wie Probleme gelöst werden.

Durchführung der Änderung

Wenn wir die Lösungsphase im Lebenszyklus eines Problems erreicht haben, heißt das, dass wir den Grund¹ des Problems unserer Ansicht nach erkannt haben und bereit sind, eine Änderung durchzuführen, die das Problem behebt.

Je nach dem Grund und der Art des Problems, kann die Komplexität der nötigen Änderung erheblich variieren.

Wenn es sich um ein grundlegendes funktionales Problem² handelt, bei dem etwas eindeutig nicht so wie gewünscht funktioniert, kann die Lösung manchmal ganz einfach sein, sobald der Grund des Problems erkannt wurde. Zumindest für Leute, die jahrelange Erfahrung mit der Arbeit am Spielcode haben.

Bei komplexeren Problemen kann es hingegen eine enorme Herausforderung darstellen, die richtige Änderung zu seiner Behebung zu finden. Manchmal sind hierzu Modifikationen oder Ergänzungen der Kern-Technologien nötig, auf denen das gesamte Spiel basiert. Oder es sind Änderungen an mehreren Systemen verschiedener Teams nötig.

Wenn das Problem und die vorgesehene Art der Lösung nicht so eindeutig sind, kann das Ganze durchaus sehr komplex werden. Das ist zum Beispiel dann der Fall, wenn ein Problem Anpassungen des Feintunings oder der Spielbalance erfordert und man darauf achten muss, dass eine Änderung keine neuen Probleme in anderen Spielbereichen auslöst.

Die Bandbreite der potenziell erforderlichen Kapazitäten für eine Änderung ist also sehr groß. Für eine relativ einfache Änderung können mehrere Arbeitsstunden eines einzelnen Software-Engineers (SE)³ reichen. Für die reibungslose Behebung eines komplexen Problems kann hingegen die wochenlange oder monatelange Arbeit eines ganzen Strike-Teams⁴ aus erfahrenen Software-Engineers nötig sein.

Unabhängig von der Komplexität der jeweiligen Änderung, arbeiten die Software-Engineers beim Entwickeln einer Änderung in der Regel in einer lokalen Build⁵, also einer einzigartigen Spielversion, die das Spiel sowie die spezifische Änderung enthält. Damit wird sichergestellt, dass letztlich nur für einen Check-In verifizierte Inhalte in die Mainline-Build⁶ des Clientcodes⁷ oder des Servercodes⁸ übernommen werden. Zu diesem Thema komme ich in Kürze.

Sobald eine Änderung in der lokalen Client-Build oder Server-Build durchgeführt wurde, testen sie die Software-Engineers mit den Embedded-Quality-Verification-Analysts⁹, um sicherzustellen, dass das Problem behoben wurde und dass die Änderung keine offensichtlichen neuen Probleme (die sogenannten Knock-On-Probleme¹⁰) ausgelöst hat.

Je nach der Art der Änderung, können hier zusätzliche Schritte erforderlich sein, ehe diese Phase abgeschlossen werden kann und wir mit den nächsten Schritten der Lösungsphase fortfahren können.

Ich möchte kurz ein Beispiel für derartige zusätzliche Schritte nennen: Wenn die Änderung zu neuen Server-Calls¹¹ oder zu Modifizierungen der bisherigen Server-Calls führt, müssen wir die Änderung unter Umständen mittels Load-Testing¹² prüfen. Dort simulieren wir in einem einzigartigen Server-Environment, was auf den Servern passiert, wenn die Spieler das Spiel spielen. Mit diesen Tests wollen wir sicherstellen, dass die Änderung nicht zu einer Erhöhung der Serverlast führt und so Stabilitätsprobleme hervorruft oder die Verarbeitung der unterschiedlichen Spieleranfragen an den Server in irgendeiner Weise beeinträchtigt.

Das Gameplay-Team hat außerdem ein Test-System namens "Gauntlet", mit dem sie Änderungen durchspielen können, um sicherzustellen, dass sie den gewünschten Effekt haben und keine Fehler in anderen Gameplay-Systemen verursachen.

All diese zusätzlichen Schritte sollen sicherstellen, dass die durchgeführte Änderung das jeweilige Problem auch wirklich behebt und keine neuen Fehler hervorruft. Sie dienen der Vorbereitung des nächsten wichtigen Schritts im Lebenszyklus, nämlich der Prüfung der Änderung im eigentlichen Spiel und der Vorbereitung auf die Veröffentlichung in unserem Live-Environment¹³

Code-Reviews/Check-Ins

Sobald der Software-Engineer davon überzeugt ist, dass eine sichere Änderung vorliegt, und er die nötigen Prüfungsschritte und Verifizierungsschritte durchlaufen hat, ist er bereit für einen wichtigen Schritt bei der Vorbereitung der letztlichen Veröffentlichung, nämlich den Check-In¹⁴ der Änderung in die Mainline-Build.

Bevor das Team dies tun kann, muss die Änderung zunächst von einem technischen Lead abgenommen werden. Er prüft die durchgeführte Änderung und die Testergebnisse. Manchmal wird diese Prüfung auch schon zu einem deutlich früheren Zeitpunkt durchgeführt. In jedem Fall muss sie aber zwingend vor dem Check-In stattfinden.

Wenn die Prüfung abgeschlossen ist, kann der Check-In der Änderung in die Mainline-Build stattfinden. Egal, ob es sich dabei um die Mainline-Build des Clientcodes oder die Mainline-Builds der verschiedenen Serversysteme handelt. Nach dem Check-In in die Mainline-Build ist die Änderung nun Teil des internen Spiels. Damit ist sie nun also bereit für die letzte Phase des Lebenszyklus des Problems, nämlich die Veröffentlichungs-Phase. Um diese Phase kümmern wir uns dann im nächsten Teil dieser Serie, der zugleich auch der letzte Teil sein wird.

Vielen Dank, dass ihr euch die Zeit genommen habt, diesen Beitrag zu lesen. Ich hoffe, dass ihr durch diese Serie besser versteht, wie die Probleme behoben werden, die euch beim Spielen eines Videospiels aufgefallen sind.

Joel Doonan und das FIFA Live-Team.

Fußnoten

¹: Mit dem Grund eines Problems meinen wir seine eigentliche Ursache. Er wird in der Untersuchungsphase identifiziert, wie wir im vorherigen Artikel erläutert haben.

²: Mit einem funktionalen Problem meinen wir in der Regel ein Problem, das dazu führt, dass irgendetwas eindeutig nicht so funktioniert, wie es vorgesehen war. Das ist zum Beispiel der Fall, wenn es eine Option gibt, die Farbe eines Pfeils zu wählen und ihr blau wählt, der Pfeil dann aber letztlich rot angezeigt wird. Hier hat also eine Farbauswahl nicht ordnungsgemäß funktioniert. Probleme mit der Spielbalance oder dem Feintuning oder qualitatives Feedback gehören nicht zu den funktionalen Problemen, da sie oft Ansichtssache sind. Auch Situationen, in denen Probleme in Funktionalitäten auftreten, die keine konstant eindeutige Funktionsweise haben, gehören dazu. Im Hinblick auf das bereits erwähnte Beispiel der Farbauswahl ist das zum Beispiel dann der Fall, wenn diese Auswahl eine blaue Option hatte, dieses Blau dem gemeldeten Problem zufolge aber "nicht blau genug" ist. In diesem Fall ist es nicht eindeutig, wie blau das Blau sein sollte.

³: Ein Software-Engineer (SE) schreibt den Code, auf dessen Grundlage das Spiel grundsätzlich ausgeführt wird. Es gibt viele verschiedene Arten von Software-Engineers, da unterschiedliche Arten von Codes auch unterschiedliche Fähigkeiten erfordern. Die Coding-Arbeit am Servercode unterscheidet sich zum Beispiel erheblich von der Coding-Arbeit am Gameplay.

⁴: Ein Strike-Team ist in diesem Zusammenhang eine aus speziell zu diesem Zweck zusammengeführten Einzelpersonen bestehende Gruppe. Die Gruppe existiert für begrenzte Zeit, um sich um ein bestimmtes Problem oder Projekt zu kümmern. Daher ist es immer wieder erforderlich, Experten aus anderen Teams in diese kleinere Gruppe zu holen, um das Wissen und die Fähigkeiten dieser Experten zusammenzubringen. Dies geschieht in der Regel in Situationen, in denen das Problem oder das Projekt sehr anspruchsvoll oder komplex ist.

⁵: Eine lokale Build (egal ob auf Clientseite⁷ oder auf Serverseite⁸) ist eine interne Version des Spielcodes, mit deren Hilfe wir an neuen Änderungen arbeiten können. Sie vereint das normale Spiel mit den Coding-Veränderungen, an denen eine Einzelperson oder eine Gruppe (oftmals mit dem Fokus auf einem bestimmten Bereich) gearbeitet hat. Sie wird zu anfänglichen Tests und Prüfungen einer Änderung genutzt, ehe diese Änderung dann in die Mainline⁶-Version des Spiels übernommen wird.

⁶: In der Mainline-Build bzw. in den Mainline-Builds finden sich alle verschiedenen Einzelcodes und Einzelentwicklungen wieder, sobald sie einem Check-In unterzogen wurden. Hier entstehen letztlich die finalen Versionen des Clientcodes und des Servercodes für das Spiel. Wenn etwas bei der Erstellung einer Veröffentlichung in der Mainline-Build enthalten ist, ist es damit grundsätzlich auch Teil dieser Veröffentlichung.

⁷: Mit dem Client meinen wir die Daten auf der Disc bzw. bei einer digitalen Spielversion die Daten, die ihr auf eure Konsole oder euren PC herunterladen müsst, um das Spiel zu spielen.

⁸: Wenn ein Inhalt serverseitig ist, bedeutet das, dass er sich nicht auf der Disc befindet, sondern dass der Code bzw. die Daten von einem Server stammen und über die Onlineverbindung vom Server abgerufen werden. Es gibt viele verschiedene Arten von Serverdaten. Und in FIFA 21 gibt es zudem viele verschiedene Serversysteme, mit denen ihr kommuniziert, je nachdem, in welchem Teil des Spiels ihr spielt.

⁹: Ein Embedded-Quality-Verification-Analyst (QV) ist ein Mitglied unserer Quality-Verification-Organisation, das direkt mit den Software-Engineers zusammenarbeitet und auch in ihrer Nähe arbeitet. Er testet die Funktionalität bestimmter Änderungen und versucht, im Rahmen des Entwicklungsprozesses etwaige Probleme bei diesen Änderungen zu erkennen.

¹⁰: Ein Knock-On-Problem ist ein Problem, das durch eine andere Änderung hervorgerufen wurde. Dabei handelt es sich fast immer um unabsichtlich verursachte Fehler. Das kann zum Beispiel passieren, wenn wir in einem Bereich eine Änderung durchführen, die sich auf die Funktionalität in einem anderen Bereich auswirkt, da es gegenseitige Abhängigkeiten oder gemeinsam genutzte Codes oder Technologien gibt.

¹¹: Bei einem Server-Call führt der Client eine Anfrage an den Server durch. Dabei geht es in der Regel um den Abruf neuer Daten oder das Validieren vorhandener Daten. Wenn ihr euch beispielsweise bei FUT anmeldet, werden etliche Server-Calls durchgeführt, um alle Daten zu eurem FUT-Club abzurufen. Beispielsweise, welche Items ihr besitzt, wie euer Status in den verschiedenen FUT-Modi aussieht und welche Items ihr auf dem FUT-Transfermarkt angeboten habt.

¹²: Mit Load-Testing meinen wir die Messung der Spielleistung und der Stabilität einer Serverumgebung. Zu diesem Zweck werden die gleichzeitigen Spielhandlungen großer Spielermengen simuliert, so als würden sie das Spiel spielen, verschiedene Ingame-Aktionen ausführen und unterschiedliche Aufgaben an die Server stellen. Ziel ist es dabei, sicherzustellen, dass alles auch dann noch ordnungsgemäß funktioniert, wenn Tausende oder sogar Millionen von Spielern das Spiel gleichzeitig spielen.

¹³: Das Live-Environment ist die im Handel erhältliche Spielumgebung bzw. die Produktions-Spielumgebung. In ihr können die Spieler die veröffentlichte Version des Spiels spielen. Darüber hinaus haben wir auch diverse Environments, die in der Regel nur intern genutzt werden. Beispielsweise unsere Test-Environments, in denen wir Pre-Release-Versionen des Spiels vor der Veröffentlichung testen.

¹⁴: Beim Check-In einer Änderung wird diese Änderung in eine Build eingebaut. Im Hinblick auf diesen Beitrag meinen wir damit vor allem, dass die Änderung in eine Mainline-Build oder in mehrere Mainline-Builds für den Client und den Server eingebaut wird. Sobald der Check-In einer Änderung durchgeführt wurde, ist sie in diesen Builds enthalten und kann potenziell in einer künftigen Veröffentlichung enthalten sein.

Weitere detaillierte FIFA-Beiträge der Mitglieder des Spielteams finden sich auf der Pitch Notes-Seite.

Wichtiger Hinweis: Dieser Beitrag beschreibt grundsätzlich, woran die Entwicklerteams arbeiten. Da es unser Ziel ist, das Gameplay für alle Spieler unablässig weiter zu optimieren, kann es vorkommen, dass die Angaben dieses Artikels aufgrund vorgenommener Anpassungen zur Steigerung des Spielvergnügens veraltet sind.

Bleibe in Sachen FIFA auf dem Laufenden. Werde Fan auf Facebook, folge uns auf dem offiziellen Twitter- und Instagram-Channel, folge dem Entwickler-Twitter-Channel @EAFIFADirect und dem EA SPORTS FIFA-Tracker und werde Teil der offiziellen FIFA-Foren. Melde dich an, um E-Mails zu EA SPORTS FIFA sowie zu Produkten, News, Events und Angeboten von EA zu erhalten.