Übersetzung "Neuer Einblick in die Entwicklerküche"

[Gast]

Ich habe mal den in "Neuer Einblick in die Entwicklerküche" verlinkten Blogeintrag relativ frei übersetzt:



Fortschrittliche Spieletechnologie


Einleitung

Mein Name ist Paul "Locki" Wedgewood, Besitzer und leitender Spieledesigner bei Splash Damage - den Entwicklern von id Software’s Enemy Territory: Quake Wars (ETQW).


Vergangene Projekte

* 2000/2002 - Quake 3 Fortress - http://www.q3f.com (Projektleiter)
* 2002/2003 - Wolfenstein: Enemy Territory (Leitender Spieledesigner)
* 2003/Jetzt - Enemy Territory: Quake Wars (Leitender Spieledesigner)


QuakeCon 2006 und die ersten Eindrücke der Besucher

Wie immer war die QuakeCon 2006 einfach nur erstaunlich. Ich kann bestätigen, dass sich die QuakeCon in den sieben Jahren, in denen ich sie nun besucht habe, weiterentwickelt hat. Was mit einer einfachen LAN-Party begonnen hat ist nun eine Feier für id Software und alles damit Zusammenhängende - Zocken, Turniere, Modding, Präsentationen, verrückte Kostüme, Partys und die sonstige Unterhaltung - alles war perfekt organisiert. Aber abgesehen davon war für mich der größte Moment, endlich mitzuerleben wie die Multiplayergemeinschaft Enemy Territory: Quake Wars spielte. Ich genoss es.

Überraschenderweise kamen die meisten Fragen zur Technik. Die Besucher der QuakeCon schienen schnell zu verstehen, dass der Fokus des Spieles auf dem Zusammenspiel der Spieler liegt und nur wenige brauchten eine Erklärung wer die Strogg sind (und warum die Teams asymmetrisch sind), aber mit Ausnahme der Modder und anderer Entwickler waren die meisten davon überrascht, dass wir beteuerten mit der Quake 3-Engine angefangen haben.

Im heutigen Tagebucheintrag erläutere ich die Herausforderung, der sich Splash Damage und id stellen mussten, indem wir eine fortschrittliche Multiplayer-Engine erstellt haben, die die neue "MegaTexture" Technologie, bruteforce rendering, eine erweiterte Fahrzeugphysik und streambasierte Netzwerke beherrscht, alles mit dem Ziel das Eintauchen des Spielers in das Spiel und somit letztendlich auch das Spielgefühl zu verbessern.


Die erste Entscheidung

Mein guter Freund Kevin Cloud (Mitbesitzer von id Software und künstlerischer Leiter bei ETQW) und ich arbeiteten im Sommer 2003 zusammen an einem übergeordneten Konzept für ETQW (ungefähr zu der Zeit als unsere beiden Firmen die Arbeiten an Wolfenstein: Enemy Territory abschlossen).

Für uns beide war die Vision von ETQW’s Gameplay und dem Universum in dem es spielt ziemlich eindeutig...
Wir beide lebten und atmeten Wolfenstein: Enemy Territory nun für eineinhalb Jahre und hatten Millionen Ideen zum Teamplay in Enemy Territory; auch heute bleibt das unsere gemeinsame Leidenschaft.

Wie dem auch sei, ETQW wird trotz unserer geringen Erfahrung mit kommerziellen Projekten Splash Damage’s erstes gewinnorientiertes Spiel sein und hat, anders als Wolfenstein: Enemy Territory kein bestehendes Spiel, Engine oder Grafiksätze als Basis. Ich war mir immer sicher, dass das Spieldesign und die künstlerische Ausarbeitung dem Gameplay und dem Quake-Universum gerecht werden, hatte aber wenig Vertrauen in die Technologie. Wir wussten, dass die Doom 3-Engine die Qualität bieten würde die wir wollten, waren uns aber wie die meisten unsicher, ob man sie zu einer Engine für große Außenlandschaften erweitern könnte. Zusätzlich brauchten wir eine fortschrittliche Fahrphysik, streambasierte Netwerke und eine Menge anderer Eigenschaften, die man für ein rasantes Multiplayer-Actionspiel, das in weitläufigen Außenlandschaften spielt, benötigt. Die Programmierer von id hatten bereits während der Entwicklung von Doom 3 im Rahmen von Physik- und Fahrzeugtests mit einigen dieser Elemente experimentiert und dieses Wissen kam uns nun zu Gute, aber wir standen dennoch vor einer großen Herausforderung.


Landschaftsdarstellung

Nach neun Monaten voller Versuche mit verschiedenen Technologierichtungen bei Splash Damage gingen wir kleinlaut zu id Software. Ironischerweise brauchte John Carmack ungefähr neun Sekunden um uns die Lösung für unsere Probleme zu präsentieren - warum sollten wir nicht die gesamte Landschaft mit einer einzigartigen, bis zum Horizont ununterbrochenen Textur darstellen? Zusätzlich sollten wir den Nebel abschaffen, damit man diese Textur komplett sehen kann. Einfach, oder?

In Wahrheit ist dies eine naive, aber einfache Idee. Ähnlich wie Normal-Mapping (das Auftragen einer hochauflösenden Textur auf ein Model mit nur wenigen Polygonen lässt dieses detaillierter aussehen) trägt John Carmack’s Programmcode eine detaillierte Textur auf die vergleichsweise einfach gehaltene Landschaft auf - das Ergebnis (nach ungefähr einem weiteren Jahr gemeinsamer Entwicklungszeit unserer beider Firmen) war ein System zur Darstellung der Landschaft das einige zusätzliche Vorteile für das Gameplay hatte. Wir konnten nun die Bodenhaftung der Fahrzeuge, Partikeleffekte, Geräusche und diverse andere Elemente die das Gameplay beeinflussen direkt von der MegaTextur (anstatt von den darunter liegenden Polygonen) auslesen. Dies bietet eine größere Genauigkeit für diese Effekte während wir noch weniger Polygone für die Landschaft benötigen. Ihr könnt euch sicher vorstellen, wie die nächsten Schritte mit dieser Technik aussehen könnten, aber dazu später mehr.


Fahrzeugphysik

Für die meisten Multiplayerspiele wird ein Singleplayerspiel als Basis benutzt. Aber wenn man das macht, ist man als Entwickler gezwungen die Effekte und die Physik aus dem Ursprungsspiel zusammenzustreichen damit es möglich wird, alle benötigten Daten über Internet oder LAN zu verschicken. Die Entscheidung ETQW von Grund auf als reines Multiplayerspiel zu programmieren half uns dieses Problem zu umgehen. Landschaftsdarstellung, Physik und Netzwerkcode wurden von Anfang an auf Multiplayer ausgelegt.

Anstatt Fahrzeuge als eine einfach Box, die sich physikalisch über ebenes Gelände bewegt, zu betrachten war uns klar, dass wir Fahrzeuge, die das Charakterklassensystem verstärken, und Transportwege, die bestimmte Fahrzeugtypen erzwingen, brauchten - wir wollten eine bessere Sprung-, Flug- und Geländephysik. Jan Paul von id Software und Gordon Biggans von Splash Damage arbeiteten zusammen und heraus kam etwas, das mehr einer Singleplayer-Fahrphysik mit realistischen Radaufhängungen, Antrieben und Kollisionen ähnelt. Dies war einer der Schlüssel zum Gameplay, weil wir, obwohl wir eine traditionelle Arcade-ähnliche Tastaturbelegung verwenden, eine realistische Reaktion auf Benutzereingaben (und somit ein besseres Gefühl für das, was man mit dem Fahrzeug machen kann) wollten.

Der Beweis, dass wir dies geschafft haben, war für mich erbracht, als wir die Unterstützung für analoge Eingabegeräte einbauten. Mit der analogen Fahrzeugsteuerung (genauere Beschleunigung, Lenkung und Bremsen als mit der Tastatur) wurde mir klar, dass sich unser Physiksystem eher wie das eines guten Singleplayer Renn- oder Abenteuerspiels auf einer Konsole und nicht wie eine gewohnt schlechte Multiplayerphysik anfühlt. Ich bin mit dem Ergebnis sehr zufrieden. Während wir uns jetzt der Beta nähern konzentrieren wir uns darauf, die Steuerung mit Tastatur und Maus so zu verbessern, dass wir die Vorteile von analogen Eingabegeräten simulieren können.


Netzwerk

Es ist nicht vielen Leuten bekannt, dass Wolfenstein: Enemy Territory seinem Vorgänger Return to Castle Wolfenstein gegenüber eine Menge Vorteile im Netzwerk hatte, aber das Netzwerkmodel von Doom 3 ist komplett anders und so konnten wir diese (wie Anti-Lag für verbessertes Snipern) nicht übernehmen.

Anstatt dessen brauchten wir einen komplett neuen Ansatz; wir wollten, dass jeder auf dem Schlachtfeld exakt das Gleiche sieht, und, was fast genauso wichtig ist, dass jeder so weit wie möglich sieht.

Die erste Idee wurde "Area of Relevance" getauft. Ähnlich "Level of Detail" bei Grafiken (oder Stephen Hawkin’s Zeitkegel - abhängig von der Sichtweise) ist es ein Satz von Kreisen die von dir ausgehen und von denen die zurückkommende Datenmenge abhängt, je nachdem was dich auf diese Entfernung beeinflussen kann. Ein gutes Beispiel dafür ist das Zielfernrohr der Scharfschützen. Wenn du dieses nicht benutzt bekommst du weniger Informationen über weit entfernte Spieler - zum Beispiel in welche Richtung sie schauen -, aber sobald du heranzoomst verengen wir diesen Kegel (und das für dich relevante Gebiet) und du bekommst diese Daten öfter.

Ein weiteres Merkmal ist das auf geteilten Streams basierende Netzwerk. Die Daten werden auf zwei Ströme aufgeteilt, einer mit Dingen die sehr oft passieren und die der Client gut voraussagen kann (wie bestimmte Aspekte der Fahrphysik) wird selten übertragen, während der andere mit seltenen Ereignissen (z.B. Artilleriebeschuss) in Echtzeit gesendet wird. Dies allein halbiert die benötigte Bandbreite.


Die Zukunft

An diesem Punkt werden für unsere Programmiere nun Performanceoptimierungen im Vordergrund stehen. Angeführt von unserem technischen Direktor Arnout "RR2DO2" van Meer (der auch leitender Programmierer bei Wolfenstein: Enemy Territory und unserem ursprünglichen Mod-Projekt Quake 3 Fortress war), bin ich mir sicher dass wir in guten Händen sind und bin sehr stolz darauf, dass unsere Firma mit Enemy Territory: Quake Wars ihren Teil zu einer komplett neuen Generation von id Technologie beisteuert.

[DP-Bl00dy]

aehm ja.nen bissel viel text würd ich sagen.

[eiM]

hey thx coole arbeit.... ich habs mir zwar nicht durchgelesen weil ich grad keine zeit hab mach ich aber später mal

[Flitsche]

Original geschrieben von DP-Bl00dy
aehm ja.nen bissel viel text würd ich sagen.

schnauze 06er..
genau um den text gehts hier du idiot!

thx @ maniac, ich find so tagebücher immer sehr interessant- kann se zwar in englisch lesen, wusste aber ohne deinen post nicht, dass es existiert!

[SmuBoB]

Landschaftsdarstellung, Physik und Netzwerkcode wurden von Anfang an auf Multiplayer ausgelegt.

[cass]

haben will, haben will, haben will

[Chckn]

Danke für die Arbeit

[jo0]

thx! kannst das von mir aus auch öfters machen :P

naja ich kauf mir das game sofort