MrBurns hat geschrieben:WTF? Sag mir jetzt bitte nicht, dass die Wii Version deutlich schlechter aussieht als die Cube Version.
Also das würde eigentlich gar keinen Sinn machen. Ich dachte es hätte nur den Bonuscontent der PS2 Version.
Nein es ist die PlayStation 2-Version. Die Zwischensequenzen sind nicht in echtzeit berechnet wie die der GameCube-Version, sieht man an den Bonus-Kostümen. Wärend in der GameCube-Version in den Zwischensequenzen immer das Outfit zu sehen ist das man auch im Spiel nutzt ist es in der PlayStation 2- und Wii-Version egal, in den Zwischensequenzen erscheint immer das Standard-Outfit. Capcom hat dies wahrscheinlich gemacht weil es einfacher ist die PlayStation 2-Version auf Wii zu bringen und abzuändern anstatt nur die Bonusinhalte der PlayStation 2-Version auf Wii zu bringen und sowohl die Bonusinhalte als auch das Spiel einzeln abzuändern, einmal halt von der GameCube-Version [Spiel] und einmal von der PlayStation 2-Version [Bonusinhalte]. Resident Evil 4 Wii Edition ist ein Port der PlayStation 2-Version die wiederrum ein Port der GameCube-Version ist.
Also mit eine der alten Engines brauchen sie gar nicht erst antanzen, das kann imo nichts werden.
Wichtig für das Endergebniss ist NICHT die gewählte Engine sondern die Assets die man mit der Toolchain der Engine erstellen kann [und natürlich die Power der Konsole]. Auch auf der Xbox 360 und PlayStation 3 wird für Dead Space sicherlich die
"alte" Engine genutzt. Hier mal ein Text als Info dazu:
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), 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.
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.).
"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.
Letzendlich sagt eine Engine nichts über das Endergebniss aus, wie man an diversen Bsp. festmachen kann: Super Mario 64 und Zelda - Ocrina of Time nutzen die selbe Engine, Zelda - The Wind Waker und Zelda - Twilight Princess nutzen die selbe Engine, Turok 2 und das erste South Park auf dem Nintendo 64 nutzen die selbe Engine, etc.
![[ externes Bild ]](http://nio.gamingmedia.de/wss.jpg){kind=link}