Hallo Community,

in ARK Patchnotes 236.0 wurde ein interessanter Punkt angesprochen, nämlich der Wunsch, wie es eigentlich bei der Veröffentlichung eines Patches genau von statten geht, also welche Prozesse es gibt usw.

Ich möchte versuchen, euch in diesem Thema das ganze Handling eines kompletten Patch Releases näher zu bringen - vielleicht hilft es dem ein oder anderen dabei, zu verstehen, warum es manchmal einfach länger dauert, warum Inhalte gestrichen werden und der für euch absolut nervigste Bug immer noch nicht behoben wurde.

Außerdem steht hier, was eigentlich der Unterschied zu einem "fertigen" Spiel wie Battlefield und einem Early Access Spiel wie ARK ist und warum meckern eigentlich bis zum Release völlig fehl am Platz ist:
Der Unterschied zwischen dem Modell "Early Access" vs. "Fertiges Spiel kaufen"

• Die Veröffentlichung einer neuen Patchnote
  Je nach Entwicklungsmethode gibt es einen Projektfahrplan an den sich das Dev-Team halten muss, oder aber es gibt einen großen Feature-Topf der bis zu einem Zeitpunkt X umgesetzt worden sein muss. Das Entwicklungsteam hat je Woche eine bestimmte Kapazität - gehen wir mal bei einer Person von 40 Stunden aus. Bedeutet, dass bei 10 Entwicklern also rund 400 Stunden Entwicklungsleistung zum Abruf bereitstehen. Nun sieht sich das Team mit seinen 400 Stunden Leistung diesem Berg an Features gegenüber und muss diese Features einzeln nach ihrem Aufwand schätzen... wenn die Features nicht sehr aufwändig sind, dann können entsprechend mehr solcher Dinge umgesetzt werden, als wenn ein Thema sehr komplex ist. Steht nun also fest, was sich priomäßig als nächstes umsetzen lässt, dann wird eben die sogenannte "Patchnote" bekannt gegeben. Das sind also Inhalte, die das Team für den nächsten Patch versuchen wird umzusetzen. Hierbei wird je nach Team schon bereits berücksichtigt, dass eventuell Zeit für Bugfixing draufgeht, bzw. dass jemand Urlaub hat oder krank wird.
• Entwickler schwärmen aus und bearbeiten ihre Aufgabenpakete
  Nicht jeder Entwickler kann alles programmieren... Es gibt Entwickler, die kümmern sich eher um das Aussehen eines Spiels/Programms/Webseite und es gibt welche, die im Hintergrund an der Technik arbeiten, oder man arbeitet sogar zusammen an ein und dem selben Teil. Damit am Ende wieder alles zusammenlaufen kann und in dem "Hauptprogramm" landet, ist es notwendig, dass die Entwickler ihre umgesetzten Aufgabenpakete in das "Hauptprogramm" überführen. Umgangssprachlich sagt man auch "mergen" dazu. Beim Mergen können aber bereits die ersten Konflikte auftreten, wenn z.B. zwei Entwickler am selben Teil gearbeitet haben und diese beiden Teile sich ggf. überschneiden. Das kann also dazu führen, dass man vor der Zusammenführung nochmal darübersprechen muss, wie man den Code am besten nun aus zwei Paketen in das eine Hauptpaket überführt. Je nach Umfang der Änderungen kann hierfür einige Zeit ins Land gehen.
• Grobe Entwickler-Tests
  Wenn die Entwickler mit ihrem Teil fertig sind, wird dieser grob getestet. Da man jedoch nie alle Fälle bedenken kann, gibt es danach einen sogenannten "Testbuild" - eine erste testbare Version für die "offiziellen Tester"
• Testbuild und das Testen
  In aller Regel erscheint ein Testbuild zwischen 12-24 Stunden vor dem eigentlichen Releasetermin. Auf einem speziellen "Branch" (also einer speziellen Version) wird dann dieser Testbuild hochgeladen und steht für alle Tester dann zum Download bereit. Mit dabei sind erste Infos wie man z.B. neue Dinos oder Gegenstände spawnen kann. Zusätzlich sind die Tester angehalten, alle Bugs in einem Excel Sheet zu dokumentieren, das für alle anderen Tester ebenfalls zugänglich ist. Durch das Testen können durchaus zwischen 100 und 300 "Bugs" und sonstige Anmerkungen gefunden werden, am Ende sieht das ganze dann in etwa so aus:

  
  

  
  

  

  
  

  Für die letzte Version waren rund 130 solcher Meldungen, die allesamt behoben werden mussten, sofern sie kritisch für das Spiel selbst waren.
  

• Fixen der Fehler
  Je nachdem wieviele Fehler die Tester gefunden haben, beginnt ab Sekunde 1 des Testens der Wettlauf gegen die Zeit, denn das Release steht ja an und natürlich hoffen die Entwickler, dass nicht so viele Bugs oder Hinweise eingetragen werden. Es ist je nach Umfang des Releases auch weniger oder mehr, was auffällt. Aber egal wie: Es muss korrigiert werden. Damit aber nicht genug. Wenn die ersten Bugs behoben sind, wird ein neuer Betabuild erstellt, der dann wiederum getestet werden muss, um zu prüfen, ob die ersten Fehler bereits korrigiert wurden oder nicht. Wenn ja, ist gut. Wenn nicht, muss nochmal nachgesehen werden, warum es nicht funktioniert. Im Fall wie bei Version 235 war das also rund 130x der Fall, dass all das, was korrigiert wurde, nochmal getestet und versucht werden musste, zu reproduzieren. Da die Entwickler von ARK natürlich auch nicht 5000 Leute dort sitzen haben und auch ab und an mal schlafen müssen, wird an dieser Stelle sicherlich etwas deutlich, dass man einige hundert Hinweise oder Bugs eben nicht in weniger als 24 Stunden fixen kann
• Kleiner Fehler - große Wirkung
  In einem so großen Projekt wie ARK ist es unmöglich, dass man jederzeit alle Zusammenhänge kennt und jederzeit weiß, welche Auswirkung eine kleine Änderung am Code haben kann. Dies kann dazu führen, dass vielleicht ein winzig kleiner Bug eine riesengroße Änderung im gesamten Code mit sich führt, weil an verschiedenen Stellen auf den Bug verwiesen wird. Bis man diese Stellen in einem Projekt mit mehreren hunderttausenden Zeilen von Code gefunden hat, dauert auch nochmal eine Weile, auch wenn man natürlich das gesamte Projekt durchsuchen kann
• Alles fertig? Endabnahme
  Wenn dann abschließend aus Entwicklersicht alle o.g. Punkte behoben sind, muss nochmals alles einmal durchgetestet werden, sodass auch wirklich sicher ist, dass alles wichtige funktioniert. Manche Bugs werden auch nicht sofort behoben, wenn sie nicht so kritisch sind. z.B. wäre vielleicht ein fehlendes Brüllen bei einem Dino nicht so wichtig wie das Fliegen eines Fisches übers Land. Sollte es wider Erwarten weiter Probleme geben, die ein "Blocker" für ein Release wären (z.B. durch Implementation eines neuen Dinos sterben auf einmal alle Spieler auf dem Server oder alle Strukturen buggen weg) dann kann es natürlich auch dazu kommen, dass ein Inhalt kurzfristig noch rausgestrichen wird. Dies passiert allerdings erst in den letzten Minuten, weil hier meist aus der Management Ebene die Entscheidung gefällt werden muss, etwa wie: "Muten wir das jetzt unseren Spielern/Kunden zu oder nicht?".
• Release ist fertig
  Abschließend wird aus dem fertigen Betabuild ein "Release gekocht", was dann bei Steam bzw. Microsoft eingereiht und zum Download veröffentlicht wird. Bei Microsoft/Sony ist die große Besonderheit, dass jeder Upload manuell freigeschaltet werden muss, d.h. bei MS/Sony wird nochmals überprüft, was am Code geändert wurde - einfach um Schadcode oder ähnliches vermeiden zu können. Das kann auch nochmal gut und gerne zwischen 6-24 Stunden oder sogar länger dauern, wenn nämlich gerade Wochenende oder Feiertag in den USA. Laut den AGB sichern sich MS und Sony teilweise sogar bis zu 4 Wochen für eine Prüfung eines neuen Patches vor, d.h. hier kann man noch so sehr auf Wildcard schimpfen und dass sie ihre Patches doch am besten gar nicht mit Datum ankündigen sollen... aber es liegt an Sony/MS in diesem Fall... Zumal eine "ETA" immer noch eine Schätzung ist und bleibt... Ist dann endlich alles veröffentlicht. aktualisiert jeder Entwickler das "Hauptprogramm" auf seinem PC um von dort aus wieder für den nächsten Patch neu starten zu können.

Außerdem möchte ich in an dieser Stelle nochmal darauf eingehen, bezüglich der immer wieder aufkommenden Forderung "Erstmal Bugs fixen und dann neue Inhalte bringen" bzw. "Warum beheben die nicht endlich mal den Bug, der ist schon soo lange im Spiel und nervt total."

Wer sich in der Software-Entwicklung auskennt, weiß, dass je größer ein Projekt wird, desto umfangreicher werden kontextuale Zusammenhänge zwischen unterschiedlichen Programmbereichen. So kann es beispielsweise sein, dass eine Korrektur an einem Dodo dazu führt, dass auf einmal die Pteranodons nicht mehr fliegen können. Warum? Weil sie bestimmte Kreaturen-Eigenschaften vererbt bekommen haben, die irgendwo zentral definiert wurden. Passt man also nun etwas bei einem Tier an, kann es sein, dass es bei einem anderen Tier dann auf einmal knallt. Und man weiß im ersten Moment ggf. nicht mal, warum das so ist.

Aus diesem Grund bringt man eine Entwicklung in aller Regel erst einmal vollständig zu Ende, denn nur dann hat man codemäßig alles zusammen was man braucht, um die wirklichen Optimierungen zu beginnen.

Man könnte es mit einer Fertigungswerkstatt für Fahrzeuge vergleich (ja, ich nehme gerne das Beispiel mit einem Auto, weil das gut verglichen werden kann). Lasst uns mal sagen, dass unser Ziel ist, ein Auto zu bauen - bzw. die Entwickler von ARK definieren ein Ziel, dass ARK: Survival Evolved ein Spiel mit Dinos sein soll, was dieses und jene Sachen kann.

Nun fangen sie an, die ersten Autoteile zusammen zu schweißen. Verschiedene Entwickler kümmern sich dabei um die technischen Aspekte wie Kabel und andere Entwickler sind mehr dafür da, die Karosserie bzw. das grafische Design des Spiels zu definieren.

Dann treffen sich die Techniker mit den Designern und fangen an, die Teile zusammenzubauen. Sie haben vorher natürlich einen groben Bauplan von jemanden bekommen, der das Konzept erarbeitet hat. In der Autoindustrie sind das technische Zeichner, in der Software Entwicklung vielleicht ein Produktmanager oder Projektmanager. Dieser hat eine Vision und Vorstellung von dem fertigen Spiel bzw. Auto. Beim zusammenbauen merken dann alle Beteiligten, dass vieles schon gut auf einander abgestimmt ist, aber noch an machen Stellen die Ecken vielleicht etwas arg kantig und scharf sind, d.h. sie haben "Bugs" verursacht. Wenn die Stelle nun irgendwo unter der Motorhaube ist, wo es nicht sofort jemanden stört oder es eine Stelle ist, an die man nur schwer herankommt, weil grade das passende Werkzeug fehlt, dann schreiben sich die Entwickler das auf, dass man sich erstmal darum kümmert, das richtige Werkzeug (z.B. einen speziellen Experten in diesem Bereich der Software-Entwicklung um seine Meinung zu fragen) zu besorgen, bevor man einfach was drauf los korrigiert und das ganze vielleicht sogar schlimmer macht, als es vorher war, nur weil draußen vor der Werkstatt jemand steht und schreit: "Mach schneller, ich will mein Auto fehlerfrei haben" -- Also wir, die Spieler.

Und so wird über Monate das Auto immer weiter und weiter zusammengeschraubt. Es werden an bestehenden Teilen nochmals Anpassungen durchgeführt, die notwendig sind, damit am Ende sich die Teile einfacher montieren lassen.

Ist dann alles fertig, beginnt der Feinschliff. Die Teile werden fest verschweisst, die Scheinwerfer werden eingestellt, der Motor wird auf seine Leistung hin überprüft und es werden Testfahrten gemacht. Die Ergebnisse der Testfahrten zum Fahrverhalten nehmen die Entwickler wiederum zum Anlass jetzt mehr und mehr den Motor, Spoiler etc. so einzustellen, dass sie das perfekte windschnittige Auto bekommen, was sie benötigen um den genervten Kunden draußen zufrieden zu stellen.

Ich hoffe, dass euch dieses Beispiel ein bisschen verständlich machen konnte, weshalb es keinen Sinn macht, schon mittendrin am Motor rumbasteln zu wollen, obwohl die Karre noch auf der Hebebühne steht und noch nicht mal irgendwelche Reifen montiert hat... Alles passiert zu seiner Zeit, Software-Entwicklung ist sehr komplex (ich spreche aus eigener Erfahrung) und es lässt sich nicht alles sofort und schon gar nicht einfach beheben.

Also hört bitte auch auf, zu meckern, dass euer Auto auf der Straße noch am Schleifen ist.... ist auch klar, wenn nur 1 von 4 Reifen montiert wurde und der Rest noch eingebaut werden muss Das wurde euch beim Kauf auch schon gesagt, dass es so ist

Viele Grüße
Tom

Hier an der Stelle auch noch einmal D A N K E!

Sehr gut geschrieben und für mich sehr hilfreich.

Grüße!

Deckt sich ja einigermaßen mit meiner Aussage puuuh

Vielen Dank für den sehr informativen Beitrag Tom

Danke für den aufschlussreichen Artikel.

Mich persönlich stören die Verzögerungen nicht, außer es wird ein Bugfix verschoben, oder ein unangenehmer Bug wird nicht erfolgreich gefixt. Ist ab meines Wissens schon länger nicht mehr passiert, oder hat mich nicht betroffen. Die letzten Bugs

die mich wirklich gestört haben.

Ansonsten kann man sich bei ARK nicht darüber beschweren, dass es nicht ständig neuen Content gibt. Ich persönlich kenne keine Betaspiel bei dem sich "jede" Woche was tut.

Oh, das ist mal gut zu wissen! Auch, wenn ich mir sowas schon dachte, dass der Releasetermin der Wunschtermin ist

Ich habe den ersten Beitrag noch um folgenden Teil erweitert:

Zitat

Außerdem möchte ich in an dieser Stelle nochmal darauf eingehen, bezüglich der immer wieder aufkommenden Forderung "Erstmal Bugs fixen und dann neue Inhalte bringen" bzw. "Warum beheben die nicht endlich mal den Bug, der ist schon soo lange im Spiel und nervt total."

Wer sich in der Software-Entwicklung auskennt, weiß, dass je größer ein Projekt wird, desto umfangreicher werden kontextuale Zusammenhänge zwischen unterschiedlichen Programmbereichen. So kann es beispielsweise sein, dass eine Korrektur an einem Dodo dazu führt, dass auf einmal die Pteranodons nicht mehr fliegen können. Warum? Weil sie bestimmte Kreaturen-Eigenschaften vererbt bekommen haben, die irgendwo zentral definiert wurden. Passt man also nun etwas bei einem Tier an, kann es sein, dass es bei einem anderen Tier dann auf einmal knallt. Und man weiß im ersten Moment ggf. nicht mal, warum das so ist.

Aus diesem Grund bringt man eine Entwicklung in aller Regel erst einmal vollständig zu Ende, denn nur dann hat man codemäßig alles zusammen was man braucht, um die wirklichen Optimierungen zu beginnen.

Man könnte es mit einer Fertigungswerkstatt für Fahrzeuge vergleich (ja, ich nehme gerne das Beispiel mit einem Auto, weil das gut verglichen werden kann). Lasst uns mal sagen, dass unser Ziel ist, ein Auto zu bauen - bzw. die Entwickler von ARK definieren ein Ziel, dass ARK: Survival Evolved ein Spiel mit Dinos sein soll, was dieses und jene Sachen kann.

Nun fangen sie an, die ersten Autoteile zusammen zu schweißen. Verschiedene Entwickler kümmern sich dabei um die technischen Aspekte wie Kabel und andere Entwickler sind mehr dafür da, die Karosserie bzw. das grafische Design des Spiels zu definieren.

Dann treffen sich die Techniker mit den Designern und fangen an, die Teile zusammenzubauen. Sie haben vorher natürlich einen groben Bauplan von jemanden bekommen, der das Konzept erarbeitet hat. In der Autoindustrie sind das technische Zeichner, in der Software Entwicklung vielleicht ein Produktmanager oder Projektmanager. Dieser hat eine Vision und Vorstellung von dem fertigen Spiel bzw. Auto. Beim zusammenbauen merken dann alle Beteiligten, dass vieles schon gut auf einander abgestimmt ist, aber noch an machen Stellen die Ecken vielleicht etwas arg kantig und scharf sind, d.h. sie haben "Bugs" verursacht. Wenn die Stelle nun irgendwo unter der Motorhaube ist, wo es nicht sofort jemanden stört oder es eine Stelle ist, an die man nur schwer herankommt, weil grade das passende Werkzeug fehlt, dann schreiben sich die Entwickler das auf, dass man sich erstmal darum kümmert, das richtige Werkzeug (z.B. einen speziellen Experten in diesem Bereich der Software-Entwicklung um seine Meinung zu fragen) zu besorgen, bevor man einfach was drauf los korrigiert und das ganze vielleicht sogar schlimmer macht, als es vorher war, nur weil draußen vor der Werkstatt jemand steht und schreit: "Mach schneller, ich will mein Auto fehlerfrei haben" -- Also wir, die Spieler.

Und so wird über Monate das Auto immer weiter und weiter zusammengeschraubt. Es werden an bestehenden Teilen nochmals Anpassungen durchgeführt, die notwendig sind, damit am Ende sich die Teile einfacher montieren lassen.

Ist dann alles fertig, beginnt der Feinschliff. Die Teile werden fest verschweisst, die Scheinwerfer werden eingestellt, der Motor wird auf seine Leistung hin überprüft und es werden Testfahrten gemacht. Die Ergebnisse der Testfahrten zum Fahrverhalten nehmen die Entwickler wiederum zum Anlass jetzt mehr und mehr den Motor, Spoiler etc. so einzustellen, dass sie das perfekte windschnittige Auto bekommen, was sie benötigen um den genervten Kunden draußen zufrieden zu stellen.

Ich hoffe, dass euch dieses Beispiel ein bisschen verständlich machen konnte, weshalb es keinen Sinn macht, schon mittendrin am Motor rumbasteln zu wollen, obwohl die Karre noch auf der Hebebühne steht und noch nicht mal irgendwelche Reifen montiert hat... Alles passiert zu seiner Zeit, Software-Entwicklung ist sehr komplex (ich spreche aus eigener Erfahrung) und es lässt sich nicht alles sofort und schon gar nicht einfach beheben.

Viele Grüße
Tom

Alles anzeigen

Gute Erklärung, hast du echt gut beschrieben allerdings muss man leider dazu sagen das die meisten leider keine Geduld haben was bei einen so großen Titel wie ark und anderen spielen leider dazu führt das nur Kritik und kein Lob folgt.

Dabei macht das doch fast jeder so... Erstmal die Arbeit zu ende bringen und dann auf Fehler und stimmigkeit prüfen oder auch sein Werk begutachten ob man was noch besser machen kann. Da sollte mal jeder in seinem alltäglichen Ablauf aufpassen, vielleicht erwischt der ein oder andere sich ja selbst weil es FAST jeder macht.