Helldivers 2: PC-Version schrumpft von 154 GB auf 23 GB
von Olli | 11 Kommentare
Wer auf dem PC ständig mit dem Speicher kämpft, kann bei Helldivers 2 bald etwas beruhigter sein. In einer neuen Beta-Version haben die Entwickler die Installationsgröße auf dem PC um rund 85 Prozent reduziert, von etwa 154 GB auf nur noch ca. 23 GB.
Möglich wurde das laut dem Team durch eine vollständige Deduplizierung der Spieldaten. Ursprünglich wurden Assets mehrfach abgelegt, um Ladezeiten auf Festplatten zu verbessern. Inzwischen weiß man, dass die Ladezeiten hauptsächlich an der Level-Generierung hängen, nicht am Asset-Streaming. Der Effekt der doppelten Daten war also wesentlich geringer als erwartet und betraf nur den kleinen Teil der Spieler mit mechanischer Festplatte.
Die neue „Slim“-Version steht PC-Spielern bereits über die technische Public Beta auf Steam zur Verfügung und soll später zur Standard-Version werden. Die Auswirkungen auf die Ladezeiten sollen mit ein paar Sekunden minimal sein.
Transparenz: In diesem Artikel sind Partnerlinks enthalten. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir eine kleine Provision. Für euch ändert sich am Preis nichts. Partnerlinks haben keinerlei Einfluss auf unsere Berichterstattung.
Wird geladen ...
Ein sehr guter Schritt, der zeigt wie viel Potential hier vorhanden ist.
Optimierungen sind ein rares Gut geworden. In sämtlichen Softwarebereichen scheinen einige Entwickler seit Jahren zunehmend verschwenderisch mit Speicher umzugehen. In meinen Augen ist sowas Kostenoptimierung durch Verlagerung des Problems an den Kunden.
Das war eine Optimierung, die man eben weggeworfen hat, weil sie auf dem PC wenig brachte.
Solches Potential ist nur da vorhanden, wo man Daten redundant angelegt hatte, um dem Kunden die Ladezeit zu sparen.
Kann denen jemand mal die Telefonnummer von den Call of Duty Entwickler geben?
Das witzige ist ja auch, dass Leute vielleicht durch die Größe von 154GB sich gezwungen sahen das Spiel auf einer Festplatte zu installieren statt auf einer SSD, sie die Mehrfachablegung allerdings gar nicht erst hätten manchen müssen/sollen, wenn festgelegt worden wäre, dass SSD eine Mindestanforderung ist.
Wäre es da nicht von Anfang an sinnvoller gewesen, die „Optimierung“ lokal durchführen zu lassen, solange man der Meinung war, dass diese etwas bringen würden?
Statt bisher global betrachtet wer weiß wie viel unnötiges Daten- und Downloadvolumen zu verursachen, weil dieselben(!) Daten mehrfach heruntergeladen werden mussten, hätte man doch von Anfang an alles nur in einfacher Ausfertigung übertragen können und dann meinetwegen in der .exe eine kurze Prüfung einbauen können, ob die betroffenen Datendateien bereits mehrfach vorliegen – und falls nicht (bspw. nach dem ersten Download oder nach Updates der Dateien) einfach ein kurzes „Spieldateien werden vorbereitet…“-Fenster einblenden und dann lokal halt einen copy-Befehl laufen lassen… Idealerweise wäre das auch nur passiert, wenn der Client feststellt, dass tatsächlich eine HDD statt SSD verwendet wird. Kurzer Vermerk auf die Store-Page, dass bei Installation auf HDD der siebenfache(!) Speicherplatz benötigt wird, und fertig.
Aber naja – Optimierung passt halt nicht mehr so richtig in den Zeitgeist – einfach mehr Ressourcen der Kunden verbraten, dann wird das schon…
Ich bezweifle, dass die gleichen Datendateien mehrfach vorlagen, das macht wenig Sinn, denn das Spiel kann nicht steuern, wo genau auf der SSD die Datei liegt, das macht nicht mal das Betriebssystem, sondern der Controller der SSD.
Ich vermute, dass bestimmte Daten wie Texturen innerhalb der Dateien mehrmals vorhanden waren, damit man sie schneller von der SSD lesen kann, denn sequenzielles Lesen ist bei SSDs in der Regel deutlich schneller als zufälliges Lesen, da Daten zusammenhängend gelesen werden.
Technisch gesehen würde das mit getrennten (aber identischen) Datendateien sogar mehr Sinn ergeben als in einem großen File.
Da die „Optimierung“ ja für HDDs und nicht für SSDs war, also auf der Annahme beruht, dass auf einer HDD das sequentielle Lesen performanter ist als verteilte Zugriffe (bei denen der Lesekopf sich mechanisch umpositionieren muss, was Zeit kostet), wäre es deutlich sinnvoller, die duplizierten Daten in eigenen Dateien abzulegen.
Hintergrund ist, dass beim Anlegen einer Datei auf einer HDD idealerweise angestrebt wird, dass die Datei wenn möglich „unzerstückelt“ am Stück auf der HDD abgelegt werden kann. Dies setzt natürlich voraus, dass beim Anlegen der Datei entsprechend viel Platz „am Stück“ verfügbar ist. Die Wahrscheinlichkeit, sagen wir mal 6×15 GB „irgendwo“ jeweils für sich betrachtet am Stück unterzubekommen ist vermutlich höher als dass irgendwo ein einzelner 90 GB Bereich frei ist.
Ebenso haben mehrere „kleine“ Dateien eine höhere Wahrscheinlichkeit, beim (klassischen, für HDDs entwickelten) Defragmentieren jeweils pro Datei zusammengehalten zu werden, auch wenn die HDD schon recht voll ist. Je größer die einzelne Datei ist, desto mehr freier Platz wird während des Vorgangs gebraucht um das Ziel zu erreichen.
Diese „Optimierung“ die bei HD2 stattfand erinnert mich an die Optimierung aus Xbox360 und PS3-Zeiten, wo Spiele noch nativ vom optischen Medium liefen (Installation kam ja erst später in der Generation und war häufig auch nur optional) – dort wurden die Dateien auch mehrfach auf der DVD bzw. Blu-ray Disc abgelegt, damit der Laser einen nicht so weiten Weg zurückzulegen hat… Da wurden die Disc-Layouts extra optimiert gepresst, weil bei vielen (linearen) Games ja durchaus vorhersehbar ist, an welcher Stelle welche Daten nachgeladen werden müssen. Die Xbox 360 hat später dann bei der optionalen Spiele-Installation, wo die Disc nur noch als Besitznachweis gedient hat, automatisch „shared assets“ (= doppelte Dateien) _nicht_ mit installiert und somit Speicherplatz auf der HDD gespart, womit installierte Spiele auf der Konsolen-HDD kleiner waren, als wenn man die Disc gedumped hat…
Wie dem auch sei – es hat sich ja nun auch bei den HD2 Entwicklern gezeigt, dass das am PC alles für die Katz‘ war und das Ergebnis zählt. Auch wenn es schöner gewesen wäre, wenn sie ihre Performance-Tests einfach früher gemacht hätten… 😉
Bei der Produktion von optischen Datenträgern kann man ja auch genau festlegen, wo sich die Daten physikalisch auf dem Datenträger befinden. Da kann man die Anordnung auf das Leseverhalten anpassen und damit den Ladevorgang optimieren.
Aber genau diese Möglichkeit hat man beim Schreiben auf Festplatte ja eben nicht. Da bestimmt eben nicht das Programm, wie und wo die Daten nun auf der Festplatte angeordnet sind.
Und es gibt auch keine Möglichkeit (jedenfalls bei Windows und seinem Filesystem) dass dem System redundante Daten bekannt sind und auf die schnellstmöglich erreichbare Version zugreift.
Mir ist absolut nicht klar, wie diese Technik jemals etwas gebracht haben soll.
und deswegen sind Informatiker keine „Ingenieure“ – wer denkt sich so ne scheisse aus
Mir wäre ja wichtiger gewesen, wenn sie das ganze DRM-Geraffel wegoptimiert hätten. Kein Steam, Playstation-Account, Kernel-Anti-Cheat … So bleibts bei einem danke, nein …
Überall nur shrinkflation… Alles wird kleiner und der Preis bleibt identisch. Frechheit!