Onkel Willie, was ist eigentlich eine "Engine"...?

wsippel

L20: Enlightened
Thread-Ersteller
Seit
15 Mai 2006
Beiträge
25.225
Weil mir immer wieder auffällt, dass hier und in anderen Foren unglaublich gerne mit diesem Begriff geworfen wird, ohne dass jemand versteht, was eine Engine ist und wie sie funktioniert, dachte ich mir, man sollte es mal erklären.

Was ist eine Engine?

Eine Engine ist eine Laufzeitumgebung für Spiele. Spiele laufen auf Engines.

Werden Spiele mit der Engine gemacht?

Nein. Erstellt werden die Spiele mit einer Toolchain, einer Reihe externer Werkzeuge. Die Toolchain muss allerdings zur Engine passen, damit die eigentliche Engine die erstellten Inhalte versteht. Viele Engines kommen im Paket mit entsprechenden Toolchain-Komponenten wie zum Beispiel Leveleditoren.

Woraus besteht dann das Spiel?

Aus Assets, also aus den Inhalten, die mit der Toolchain erstellt werden. Das sind beispielsweise 3D Modelle, Texturen, Leveldesigns, Soundeffekte, Musik, Cutscenes, das Interface und nicht zuletzt das eigentliche Spiel: eine Sammlung von Skripten, die die Spielabläufe steuern. Die Regeln, sozusagen.

Spiel und Engine sind also verschiedene Programme?

Könnte man so sagen. Und es kommen üblicherweise auch unterschiedliche Programmiersprachen zum Einsatz. Während die Engines überwiegend in C, C++ und/ oder Assembly geschrieben werden ("richtigen" Programmiersprachen also, wobei Assembly eigentlich schon gar keine Programmiersprache mehr ist), werden die eigentlichen Spiele idR in Skriptsprachen geschrieben, also beispielsweise LUA, ECMA (JavaScript), Lisp, Squirrel, Perl oder Python. Manche Engines verwenden eigene Skriptsprachen, wie beispielsweise die Unreal Engine von Epic (UnrealScript). Skriptsprachen sind nicht nur wesentlich einfacher und schneller zu programmieren, sie sind auch plattformunabhängig. Ein LUA-Skript läuft auf jeder Plattform, für die es einen LUA-Interpreter gibt. Und damit auf so ziemlich jedem Stück Hardware von der PS3 bis zur Kaffeemaschine.

Wie sieht eine Engine aus?

Gar nicht. Engines selbst sehen überhaupt nicht aus, sie klingen nicht, sie machen ohne Spiel ziemlich genau gar nichts. Daher sind Aussagen wie "alle UE3-Spiele sehen gleich aus" unsinnig. Wie das Spiel aussieht, klingt oder sich spielt hängt in erster Linie von den Assets ab, und natürlich von den Möglichkeiten der Hardware. "Das Spiel sieht scheiße aus, weil die Engine nix taugt" kann in Ausnahmefällen stimmen - in der Regel sind aber tatsächlich nur die Assets scheiße.

Interessiert den Entwickler des eigentlichen Spiels die Engine dann überhaupt?

Kaum. Den Entwickler interessiert im Prinzip nur die Toolchain, denn damit muss er schließlich arbeiten. Und von der Engine hängt eben ab, welche Werkzeuge er benutzen kann. Und natürlich, wie stabil die Engine läuft, und was man mit ihr (wie einfach) umsetzen kann.

Warum verwenden dann so viele Leute beispielsweise die UE3, wenn die Engine doch eigentlich keine Rolle spielt?

Ich sage nicht, dass die Engine überhaupt keine Rolle spielt. Die UE3 ist robust und einigermaßen flexibel. Aber in erster Linie hat die UE3 eine sehr gute, gut dokumentierte und effiziente Toolchain. Es ist also einfach, auf UE3 zu entwickeln. Sofern man damit während der Entwicklung ausreichend Zeit und Geld spart, können die horrenden Lizenzkosten kompensiert werden. Und nicht zuletzt hängt von der Engine ab, auf welchen Plattformen das Spiel am Ende überhaupt läuft bzw. laufen kann. Das Spiel kann nur auf Plattformen laufen, für die es eine passende Laufzeitumgebung gibt.

Ab welchem Punkt der Entwicklung spielt die Plattform eine Rolle?

Eigentlich erst am letzten Punkt, also wenn das eigentliche Spiel auf der Engine ausgeführt wird. Sofern die Laufzeitumgebung auf mehreren Plattformen läuft, und die Assets nicht überdimensioniert sind, läuft das Spiel auf jeder unterstützten Plattform mehr oder weniger gleich. Es ist also durchaus möglich, eine "Engine" zu entwickeln, die Plattformen vom DS bis hin zu high-end PCs unterstützt, und auf jeder Plattform erlaubt, das Maximum herauszuholen. Tatsächlich wären es aber unterschiedliche Laufzeitumgebungen für jede Plattform - nur die Toolchain wäre immer die selbe.

Also ist selbst die UE3 ein glorifiziertes Flash?!?

Dingdingding! Die UE3 Laufzeitumgebung ist das Flash Plugin, UnrealEd ist Flash, UnrealScript ist ActionScript, und der Rest der Toolchain kann sogar mehr oder weniger identisch sein (Photoshop, Illustrator, 3D Studio, Wavelab etc.).


Habe ich noch irgendwelche typischen Fragen vergessen? :)
 
Zuletzt bearbeitet:
Ändere das in Game Engine.
Mit Engine alleine meint man eher ne Grafik Engine, die bietet aber keine Sound Unterstützung, Tastaturabfragen, Network,.....
Und man braucht schließlich alles zusammen um nen Game zu machen, ergo Game Engine ;)

Grob genomne ist OpenGL auch ne Grafik Engine, aber es bietet keine Funktionen um Tastatur abzufragen ohne entsprechende 3rd Party Libraries und OpenGL alleine reicht nicht aus um ein Game zu machen
 
Ändere das in Game Engine.
Mit Engine alleine meint man eher ne Grafik Engine, die bietet aber keine Sound Unterstützung, Tastaturabfragen, Network,.....
Und man braucht schließlich alles zusammen um nen Game zu machen, ergo Game Engine ;)
Die "Engine" in diesem Kontext ist die Summe der Komponenten.

Grob genomne ist OpenGL auch ne Grafik Engine, aber es bietet keine Funktionen um Tastatur abzufragen ohne entsprechende 3rd Party Libraries und OpenGL alleine reicht nicht aus um ein Game zu machen
OpenGL ist keine Engine. Es ist eine API, bzw. die Spezifikation für eine API. Die Grafik Engine kann man auf diese API aufsetzen (oder eben auf D3D, GX, SDL etc.).


wiispiele haben eine scheiß engine
Here we go!
 
Dank an wsippel für die gute Erklärung nun dürfte es jeder Laie (auch ich) verstanden haben, man lernt halt niemals aus ABER hier ist war bereich also - alle UE3 Spiele sehen gleich scheiße aus xD
 
Die "Engine" in diesem Kontext ist die Summe der Komponenten.


OpenGL ist keine Engine. Es ist eine API, bzw. die Spezifikation für eine API. Die Grafik Engine kann man auf diese API aufsetzen (oder eben auf D3D, GX, SDL etc.).
Drum hab ich auch geschrieben grob!
OpenGL bietet dir alles um ne Grafik Engine zu bauen, willst du aber jedoch Sound ausgeben bietet dir OpenGL nix in der Hinsicht, muss es ja auch nicht ;)
Wollte nur sagen Grafik Engine != Game Engine
Wenn du schon mit den ganzen Toolchain Zeugs kommt, is es besser wenn man Game Engine sagt anstatt Engine, naja mir wurscht aber wenn du schon aufklären willst dann richtig
 
Gute Erklärung.
Eine Frage hätte ich trozdem noch:
Was für Tools können alles in einer Toolchain enthalten sein bzw. was ist bewährt in der professionellen Game Entwicklung? Ich kenn nur 3ds MAX.
 
Ich finden den Thread sehr interessant, ach wenn das Unterforum vielleicht nicht sehr geeinget dafür ist. Aber so werden bestimmt die meisten aufgeklärt ^^
Es spielt schon in den War rein. Beispiel:

"UE3 läuft nicht auf der Wii, weil die Wii zu schwach ist." - Das ist kompletter Schwachsinn, und Mark Rein sollte man für die Aussage einen Regenschirm in den Hintern schieben und aufspannen. Kein Lizenznehmer nutzt die UE3, weil die eigentliche Engine so toll ist. Sie nutzen sie, weil die Tools so gut sind, und sie Erfahrung damit haben, also Zeit und Schulungskosten sparen, und kein Geld für andere Werkzeuge ausgeben müssen. Natürlich könnte Epic nicht einfach die vorhandene Laufzeitumgebung auf Wii portieren, denn die wäre sicherlich überdimensioniert. Aber sie könnten eine kompatible Laufzeitumgebung schreiben (auch die bereits vorhandenen vier Versionen der Laufzeitumgebung unterscheiden sich gewaltig voneinander), und schon könnten die eigentlichen Entwickler mit ihrer gewohnten Toolchain anfangen, Wii-Spiele zu entwickeln.

Andere Entwickler wie SQEX haben das scheinbar verstanden. Die haben ihre Engine auch nicht grundlos von White Engine in Crystal Tools umbennant. Denn auf genau diese Tools kommt es schließlich an. Wenn SQEX also sagt, sie haben die Crystal Tools für Wii angepasst, meinen sie damit, dass sie ihre Toolchain so angepasst haben, dass Entwickler mit der exakt selben Arbeitsumgebung für PC, PS3, Xbox360 und Wii entwickeln können. Natürlich sehen die Resultate unterschiedlich aus, und die Wii-Version hat höchstwahrscheinlich eine komplett andere, aber eben kompatible Laufzeitumgebung, nur erlaubt ihnen das, Teams nach Belieben auf Projekte für jede Plattform anzusetzen und Assets soweit wie möglich zwischen den Plattformen zu recyclen. Nehmen wir beispielsweise an, sie wollten ein Wii-Spiel machen, in dem FFXIII-Charaktere vorkommen. Sie können nicht die HD-Versionen der Modelle und Texturen verwenden, aber zumindest die Animationen und Soundeffekte (Skits) 1:1 übernehmen. Gut, die Modelle und Texturen möglicherweise auch, wenn sie niedrigere LODs haben.

Daher sollte man auch Aussagen wie "Team X hat jetzt Erfahrungen mit Plattform Y gesammelt, also entwickeln sie weiterhin dafür" in diesem Fall vergessen. Sie haben Erfahrungen mit der Toolchain gesammelt, und somit die Möglichkeit, jederzeit für jede kompatible Plattform zu entwickeln. Eine Option, die Epic und ihre Lizenznehmer nicht haben.
 
Zuletzt bearbeitet:
Sehr cooler Thread :) Dann hat die Engine also per se auch nichts mit der Grafik oder Nutzung von Tevs/Shadern zu tun? Was ist mit Middleware? Fürs ruhig noch ein wenig weiter aus Wsippel, ist sehr interessant.
 
Gute Erklärung.
Eine Frage hätte ich trozdem noch:
Was für Tools können alles in einer Toolchain enthalten sein bzw. was ist bewährt in der professionellen Game Entwicklung? Ich kenn nur 3ds MAX.
Kommt auf die zu entwickelnden Assets an:

3D: zB 3DS Max, Maya, XSI, Modo, Blender, ZBrush
2D (Bitmap): zB Photoshop, ZBrush, Bodypaint, TV Paint, Paintshop Pro, Gimp, Cinepaint
2D (Vektor): zB Illustrator, Freehand, Inkscape
Animationen: zB XSI, 3DS Max, Maya, Endorphin
Leveldesign: je nach Engine: UnrealEd (Unreal Engine), Radiant (alle id Engines), Hammer oder XSI mit entsprechendem Plugin (Source) etc.
Sound: zB Wavelab, ProTools
Musik: je nach unterstütztem Format: Cubase, Logic (Midi, Wave), ProTools (Wave), Renoise, Skale (Mod)
Video: praktisch jedes Programm, das so für Videoproduktionen verwendet wird, von 3D Programmen (siehe oben) über Compositing (zB Shake, After Effects) bis hin zu Schnittprogrammen (Final Cut, Premiere)
Skripte: prinzipiell jeder noch so einfache Texteditor, bevorzugt mit Syntax Highlighting (VIM, Emacs, BBedit), oder eben IDEs (Visual Studio, Codewarrior)


Sehr cooler Thread :) Dann hat die Engine also per se auch nichts mit der Grafik oder Nutzung von Tevs/Shadern zu tun? Was ist mit Middleware? Fürs ruhig noch ein wenig weiter aus Wsippel, ist sehr interessant.
Ob und wie beispielsweise Shader unterstützt werden, hängt von der Engine ab. Aber die Engine bestimmt idR nicht, wie man sie schreibt und wie effizient sie sind. Shader sind im Prinzip nicht viel anders als Texturen, nur sind es keine Bilder, sondern kleine Programme. Man schreibt die Shader auch nicht mit der Engine, sondern mit Texteditoren oder speziellen Hilfsmitteln - grafischen Programmen, die hinterher die Shader ausspucken.

Auch sonst hat die Engine schon mit der Grafik zu tun. Beleuchtung und Schatten sind beispielsweise Aufgaben der Engine. Es gibt allerdings Wege, bei den meisten Engines gewisse Limitierungen zu umgehen, indem man Schatten in Texturen einbackt und dergleichen. Von der Engine hängt nicht so sehr ab, was man machen kann, sondern in hohem Maße wie man es macht. Auch mit der Performance der Grafik hat die Engine zu tun. Keine Engine kann irgendwas an der Leistungsfähigkeit der Hardware ändern, also kann auch die UE3 nicht mehr Polygone darstellen als die Hardware erlaubt, beispielsweise. Aber es gibt bestimmte Tricks, um mit den Ressourcen effizienter umzugehen. Und da kann die Engine dem Entwickler durchaus einige Arbeit abnehmen.

Und ich weiß jetzt nicht genau, was Du mit Middleware meinst? Die Engine selbst ist Middleware. ;)
 
Zuletzt bearbeitet:
Kommt auf die zu entwickelnden Assets an:

3D: zB 3DS Max, Maya, XSI, Modo, Blender, ZBrush
2D (Bitmap): zB Photoshop, ZBrush, Bodypaint, TV Paint, Paintshop Pro, Gimp, Cinepaint
2D (Vektor): zB Illustrator, Freehand, Inkscape
Animationen: zB XSI, 3DS Max, Maya, Endorphin
Leveldesign: je nach Engine: UnrealEd (Unreal Engine), Radiant (alle id Engines), Hammer oder XSI mit entsprechendem Plugin (Source) etc.
Sound: zB Wavelab, ProTools
Musik: je nach unterstütztem Format: Cubase, Logic (Midi, Wave), ProTools (Wave), Renoise, Skale (Mod)
Video: praktisch jedes Programm, das so für Videoproduktionen verwendet wird, von 3D Programmen (siehe oben) über Compositing (zB Shake, After Effects) bis hin zu Schnittprogrammen (Final Cut, Premiere)
Skripte: prinzipiell jeder noch so einfache Texteditor, bevorzugt mit Syntax Highlighting (VIM, Emacs, BBedit), oder eben IDEs (Visual Studio, Codewarrior)

Danke danke :-)
 
Zurück
Top Bottom