Einführung

Vor kurzem wurden Geschichten über klassische Spiele in der GDC gut aufgenommen, aber es gab nur sehr wenige Geschichten über die Werkzeuge für ihre Entwicklung. In dieser Artikelserie werden wir versuchen, diese Lücke zu schließen, indem wir Menschen interviewen, die eine wichtige Rolle in der Geschichte der Spieleentwicklungstools gespielt haben.

In den ersten beiden Teilen der Serie haben wir mit John Romero (über TEd Editor) und Tim Sweeney (über Unreal Editor) gesprochen .

Beim Schreiben des dritten Artikels hatte ich die Ehre, mit Chris Norden über die Tools zu sprechen, die er für den FPS / RPG-Hybrid namens Deus Ex entwickelt hat . Ich habe mit Chris in San Francisco auf der GDC 2018 geplaudert.

Vor dem Ionensturm: Ursprung und Spiegel

David Lightbone: Wie bist du zu Deus Ex bei Ion Storm gekommen?

Chris Norden: 1994 arbeitete ich als Origin-Programmierer in Austin. Mein erstes bezahltes Projekt war Jane's Combat Simulations AD-64D Longbow von Jane's Combat Simulations. Es war ursprünglich ein Arcade-Spiel namens Chopper Assault. Zusammen mit Andy Hollis habe ich zwei Jahre daran gearbeitet.



Nach der Veröffentlichung des Spiels möchte ich als letztes einen weiteren Militärsimulator machen, weil ich absolut nicht alles Militärische mag. Von Zeit zu Zeit sprach ich mit Warren Spector, der auch bei Origin arbeitete. Er mochte die Handlung Rollenspiele wirklich. Ich dachte mir: "Ich mag diese Spiele auch, ich möchte an so etwas arbeiten!"

1996 trat Warren von Origin zurück und wurde Leiter der Looking Glass Studios in Austin, deren Existenz damals niemand kannte. Dieses Studio hat Ports für Mac-Spiele wie das Links 386 Pro erstellt . Sie war auch dabei, ihr eigenes Golfspiel namens British Open Championship Golf zu entwickeln.

Origin entwickelte noch Ultima Online. Sie wurde Multima genannt und scheint den Ultima VII-Motor verwendet zu haben. Ich habe ein bisschen mit ihm experimentiert, bis ich Origin verlassen und mich Warren in Looking Glass angeschlossen habe.

[Anmerkung des Autors: Das Hauptstudio von Looking Glass befand sich in Cambridge, Massachusetts, in der Nähe von Boston]

Warren schrieb ein Designdokument und wir arbeiteten einige Zeit an einem Rollenspiel mit der Abkürzung AIR (von Austin Internet Role-Playing), das ein Online-Projekt sein sollte. Wir wollten etwas in 3D machen, denn während 3D-Beschleuniger gerade erst auftauchten. Wir haben einen Prototyp von Voodoo 1 bekommen und einen kleinen Motor auf GLide geschrieben.

Wir haben uns mit dem Büro von Looking Glass in Cambridge zusammengetan. Nach der Veröffentlichung der British Open half ich Mark LeBlanc und Doug Church mit einer Dieb-Engine namens Dark Engine .

Aus finanziellen und anderen Gründen fühlte sich Looking Glass zu dieser Zeit nicht sehr gut. Die Firma hatte tolle Spiele, aber sie verkauften sich schlecht. Daher wurde nach etwa einem Jahr beschlossen, das Büro in Austin zu schließen.

[Anmerkung des Autors: Chris hat absolut Recht mit den Spielen - Ultima Underworld, System Shock und Terra Nova wurden von Kritikern sehr gut aufgenommen, sie waren einige der besten Spiele der 90er Jahre]

Zum Zeitpunkt der Schließung des Büros gab es nur wenige von uns: Warren, ich, Al Yarusso, Harvey Smith, Steve Powers. Wir wollten alle noch an diesem Rollenspiel arbeiten. Nachdem das Büro geschlossen war, hielten wir uns ungefähr sechs Monate lang fest und hofften, dass wir eine neue Firma gründen und etwas unternehmen könnten. Wir hatten ein sehr gutes Designdokument, wir haben angefangen, es an Verlage zu „verkaufen“ und mit verschiedenen Leuten zu kommunizieren. Ich erinnere mich nicht einmal an alle Verlage, die wir kontaktiert haben. Einer dieser Leute war John Romero und Tom Hall, die zusammen mit Eidos daran arbeiteten, in Dallas ein neues Studio namens Ion Storm zu schaffen.


Ich kannte John aus den frühen Jahren von Id. 1991 veranstaltete MTV in Dallas eine riesige Schiffsparty, die Wolfenstein 3D gewidmet war. Es gab zwei VR Virtuality Arcade Machine- Maschinen. Zu dieser Zeit war ich ein Kind und dachte: "Gott, das ist das Coolste auf der Welt!" Ich habe John damals getroffen, als er im Stil von "Ich bin zu reich, um mir um irgendetwas Sorgen zu machen" lebte.

John ist eine wundervolle Person, ich habe mit ihm bei Monkeystone Games zusammengearbeitet und das Spiel für Gameboy Advance entwickelt, aber das ist eine andere Geschichte.

[Anmerkung des Autors: Das Spiel hieß Hyperspace Delivery Boy. Für Gameboy Advance sollte es von Majesco veröffentlicht werden, aber im letzten Moment weigerte sich das Unternehmen, es zu veröffentlichen.]

Wir haben mit Romero und Tom Hall gesprochen und sie sind: "Warren, du bist cool, lass uns dieses Spiel machen!". Und Warren antwortete: „Es gibt einen Haken. Wir werden nicht nach Dallas ziehen. Wir werden nicht nach Kalifornien ziehen. Wir werden überhaupt nicht umziehen. Wir werden das Studio in Austin behalten. Wir bleiben also völlig autonom. Sie geben mir die vollständige Kontrolle über alles. Du wirst mir Geld geben, und alles wird gut. “ Sie antworteten: „Okay, es passt zu uns. Gelöst. "

[Anmerkung des Autors: Dies ist natürlich eine zu vereinfachte Version der Verhandlungen, aber sie gibt eine Vorstellung davon, was passiert ist.]

Warren hatte zu dieser Zeit ein großartiges Designdokument für das Troubleshooter-Spiel, das sich allmählich in ein Deus Ex-Designdokument verwandelte.

Also gründeten wir sechs Ion Storm Austin. Zu dieser Zeit war ich technischer Direktor, Leiter der IT-Abteilung „Homo Arom“, Sicherheitsdienst und führender Ingenieur. Wir hatten nicht genug Leute, um all diese Dinge zu tun. Daher war es notwendig, schnell Interviews zu führen und Mitarbeiter zu rekrutieren.

Das Team war winzig. Wir hatten drei Ingenieure: mich, Scott Martin und Al Yarusso. Sheldon Pacotti wurde als Drehbuchautor eingestellt. Wir hatten zwei Designteams mit jeweils drei Personen. Einer wurde von Robert White geführt, der zweite von Harvey. Es schienen sechs weitere Künstler unter der Leitung von Jay Lee zu sein.

Oh, und ich habe auch Alex Brandon engagiert, weil ich ein großer Fan seiner Musik für Unreal war. Jetzt sind wir gute Freunde. Ich stellte ihn seiner zukünftigen Frau vor, weil wir Freunde in der High School waren. Er ist ein großartiger Typ: ein ausgezeichneter Musiker und mit technischen Details bestens vertraut.

Dann haben wir einen Administrator eingestellt, und das war's. Und dann standen wir zweieinhalb Jahre vor höllischer Arbeit! [lacht]

Wahl zwischen Unreal- und Quake-Engines

JL: Während der Rest von Ion Storm mit der Quake-Engine arbeitete, haben Sie sich für Unreal entschieden. Können Sie erklären, wie Sie zu dieser Entscheidung gekommen sind?

KN: Egal wie sehr ich die Quake-Engine respektiere, ich wusste, dass wir zu diesem Zeitpunkt keine Unterstützung haben würden. Wir haben ein sehr spezifisches Spiel entwickelt, in dem wir alles machen wollten. Quake war ein Schütze und nichts weiter. Wenn wir versucht hätten, etwas anderes als FPS zu tun, hätte dies viel Arbeit gekostet, und wir hätten keine Unterstützung von Id erhalten. Sie brannten einfach eine CD mit dem Code, gaben sie den Entwicklern und ließen sie in Ruhe.

JL: In meinem Interview mit Tim Sweeney nannte er das Quake Engine-Lizenzmodell der damaligen Zeit "eine Viertelkopie-Operation".

KN: Ja, absolut richtig! Ich stimme zu, der Motor war unglaublich. Zu dieser Zeit machte er eine Revolution, aber wir wussten, dass ein Team von drei Ingenieuren den Motor nicht umschreiben und keinen eigenen schreiben konnte. Wir hätten einfach nicht genug Zeit.

Zu einer Zeit war ich ein großer Fan der Amiga, C64 und PC Demo Szene. Ich fing an, ein Videospiel namens Unreal anzuschauen und dachte: „Oh mein Gott, ja, es gibt RGB-Beleuchtung und volles 3D. Die Engine verwendet MMX, SSE und 3DNow. Er sieht sehr cool aus! " Da wir jedoch keine detaillierten Informationen über ihn finden konnten, planten wir eine Reise zu Digital Extremes in London (Kanada). Wir haben uns mit Tim und seinem Team getroffen, sie haben uns alle Eigenschaften des Motors gezeigt. Ich habe auch Carlo Vogelsang getroffen , den ich jetzt mit Sony zusammenarbeite - er ist in der Playstation-Abteilung. Er schrieb die Galaxy Audio Engine: fast alles in Assembler, ein Super-Hardcore-Typ. Der Motor hatte ein Partikelsystem namens Feuer. Das alles war im Motor. Ich dachte: "Leute, ich mag deinen Ansatz."


Zu dieser Zeit konzentrierten sie sich darauf, äußerst praktische Tools zu entwickeln, die noch niemand zuvor gemacht hatte. Quake-Tools waren gut, aber für nicht-technische Benutzer schienen sie nicht sehr freundlich zu sein. Wir hatten Designer, die keine technischen Fähigkeiten hatten, und sie mussten herausfinden, wie man diese Programme verwendet.

Also beschlossen wir: „Diese Leute haben gute Werkzeuge, jeder hilft uns sehr, es gibt viele alte Leute, die in den 80ern Hardcore-Sachen geschrieben haben. Wie ist die Lizenzierung angeordnet? “ Sie antworteten: "Wir haben das noch nie gemacht, für uns ist es etwas Neues." Ich denke, dass sie zu dieser Zeit nicht verstanden haben, wie man ein Lizenzmodell erstellt. Wir sagten: "Wir haben Warren Spector und er möchte ein Spiel auf Ihrer Engine erstellen." Als sie das hörten, wurde klar, dass sie wirklich mit uns arbeiten wollten.

Ehrlich gesagt erinnere ich mich nicht an die Details unserer Lizenzvereinbarung. Tim erinnert sich wahrscheinlich. Ich kann mich nicht erinnern, wie viel wir bezahlt haben, aber ich denke nicht so viel. "

JL: Wahrscheinlich vergleichbar mit der Anzahl der IDs, die zu diesem Zeitpunkt nach Quake gefragt wurden?

KN: Ich denke weniger! Und das war ein weiteres Plus. Ihr Motor war relativ neu, aber wir waren nicht die ersten Lizenznehmer. Eines der ersten war Wheel of Time und Klingon Honor Guard.

[Anmerkung des Autors: Weitere Informationen zur Lizenzierungshistorie von Unreal Engine finden Sie in meinem Interview mit Tim Sweeney über Unreal Editor. ]

Deshalb haben wir uns für es entschieden. Die Entwickler gaben uns den Quellcode und sagten: "Wir werden Sie so schnell wie möglich unterstützen." Wir haben immer von Angesicht zu Angesicht gesprochen. Wenn wir eine Frage hatten, schickten wir eine E-Mail: Es gab kein technisches Support-System.

Wir hatten viele Probleme, weil sie dies noch nie zuvor getan hatten. Wir haben ihnen viel Code und Fragen geschickt, hatten eine lange Korrespondenz und erhielten Updates. Aber ich glaube, dass es die richtige Entscheidung war. Ich denke, wenn wir uns für Quake entscheiden würden, wäre das Spiel viel schwieriger zu erstellen.

Außerdem wurde ich Mitglied der Unreal Tech Advisory Group. Wir hatten die Idee des ersten technischen Treffens, bei dem sich die Leiter aller Unternehmen, die Lizenznehmer wurden (es waren zu dieser Zeit vier), versammelten, Möglichkeiten zur Verbesserung des Motors diskutierten, Tim wegen unbequemer Aspekte schimpften, mit Alkohol und Essen aussortierten in der Regel. Ich bin immer noch mit all diesen Leuten in Kontakt.

JL: Haben Sie etwas mit anderen Mitgliedern der Unreal Tech Advisory Group geteilt?

KN: Ich denke, wir haben hauptsächlich Verbesserungen am Unreal Editor geteilt. Der Motor war ausgezeichnet, aber er hatte noch einen langen Weg vor sich. Als wir dann noch mehr Designer und Künstler einstellen konnten, machten sie auch Vorschläge zur Verbesserung der Arbeitsprozesse. Wir haben sie entweder selbst implementiert oder an das Unreal-Team gesendet oder das Unreal-Team gefragt, ob sie es schneller machen könnten als wir.

Wir haben viele Änderungen am Haupteditor vorgenommen, aber die meisten betrafen nur unser Spiel. Wir haben einige der Verbesserungen geteilt, aber die meisten anderen Entwickler waren an völlig anderen Spielen beteiligt.

Ich musste eine Reihe von Systemen schreiben, von denen ich glaube, dass sie die ersten ihrer Art waren. Zumindest habe ich sie nie gesehen. Zum Beispiel ein Animationsmischsystem; Im Wesentlichen werden Morph-Ziele oder Mischformen heute so genannt. Ich kann mich nicht erinnern, dass jemand dies zu dieser Zeit in Spielen getan hat. Möglicherweise wurde es bereits irgendwo implementiert, aber vor der weit verbreiteten Nutzung des Internets war der Informationsaustausch sehr schwierig.

JL: Können Sie über die Änderungen sprechen, die Sie am Unreal Editor vorgenommen haben?

KN: Eines der Systeme, das zu diesem Zeitpunkt aus irgendeinem Grund nicht im Editor enthalten war, ist die Visualisierung von Kamera-Splines.

In den ersten Versionen von UnrealEd mussten Sie die Kamera ziehen und die Punkte ihres Pfades festlegen. In diesem Fall war es möglich, die Punkte zu sehen, aber nicht die Verbindungen zwischen ihnen, die den Weg der Kamera bestimmten.


JL: Es ist wie ein Punkt-zu-Punkt-Spiel, aber ohne Zahlen!

KN: Genau! Der Spline hatte Haltepunkte und Designer konnten nicht immer herausfinden, wie der Pfad aussehen würde. Sie wollten sehr genau wissen, wie sich die Kamera auf dem Weg bewegen würde. Also habe ich dieses System hinzugefügt und es hat ihnen gefallen.

Es war sehr einfach. Ich meine die Einfachheit des Codes: Zeichnen Sie die Koordinatenachsen an jedem Hauptkontrollpunkt und dann den Kontrollpunkt, um tatsächlich zu sehen, wohin er ging. Es hat dem Designer wirklich geholfen, und ein solches System herzustellen war sehr einfach. Ich weiß nicht, warum wir es hinzufügen mussten. Ich denke Tim dachte nicht, dass sie wirklich gebraucht werden würde.

DL: Das ist lustig, denn wenn Sie sich an die erste Demo von Unreal in der Öffentlichkeit erinnern, war das erste, was die Leute sahen, eine Kamera, die um das Schloss flog, das heißt, Epic schien keine Kamerapfade erstellt zu haben.


KN: Ich denke, der Grund war, dass viele ihrer Level-Designer Super-Technikfreaks waren und es gewohnt waren, solche Dinge in ihren Köpfen zu simulieren. Die Videospielbranche reifte jedoch allmählich, so dass es notwendig war, Tools für Menschen mit unterschiedlichen Erfahrungsstufen zu entwickeln. Nicht jeder Designer war Ingenieur, und heute noch mehr! Dies war eher die Ausnahme als die Regel. Daher sollte das Werkzeug bequem und einfach geworden sein.

Ich weiß übrigens immer noch nicht, warum Pawn mit dem Kopf eines Dinosauriers bezeichnet wird.

JL: [lacht] Ja, Tim und ich haben das in einem Interview besprochen! Haben Sie übrigens Ihre technologischen Entscheidungen bereut?

KN: Wir haben UnrealScript zu oft verwendet. Dies war einer der Fehler. UnrealScript war sehr flexibel, aber zu langsam. Wir mussten in nativem C viel mehr schreiben als in UnrealScript.

Echter Norden und falsche Pannen

[Anmerkung des Autors: In dieser Phase des Interviews habe ich den Deus Ex Editor (Version für UnrealEd) sowie die Deus Ex SDK-Dokumentation geöffnet.]

JL: Das Deus Ex SDK-Installationsprogramm verfügt über einen Docs-Ordner mit einigen Dokumentationsdateien, die Sie, Robert White, Sheldon Pacotti, Al Yarusso und Scott Martin anscheinend zu sponsern scheinen. Können Sie sagen, wer diese Leute waren und woran sie gearbeitet haben?

KN: Al war am Dialogeditor beteiligt. Scott arbeitete an AI. Ich habe ... alles getan. [lacht] Ich war unter anderem Regieassistent und leitender Programmierer. Aber wir haben ein bisschen von allem gemacht, denn im gesamten Projekt von Anfang bis Ende gab es nur drei Ingenieure.


Chris Norden (unten links), El Yarusso (rechts und oben auf Chris, mit einer Uhr auf dem Zeiger), Robert White (mittlere Reihe, etwas rechts von der Mitte, Sonnenbrille tragend), Sheldon Pacotti (unten rechts) und Scott Martin (in der zweiten) Reihe ganz rechts, auch mit Sonnenbrille)

DL: In der Dokumentation für den Editor gibt es einen Abschnitt, der besagt: "Unreal bietet keine native Unterstützung für vertikale Treppen, aber sie werden zu Deus Ex hinzugefügt." Können Sie uns mehr darüber erzählen?

KN: Die Treppen sind eine interessante Geschichte, weil wir uns im Level bewegen mussten und bei Ego-Shootern dieser Zeit traditionell geneigte Treppen und sanfte Anstiege verwendet wurden.

Eines von Warrens Dekreten (weil Design das Gesetz ist!) Sagte, dass ein Spieler in der Lage sein sollte, jede Mission auf irgendeine Weise zu erfüllen. Die Schlüsselidee des Spiels war, dass man es, wenn man es wünscht, ganz durchgehen kann, ohne zu schießen. Tatsächlich haben wir es nicht ganz geschafft - es gibt mehrere Zonen, in denen Sie ein paar Mal schießen müssen, aber wir waren uns sehr nahe.

DL: Ich denke, die Entwickler haben die Fortsetzungen geschafft.

KN: Ja wahrscheinlich.

Der Spieler sollte also in der Lage sein, das ganze Spiel zu durchlaufen, ohne einen Schuss abzugeben. Außerdem konnte er das ganze Spiel durchspielen, ohne etwas anderes als zu schießen. Der Spieler konnte das ganze Spiel durchlaufen, so dass es vom Feind nie entdeckt wurde. Es war möglich, es auf ganz andere Weise durchzugehen.

JL: War das Fehlen vertikaler Treppen eines der Themen, die Sie bei den Treffen der Unreal Tech Advisory Group mit Tim besprochen haben?

KN: Um zu antworten, muss ich im Skriptcode finden und nachsehen, ob dort „Fuck you, Tim!“ Steht. [lacht], denn genau das haben wir getan, als wir wütend waren - wir haben Kommentare aufgeschrieben, um uns später daran zu erinnern.

Als wir darüber nachdachten, wie wir vertikale Leitern unterstützen können, überlegten wir zunächst: „Lassen Sie uns die Geometrie erstellen und dann vielleicht knifflige physische Tricks ausführen, damit der Spieler mit synchronisierten Animationen auf die Balken greifen kann.“ Aber nachdem wir uns entschieden hatten - nun, das ist alles zur Hölle, zu kompliziert.

JL: [lacht]

KN: Wir mussten das sehr schnell erledigen, weil die Designer diese Mechanik erstellen wollten.

Infolgedessen musste ich zu höllischen Hacks gehen. Die Engine hatte das Konzept der "Texturgruppen". Im Wesentlichen handelt es sich um eine Zeichenfolgenbezeichnung, die bestimmten Texturtypen zugewiesen wird, um das Sortieren zu vereinfachen. Wir könnten sie im Code anfordern. Also dachten wir: "Warum machen Künstler nicht einfach einige Texturen, damit sie geklettert werden können?" Danach fügten wir sie einfach der Texturgruppe hinzu, führten einen Raycast durch, um sie zu erkennen, und klebten den Spieler dann einfach mit einigen Einschränkungen in Richtung seiner Bewegung an sie. Dies funktionierte gut, war aber nicht immer perfekt, denn als der Spieler an die Spitze der Textur kletterte, strahlte der Strahl nicht mehr hinein und wir mussten den Spieler nach oben und auf die Plattform schieben. Das heißt, die Lösung ist unvollkommen, aber als Ergebnis hat es funktioniert. Es war ein billiger und einfacher Hack.

Die heutigen Leser könnten denken: Warum gab es keine Treppen im Motor, ist das überhaupt logisch? Aber damals gab es nichts. Dies waren nur BSP-Fragmente, wir hatten keine statischen Netze, es gab nichts Vergleichbares.


JL: UnrealEd hatte einen sehr coolen Wendeltreppengenerator [lacht], aber es gab keine vertikalen Treppen.

KN: Ja, richtig ... Es scheint, dass wir Designer dafür beschimpft haben, weil es Löcher in BSP erzeugt hat. Die Treppe sah wunderschön aus, wenn nichts in der Nähe war. Sobald Sie jedoch anfangen, eckige Schnitte im BSP zu erstellen, können Sie kleine Löcher im BSP erhalten, durch die Sie fallen können, aber die Löcher selbst sind nicht sichtbar. Diese Funktion verursachte große Schmerzen und wir untersagten ihre Verwendung. Sie sah gut aus, war aber kaputt ...

DL: In der Dokumentation wird auch eine Klasse namens DeusExLevelInfo beschrieben, die Informationen zur Karte (z. B. Mehrbenutzer), den Namen des Autors der Karte, den Ort, an dem die Mission abgeschlossen wurde, die Missionsnummer usw. enthält. Aber ich möchte Sie nach TrueNorth fragen.

KN: [lacht] Es war eine BAM-Art von Unreal: Binary Angle Measurement Engine!

JL: Was sind das für verrückte Zahlen ?!

KN: Damals waren Gleitkommaoperationen sehr teuer. Das Eisen war schwach, aber nicht genug Gedächtnis. 360 Grad wurden nicht durch eine 8-Bit-Zahl beschrieben, die 255 Genauigkeitseinheiten liefern würde, dh etwa 1,4 Grad pro Einheit, was nicht ausreichen würde. Tim verwendete eine 16-Bit-Zahl für Orientierungen, was eine größere Genauigkeit ermöglichte.

Für einen Programmierer sind alle diese Zahlen recht einfach. Dies sind nur Zweierpotenzen, keine Probleme, Sie können sie alle in Ihrem Kopf berechnen. Aber Designer und Künstler hatten Probleme. Aus diesem Grund haben wir kleine Vereinfachungen entwickelt, damit Entwickler sich an sie erinnern können.

[Während wir mit dem Editor zusammengearbeitet haben, ist Chris in die Dekorationsklasse gekommen]



KN: Dekorationen waren auch eine große Klasse. Alle Netze, mit denen Sie interagieren können, sind Dekoration. Das heißt, fast alles im Spiel!

JL: Im Abschnitt "Dekorationen" der Dokumentation heißt es: "Wir warnen Sie, dass der Editor abstürzen kann, wenn Sie einige der unten nicht aufgeführten Felder ändern." Erinnerst du dich nicht, warum das passiert ist?

KN: [lacht] Ehrlich gesagt, ich erinnere mich nicht. Ich denke, weil Dekoration eine so große Klasse war und so viele epische Funktionen hatte, die auf seltsame Weise mit der Engine interagierten, dass wir einfach einem Designer erklären, der die technischen Feinheiten nicht versteht, warum ein bestimmtes Feld zu unerwartetem Verhalten führen kann Sie sagten: "Benutze es nicht, sonst stürzt der Editor ab."

JL: [lacht]

KN: So etwas wie eine Angst-Taktik. Bei den Treffen der Programmierer haben wir uns gefragt: Wie können wir den Benutzern erklären, dass dies zu Schäden an der BSP-Kette führt, und Sie müssen dies und das tun? Sagen wir ihnen einfach, dass der Editor abstürzen wird.

Ich sollte den Code noch einmal studieren, aber es scheint, dass wir uns sogar schuldig gemacht haben, an einigen Stellen absichtliche Fehler versteckt zu haben, um Benutzer zu erschrecken, die zu tief betrogen sind.

JL: Lass uns weitermachen. Im Abschnitt "Partikelgenerator" heißt es: "Eine der Hauptfunktionen besteht darin, dass es mithilfe von Triggern und UnTriggern ein- und ausgeschaltet werden kann." Das heißt, in der Version der Unreal-Engine, mit der Sie gearbeitet haben, war es unmöglich, Partikel ein- und auszuschalten?

KN: Damals nein. Wenn Sie ein Partikelsystem eingefügt haben, war es ständig vorhanden und wurde nie ausgeschaltet. Es scheint mir, dass dies ein seltsames Versehen ist.

Ansonsten war das unwirkliche Partikelsystem fantastisch. Die meisten wurden in Assembler geschrieben. Es war prozedural und im Vergleich zu allem anderen sehr gut geschrieben. Designer liebten sie. In der Tat sogar zu viel. Es war möglich, die gesamte Bildrate zu töten, und sie wurden verrückt und fügten immer transparentere Ebenen hinzu.

Zu diesem Zeitpunkt mussten wir noch Software-Rendering unterstützen, während Hardware-Rendering noch nicht weit verbreitet war. Tim hatte erstaunliche Programmierkenntnisse und schrieb einen großartigen Software-Renderer. Er war großartig.

[Beim Betrachten verschiedener Objekte im Spiel bemerkte ich eine Kategorie mit einem ungewöhnlichen Namen im Eigenschaftenfenster]

DL: Was ist diese Geruchseigenschaft?

KN: Die Tiere brauchten einen Duft, um eine Spur zu nehmen. In der Tat können Hunde Geruchsknoten verfolgen. Wenn ich mich richtig erinnere und dann durch die Levels ging, konnte der Spieler Geruchsknoten hinterlassen, die für eine bestimmte Zeit aktiv waren. Deshalb haben wir es so gemacht, dass Hunde ihn riechen können.

DL: Das heißt, wenn Sie sich hinter einer Kiste verstecken, werden die Leute Sie nicht finden, aber Hunde können ...

KN: Genau, weil dies in der Realität passiert und wir dachten, es wäre ein interessanter Gameplay-Aspekt. Es scheint jedoch, dass er am Ende herausgeschnitten wurde. Da es kein grafisches Feedback gab, war dieses Konzept dem Spieler schwer zu erklären.



[ Intro, — , . ]

: . . ...



KN: Nein, die Spiegel waren echt! Sie waren sehr langsam, deshalb haben wir Designer gebeten, sie selten zu verwenden. Dies sind jedoch echte Spiegel.

In der Tat, als ich den Lasercode schrieb ... [lacht]

DL: [lacht] Ich sehe, worauf Sie hinaus wollen ...

KN: ... ich musste tatsächlich nach Spiegeln suchen. Ich hatte eine Teststufe, in der ich den Code für alle Geräte getestet habe. Als ich den Laserpointer-Code schrieb, erstellte ich eine reflektierende Spiegel-Discokugel und baute dann einen Raum mit Spiegeln an beiden Enden. Ich nahm den Laserpointer, richtete ihn auf die Disco-Kugel und es funktionierte!

Natürlich fiel die Bildrate unter nichts, weil ich alle Zeilen verfolgen musste ...

Siehe das Befehlszeilen-Tool Light Wave: LWO23D

[Anmerkung des Autors: LWO steht für Lightwave Object. Dies ist das 3D-Geometrieformat von Newteks Lightwave 3D- Softwarepaket , das ebenfalls in Texas ansässig ist, wie das damalige Deus Ex-Team.]



Screenshot von Tacks Deus Ex Lab

JL: Warum hat sich Ihr Team für Lightwave entschieden?

KN: Unsere Künstler kannten ihn gut. Deshalb mussten wir uns anpassen.

JL: Erzählen Sie uns mehr darüber, warum Sie den Exporter als Befehlszeilentool geschrieben haben.

KN: Damals und auch heute schreibe ich oft kleine Befehlszeilen-Tools zur Automatisierung von Aufgaben. Ich bin ein Programmierer der alten Schule und mag keine unnötigen Komplikationen. Ich mag C ++ meistens nicht. Ich mag keine Muster. Ich mag nicht alles, was Zeit braucht.

Wenn ich Befehlszeilentools schreibe, erstelle ich eine Win32-Batchdatei, entferne alles, was eingebaut ist, beginne mit einer leeren Datei mit int main() und gehe einfach weiter. Dies ist eine schnelle und tragbare Lösung, die keine Probleme verursacht.

DL: Ich denke, dass das Exportieren statischer Netze ein ziemlich normaler Prozess war. Aber teilen Sie uns mit, wie Sie die Animation exportiert haben.



Screenshot von Tacks Deus Ex Lab

KN: Es gab keine Skelettanimation im Spiel. Ich kenne keinen einzigen Motor der Ära, in der er implementiert ist. Daher wurde alles durch Mischen von Eckpunkten erledigt. Das Enthäuten war zu dieser Zeit sehr teuer. Keine GPUs, alles musste auf der CPU berechnet werden und Gleitkommaberechnungen auf jeden Fall vermieden werden.

In Lightwave erstellten Designer Skelettanimationen und zeigten dann die Keyframes an. Es war notwendig, eine T-Pose zu erstellen, da zum Mischen von Animationen von einer gemeinsamen Basis ausgegangen werden musste. Das heißt, für die richtige Mischung waren die Animationen im Wesentlichen Offsets von der T-Pose. Das Mischen wurde auf der Motorseite durchgeführt.

JL: Also, in Unreal hat alles das Gleiche getan?

KN: Wahrscheinlich ja. Ich glaube nicht, dass Tim der nächsten Version eine Skelettanimation hinzugefügt hat.

Sprechende Köpfe: ConvEdit und Lipsink

[Jetzt öffnen wir den ConvEdit-Ordner]


JL: Erzählen Sie uns von ConvEdit

KN: Es war Al's Idee, er hat es in Visual Basic geschrieben.

JL: Wie damals UnrealEd.

Ja, damals gab es nicht viele Möglichkeiten für eine einfache Implementierung der Schnittstelle. Es gab Delphi und mehrere andere UI-Frameworks. Wenn Sie sie nicht verwendet haben, mussten Sie alles nativ schreiben, z. B. auf die Win32-API, GDI und all das. Es war ein großes Problem.

Das heißt, Visual Basic, das heute eher primitiv erscheint, war zu dieser Zeit sehr gut - ein einfaches visuelles Framework mit einer eigenen Programmiersprache ähnlich Basic, dem Vorgänger von C #. Er erlaubte uns, Funktionen zu prototypisieren und Werkzeuge sehr schnell zu schreiben.

[Hinweis: Wenn Sie daran interessiert sind, wie Visual Basic in Spielentwicklungswerkzeugen dieser Zeit verwendet wurde, lesen Sie mein Interview mit Tim Sweeney über Unreal Editor ]

Es wurde hauptsächlich von Sheldon verwendet. Er brauchte Werkzeuge zur Steuerung der Kamera, Werkzeuge zur Steuerung von Geräuschen. Er wollte viele filmische Werkzeuge verwenden, die noch niemand zuvor benutzt hatte. Ich habe zuerst gelernt, was Rostrum-Zoom ist, als ich mit Sheldon an diesem Spiel gearbeitet habe.

Ich denke, dass dieses Tool auch heute noch verwendet wird.

Sheldon hatte übrigens ein Tunnel-Handgelenk-Syndrom (RSI, Repetitive Strain Injury), so dass das Siegel für ihn zu einer Qual wurde. Er arbeitete fast vollständig an Deus Ex mit Sprachtranskription in Dragon Dictate, was zu dieser Zeit viel schlimmer war als heute. Sheldon musste sogar Orthesen tragen, weil das Syndrom sehr stark war.




JL: Wow! Ich wusste es nicht. Das Spiel hatte viele Dialoge und eine Reihe von Zweigen ...

KN: Eine riesige Datenmenge, selbst für eine Mission.

Sheldon wollte eine starke Kontrolle über das Spiel und viele interaktive Dialoge haben. Er wollte, dass der Spieler eine sinnvolle Wahl trifft. Er und Warren hassten es, ohne Auswahl durch Dialoge klicken zu müssen. Sie wollten, dass der Spieler mit den Charakteren interagiert und wichtige Dinge auswählt, damit das Spiel Flaggen setzt und sich daran erinnert, wie er mit den Charakteren interagiert und sich während der Passage verhält.

JL: Von der ersten Deus Ex-Besichtigung an erinnere ich mich an Anna Navarres Briefing in ihrem Büro. Wie in jedem Videospiel üblich, rannte ich im Büro herum und machte alle Arten von Unsinn, bis die NPCs ihren Dialog beendet hatten. Plötzlich stoppte sie ihren Dialog, drehte sich zu mir und fragte: "Was zum Teufel machst du?"

KN: [lacht]

DL: Für eine Sekunde erstarrte ich und fragte mich: "Ist das wirklich passiert?" Es war für mich ein so bedeutendes Ereignis in Bezug auf das Eintauchen in das Spiel. Kein einziges Spiel, bevor sich dieses jemals getroffen hat. Ich vermute, dass dies teilweise auf den Conversation Editor zurückzuführen ist.

KN: Eines von Warrens Geboten war: "Wenn ein Spieler in einem Büro ist, sich wie Tiere verhält und Dinge kaputt macht, muss der Charakter etwas sagen!" Er sollte den Spieler nicht ignorieren, weil es unrealistisch ist. "

JL: Gab es irgendwelche Aspekte im Zusammenhang mit der Zwischensequenz, für die es sich als besonders schwierig herausstellte, Werkzeuge zu erstellen?

KN: Wir hatten viele Dialoge und sie wurden alle geäußert. Wir haben Wochen in einem Aufnahmestudio verbracht, um Dialoge mit Schauspielern aufzunehmen. Dies bedeutete, dass wir darüber nachdenken müssen, die Bewegung der Lippen (Lipsyne) zu synchronisieren. Ich dachte: "Wie erstelle ich einen lipSink für so viele Dialoge?" Immerhin hatten wir nicht nur ein paar Sätze, sondern auch mehrere Sprachen.

Zu dieser Zeit gab es nicht viele Werkzeuge, um beim Verputzen zu helfen. Die meisten Entwickler führten eine Vorverarbeitung durch: Sie führten den Dialog im Tool aus, zeigten eine Datendatei an und spielten sie dann wieder. Aber ich entschied: "Wir werden keine Zeit dafür haben, und wenn Sie die Stimme neu aufnehmen müssen, müssen Sie alles erneut verarbeiten."

Also begann ich zu denken, dass es eine Möglichkeit geben muss, dies mithilfe der dynamischen Klanganalyse in Echtzeit zu tun. Im College habe ich Elektrotechnik studiert und mich entschlossen, es selbst herauszufinden, ohne es jemandem zu sagen.

JL: [lacht]

KN: Ich dachte: "Mal sehen, ob ich das kann und alle überraschen." Auch hier glaube ich nicht, dass jemals jemand so etwas getan hat, aber heute ist diese Technik überall.

Zu dieser Zeit war Half-Life von allem, was ich sah, einem solchen System am nächsten. Die Entwickler verwendeten die Envelope-Follow-Technik, die buchstäblich so lautete: Öffnen und schließen Sie den Mund je nach Lautstärke des Klangs. Das System funktionierte, sah aber nicht sehr realistisch aus.

JL: Tatsächlich war es ein "Kieferzucken".

KN: Ja genau genau.

Ich erinnere mich, dass ich einmal mit Gabe Newell besprochen habe, wie sie diese Aufgabe erfüllt haben, und er sagte: „Oh, benutze einfach die Umschlagfolge , und das wird ausreichen. Alles andere wird zu kompliziert sein. “

Dann kehrte ich nach Hause zurück und begann, mathematische Berechnungen abzuschätzen. Dann schrieb ich ein System, das FFT ( Fast Fourier Transform ) durchführte. Ich wiederhole, während Gleitkommaberechnungen sehr teuer waren, und ich habe wahrscheinlich eine ganzzahlige Näherung geschrieben, die sie simuliert.

Sie analysierte in Echtzeit eine kurze Audioaufnahme, extrahierte die Hauptfrequenzkomponenten und band sie dann an sechs bis sieben verschiedene Phoneme.

Insgeheim bat ich einen der Künstler, verschiedene Formen des Mischens (Mischformen) zu simulieren: Ich brauchte ein „o“, ein „a“, geschlossene Lippen und dergleichen. Er fragte warum und ich antwortete, dass er dies einfach tat und mir die Daten gab.



Schnelle Fourier-Transformation (Wikipedia Image) und Preston Blair Phonemes Series

JL: [lacht] Dies scheint perfekt zu der Mischung von Animationen zu passen, die Sie in Deus Ex verwendet haben.

KN: Ja genau, perfekt.

Also gab er mir die Daten, ich schrieb mathematische Berechnungen und fügte die Formulare, wie ich konnte, manuell hinzu. Ich habe keine ernsthaften Nachforschungen angestellt, und das System war in Bezug auf die Leistung ziemlich teuer.

Ich habe ein Testlevel mit einem riesigen Kopf in der Mitte erstellt und ihr ein paar Zeilen gegeben. Ich habe den Satz auf Deutsch, Englisch, Französisch überprüft und alles perfekt synchronisiert. Ich dachte: „Verdammt, das ist unglaublich! Es hat wirklich funktioniert! "

Ich fand Warren und sagte zu ihm: "Ich möchte dir etwas Cooles zeigen." Sieht aus wie er fassungslos war. [Lacht] Er fragte mich: „Was zum Teufel, können wir das ins Spiel bringen? Es ist einfach großartig! "

Infolgedessen haben wir ein Spiel mit diesem System veröffentlicht, aber aus Gründen der Leistung musste ich es stark reduzieren, wodurch die visuelle Qualität abnahm. Aber mein erstes Testlevel war großartig. Ich glaube immer noch, dass dies das allererste Echtzeit-Lippensynchronisationssystem war. Ich kann mich an niemanden erinnern, der dies zuvor getan hat.

Vielleicht hat es sich gelohnt, es zu patentieren. Aber ich glaube nicht an Softwarepatente, weil ich denke, dass dies eine bösartige Praxis ist ...

Ich habe auch einen großen Streit mit einem der Art Direktoren in Dallas bekommen, der dieses System in Anacronox verwenden wollte. Sie hätte vor unserem Spiel herauskommen sollen. Ich sagte: "Es wird mir nichts ausmachen, zu teilen, aber ich möchte, dass Deus Ex das erste Spiel ist, in dem es erscheint." Er sagte: "Nein, du musst es uns geben!" Er hat uns in der Halle praktisch angeschrien. Ich antwortete: "Nein, ich sollte nicht" und Warren unterstützte mich. Es ist so passiert, dass wir das Spiel zuerst veröffentlicht haben, also war das sowieso nicht wichtig. Tatsächlich denke ich, dass sie als Ergebnis unabhängig ihre eigene Version des Systems implementiert haben, weil wir es nicht verraten wollten. Es mag egoistisch gewesen sein, aber ich wollte, dass wir zuerst unseren Abschluss machen, damit wir diese Funktion demonstrieren können.

Alles andere, was von Ion Storm produziert wurde, wurde in Dallas entwickelt: Dominion: Storm Over Gift 3 , Daikatana , Anacronox - alles wurde in Dallas gemacht. Nur Deus Ex wurde in Austin gegründet, und es gab nur unser Team, sonst niemanden. Wir waren in einer Blase, ziemlich isoliert vom Büro in Dallas, und dies wurde absichtlich getan. Wir wollten uns nicht mit einem Haufen anlegen ... Ich werde ehrlich sein, mit einem Haufen all ihres Mülls. Diese Trennung war völlig beabsichtigt und für uns sehr wichtig. Unser Team und seine Teams tauschten keine Technologien aus, keine echten Kontakte.

Fazit

DL: Zusammenfassend möchte ich fragen: Wenn Sie Tool-Entwicklern, die diesen Artikel lesen, Ratschläge geben könnten, was würden Sie sagen?

KN: Hören Sie Ihrem Kunden zu. Schreiben Sie niemals Werkzeuge im luftleeren Raum. Als Ingenieur denken Sie vielleicht: "Ich kann dieses Tool auf diese Weise verwenden, und diese Methode ist am effektivsten, also schreibe ich sie so."

Aber fast immer irren Sie sich. Sie sollten Designern und Künstlern zuhören, da ihre Arbeitsabläufe sehr unterschiedlich sind. Sie arbeiten ganz anders als die anderen. Das Tool wird von Ihnen nicht verwendet, meistens ist es für sie.

DL: Haben Sie in den Teams, mit denen Sie zusammengearbeitet haben, jemals eine solche Mentalität erlebt? Und wie sind Sie damit umgegangen?

KN: Sie müssen den Programmierern nur sagen: „Warum hat der Benutzer dieses Problem? Denken Sie, dass das Problem im Code liegt? Oder liegt das Problem vielleicht an der Bildschirmstruktur? Ist die Schrift zu klein? Falsche Tastenfarbe? Vielleicht machst du etwas, das nicht dem Standard entspricht? “

Denn wenn Sie sich die meisten Werkzeuge mit einem professionellen Design ansehen, sind sie normalerweise ziemlich konsistent. Es gibt Design-Anleitungen, wie die Dinge funktionieren sollten.

Das Kreativteam sollte in der Lage sein, diese Tools zu verwenden. Es sollte nicht sein, dass sie die Dokumentation lesen müssen. In einer idealen Welt sollte alles offensichtlich sein.

Heute gibt es UX / UI-Designer, aber zu dieser Zeit gab es keine, daher mussten wir das Interface-Design selbst erstellen, jedoch mit dem Feedback der Benutzer.

Setzen Sie sich also neben die Benutzer und sehen Sie, wie sie das Tool verwenden. Wir haben gesehen, wie sie in Lightwave funktionieren. Als wir die erste Version des Instruments geschrieben haben, saßen wir in der Nähe, ohne zu fragen, was zu tun ist, und schauten sie uns an und machten uns Notizen, wie „es gab Schwierigkeiten damit“ oder „sie müssen ständig ins Menü klettern, um das zu finden“ oder „vielleicht Es lohnt sich, daraus einen Hotkey zu machen. " Schau sie dir an, lerne und passe dich an.

Das heißt, Sie sollten wirklich über den Workflow von Designern nachdenken. Es ist notwendig, unnötige Bewegungen zu minimieren, das Crawlen im Menü zu minimieren und Hotkeys hinzuzufügen. Wir haben Tastaturkürzel für alle Funktionen aktiv beworben, da sie den Workflow beschleunigen. Während des Lernens des Tools beschleunigen Sie die Arbeit mithilfe von Tastenkombinationen erheblich und müssen das Menü nicht aufrufen.

Für Ingenieure ist es nicht nötig, in die klassische Falle zu tappen: „Ich weiß besser, ich habe das Instrument aufgeschrieben, ich weiß, wie es funktioniert. Wenn du es nicht benutzen kannst, bist du nur ein Idiot. “ Dies ist das Schlimmste, was bei der Entwicklung eines Werkzeugs passieren kann.

JL: Exzellenter Rat. Vielen Dank Chris!