Tech-Interview – Need for Speed: Hot Pursuit
Digital Foundry zu Besuch in Guildford
Der Kreis ist nun geschlossen. Vor einem Jahr begann Digital Foundry seine ausführliche Reihe an Tech-Interviews mit den führenden Köpfen der Spieleentwicklung, als wir mit Criterions Technical Director Richard Parr und Senior Engineer Alex Fry sprachen. In der letzten Woche besuchten wir den Entwickler in Guildford, um einen Blick auf das neue Need for Speed: Hot Pursuit zu werfen, und nutzten gleichzeitig auch die Chance, uns erneut mit Parr und Fry zusammenzusetzen und über die jüngsten technologischen Innovationen für ihr neues Spiel zu sprechen.
Für Criterion stellt Need for Speed: Hot Pursuit einen großen Aufbruch dar. Es ist nicht einfach Burnout Paradise im neuen Gewand – das Entwicklerteam hat eine brandneue Engine für das Spiel erschaffen, inklusive einem anderen Fahrerlebnis und einem optischen Look, der sich deutlich von ihrem vorherigen Titel unterscheidet. Es ist Need for Speed, mehr noch, es ist ein klassisches Need for Speed, das mit State-of-the-art-Rendering und -Physik an die heutige High-Definition-Ära angepasst wurde.
In Kürze werden wir ausführlicher über das Spiel sprechen und einige überraschende Informationen hinsichtlich des Entstehungsprozesses enthüllen, aber zunächst ist es an der Zeit für die Veröffentlichung des Interviews. Fry, Parr und Leadbetter in Criterions War Room. Das ist passiert...
Ja, wir haben mit Paradise verdammt viel gelernt. Eines der Dinge, die man bei der Entwickung eines Spiels lernt... betrachtet man das Ganze rückblickend, fügt man eine Menge der eigenen Erfahrungen zusammen. Was lief gut und was nicht, wie kann man es besser machen. Um es besser zu machen, ist es manchmal nötig, einige große Änderungen vorzunehmen.
Die größte Veränderung wurde bei diesem Spiel am Threading-Modell vorgenommen, es ist komplett neu. Ausgangspunkt war das in Paradise verwendete Dual-Threading. Es gab Update- und Render-Threads. Wir haben es aufgegeben und sind zu einem Thread zurückgekehrt. Die Gründe dafür waren... nun, es gab mehrere Gründe.
Erstens wollten wir ein 30-Hz-Spiel machen, das umwerfend aussieht, und wir wollten eine schnelle Controller-Latenz. Mit einem zusätzlichen Render-Thread bei 30 Hz hat man ernsthafte Latenzprobleme, also gingen wir zum Single-Thread zurück. 30 Hz also... es wird interessant zu sehen sein, was eure Latenzmessungen ergeben. Wir glauben, dass die Latenz ziemlich gut ist.
Ich denke, wir sind vielleicht bei 83 ms... oder 100 ms.
Wenn es bei uns mehr als 100 ms sind, wäre ich sehr enttäuscht.
Zudem bin ich mir ziemlich sicher, dass die Konsolen die Eingaben des Controllers nicht sofort im Spiel widerspiegeln. Es gibt eine Art Hintergrundberechnung in der Konsole, die euch diese Information gibt, ob es ein 60-Hz-Frame oder ein 30-Hz-Frame will. Ich denke nicht, dass es augenblicklich geschieht.
Wireless oder kabelgebunden?
Wir haben versucht, den Lag im Allgemeinen so niedrig wie möglich zu halten. Das ist einer der Gründe für die Nutzung des Single-Threads. Wir haben ein paar Spiele gespielt, die 30 Hz nutzten, offenbar dualthreaded waren und scheinbar eine Menge Lag hatten. Es war keine wirklich gute Spielerfahrung. Die Designer haben sicherlich nicht besonders viel Spaß damit gehabt, damit zu arbeiten und es so zu gestalten, dass es sich gut anfühlt. Wir haben anfangs auch versucht, Need for Speed dualthreaded bei 30 Hz laufen zu lassen, aber für uns gab es einfach zu viel Lag.
Man muss Parallelismus verwenden – man muss keine Threads verwenden. Eine klassische Methode, um euer Spiel schneller zu gestalten, ist die Nutzung eines separaten Render-Threads. Die Spielsimulation, die Update-Physik, die KI und all das laufen auf einem eigenen Thread, während das Rendering davon entkoppelt parallel abläuft, üblicherweise ein Frame später. Manchmal kann es so mit einer willkürlichen Rate rendern und updaten. In Paradise haben wir es mit einem Frame entkoppelt, also waren wir stets einen Frame hinter dem Update, aber parallel zum nächsten.
Das stimmt. Die Latenz ist ein geringeres Problem und es hilft euch dabei, etwas mehr aus diesen ziemlich festen Beschränkungen auf 60 herauszuquetschen. Beim Single-Threading haben wir aufeinanderfolgende Updates statt eines Renders, und das alles innerhalb eines Threads. Einer der Vorzüge davon ist die Latenz. Das ist eine große Sache. Ein weiterer Punkt ist der Arbeitsspeicher. Man bekommt eine große Menge an Arbeitsspeicher zurück, weil man nicht buffern muss.
Wenn man zwischen Threads buffert, muss man einige Kopien des aktullen Spielstatus und der Daten behalten, damit es sicher parallel ausgeführt werden kann. Das resultiert in einer Menge Mehraufwand. Man muss die Sachen umleiten und wenn man das nicht tut, braucht man eine gute Synchronisation. Ich denke, im Vergleich mit Paradise haben wir rund 20 Megabyte an Arbeitsspeicher eingespart. Das ist ziemlich viel – und das nur, weil wir diesen Thread und das ganze, damit zusammenhängende Buffering entfernt haben. Ein Bestandteil unserer neuen Architektur ist die Kommunikation der Spielmodule untereinander. Es baut auf unserem gelernten Wissen auf, wir übernahmen die Ideen aus Paradise und haben sie auf andere Art und Weise implementiert: Das ist die neue Engine.
Es gab viel copy and paste des Paradise-Codes, da dieser Code gut genug war. Ob neue Engine oder nicht, es ist mindestens Version 2.0 der Paradise-Engine, nicht 1.1 oder etwas in der Art.
Das ist eine Möglichkeit, das Ganze zu betrachten.
Auf der optischen Seite ist es sicherlich neu.
Sagen wir es so: Es ist eine neue Architektur, aber wir haben die besten Codezeilen aus Paradise in diese Architektur übernommen, wenn es Sinn ergab. Ein gutes Beispiel dafür ist Black. Hier haben wir viele der Rendering- und Phyik-Codezeilen von Burnout 3 übernommen. Es war eine völlig neue Architektur, eine komplett neue Engine, aber wir haben viele der Low-Level-Bausteine wiederverwendet, um uns bei der Entwicklung von Black zu helfen. Das trifft noch immer zu. Wir haben nicht jede Codezeile neu geschrieben. Das wäre Wahnsinn.
Jedes Unternehmen nimmt seine guten Sachen und nutzt sie erneut. Wir haben nicht die gesamte Architektur oder Engine genommen, sondern große Teile des Codes in die neue Architektur integriert. Das haben wir schon immer getan. Wir haben es vollständig auseinander genommen und es in einer unterschiedlichen Struktur wieder zusammengesetzt, ersetzten einige Dinge, schrieben manche Teile neu und nutzten einige der guten Elemente erneut. Aber was die Architektur anbelangt, besteht die Engine aus einer brandneuen Struktur.