Was war der erste Unreal Editor?

Retrospektiven klassischer Spiele sind in letzter Zeit populär geworden, erinnern aber selten an die klassischen Entwicklungswerkzeuge. Ich habe es geschafft, mit Tim Sweeney über die erste Version von Unreal Editor oder UnrealEd zu sprechen.

BSP und Irrtümer: „Wir müssen unseren eigenen Editor schreiben“

David Lightbone: Danke, dass Sie sich die Zeit genommen haben, mit mir zu sprechen, Tim! Beginnen wir mit den Anfängen von Unreal Editor. Ich habe gelesen, dass James Schmaltz, der Schöpfer von Epic Pinball , Ihnen das Spiel gezeigt hat, an dem er gearbeitet hat, und als Sie es gesehen haben, habe ich vorgeschlagen, einen Editor dafür zu erstellen. Alles ist richtig?

Tim Sweeney: Genau! Er wurde vom Spiel Bullfrog Magic Carpet inspiriert. James ist ein unglaublich talentierter Entwickler, aber er hat nur Code in Assemblersprache geschrieben, er wollte C nicht lernen. [Lacht] Daher hat er diese 3D-Engine in einem reinen Assembler geschrieben, der den Reliefhintergrund und die Spielobjekte wiedergibt. Er wollte keinen Editor erstellen, also erstellte er manuell einen BSP-Baum und platzierte eine Kapsel auf diesem Relief. Als ich das sah, sagte ich: "Nein, nein, nein, James, James ... du musst etwas völlig anderes tun." [lacht]



James Schmalz und Bullfrog Magic Carpet

Ich sagte, dass ich einen Editor schreiben würde, also fing ich seltsamerweise an, die Benutzeroberfläche des Unreal Editor aus dem UI-Layout in Visual Basic zu erstellen. Er hatte eine textbasierte Befehlsoberfläche für die Kommunikation mit einer gerenderten C ++ - Engine. Dann schrieb ich einen Wireframe-Editor und die Entwicklung wurde auf dieser Grundlage fortgesetzt.

Das heißt, es war ein interessanter Studienprozess. Ich dachte, ich würde diesen Editor einfach schreiben und in James 'Renderer integrieren. Einmal fragte ich ihn: „Können Sie mir den Code schicken? Ich möchte verstehen, wie der Renderer integriert wird. " Und er hat mir 30.000 Zeilen Assembler-Code geschickt. [lacht] In der 3D-Rendering-Engine gab es einige Elemente von Epic Pinball und einige frühere Assembler-Codes, die er einfach kopierte. Ich dachte: „Mein Gott, was für ein Chaos ist das? Ich möchte das nicht anfassen! " [lacht]

Aber ich sagte mir, bevor ich anfange, es herauszufinden, würde ich einfach ein kleines Textur-Mapping-Tool schreiben. Also las ich Michael Abrashs Artikel über Textur-Mapping und studierte den Code, den Billy Zelsnack teilte. Das Texturieren stellte sich als ziemlich einfaches Thema heraus, also entschied ich mich: "Ich werde versuchen, mit all dem fertig zu werden."

Bevor ich Beleuchtung und dergleichen implementierte, war ein wichtiger Teil der Magie früherer Versionen von Unreal Editor die Erstellung eines Echtzeit-BSP-Baums. Die Idee war, dass Sie die Position der Pinsel im 3D-Raum ändern können. Danach wurden alle Arbeiten zur Generierung von BSPs in Echtzeit vollständig aktualisiert.


Die Möglichkeiten, die diese Funktion bietet, passten nicht in meinen Kopf, und nur um all ihre Kraft zu zeigen, habe ich dieses Werkzeug zum Erstellen von Tori erstellt. Ich kontaktierte James, der, wie ich mich erinnere, seine BSPs manuell erstellte und ihm sagte: "Check it out." Ich habe zwei verbundene Tori erschaffen und sie von der Welt subtrahiert. Er sagte: „Wow, das kann nicht sein! Das ist großartig. “ Dies war ein echtes Beispiel für die Hartnäckigkeit von Programmierern.

JL: In Bezug auf BSP war John Carmack, so wie ich es verstehe, einer der ersten, der BSP in Game Engines einsetzte, und die Idee, mit BSP zu arbeiten, war für die damalige Spielebranche ziemlich neu.

TS: Carmack hat einen wirklich mächtigen Editor für NeXT geschrieben . Ich habe alle Informationen über ihn gelesen und Screenshots gesehen, aber ich habe sie nie benutzt. Zu dieser Zeit dachte ich: "Wow, Carmack hat einen Echtzeit-BSP-Editor geschrieben!" Was ich nicht verstand, war, dass es tatsächlich nicht in Echtzeit funktionierte, es gab einen Vormontageprozess und andere Operationen. Ich wusste das nicht und dachte, dass er einen Editor erstellt hatte, der vollständig in Echtzeit funktionierte, also schrieb er auch den gleichen. [lacht]



QuakeEd auf NeXT und John Carmack

JL: [lacht] Sie dachten, er sei so mächtig, also haben Sie die Herausforderung angenommen.

TS: Ja! Viele der Merkmale von Unreal sind aufgrund meines Missverständnisses dessen entstanden, was andere Leute getan haben.

Darüber hinaus gründete eine Gruppe ehemaliger Demo-Hersteller von Future Crew eine Ausrüstungsfirma und veröffentlichte einige Screenshots mit unglaublich realistischer Surround-Beleuchtung in einer Innenszene. Es gab Lichtquellen mit großen Kugeln, und die volumetrische Beleuchtung wurde durch die gesamte sie umgebende Geometrie deutlich abgeschnitten. Es sah physisch vollkommen genau aus. Ich dachte: "Gott, ich habe so etwas noch nie gesehen, ich muss das herausfinden!"

Also begann ich zu verstehen und erkannte, dass ich das lineare Integral von der Kamera zu jedem Punkt auf dem Bildschirm berechnen musste. Im College habe ich Matanalyse studiert und mir gesagt: "Ich muss Erfolg haben." Also habe ich eine Formel dafür mit einer wahnsinnig komplizierten Trigonometrie abgeleitet. Ich habe es in Code implementiert, aber es war hundertmal langsamer als nötig. Dann wurde mir klar: „Stopp, ich kann diese Berechnungen im Raum der Lichtkarte durchführen“, weil die Lichtkarte eine Diskretisierung der Geometrie in kleine Fragmente ist. Ich habe die Berechnungen auf Beleuchtungskarten übertragen und alles in Echtzeit implementiert.



Beleuchtungsbeispiele von Unreal basierend auf Beleuchtungskarten

Ich machte einen Screenshot und schickte ihn an einen Freund aus Finnland, der für diese Ausrüstungsfirma arbeitete. Er antwortete: „Wow, das ist unglaublich! Unser Bild ist jedoch nur ein Rendering von 3D Studio Max, da wir nicht verstehen konnten, wie dies in Echtzeit gemacht wird. " [lacht]

JL: [lacht] Ja!

[Anmerkung des Autors: Die Firma, von der Tim spricht, sind die Bit Boys ]

TS: Das heißt, die Unreal Engine erwies sich als die erste volumetrische Lichtmaschine der Welt, wie ich denke ... und sie beruhte auf meinem Irrtum.

Es war eine erstaunliche Zeit in der frühen Geschichte der Spielebranche, da 3D gerade erst möglich wurde. Es wurden bereits mehrere Software-Renderer geschrieben, aber niemand war in der Lage, große Probleme zu lösen: Wie man Beleuchtung in einer großen Welt funktioniert, wie man Echtzeit-Geometrie in einer großen Welt funktioniert. Dieser Entwicklungsprozess verlief rasant: Carmack setzte neue verrückte Ideen um, ich realisierte neue verrückte Ideen und wir veröffentlichten ständig Screenshots von dem, wozu wir fähig sind.

Wenn Sie es sich jetzt ansehen, haben wir in nur vier Jahren etwa 20 Jahre Rendering-Forschung der 1980er und 1990er Jahre nachgebildet, die bisher nur durch vorläufige Berechnungen und nicht in Echtzeit möglich waren.

JL: Ja, wie die Idee von BSP auf einem Artikel aus dem Jahr 1969 basiert.

TS: Genau vor meiner Geburt!

TurboPascal und Maya: Unwirkliche Inspiration

JL: Welche Inspirationsquellen haben Sie verwendet, um die Designphilosophie von Unreal Editor zu entwickeln?

TS: Es gab nur wenige Inspirationsquellen.

Wenn Sie sich das 1991 veröffentlichte ZZT- Spiel ansehen, werden Sie die grundlegenden Funktionen der Unreal Engine sehen. Im Wesentlichen handelt es sich um eine Spiel-Engine, in die ein Spiel integriert ist. Das Spiel hat eine kleine Skriptsprache, die trotz ihrer Einfachheit eine vollständig skriptbasierte Sprache war, mit der Sie kleine Spielskripte schreiben konnten.

[Anmerkung des Autors: Details zum ZZT finden Sie in Anna Anthropys Buch, das von Boss Fight Books veröffentlicht wurde.]

Das Spiel hatte einen interaktiven WYSIWYG-Echtzeiteditor zum Erstellen von Levels. Durch Drücken einiger Tasten können Sie sich bewegen, Ebenen hinzufügen und im Spiel überprüfen und dann verarbeiten. Ein solcher interaktiver Workflow war ein wesentliches Merkmal des Spiels.



ZZT, Spielemodus und Editor-Modus

Eine weitere Inspiration war Turbo Pascal , das erste Entwicklungswerkzeug, das ich wirklich liebte. Es war ein sehr einfach zu verwendender Editor zum Erstellen von Code und Kompilieren. Sie haben gerade den Code eingegeben, nach einigen Sekunden wurde er bereits kompiliert und ausgeführt. Der iterative Prozess beim Erstellen von Programmen war erstaunlich im Vergleich zu dem, was ich damals gewohnt war. Wenn Sie sich die ZZT-Implementierung ansehen, sieht sie wirklich wie eine Textversion der Unreal Engine aus. Das gesamte Unreal-Modell wurde davon inspiriert.

Es gibt eine weitere ernsthafte Inspirationsquelle, die zur Erstellung vieler Designelemente der Engine geführt hat: Visual Basic, ähnlich dem Microsoft-Klon Delphi, dh eine Version von Object Pascal für Windows mit Bearbeitung in der visuellen Oberfläche von Borland. Aber ich habe Delphi nie benutzt, ich habe nur in Visual Basic gearbeitet.

Die Idee war, dass der Benutzer einen Formulareditor hat, Formularelemente, Felder und alles darin zeichnet, darauf klickt und den Code öffnet. Der Code wird sofort angezeigt und der Benutzer gibt ihn einfach weiter ein und arbeitet weiter.



TurboPascal von Borland

Ich habe diese Prinzipien auf Unreal übertragen: Sie können ein Objekt einfach auf eine Ebene ziehen, darauf doppelklicken, um den Skripteditor zu öffnen, das Skript eingeben und speichern. Um mit dem Schreiben von Code zu beginnen, dreidimensionale Objekte zu erstellen und alles in Echtzeit zu erledigen, reichen nur ein paar Mausklicks aus.

Ein weiterer wichtiger Aspekt bei der Entwicklung von Unreal war, dass Epic mehrere Silicon Graphics-Workstations gekauft hat, auf denen die erste Version von Maya veröffentlicht wurde. Maya war zu dieser Zeit völlig veraltet, aber es gab einen interaktiven 3D-Modus mit einem blau-rot-schwarzen Hintergrund, auf dem Objekte und Drahtgitter in Echtzeit gezeichnet wurden. Dies konnte von keinem Programm auf dem PC durchgeführt werden. Sie stecken alle in Legacy-Code und Legacy-UI-Mustern fest.



Das erste, was ich tat, als ich anfing, am Unreal Editor zu arbeiten, war, durch Kopieren von Maya einen schwarzen Hintergrund mit blauen und roten Linien zu erstellen. Ich habe eine Prozedur zum Zeichnen von Linien geschrieben und dreidimensionale Drahtgitterkonturen aller Objekte erstellt. Das war das Beispiel, das mich inspirierte und das bewies, dass es möglich war.

Von Visual Basic zu Slate: Weiterentwicklung der UnrealEd-Oberfläche

[Anmerkung des Autors: Zu Beginn des Interviews habe ich UnrealEd 1 in einer virtuellen Maschine auf meinem Laptop gestartet. Ich habe Tim eine Maus gegeben, damit er darin arbeiten kann.]

TS: Wow, großartig, du hast es bereits gestartet!

JL: Ja! Ich habe vorgestellt, dass die Version, die wir hier sehen, Visual Basic ist.

TS: Ja, ja!

[Anmerkung des Autors: Tim war glücklich, als er das Level von Grund auf neu erstellt hat. Von außen schien es ein Treffen von Freunden zu sein, die schon lange nicht mehr gesehen worden waren.

JL: Was hat Sie dazu veranlasst, Visual Basic zu verwenden, um die Benutzeroberfläche für die erste Version von UnrealEd zu entwickeln, und welche anderen Optionen hatten Sie?



Alan Cooper und Visual Basic

TS: Das war 1995. In diesem Moment waren die Benutzeroberflächen-Frameworks für C ++ einfach schrecklich. Es gab Microsoft Foundation Classes, die miserabelste API, die Sie sich vorstellen können. Der Benutzer begann mit dem Zeichnen von Fenstersteuerelementen und das Framework erstellte riesige Mengen an C ++ - Code mit unzähligen Kommentaren wie: "Hier erstellen wir ein Steuerelement für Sie!" Wenn der Benutzer das Objekt verschoben hat, hat das Framework einen Teil des Codes aktualisiert, aber nicht die anderen Teile, und es ist ständig kaputt gegangen. Deshalb habe ich mir gesagt: "Ich werde das nicht mehr anfassen."

Visual Basic war ein hervorragendes Tool für die Entwicklung einer Benutzeroberfläche, in der Sie alle Steuerelemente, Menüelemente und Teile der Benutzeroberfläche sehr effizient platzieren konnten. Es war das produktivste Toolkit für die Benutzeroberfläche, das ich je gesehen habe, hauptsächlich, weil es ein sehr klares, miteinander verbundenes Programm war: Sie haben eine Benutzeroberfläche gezeichnet, darauf geklickt und einen einfachen Code für die Interaktion hinzugefügt. Mir wurde klar, dass es viel einfacher ist, eine Benutzeroberfläche zu erstellen und sie dann über die Befehlszeilenschnittstelle an C ++ zu übergeben und Text hin und her zu senden, um Daten zu serialisieren. Ich denke, die Situation hat sich etwa ein Dutzend Jahre lang nicht geändert, bis Anfang der 2000er Jahre anständige UI-Toolkits für C ++ wie Qt und dergleichen auftauchten.

[Anmerkung des Autors: Die erste Version von Visual Basic wurde von Alan Cooper entwickelt , der oft als " Vater von Visual Basic " bezeichnet wird. Er ist auch eine wichtige Figur im Bereich Benutzerfreundlichkeit und Benutzererfahrung.]



UnrealEd 3, in dem wxWidgets-Elemente vorhanden waren

DL : Ich denke, dass im Laufe der Zeit Teile des Editors durch andere Teile ersetzt wurden. Wie kam es zu dieser Entwicklung?

TS: Nachdem ich Unreal Editor 1 abgeschlossen hatte, beruhigte ich mich und führte eine ganze Reihe von Nachforschungen der neuen Generation durch, die im Allgemeinen keine Früchte trugen, bis Warren Marshall erschien, der Teile von Visual Basic in Unreal Editor mit C ++ mithilfe von wxWidgets neu schrieb . wxWidgets, das zu dieser Zeit das beste Toolkit war. Dies wurde zur Grundlage für das UI-Framework in Unreal Editor 2.

In der Mitte des Entwicklungsprozesses von Unreal Engine 2 verschwand Visual Basic-Code vollständig aus der Engine. Wir hatten ein bequemeres und saubereres C ++ - Framework. Somit haben wir fast die gleiche Benutzeroberfläche, jedoch ohne Sprachschwierigkeiten. Das eigentliche Problem war jedoch, dass wxWidgets nicht entwickelt wurde und andere UI-Toolkits herauskamen. Daher haben wir sie weiterhin für spezielle Tools integriert. Zu Beginn des Entwicklungszyklus von Unreal Engine 4 hatten wir daher fünf verschiedene UI-Toolkits ...

JL: Das passiert oft ...

TS: ... einschließlich verrückter WPF-Teile, die in C # geschrieben und in Unreal Engine 4 integriert wurden und beispielsweise auf einem Mac nicht funktionierten. Daher gab es in diesem Moment in unserem Code ein riesiges Chaos.

Gleichzeitig erstellte Nick Atamas einen Prototyp der neuen UI-Ebene in C ++ und im Laufe der Zeit entschieden wir uns, ihn zu verwenden. Also verwandelte er sich in einen Schiefer. Also haben wir 100 Prozent der Unreal Engine-Benutzeroberfläche neu geschrieben, alle Plug-in-UI-Toolkits entfernt und sie im gleichen Stil neu erstellt. Dies ermöglichte es uns, den Umfang des Editors zu vergrößern und zu dem zu gelangen, was wir heute haben.


Screenshot von UnrealEd mit Slate UI

Aber wir konnten immer noch nicht die Bequemlichkeit erreichen, die in den Tagen von Visual Basic existierte. Sogar das C # -Benutzeroberflächen-Framework war nur ein riesiger Haufen XML und anderer unnötiger Wahnsinn. Es scheint, dass jede neue Generation die Benutzeroberfläche immer ausgefeilter implementiert und immer schlechter wird.

Screenshots und XCopy: Die Bedeutung der Lizenzierung

DL: Welche Unternehmen haben als erste Unreal Editor verwendet?

TS: In der Anfangsphase, zwei Jahre vor der Veröffentlichung, hatten wir bereits zwei Lizenzkäufer: Unreal Engine verwendete Microprose, und Legend Entertainment verwendete es für das Rad der Zeit, und wir unterstützten sie.



Legend Entertainment Rad der Zeit

JL: Sie haben dir auch geholfen, oder? Die Zusammenarbeit war Teil dieser Beziehung.

TS: Ja, ihre Lizenzzahlung hat Epic während des unwirklichen Entwicklungsprozesses über Wasser gehalten.

Zu dieser Zeit nahm ich die Lizenzierung sehr ernst, da wir damit Rechnungen bezahlen konnten, was uns zum Lizenzmodell der Engine führte, das sich völlig vom ID-Modell unterschied. Zu dieser Zeit gab es einen Witz, dass die Lizenzierung der Engine von Id wie der Kauf von XCopy für eine Viertelmillion Dollar war: Sie zahlen eine Viertelmillion, und sie geben den Befehl DOS XCopy ein, um Ihnen eine Kopie der Quelle zu geben ... und das war's. [lacht]

JL: [lacht] Okay, was hat zum Verkauf der Unreal Engine-Lizenz an Microprose und Legend Entertainment geführt, noch bevor Unreal 1 veröffentlicht wurde?

TS: Ich denke, es ist passiert, weil wir noch in den frühen Stadien, um 1995, erstaunliche Screenshots nicht nur unseres Spiels, sondern auch Screenshots unseres Editors veröffentlicht haben. Dies brachte das Unternehmen dazu, uns zu kontaktieren. Sie riefen uns von Microprose an und sagten: „Wir wollen Ihren Motor lizenzieren!“ Und wir sagen: „Motor? Welcher Motor? Ah, unser Motor! Es wird dich teuer kosten. “ [lacht] So war das Gespräch buchstäblich.



Einer der ersten Screenshots von Unreal Editor und Unreal

Dinosaurier und Eidechsen: Terminologie und Ikonographie UnrealEd

DL: Apropos Screenshots: Hier ist einer davon, der Ende der 90er Jahre in Blue's News veröffentlicht wurde. Es gibt merkliche geringfügige Unterschiede zu der Version, die in meiner virtuellen Maschine ausgeführt wird: In der oberen linken Ecke befinden sich beispielsweise die Schaltflächen "Abspielen", "Hilfe" und "Episch", die nicht in der endgültigen Version enthalten sind.

Kannst du etwas darüber erzählen?


Screenshot von UnrealEd, veröffentlicht 1998 in den Blues News

TS: Dies ist definitiv Unreal Engine 1, circa 1998, weil es den Steve Polge-Code hat, der zu der Zeit das Multiplayer-Spiel koordinierte.

Die Schaltfläche "Episch" war nur ein Link zu einer Webseite, die allen ärgerlich erschien, weil sie ständig klickten und sich ärgerten: "Ah, der Browser öffnet sich wieder!" [lacht]

JL: [lacht] Kannst du ein bisschen über Ikonographie sprechen?

TS: Für alle Elemente der Benutzeroberfläche habe ich absolut schreckliche Symbole gezeichnet und sie dann an Dan Cook gesendet, einen Künstler, der sich mit Grafiken für unseren frühen Schützen Tyrian beschäftigt hat .

Er musste ein Symbol für das Bauernelement zeichnen, also erstellte er eine Schachfigur. Ich sagte: "Nein, nein, nein" und er antwortete: "Na dann, dann sag mir, was Bauer ist." Ich sagte, dass es so etwas wie ein Monster war, etwas sehr Cooles, also zog er den Kopf einer unverständlichen Kreatur: Sie sagten, es sei ein Dinosaurier, eine Eidechse oder etwas anderes ... aber diese Ikonen blieben ungefähr zehn Jahre bei uns.



Daniel Cook und die Symbole, die er für UnrealEd erstellt hat. Das Symbol „Bauer hinzufügen“ befindet sich unten, drittens rechts.

DL: Wir haben bereits über das Wort "Bauer" gesprochen. Haben wir es uns selbst ausgedacht oder haben wir es irgendwo gesehen?

TS: Ich denke, es wurde von Steve Polge oder James Schmalz vorgeschlagen.

JL: Was ist mit "Schauspieler"?

TS: Carmack hat sich seine eigene Terminologie ausgedacht, er hat Objekte "Entitäten" genannt, und ich dachte: "Nein, wir brauchen etwas Einzigartiges."

JL: [lacht]

TS: Wir haben beschlossen, Objekte als Schauspieler zu bestimmen , weil SmallTalk , in das ich damals verliebt war, in den 1980er Jahren Programmierprinzipien auf der Grundlage des Schauspielermodells vorschlug. Das Modell war objektorientiert und schien für uns ein guter Anfang zu sein. Aus diesem Grund kamen wir auf die Idee von Bauern und Anstiftern, die den Beginn einer Reihe von Ereignissen und aller anderen Begriffe bestimmen.

Schmalzismus und Brain Voodoo Virus: Erstellen von UnrealScript

JL: Erzählen Sie uns mehr darüber, wie James und Steve zur Verwendung und Erstellung von UnrealScript beigetragen haben.

TS: James Schmalz war ein einzigartiger Diamant, Handwerker. Er war der beste Künstler des Teams, ein großartiger Level-Designer, und er konnte auch in UnrealScript und Assembler programmieren.

DL: In Unreal Credits erscheint sein Name in zwei völlig unterschiedlichen Kategorien.

TS: In der gesamten Spielebranche gibt es äußerst wenige Menschen mit diesem Talent, und er verdient den gesamten erzielten Erfolg.

Aber er wechselte vom Assembler zu UnrealScript und schrieb verrückten UnrealScript-Code, in den er einfach Zeilen hämmerte, während sie weiter arbeiteten, und abends trat ich an ihn heran und vereinfachte seinen Code. Er hatte mehrzeilige Ausdrücke wie "etwas Anstifter Punkt bla bla Punkt", und ich ersetzte sie durch etwas wie ... "Selbst". [lacht]

JL: [lacht]

TS: Wir haben diesen Code "Schmalcism" genannt. Und Polge hatte magische Zahlen wie "Schrittgeschwindigkeit = Laufgeschwindigkeit x 3,072" in seinem Code. Ich fragte ihn: "Gibt es wirklich eine Konstante von 3,072 in der Physik, von der ich nichts weiß?" [lacht]



TS: UnrealScript wurde von Java inspiriert. Zu dieser Zeit schien diese Sprache der Nachfolger von C ++ zu sein. Die Schöpfer der Sprache haben viele konstruktive Lösungen kopiert und darüber hinaus viele neue Konzepte hinzugefügt. In UnrealScript gab es die Grundlagen grundlegender Container, die nur wenige Generationen später in Java auftauchten.

Ich habe immer gedacht, dass die Autoren bei der Entwicklung der C # -Sprache UnrealScript gefolgt sind, weil ich einige Funktionen von UnrealScript gesehen habe, die in C # aufgetaucht sind. Ich habe immer gehofft, dass sie einige dieser Ideen ausgeliehen haben.

Aber je mehr ich mich in objektorientierter Programmierung vergrub und in SmallTalk die fortschrittlichste Forschung zu Metaklassen studierte, desto mehr wurde mir klar, dass es sich um eine Art Gehirn-Voodoo-Virus handelte, das keine wirkliche theoretische Grundlage hatte. Wenn wir uns wiederum die Korrespondenz von Haskell und Curry-Howard sowie andere moderne Programmierprinzipien ansehen, werden wir die Quelle und Struktur als Inspiration erkennen.

SoftDisk, Id und Schecks in Millionenhöhe

JL: Haben Jay Wilbur und Mark Rein mit ihrer Geschäftsorientierung und Erfahrung mit Shareware die Engine, Tools, den Editor oder die Ressourcen beeinflusst, die ihnen zur Verfügung gestellt wurden?

TS: In der Anfangsphase arbeitete Epic aufgrund der Tatsache, dass ich auf der technischen Seite und Mark - im Geschäft tätig war. Mark flog um die Welt und machte verrückte Geschäfte, die uns Geld brachten. Es wäre sehr wichtig, wenn wir nicht für ihn gewesen wären, hätten wir in diesen frühen Stadien nicht überlebt.



Mark Rain und Jay Wilbur

Irgendwann waren wir auf Grund und alle unsere Ausgaben wurden aus Marks American Express-Karte finanziert, die daraufhin storniert wurde.

JL: [lacht]

TS: Dann flog er zu einem Treffen mit TG Interactive und kehrte von dort mit einem Scheck über eine Million Dollar zurück. Es hat uns gerettet. Und so wurde es in unserer Geschichte mehrmals wiederholt. Es ist sehr wichtig, ausgezeichnete Geschäftsleute zu haben, die verhandeln können. Er war der erste Präsident von Id und nachdem Mark Jay der erste CEO von Id wurde.

DL: Vorher waren er und Carmack bei SoftDisk, richtig?

TS:Richtig! Und das ist lustig, weil ich tatsächlich mein erstes ZZT-Spiel an SoftDisk verkauft habe. Es war Jay Wilbur, der sich um meinen Vertrag mit SoftDisk kümmerte. Als Ergebnis dieser Verhandlungen erhielt ich dreitausend Dollar von SoftDisk, so dass ich Jay sehr lange kannte.


Die Anfänge von Id Software. Jay Wilbur auf der rechten Seite.

Die Arbeit mit den Jungs von Id hat mich von Anfang an inspiriert. Ich ging zu einer dummen Shareware-Konferenz und Id erschien dort. Sie waren zu dieser Zeit Branchenfavoriten, weil sie Wolfenstein 3D veröffentlichten, was der größte Erfolg in der Geschichte der Shareware war. Sie unterhielten sich mit uns und luden dann zum Abendessen ein. Es war so toll zu sehen, dass Branchen-Superstars nur bescheidene Typen waren. John Romero ist der süßeste Spieleentwickler der Welt.

[Anmerkung des Autors: Ich stimme zu. John Romero verbrachte viel Zeit mit unserem TEd-Interview.]

WYSIWYG und Benutzerfreundlichkeit: Am wichtigsten - Werkzeugperspektiven

DL: Im November 1998 erschien die Maximum PC-Version, in der es ein Interview mit Ihnen gab, in dem Sie auch über verschiedene Technologien sprachen, die zu dieser Zeit existierten. In diesem Artikel heißt es: "[Unreal Editor] ist in Bezug auf Einfachheit allen leicht voraus" und "es ist schwierig, mit der Quake-Technologie zu arbeiten."

Es heißt auch: „Die Technologie [Quake III: Arena] ist wirklich beeindruckend“ und „Beute und Eindringling sehen besser aus und funktionieren besser als Unreal. Wenn sich jedoch herausstellt, dass es schwieriger ist, mit ihnen zu arbeiten, bleiben die Entwickler bei Unreal. "

Hatten Sie von Anfang an das Ziel, ein Tool zu entwickeln, dessen Wettbewerbsvorteil in der Benutzerfreundlichkeit liegt?



Maximaler PC, November 1998

TS: Ja, das stimmt. Weißt du, das war schon immer das Wichtigste für mich: einen Editor zu schreiben, mit dem Level-Designer erstaunliche Kreationen erstellen können. Von Anfang an war klar, dass der wichtigste Aspekt dabei Echtzeitarbeit und ultraschnelle Designiterationen sind, die vollständige Umsetzung des Prinzips „Was Sie sehen, ist was Sie bekommen“ („Was Sie sehen, ist was Sie bekommen“, WYSIWYG). . Dann werden Sie nur durch Ihre Vorstellungskraft und Ihre Fähigkeit eingeschränkt, neue Ideen zu entwickeln. Für uns hatte Epic immer ein sehr wichtiges Werkzeug.

JL: Welchen Prozess hat Epic verwendet, um viel Aufmerksamkeit zu schenken und Zeit und Arbeit in die Vereinfachung des Werkzeuggebrauchs zu investieren?

TS:Der Entwicklungsprozess in Epic ist eine Kombination aus dem Entwicklungsteam der Engine, das Systeme, Funktionen und Tools erstellt, und dem Spielteam, das all dies für die Erstellung von Spielen benötigt. Wir verwenden einen iterativen Prozess, wenn Engine-Entwicklungsteams neue Ideen erstellen und diese dann mit Spielteams teilen und ständiges Feedback darüber erhalten, was funktioniert und was nicht. So entstand unser technischer Prozess: Die Tatsache, dass Tool-Entwickler Spieleentwicklern helfen sollten, ermöglichte es ihnen, ehrlich zu sein.

Wir wollten nicht nur benutzerfreundliche Tools erstellen, sondern auch sicherstellen, dass sie die richtigen Kompromisse bieten, mit denen Sie wirklich die Inhalte erstellen können, die für die Veröffentlichung des Spiels erforderlich sind.

Dies ist die Kehrseite der Benutzerfreundlichkeit. Es ist unmöglich, die Benutzerfreundlichkeit als separates Konzept zu betrachten. Es ist schlecht, wenn die Tools sehr einfach zu verwenden sind, wenn Sie mit dem Erstellen eines Spiels beginnen, aber es ist sehr schwierig für sie, die Erstellung des Spiels abzuschließen, da sie den Workflow oder die Funktionalität einschränken.


Wenn Sie sich die letzten fünf oder sechs Jahre der Entwicklung von Motoren ansehen, wird der Wettbewerb zwischen Epic und Unity durch die anfängliche Benutzerfreundlichkeit bestimmt, bei der Unity einen Vorteil hat. Gleichzeitig hat Unreal im Entwicklungszyklus der Veröffentlichung des Spiels einen Vorteil in Bezug auf die Leistung auf verschiedenen Plattformen. Dies liegt daran, dass wir uns darauf konzentrieren, Spiele von epischem Ausmaß veröffentlichen zu können, dh die, die wir machen. Tatsächlich ist dies viel komplizierter als die Vereinfachung der Arbeit von drei Personen, die schnell etwas Einfaches veröffentlichen.

Heutzutage ist die Unreal Engine-Codegröße etwa 20 größer als der Unreal Engine 1-Code. Die Tools sind zehnmal komplizierter geworden, und dafür gibt es Gründe. Die Leute starten Unreal und verlieren sich, weil es so viele Menüoptionen gibt. Dann wechseln sie zu Unity und sehen, dass alles süß und einfach ist. Und dann erreichen sie das Stadium, in dem Sie ein Produkt veröffentlichen müssen, und es stellt sich heraus, dass Sie eine Lizenz für den Quellcode erwerben müssen, um der Engine Funktionen hinzuzufügen, die nicht im Menü enthalten sind. Es gibt eine solche Zweiteilung.

Quelle der Inspiration und des Erbes: Die Auswirkungen von UnrealEd

JL: UnrealEd hat einige Spieleentwickler, einschließlich mir, dazu inspiriert, nicht nur Spiele zu erstellen, sondern auch ihre eigenen Tools zu schreiben. Welche Auswirkungen hat UnrealEd Ihrer Meinung nach auf die Branche?

TS: Ich denke, jeder existierende Spieleditor hat sich etwas von UnrealEd geliehen. Dies war einer der ersten Editoren. Wir haben viele korrekte grundlegende Entscheidungen getroffen, zum Beispiel, wie der Benutzer mit 2D-Gittern arbeiten, Objekte platzieren und sich auf der ganzen Welt bewegen soll. Ich denke, Sie können die Vererbung verfolgen, die vom ersten Doom-Editor an den Quake-Editor und dann an Unreal übergeben wurde. Heute basiert bis zu einem gewissen Grad alles darauf.


Verlaufsdiagramm von FPS-Engines aus Wikipedia. Klicken Sie hier, um eine größere Version zu öffnen.

Einige Aspekte wurden von allgemeinen Prinzipien beeinflusst, zum Beispiel Maya, aber einige beziehen sich ganz speziell auf Unreal - eine Möglichkeit, Klassenhierarchien zu strukturieren, ein Rückgängig-System zu implementieren und alle anderen schwerwiegenden Probleme der Spieleentwicklung. Jeder, der Anfang der 2000er Jahre in die Branche eintrat, durchlief normalerweise entweder Unreal oder Quake. Obwohl Quake ein viel größeres Spiel war, scheint es mir, dass die meisten Designer über UnrealEd gekommen sind, weil seine Tools sehr praktisch waren.

Produktivitätsmultiplikation und -teilung: Tipps für Spieleentwickler

JL: 2011 haben Sie Kotaku ein Interview gegeben. Ich werde ein paar Zitate lesen, die sich meines Erachtens auf unser Thema beziehen:

„Wir haben die Spieleentwicklung immer in Bezug auf Tools angegangen. Wir haben die benötigten Tools erstellt, benutzerfreundliche Tools erstellt und weiter daran gearbeitet. “

„Wir bei Epic denken weit voraus. Wir sind wie Intel. Wir überlegen, was wir in fünf bis zehn Jahren tun werden, und wählen die geeigneten Entwicklungsrichtungen aus, während für die meisten Unternehmen die Veröffentlichung des nächsten Spiels die Grenze der Planung darstellt. Sie setzen alle ihre Ressourcen ein und machen dann das nächste Spiel. “

"Große Spielefirmen wie EA oder Activision investieren nicht in Tools, sie haben keine so langfristige Planung wie wir und unser Bewusstsein, dass wir Spieleentwicklungsprozesse so effizient wie möglich gestalten müssen."



In meinem Interview mit John Romero hat er es sehr gut verstanden und gesagt: "Werkzeuge leben länger als Spiele."

Welchen Rat können Sie Spieleentwicklern geben, damit sie diesen Fehler vermeiden und den langfristigen Wert einer Investition in Tools verstehen können?

TS: Nun ... Sie müssen scheinbar keinen Motor erstellen. Bauen Sie entweder den Motor oder tun Sie es nicht. Jetzt lähmen so viele Unternehmen ihre Produktionsprozesse und schaffen Motoren mit nutzlosen Werkzeugen. Es sind die Werkzeuge, die Menschen töten.

Schauen Sie sich all diese Engines an, die intern von Unternehmen erstellt wurden ... Zum Beispiel verfügt Frostbite über erweiterte Rendering-Funktionen als unsere und zeichnet in vielen Fällen schönere Pixel als unsere, aber Unreal-Entwickler können Inhalte ungefähr viel produktiver erstellen 30-50 Prozent produktiver. Das heißt, ein Team kann mit der halben Kraft ein Spiel mit der gleichen Qualität erstellen. Es kann mehr Iterationen durchführen und das Spiel besser verbessern als mit weniger hochwertigen Tools. Daher muss jeder eine fundierte Entscheidung treffen - entweder vollständig in die Erstellung hervorragender Tools für den internen Gebrauch investieren oder Engines von Drittanbietern verwenden.

DL: Weil Sie denken, dass Entwickler unter halben Sachen leiden?

TS: Ja. Irgendwo in diesen Unternehmen sind unglaublich dumme Buchhalter, die so denken: "Oh, wenn wir die Ausgaben für die Entwicklung von Tools begrenzen, können wir zwei Prozent des Budgets einsparen." Dies führt zu einer Erhöhung des Budgets um 50 Prozent, da viel mehr Zeit und Arbeit in die Erstellung des Spiels investiert werden muss. Daher schafft es solche verrückten, nicht rechtfertigenden Kosteneinsparungen.

Ich denke, dass jedes Unternehmen eine Entscheidung treffen sollte - entweder viel mehr in Werkzeuge investieren oder sie überhaupt nicht tun.


Und das gilt für alles. Nicht nur zu einem 3D-Editor zum Erstellen von Ebenen, sondern auch zu Assemblersystemen, zu einer Programmiersprache, Entwicklungstechnologie, DCC-Tools, zu all dem.

Werkzeuge sollten die Produktivität steigern, und wenn sich herausstellt, dass sie sie reduzieren, müssen Sie sie entfernen.

JL: Großartig. Vielen Dank, dass Sie sich die Zeit genommen haben, mit mir zu plaudern.