EA Play FIFA 23 F1™ 22 Madden NFL 23 Apex Legends Battlefield™ 2042 Die Sims 4 Electronic Arts-Startseite Electronics Arts Home Aktuelle Spiele Bald erhältlich Free-to-Play EA SPORTS EA Originals Spielebibliothek EA app-Angebote PC PlayStation Xbox Nintendo Switch Mobile Pogo EA app EA Play Spieletests Das Unternehmen Jobs News Technology EA Studios EA Partner Unsere Verpflichtungen Positives Spielen Inklusive Firmenkultur & Mitarbeiter:innen Sozialer Einfluss Umwelt Hilfe EA-Community-Foren Tools für Spieler:innen und Eltern Barrierefreiheit Presse Investoren Aktuelle Spiele Bald erhältlich Free-to-Play EA SPORTS EA Originals Spielebibliothek EA app-Angebote PC PlayStation Xbox Nintendo Switch Mobile Pogo EA app EA Play Spieletests Das Unternehmen Jobs News Technology EA Studios EA Partner Unsere Verpflichtungen Positives Spielen Inklusive Firmenkultur & Mitarbeiter:innen Sozialer Einfluss Umwelt Hilfe EA-Community-Foren Tools für Spieler:innen und Eltern Barrierefreiheit Presse Investoren

Lebenszyklus eines FIFA-Problems - Teil 4

Veröffentlichung

Pitch Notes

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 vierte und letzte 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:

In diesem Artikel werfen wir einen Blick auf die Veröffentlichungsphase innerhalb des Lebenszyklus. In dieser Phase werden die Veränderungen, die wir zum Beheben eines Problems durchgeführt haben, im Live-Environment des Spiels veröffentlicht und den Spielern bereitgestellt.

 

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 Problembehebungen veröffentlicht werden.

Vorbereitung einer Veröffentlichung

Im vorherigen Artikel hatten wir über den letzten Schritt der Lösungsphase innerhalb des Lebenszyklus gesprochen. Dabei ging es darum, die zur Behebung des Problems durchgeführte Änderung einem Check-In¹ in die Mainline-Build(s)² des Spiels zu unterziehen. Sobald die Änderung in der Mainline-Build enthalten ist, kann sie veröffentlicht werden.

Je nachdem, welche Art von Code verändert wurde, kann es sich dabei um viele verschiedene Veröffentlichungen handeln.

Wenn es bei der Änderung um einen der verschiedenen Basiscodes eines Servers³ geht, handelt es sich bei der Veröffentlichung um einen Server-Release. Dazu wäre dann kein Titel-Update erforderlich, das die Spieler auf ihre Konsole, ihren PC oder ihr Mobilgerät (bei der FUT-Begleit-App) herunterladen müssen. Dabei ist es wichtig, zu erwähnen, dass es nur wenige Dinge gibt, die direkt auf dem Server geändert werden können. Oft geht es bei diesen Veröffentlichungen um Elemente, die der Spieler gar nicht bemerkt und die sich auch nicht auf ihn auswirken, also um Veränderungen hinter den Kulissen oder auf der System-/Infrastruktur-Ebene. Änderungen am Gameplay werden beispielsweise nicht über einen Server-Release durchgeführt, sondern erfordern ein Update des Titels.

Falls die Änderung am Client⁴-Code vorgenommen wurde, handelt es sich bei der Veröffentlichung um eine Client-Veröffentlichung, die in der Regel als "Titel-Update" bezeichnet wird. Diese Updates müssen vom Spieler heruntergeladen werden, da sie prinzipiell Code updaten oder ersetzen, der beim ersten Installieren oder Herunterladen des Spiels auf der Disc enthalten war.

Manchmal sind für die Behebung eines Problems Änderungen in mehreren Bereichen (also auf dem Server und im Client) nötig. In diesen Fällen müssen wir all diese Veröffentlichungen im Live-Environment⁵ bereitstellen, damit die Änderung übernommen wird und korrekt funktioniert.

Während jede dieser Veröffentlichungen auf technischer Ebene sehr unterschiedlich ist, durchlaufen sie alle vergleichbare übergeordnete Schritte.

Zunächst entscheiden wir, auf welcher Change-List (CL)⁶ der Release basieren soll. Das führt dazu, dass wir eine Version des Clientcodes oder des Servercodes haben, die alle Änderungen dieser neuen Change-List umfasst, bis zurück zu der Change-List, die für die letzte Veröffentlichung des Codes verwendet wurde.

Als Nächstes erstellen wir eine Veröffentlichung dieser Change-List, also eine endgültige Version, die dann auf die Server hochgeladen oder als Titel-Update bereitgestellt werden kann.

Im Anschluss wird diese Veröffentlichung getestet. Im Falle eines Server-Releases bedeutet das, dass die Veröffentlichung in einem Test-Environment⁵ eingesetzt wird. Im Falle eines Client-Releases wird das Update auf Test-Kits⁷ getestet.

Wenn die Veröffentlichung entsprechend vorbereitet wurde, gehen die Tests und die Validierung der Veröffentlichung los.

Test/Validierung einer Veröffentlichung

Die Veröffentlichung wurde also erstellt. Unsere Release-QV-Analysts⁸ verbringen nun einige Zeit damit, sie ihrem Testplan zu unterziehen. Die Dauer dieser Tests hängt von der Größe und Komplexität der in der Veröffentlichung enthaltenen Änderungen ab, reicht aber in der Regel von einigen Tagen bis zu einigen Wochen.

Das QV-Team konzentriert sich auf zwei Arten von Tests. Dabei geht es zum einen um grundlegende Tests, die sicherstellen sollen, dass das Spiel in dieser neuen Version nach wie vor ordnungsgemäß funktioniert, und zum anderen um Fokus-Tests, die sicherstellen sollen, dass alle in der Veröffentlichung enthaltenen Änderungen wie erwartet funktionieren.

Während das QV-Team seine Tests durchführt, finden häufig Reviews der Producer⁹ statt. Bei diesen Reviews prüft jeder Producer die Änderungen in den Bereichen, für die er zuständig ist. Sie müssen dabei sowohl grünes Licht für die Funktionalität als auch für die Qualität der durchgeführten Änderungen geben.

Hinzu können in dieser Phase technische Tests kommen, beispielsweise zusätzliches Load-Testing¹⁰ bei Server-Releases, falls diese erforderlich sind.

Das Ziel all dieser Maßnahmen ist es, sicherzugehen, dass im geplanten Update des Live-Environments alle erwarteten Änderungen enthalten sind und dass wir nicht eventuell unbeabsichtigte Änderungen einbauen oder unerwartete Knock-On-Probleme¹¹ verursachen.

Sobald alle Tests durchgeführt wurden und alle Beteiligten grünes Licht gegeben haben, erhält die Veröffentlichung endgültigen Status. Sie ist nun also bereit zur Veröffentlichung und kann einen Termin erhalten, an dem sie in das Live-Environment eingebaut wird.

Terminfestlegung für die Veröffentlichung - Titel-Update

Bei der Auswahl des Termins für die Bereitstellung eines Titel-Updates geht es nicht nur darum, wann wir es den Spielern gerne bereitstellen würden. Zu diesem Prozess gehört es auch, von den Eigentümern der jeweiligen Plattform (also Sony, Microsoft oder Nintendo) grünes Licht für die Veröffentlichung zu bekommen. In manchen Fällen, also bei Veröffentlichungen auf PC/Origin, geht es dabei auch um die Zustimmung einer internen EA-Organisation.

Sobald das Titel-Update finalen Status erreicht hat, wird es an diese Organisationen gesendet, damit sie ihrerseits Tests und Validierungen durchführen, grünes Licht geben können und uns die Festlegung eines Termins für die Bereitstellung ermöglichen können. Jede einzelne Organisation kann im Hinblick auf ihre Zustimmung einen unterschiedlichen Zeitplan und unterschiedliche Anforderungen haben. Das führt dazu, dass das Update auf manchen Plattformen vielleicht früher bereitgestellt wird als auf anderen, und dass Titel-Updates nicht immer auf allen Plattformen zur selben Zeit erscheinen.

Wenn wir von allen Partnern grünes Licht erhalten haben, können wir den Termin für die Veröffentlichung festlegen. Bei der Festlegung des Termins für ein Titel-Update versuchen wir in der Regel, einigen Richtlinien zu folgen.

Zunächst versuchen wir, einen Zeitpunkt festzulegen, der möglichst wenige Spieler beeinträchtigt. Idealerweise wählen wir also einen Termin, an dem der Großteil der Welt schläft oder gerade erst aufwacht. Zudem versuchen wir, Termine am Ende der Woche möglichst zu vermeiden. Denn die meisten Spieler wollen natürlich am Wochenende spielen, und sollte beim Titel-Update etwas schieflaufen, wäre es zu kurzfristig, um es vor dem Wochenende noch zu korrigieren. Außerdem versuchen wir auch, Updates nicht dann zu veröffentlichen, wenn wichtige Ingame-Events anstehen.

Wenn unser interner Veröffentlichungs-Zeitplan feststeht, sprechen wir ihn mit den jeweiligen Organisationen ab. Zu diesem Zeitpunkt gehen die meisten am Titel-Update beteiligten Personen wieder an den Anfang des Prozesses zurück und beginnen mit der Arbeit am nächsten Update. Trotzdem sind aber noch einige Schritte zu erledigen, um die ich mich weiter unten im Abschnitt "Abschluss der Veröffentlichung" kümmere.

Terminfestlegung für die Veröffentlichung - Server-Release

An der Terminfestlegung für einen Server-Release sind in der Regel weniger Personen beteiligt als an der Terminfestlegung für ein Titel-Update, da er ja nicht von den Organisationen begutachtet werden muss, die ich oben im Abschnitt zu den Titel-Updates erwähnt habe.

Bei einem Server-Release durchlaufen wir aber dieselben Entscheidungsschritte wie bei der Terminfestlegung eines Titel-Updates. Das gilt umso mehr, wenn für den Server-Release jegliche Services oder Features für die Bereitstellung der Veröffentlichung abgeschaltet oder deaktiviert werden müssen.

Wie bei einem Titel-Update, wendet sich der Großteil des Teams der nächsten Veröffentlichung zu, sobald ein Bereitstellungstermin gefunden wurde. Nun fehlen noch ein paar finale Schritte, die ich gleich beschreiben werde.

Abschluss der Veröffentlichung

Nun, da der Termin für die Veröffentlichung feststeht, gibt es noch ein paar finale Dinge, die vor der Bereitstellung eventuell vorbereitet werden müssen.

Zum einen müssen sich sämtliche internen Teams auf die Veröffentlichung vorbereiten. Und zum anderen ist es auch ein entscheidender Schritt, zu entscheiden, wie das Update und die darin enthaltenen Änderungen den Spielern mitgeteilt werden. Wir versuchen, bei jedem Release so klar wie möglich zu erläutern, was passiert. Das kann mit Titel-Update-Hinweisen für ein Titel-Update geschehen, mit Server-Release-Hinweisen für diverse Server-Releases, mit Wartungs-Hinweisen für Ausfälle oder mit Pitch-Notes-Beiträgen, die einige Änderungen des Releases genauer beschreiben.

Sobald das durchgeführt wurde, warten wir ab, bis der Zeitpunkt gekommen ist, an dem die Veröffentlichung live geht. Ist die Veröffentlichung dann live, testen unsere Live-Quality-Verification-Analysts (Live QV)¹² im Live-Environment alle im Update enthaltenen Änderungen, um zu verifizieren, dass alle vorgesehenen Problembehebungen enthalten sind und die Probleme auch tatsächlich behoben sind.

Sollte das Live-QV-Team feststellen, dass das Problem nicht behoben wurde, kehrt das Problem zum Beginn der Untersuchungsphase zurück, und der Prozess beginnt für dieses Problem wieder ganz von vorne. Wurde das Problem behoben, wird es geschlossen. Es hat also sämtliche Phasen seines Problem-Lebenszyklus durchlaufen.

 

Und damit ist es also am Ende seines Lebenszyklus angekommen.

Man darf dabei nicht vergessen, dass jedes Problem einzigartig ist. Einige können relativ schnell behoben werden, andere brauchen deutlich mehr Zeit, um alle im Rahmen dieser Serie beschriebenen Phasen zu durchlaufen.

Es gibt beispielsweise außergewöhnliche Fälle, die vielleicht nicht alle Phasen durchlaufen müssen, die ich beschrieben habe. Aber diese Fälle hätten einen eigenen Beitrag verdient, und das wäre dann vermutlich wirklich für euch alle TL;DR!

Ich hoffe, dass ihr nach dieser Serie besser versteht, wie die Problembehebung im FIFA Live-Team abläuft. Und ich danke euch, dass ihr euch die Zeit genommen habt, um diese Artikel zu lesen.

Joel Doonan und das FIFA-Team.

 

Fußnoten

¹: Der Check-In einer Änderung bedeutet, dass man diese Änderung in eine Build einbaut. 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.

²: 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.

³: 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.

⁴: 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.

⁵: 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.

⁶: Die Change-List (CL) ist eine Version des Codes. Sobald ein Check-In einer neuen Änderung im Clientcode oder im Servercode durchgeführt wird, wird eine neue Change-List erstellt. Die neue Change-List enthält diese neue Änderung und jeglichen vorherigen Code, der aus der Zeit vor der neuen Änderung stammt.

⁷: Ein Test-Kit ist eine Version der Spielkonsole, die während der Entwicklung genutzt wird. Auf ihm können wir bei den Tests spezielle Tools einsetzen, um zum Beispiel bestimmte Dinge schneller zu testen oder Daten zu erfassen, die in der offiziellen Spielversion oder der offiziellen Konsolenversion nicht verfügbar sind. Auf einem Test-Kit können wir im Rahmen der Entwicklung auch Pre-Release-Versionen oder Testversionen nutzen.

⁸: Ein Release-Quality-Verification-Analyst (QV) ist ein Mitglied unserer Quality-Verification-Organisation, das die verschiedenen Client-Releases und Server-Releases testet, bevor sie im Live-Environment eingesetzt werden können. Seine Rolle ist es, zum einen die im Release enthaltenen Änderungen zu validieren, und zum anderen sicherzustellen, dass der Release keine neuen Probleme verursacht hat.

⁹: Ein Producer ist grundsätzlich für einen bestimmten Bereich oder einen bestimmten Aspekt des Spiels verantwortlich. Er ist dafür zuständig, dort die Ausrichtung und die Prioritäten vorzugeben. Ein Live-Producer hat dieselbe Aufgabe wie ein Producer, konzentriert sich dabei aber in erster Linie auf das Live-Spiel und ist somit nicht Teil des Teams, das am bevorstehenden Spiel arbeitet.

¹⁰: 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.

¹¹: Ein Knock-On-Problem ist ein Problem, das unabsichtlich von einer anderen Änderung hervorgerufen wird. 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.

¹²: Ein Live-Quality-Verification-Analyst ist ein Mitglied unseres Quality-Verification-Teams oder unseres Live-Monitoring-Testing-Teams. Sie sind ständig im Spiel. Manchmal spielen sie das Spiel so, wie es auch unsere durchschnittlichen Spieler tun, aber manchmal führen sie auch äußerst fokussierte Tests durch, um verschiedene Bestandteile des Spiels zu verifizieren und/oder Probleme auszulösen. Ihre Hauptaufgabe ist es, Probleme im Spiel zu finden, zu tracken und zu melden. Sie validieren außerdem alle Veröffentlichungen, die in das Live-Environment eingebaut werden, um sicherzustellen, dass die Änderungen der Veröffentlichung genau den gewünschten Effekt haben.

 

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.

Ähnliche Artikel

FIFA 23 | Pitch Notes – FIFA 23 auf Xbox Cloud Gaming (Beta) – FAQ

FIFA
27.07.2023
Xbox Cloud Gaming

Werte der Weltmeisterschaft der Frauen - Offizielle EA SPORTS-Website

FIFA
22.06.2023
Lerne die 100 besten internationalen Stars der Frauen-Fußballwelt vor der FIFA Frauen-Weltmeisterschaft 2023™ kennen.

FIFA 23 | Pitch Notes - Frauen-Weltmeisterschaft

FIFA
19.06.2023