SCB|Sean Tracy im Interview mit Gamers Nexus(Teil1)

Steve Burke, Chefredakteur der Spiele-und-Hardware-Webseite Gamers Nexus, konnte das Star Citizen Team besuchen und verschiedene Interviews führen. Als zweites traf er Technical Director Sean Tracy. Wir liefern Euch hier eine Zusammenfassung. Viel Spaß beim Lesen!
[Der genaue Tag des Interviews wird leider nicht genannt, es muss aber zwischen dem 19. und 23.09. stattgefunden haben. Das Interview wird in zwei Teilenveröffentlicht, hier geht es zum zweiten Teil.]

• Wie Chris Roberts schon erwähnte, nennt man die Engine intern nicht mehr CryEngine, sondern StarEngine. Dieser Name kam irgendwann auf, Sean Tracy kann nicht sagen, inwieweit er offiziell ist.
• Es ist jedenfalls eine "ziemlich andere" Software als die CryEngine. Man ist von dieser schon vor einer Weile abgezweigt "“ nach seiner Erinnerung mit Version 3.7 oder 3.8 Anfang 2015 "“ und hat seitdem keine neue Version der CryEngine mehr eingesetzt.
• Die Entscheidung fiel, nachdem Integrationen immer schwieriger wurden. Sean Tracy erklärt: Wenn man ein Spiel mit "Middleware" [Teile einer Game-Engine, die spezialisierte Aufgaben lösen wie Physik-, Grafik- oder Netzwerkfunktionen] entwickelt und diese für den eigenen Bedarf anpasst, kommt irgendwann der Punkt, an dem neue Versionen des Herstellers der Middleware-Lösung immer schwieriger einzufügen sind. Man beginnt also, zu selektieren: Wir übernehmen dieses Feature, aber dieses nicht. Jedoch weiß man vorher nicht, ob evtl. gegenseitige Abhängigkeiten bestehen, die bei solcher Auswahl später zu Problemen führen. Daher stoppte man die Integration neuer CryEngine-Versionen vollständig.
• Er selbst kam vor ca. zweieinhalb Jahren zu CIG, nachdem er als Crytek-Mitarbeiter die Übernahme neuer Versionen durch CIG betreut hatte, sich dann aber irgendwann dachte: Ich gehe mal besser da rüber.
• Eine der großen Modifikationen der CryEngine war die Umsetzung auf 64 Bit, die Chris Roberts bereits nannte (er war beim Interview mit Chris anwesend). Allerdings sei vielleicht nicht ganz deutlich geworden, dass nicht die gesamte Engine auf 64 Bit umgestellt wurde. Vielmehr besteht die CryEngine aus weitgehend unabhängigen Modulen, und für die meisten von ihnen sind 64 Bit völlig unnötig (oder schon vorhanden) wie z. B. Physik, Rendering oder AI [künstliche Intelligenz].
• Die Ausweitung der Bitbreite war nur im Zusammenhang mit Koordinaten erforderlich, um die immensen Dimensionen abbilden zu können. Das aktuelle Maximum, das man nun unterstützt, steht an sein Board geschrieben: es hat 18 Nullen.
• Für Leute, die von Crytek kamen, war das Neuland: dort arbeitete man mit Maßen von vier, vielleicht maximal acht Kilometern in einem Level. Das hier aber "kann einen schon verwirren", meint Sean. Man arbeitet an etwas und klickt Herauszoomen"¦ und zoomt noch mal heraus"¦ und nochmal "“ und es geht immer weiter. Das Gefühl für Skalen geht da leicht verloren. Ein Planet, den man sich so anschaut, umfasst in Wahrheit Tausende von Kilometer. Im ersten System, das man gerade baut (Änderung am Quantum Drive vielleicht noch vorbehalten) dauert die Reise von einem Ende zum anderen rund 45 Minuten. "Und das ist nur ein System." Und denkt man an dieses System als ein Level, so bedeutet das keinen Ladebildschirm über 45 Minuten Reise mit Quantum Drive (0,2-facher Lichtgeschwindigkeit).
• Im Fazit war also die Umwandlung der CryEngine auf 64 Bit für Physik und Positionierungen erforderlich.
• Neben der benötigten Abbildung von Koordinaten für einen großen Weltraum bringt diese Modifikation jedoch keine zusätzlichen Vorteile, soweit sich Sean bewusst ist. Selbst in Sachen Performance ergibt sich, wenn überhaupt, eher ein ganz leichter Nachteil. Dafür hat man neue Prozessoren besser unterstützt, sodass es unterm Strich schneller wurde.
• Zum Thema prozedurale Generierung bei Planeten: Der wesentliche Unterschied zwischen Version 1 und Version 2 der Planetentechnologie ist, dass mit v1 in der Gamescom-Demo nur eine Gelände- bzw. Materialschicht (Layer) pro Planet gezeigt werden konnte. Ja, es gab verschiedene Texturen für unterschiedliche Sichtdistanzen, aber alle Himmelskörper hatten nur einen Layer über die gesamte Oberfläche. Die meisten Fälle prozeduraler Generierung, die man [in der Branche] so sieht, geben sich damit auch zufrieden und gehen nicht darüber hinaus.
• Die jetzige Möglichkeit mehrerer Layer mit v2 bringt sie aber viel näher an die Möglichkeiten, wie man in Crysis bzw. bei Crytek das Gelände von Leveln gestaltete: dort hatten die Künstler Zugriff auf bis zu 16 Layer. Genau das "“ nur auf irrsinnige Größe skaliert "“ will man dem eigenen Team nun auch an die Hand geben. Nur so könne man die Qualität von First-Person-Shootern erreichen, die man anstrebt.
• Ein weiterer Vorteil von v2 sind die Biome, die es in v1 nicht gab. Jedes Biom hat wiederum eigene Layer für Objektplatzierungen, Wettersystem, Vegetation usw.
• Hier bewährte sich nach Ansicht von Sean Tracy, dass man damals auf die CryEngine gesetzt hatte; denn so konnte man nun eine Vielzahl von Werkzeugen nutzen, welche diese für genau solche Zwecke bereits besaß, beispielsweise für Gelände-Layer oder Vegetation. In Crysis, gibt Sean ein Beispiel, gab es nur rund 16 unterschiedliche Palmen. Diese aber in verschiedener Drehung platziert führten eben nicht zum Eindruck von Wiederholung, sondern funktionierten für ganze Wälder ziemlich gut. Genau dafür gab es schon damals starke Werkzeuge, die nach bestimmten Regeln in Abhängigkeit vom Terrain die Platzierung regelten (wie ist z. B. Gras an einem Berghang ausgerichtet, und wie verhält sich ein Baum an gleicher Stelle). Grund dafür war die Sichtweise bei Crytek: Werkzeuge sollten 90% der Arbeit erledigen können, damit die Künstler sich auf die restlichen 10% konzentrieren konnten. Es war also keine verrückte Idee, auf die CryEngine zu setzen, wie viele Leute sagten, meint Sean; sie enthielt viele sehr, sehr mächtige Werkzeuge, die man natürlich weiterverwendet, wo es sinnvoll ist.
• Ein großes Thema im Kontext der prozeduralen Planetengenerierung ist noch das Überblenden von aneinandergrenzenden Biomen. Was Sean Tracy heute dazu sagen kann, dürfte sich daher in der Zukunft noch ändern. Die Überlegungen zurzeit sind folgende: Es gibt eine Verteilungskarte (distribution map). Diese kann entweder alle Platzierungen übernehmen, jedoch erhält man so keine perfekten Überblendungen. Alternativ kann man an den Grenzen der Verteilungskarte bestimmte Entfernungen als "Überblendungsdistanzen" definieren, wo der Übergang stattfindet. Hat man aber viele [verschiedene] Biome, werden die Regeln, die auf die Überblendung angewendet werden, vermutlich sehr unterschiedlich sein mit Blick auf Dinge wie Vegetation oder platzierte Objekte. Der Übergang von Wüste auf Dschungel ist beispielsweise noch recht einfach. Bei einem bergigen Wald, einem Dschungel und einer Stadtzone aber stellt sich die Frage: Was machst du? Die Überblendungsdistanz wird sich deshalb danach richten, um welche Art eines Biomes es sich handelt. Im Moment versucht man, ein Regelsystem zu entwerfen, das einerseits stabil genug ist, gute Überblendungen zu liefern, jedoch nicht so komplex wird, dass niemand mehr versteht, was da eigentlich passiert. Künstler werden sicherlich hier und da manuell korrigieren müssen "“ Ziel ist aber, die genannten 90% mit regelbasierten Werkzeugen zu erledigen.
• Die Citizencon-Demo zur v2 wird viele dieser Überblendungen bereits enthalten, jedoch noch nicht für große Objekte.

Zum zweiten Teil des Interviews

Quelle: Youtube
Übersetzung: StarCitizenBase
Social Media: FaceBook | Twitter | Community Hub

Quelle:Starcitizenbase
Link:http://starcitizenbase.de/sean…-mit-gamers-nexus-teil-1/
Autor:Yatan