[Demo 3] Terranigma 2 - Neue Engine

[The King2]

Hallo,

nach längerer Zeit der Stille melde ich mich hier mit einigen Neuigkeiten zu meinem "Terranigma 2" Projekt. Zuallererst: Ja, das Projekt geht weiter, auch wenn seit dem Release der Episode I etwas Zeit vergangen ist. Statt mit Episode II zu beginnen habe ich mich aber entschlossen, das Projekt auf die 2D/3D Game-Engine zu portieren, die ich innerhalb der letzten 2 1/2 Jahre im Rahmen des Studiums sowie meiner Freizeit entwickelt habe. Der Hauptgrund dafür ist, dass die Toolsets des Rpg-Maker XP einfach nicht (mehr) optimal für ein solches Spiel sind. Außerdem gibt es im Maker auch zur Runtime einige Beschränkungen, die ich nicht wirklich loswerden kann (doch dazu später mehr). Abgesehen davon hat sich im Laufe der Zeit eine Menge Müll im Projekt angesammelt, also schadet es auch nicht dieses mehr oder weniger "neu" zu beginnen.

Aber nun zu dem was sich das Ganze eigentlich bringt:

Demo

Fangen wir mit dem interessanten Teil an. Es gibt bereits eine Demo zum aktuellen Stand, welche den gesamten Prolog enthält und bis auf einige fehlende Features z.B. in Arks Steuerung und der Truhe im Endeffekt Release-fertig ist. Unten könnte ihr unter "Das Spiel" lesen, was es für wichtige, sichtbare Änderungen gibt, falls ihr selber keinen Unterschied bemerkt (Tipp: Die neue Version ist sehr, sehr nahe am Original dran, was looks/feels und controls angeht. Der Link ist hier:

http://www.envile-media.at/terranigm...gma2_Demo1.rar

Zum Starten im Ordner bin/Terranigma 2.exe starten. Windows 7 ist aktuell erforderlich, je nach Bedarf werde ich später auch eine WindowsXP/DX9-Variante rausbringen (muss dazu den DX9-Renderer mal auf Vordermann bringen). Die Demo hat einen längeren Betatest hinter sich, jedoch hält sich die Zahl der getesteten Rechner in Grenzen, sollte es also Probleme geben (vor allem beim Starten) bitte Kontakt mit mir aufnehmen.

Und nun eine genaue Erklärung, was sich alles geändert hat:

Das Spiel

Für das Spiel selber die neue Engine mehrere Vorteile:

- Flüssigere Darstellung:
Das Spielgeschehen wird mit 50 FPS statt mit 40 wie auf dem Maker durchgeführt, was der Framerate des SNES-Spiels entspricht. Damit lassen sich auch z.B. Animationstimings realisieren, die 1:1 denen des Originalspiels entsprechen.
- Bessere Performance:
Der Rpg-Maker hatte auch in der letzten, optimierten Version von mir noch immer extreme Performance-Probleme, gerade auf schwachen Rechnen. Die neue Engine ist in C++ und mit DirectX(9/11) realisiert, wodurch faktisch keine Peformance-Probleme mehr auf egal welchem Rechner auftreten sollten. Auf meinem High-End Hauptrechner läuft das Spiel mit 1000+ FPS, auf meinem schwachen Nebenrechner immerhin mit ~200 FPS.
- Höhere Darstellungsqualität:
Abgesehen von der Originalgetreuen Wiedergaberate, lassen sich dank kompletter Kontrolle über das Rendering auch in anderen Bereichen starke Verbesserungen erzielen. So wird der Text beispielsweise in Originalgröße mit einer 4-Zeiligen Textbox angezeigt. Die Screen-Fades zu/von schwarz laufen nun per Interpolation zu schwarz (statt Addition) und erzeugen dadurch einen viel weicheren Übergang. Spezielle NPCs wie die flackernden Seelen sehen nun durch die höhere Wiedergabegeschwindigkeit exakt wie im Original aus. Im Vollbild wird das Spiel nun pixelgetreu hochskaliert, anstatt mit einem bilinearen Filter (später wahlweise). Der Mode7 für die Weltkarte besitzt nun eine Krümmung, die exakt der Original-Weltkarte entspricht. Und noch vieles mehr...
- Bessere Steuerung:
Gut, dieser Punkt hätte sich theoretisch auch im Maker umsetzen lassen (bis zu einem gewissen Grad). Aber in der neuen Version habe ich nun die exakte Steuerung aus dem Original übernommen, mit kleinen Details wie z.B. dass Ark beim Drücken einer Richtungstaste erst nach 2 Frames zu laufen beginnt, dafür aber auch nach loslassen noch 2 Frames weiterläuft. Das Pixelmovement ist nun auch exakt, d.h. man bewegt sich tatsächlich auf dem Pixelraster, statt wie im Maker auf einem 8x8 Raster.



Man sieht, es gibt einige Vorteile die sich für das Spiel ergeben. Manche davon hätten sich auch irgendwie im Maker umsetzen lassen (Steuerung), gehen aber in der neuen Engine besser (warum , seht ihr gleich). Andere Wiederum sind nur schwer bzw. unmöglich umzusetzen, gerade in Betracht auf Echtzeitfähigkeit.

Der Editor

Die größten Verbesserungen gibt es beim Toolset, also sprich dem Editor. Versteht mich nicht falsch: Der Rpg-Maker war großartig zum Lernen der Spielentwicklung und kann auch einiges Bewerkstelligen, aber er hat einige bedeutende Schwächen (wenn man ihn mit aktuellen Möglichkeiten vergleicht).

- Erweiterbarkeit/Anpassung: Da mangelt es an vielen Stellen. Als Beispiel das Event-Scripting : Das ist zwar eigentlich großartig, aber leider sind die verfügbaren Kommandos begrenzt und lassen sich nicht aufstocken. Es ist Möglich, per Call-Script eigenen Code auszuführen, aber einerseits gibt es dafür eben keine direkte grafische Editorunterstützung (was den Sinn einer grafischen Oberfläche hintergeht), andererseits war das Call-Script Fenster auch extrem beschränkt(das lässt sich zwar extern hacken, aber gut...). Auch abgesehen davon kann man den Editor einfach nicht wirklich erweitern, sei es per Plugin, Script etc... Es lassen sich noch nicht einmal wirklich Fenster/Dockgrößen etc... ändern.
Zusätzlich gibt es noch Daten, die extrem Spielspezifisch sind, und die z.B. für jede Map anders sind, am Beispiel von Terranigma ob die Map eine Kampfzone darstellt, oder nicht. Solche Daten lassen sich nur Mühsam über Konfigurationsscripte oder ähnliches setzen, statt dass man sie irgendwie per Editor für die Maps konfigurieren kann.

- Generalisierung: Es ist relativ schwer möglich, Routinen zu generalisieren, vor allem wenn diese die Fähigkeit des Event-Systems ausnutzen sollen, dass Kommandos eine Zeit lang ausgeführt werden sollen (z.B. "Wait"). Was ich damit meine ist z.B, dass jeder Teleporter ein eigenes Event auf der Map ist. Tatsächlich unterscheiden sich aber nur Teleport-Ziel und Richtung des Betretens/Verlassens. Der restliche Code (Screen-Fade, Musik-Wechsel, etc...) ist für jeden Teleporter dupliziert. Das hat dazu geführt, dass ich ungelogen mindestens 10 Mal JEDEN einzelnen Teleporter im ganzen Spiel überarbeiten musse, weil sich ein Parameter geändert hat (andere Fade-Zeit, Fade-Out über expliziten Screen-Black statt bloß den regulären Teleporter-Fade, ...). Das ist Zeitaufwendig und Fehleranfällig. Und das gilt für so ziemlich alles was mehrfach vorkommt. Lösungsansätze gibt es, indem man z.B. Events einen bestimmten Namen gibt ("NoAttack" für Event, welches in einer Kampfzone angesprochen werden kann"), den Event-Command-Stack analysiert bzw. bearbeitet... aber es fehlt eben wieder an Editor-Tools, um das sauber zu lösen.

- WYSIWYG/Live-Editing: Der wohl größte Punkt, der sich unter keinen mir bekannten Mitteln lösen lässt. Der Rpg-Maker Editor ist eine komplett externe Anwendung, welche eine extreme beschränkte Darstellung des Spiels hat. Die Tilemap wird in Layer-Order flach gerendert, Events haben einen eigenen Layer und werden als 32x32 Quadrat dargestellt. Ich habe absolut keine Ahnung, ohne das Spiel zu starten, wie es aussehen wird. Und ja, ich kann das Spiel eben auch nicht direkt im Editor starten und eventuall anpassungen machen, nein, ich muss es extern starten, ansehen ob alles passt, schließen, wieder starten, etc... das ist ein großes Problem im Sinne von Iterationsgeschwindigkeit und Fehlersicherheit (vor allem in Bezug auf falsche Priorities/Passierbarkeiten, etc..).

Das ist nur eine kleine Übersicht der praktischen Probleme, die ich im Laufe der Entwicklungszeit gehabt habe. Nun aber zu den Features von meinem Editor auf den nächsten Tabs.

Statt fixen "Events" mit Grafik, Auslöser etc... sind sämtliche Game-Einheiten bei mir komplett modular aufgebaut. Was heißt das? Wenn man eine Entity platziert, hat die erstmal gar nichts. Dann kann man Verhalten hinzufügen: Position und Sprite entsprechen einem Picture. "Character" platziert die Entity auf der Map wie einen regulären NPC. "Plane" looped das Sprite über den gesamten Bildschirm. Der Hauptvorteil liegt darin, dass nun alles zentral über dieses Entity-System laufen kann. Man braucht kein extra "Set Picture" mit einer ID mehr um ein Bild anzuzeigen, sondern kann dieses ganz einfach entweder direkt im Editor platzieren, oder per Script spawnen lassen. Dabei hat jede Entity nur das, was sie braucht, was auch Performance-mäßig ein extremer Vorteil ist (ich hatte extre ein Antilag-Script für Terranigma 2 entworfen, was Events nach Verwendung sortiert, damit z.B. Events welche nur ein Script darstellen erst gar kein Sprite bekommen).

Wer schon einmal von Units gehört hat, hat sich von deren Prefab-System gehört. Im Grunde geht es darum, dass eine bestimmte Entity als Vorlage gespeichert wird, wobei andere dann davon ableiten können. Heißt, ich erstelle mir eine Entity "BackgroundPanorama", gebe ihr die entsprechenden Komponenten, und speichere sie als Prefab. Will ich dann der Map ein Panorama geben, erzeuge ich eine Instanz von diesem Prefab. Der Vorteil ist nun, dass Prefabs ihre Daten an die "Kinder" vererben, heißt wenn ich etwas am Prefab ändere, passen sich auch alle Instanzen davon an. Andererseits kann ich aber auch jedes Kind selber anpassen, indem ich z.B. eine andere Grafik verwende. Dies ist extrem praktisch, und sorgt dafür, dass Änderungen an so wenig Stellen wie möglich gemacht werden müssen, aber genauso spezifische Ansprüche umgesetzt werden können (zB. Gegner der bei Tod eine Tür öffnet).

Als Scriptsprache kommt eine eigene Umsetzung einer grafischen Scriptsprache zum Einsatz, die sich an den "Blueprints" der Unreal Engine orientieren. Kurzum wird bei einer solchen Sprache statt Text, ähnlich wie die Event-Commands im Maker bestimmte Command-Blöcke gesetzt und verbunden. Der Unterschied ist, dass es hierbei Klassen wie im normalen Script gibt, sich die Commands entsprechend erweitern (jede neue Klasse/globale Methode steht zur Verfügung), und die Ein/Ausgänge von Parametern verbinden lassen, womit man wesentlich mehr Möglichkeiten hat. Ein großer Fokus wurde auf die Funktionalität gesetzt, Commands eine Zeit lang laufen zu lassen, wie z.B. ein Wait, aber auch ein "PlayAnimation", welches nach Ablauf der Animation das Script weiterlaufen lässt. Zusammengefasst, dieses System bietet alle Möglichkeiten eines normalen Scriptsystems, mit den Vorteilen des Rpg-Maker Event-Systems, wodurch sie sich sowohl für Cutscenes als auch für gescriptete Systeme eignet.



Eine Entity kann dann unter Verwendung einer "Script" Komponente ein bestimmtes Script verwenden. Dort können dann die öffentlichen Parameter angepasst werden, so lässt sich z.B. rein als Scriptklasse ein scrollender Fog bauen, für den sich dann per Editor die Scrollgeschwindigkeit einstellen lässt (ohne dies Tile des Map/Tileset-Formats zu machen).



Also konkretes Beispiel, wofür sich das Scripting praktischerweise hernehmen lässt: Grundsätzlich ist es öfters notwendig, von einer Musik zuerst auszufaden, und dann eine neue einzufaden. Grundsätzlich gibt (wie im Maker) nur die Befehle "Fade in Music" und "Fade out Music". Aber mit dem visuellen Scripting lässt sich jetzt ein Befehl "FadeToMusic" erstellen, welcher eben genau diese beiden kombiniert (und z.B. noch ein Wait zwischendurch hat). Dann kann ich immer wenn dieser Fall autritt "FadeToMusic" aufrufen. Das ist ein sehr simples Beispiel, das lässt sich auch beliebig aufziehen, z.B. ein Command welches dem Spieler ein Item gibt, und die entsprechende Animation/Musik ausführt (ohne das irgendwie im Hintergrund reinwurschteln zu müssen, und damit immer wenn ein Item gegeben wird automatisch die Animation ausführen zu müssen wie es im Maker war; da musste ich dann im Endeffekt einen Hackfix mit Switches einbauen wenn ich ein Item "heimlich" vergeben wollte).

Das Asset-Handling (also die Verwaltung/Verwendung von Ressourcen wie Texturen, Sounds...) besitzt ebenso einige Erleichterungen der Arbeit. Zum einen können Assets beliebig in Ordner und Unterordner verschoben werden, und müssen nicht z.B. für Panoramas in "Graphics/Panoramas" liegen.

Weiters lassen sich spezifische Parameter an die Assets anhängen. Bei den Texturen wären das z.B. Anzahl der Frames und Richtungen, Animationsgeschwindigkeit, etc... auf diese Weise muss ich nicht wie beim Maker diese Daten in den Texturnamen speichern (Arkf[7] für eine Textur mit 7 Frames). Andere Informationen wie Animationsgeschwindigkeit brauche ich jetzt nicht bei den Entities selber angeben wie es im Maker der Fall war, sondern habe sie da wo sie hingehören, in der Textur.

Entities werden außerdem nicht per Dateinamen referenziert, sondern per (versteckter) ID, was bedeutet dass sich Assets umbenennen lassen, und trotzdem noch gefunden werden.

Die Speicherung von Savegames läuft bei mir vollautomatisch ab. In Scripten lässt sich beispielsweise einstellen, welche Attribute gespeichert werden sollen, und welche temporär sind (z.B. Tür offen/zu wird gespeichert, aber Arks Sprung-Status als Variable braucht nicht gespeichert werden, da diese eh nur während des Sprungs verwendet wird). Sämtliche Entities werden genauso automatisch gespeichert, und eben auch die dazugehörigen Scripte.

Außerdem sind die Savegames zu 99,99999% zu alten Versionen kompatibel. Einerseits gibt es keine Lese-Fehler wenn neue Elemente eingefügt werden, andererseits werden auch nur Änderungen gespeichert (z.B. Entity steht auf 99,100 statt 128, 128), d.h. nachträgliche Änderungen sind auch (meist) mit den alten Savegames kompatibel.

Für die alleinige Arbeit eigentlich weniger relevant, aber sämtliche grundlegenden Spielsystem sind in C++ gehalten, d.h. vor allem alle Componenten. Das passiert in der Form von Plugins, welche anders als die DLLs im Rpg-Maker ein komplettes C++-Interface haben, mit dem sich z.B. auch bestimmte Klassen ableiten/erweitern lassen. Das hat den Vorteil, das Performance-kritische Abschnitte wie Kollision/Pixelmovement immer so schnell wie möglich ablaufen. Vor allem hilft das, den Code strukturiert zu halten. Über die Plugins lässt sich auch der Editor erweitern, sodass ich Game-spezifische Tools nicht in den Editor selbst coden muss.

Dass das Rendering komplett hardwarebeschleunigt über DirectX abläuft, hat nicht nur Performance-Vorteile. Es ist auch viel einfacher, bestimmte Render-Effekte umzusetzen, z.B. Mode7, Screentone, oder andere spezielle Per-Pixel Effekte (Pixel-Shift um Nebel zu animieren). Dafür lassen sich eigene Shader in einer vereinfachten Shadersprache schreiben, die dann auf ein Sprite, oder auch auf den gesamten Screen angewandt werden kann (auch eigene Geometrie wie in einem 3D-Spiel lasst sich rendern, so z.B. geschehen um die Tilemap performant zu rendern).

Es stehen eine Menge an grafischer Tools zur Verfügung, um zu Testen bzw. zu Debuggen. Grundsätzlich ist es bei meinem Editor der Fall, dass das Spiel im Editor 1:1 so aussieht, wie es im Player aussehen wird. Genauso lässt sich das Spiel direkt im Editor starten.
Zum Debugging selber musste man im Maker im Endeffekt mit "print" oder einem Textlog arbeiten. Hier habe ich dank der direkten Ausgabe im Editor verschiedene Möglichkeiten:

-Visuelle Ausgaben: Es stehen mehrere Debug-Ausgaben bereits, welche sich auch erweitern lassen. Man kennt aus dem Maker bereits die Möglichkeit, nur den aktiven Map-Layer anzuzeigen, etc...hier gibt es eine Anzeige für: Passierbarkeit jeder Position auf der Map, welche Tiles an der Position der Maus sind, alle unsichtbaren Tiles (z.B. Tiles für andere Passierbarkeit), das im Tileset markierten Tile auf der Map, der Terrain-Tag auf jeder Position der Map, sowie der Eigenschaften der Entities (Kollisonsgröße, Spritegröße, Sensor-Umfang).

-Pause/Frame-Step/Speed: Eine sehr praktische Möglichkeit des Debuggings ist es, das Spiel jederzeit anhalten zu können, diese Möglichkeit hatte ich bereits in der Rpg-Maker Variante eingebaut, hier gibt es das jetzt standardmäßig im Editor. Es lässt sich auch jeweils nur eine Frame weiterspringen, bzw. die Geschwindigkeit zwischen 0.125x und 8x anpassen, um bestimmte Abschnitte schneller überspringen zu können, oder auch selten auftretende Fehler schneller reproduzieren zu können.

-State save/loading: Es lassen sich im Editor Playmode jederzeit Savegames erstellen, sowie bereits vorhandene laden. Damit kann man relativ schnell Änderungen testen, indem man bis zu einer gewissen Stelle spielt, ein Savegame erstellt, Änderungen im Editor-Mode macht, und das Save wieder lädt, solange bis man zufrieden ist.

-C++/Plugin-Debugging:SämtlichenPlugin/C++-Code lässt sich logischerweise mit einer IDE debuggen (Visual Studio), was dafür sorgt dass ich mit Breakpoints, direkter Anzeige von Variablen-Werten etc... Probleme viel schneller finden und lösen kann, als das im Maker der Fall war.

-Script-Debugging: Das Script-System lässt sich ebenso komplett debuggen. Breakpoints stehen zur Verfügung, und Variablenwerte bzw. lokale Werte von Commands lassen sich ebenso anzeigen. Damit ist auch das finden von Fehlern in Scripten deutlich einfacher (obwohl es ebenso noch "print" Befehle gibt, welche aber seltener zur Anwendung kommen).

Die Übersetzung von Texten im Rpg-Maker empfand ich persönlich immer als extrem umständlich, da man standardmäßig jeden Text in den Events suchen musste, und durch die anderssprachige Version ersetzen musste. Dabei konnte man dann die Sprache nicht zur Laufzeit ändern (minor issue), aber vor allem konnte ich nicht einfach zu einem gewissen Stand des Projekts einen Teil übersetzen, dann weiterarbeiten, und dann die Übersetzungen mergen, weil ich dafür ja ein eigenes Projekt für die andere Sprache anlegen musste. Hier ist die Lokalisierung standardmäßiger Teil des Editors, und statt
die Texte direkt in die Cutszenes zu schreiben, wird ein lokalisierter String referenziert, und je nach Sprache gibt dieser einen anderen Wert zurück.

Auch die Oberfläche des Editors hat einige offensichtliche Verbesserung. So lassen sich sämtliche Objekte, von Szenen über Assets bis hin zu lokalisierten Strings mit Ordnern im Editor gruppieren, um eine bessere Übersicht zu schaffen. Sämtliche Elemente lassen sich vergrößern/verkleinern, bzw. sofern vorgesehen aus der Verankerung lösen und frei am Bildschirm bzw an einer anderen Stelle platzieren. Es werden theoretisch unendlich Undo-Befehle unterstützt, und es gibt eine größere Anzahl an nützlichen grafischen Ansichtselementen (Entities der aktuellen Map, Eigenschaften des ausgewählten Objekts, ...).

Die Szenen entsprechen der Maps Rpg-Maker. Abgesehen davon, dass man jetzt wie oben erwähnt auch Szenen gruppieren kann, ohne diese untereinander anordnen zu müssen, haben die Szenen hier auch eine wesentlich breitere Verwendung. Im Maker musste ich z.B. für das Truhenevent ein eigenes "Scene"-Script anlegen, und die grafischen Elemente coden, da es nicht (nativ/leicht) Möglich war, mehrere Szenen übereinander anzuzeigen. Durch die breitere Verwendbarkeit der Entities, sowie einem "Scene-Stack" (es können mehrere Szenes gleichzeitig aktiv sein, wobei immer nur die neueste angezeigt wird) ist es jetzt auch Möglich, komplexe Menüs direkt im Editor als Szene anzulegen und zu verwenden, was es wiederum leichter macht diese anzupassen bzw. zu debuggen/testen.
Außerdem können Szenen ebenso wie Assets User-Parameter haben, wie z.B. Kampfgebiet ja/nein, Name der beim Betreten angezeigt werden soll, etc...

Das war die Übersicht über die wichtigsten generellen Editor-Features die mir gerade eingefallen sind. Es handelt sich auch dabei nur um einen groben Auszug, es gibt noch sehr viele Details die anders sind. Zum Beispiel gibt es bei mir keinen globalen Player ($game_player), sondern um einen steuerbaren Player zu erzeugen, wird lediglich eine spezifische Entity gespawnt, die auch nur auf dieser Map lebt. Das macht es einfacher, Szenen umzusetzen wo kein Player benötigt wird, bzw. sorgt dafür dass der Player nicht fälschlicherweise Änderungen aus Cutszenes mit sich trägt. Playerdaten müssen daher in einem externen Script bzw. Plugin gespeichert werden. Nur als Beispiel, gibt sicher tausende mehr, aber ich denke der Punkt kommt rüber.

Abgesehen davon gibt es noch einige weitere Verbesserungen, die eher spezifisch auf Terranigma zugeschnitten sind:

Grundsätzlich wird für die Tilemap/das Tileset ein ähnliches Format wie im Rpg-Maker XP verwendet.

Weniger Beschränkungen:
Aber viele Beschränkungen wurden aufgehoben: Es ist jetzt möglich, beliebig viele Autotiles zu haben. Außerdem lassen sich beliebig viele Layer verwenden. Für kleine, simple Maps reicht ein Layer, was Speicherplatz spart und die Darstellung schneller macht, und für richtig komplexe Maps lassen sich auch mehr als 3 Layer verwenden.

"SmartMapping":

Dabei handelt es sich um ein sehr spezielles Feature, das ich entworfen habe um das Mapping schneller zu machen (man missachte den unkreativen Namen). Dabei handelt es sich grundsätzlich um eine Option für das Mapping, welche grob gesagt das Layer-System für den Nutzer deaktiviert, sodass man einfach Mappen kann, und das Tool wählt dann den "richtigen" Layer aus. Das passiert basierend auf ein paar generischen Regeln, die ich mir überlegt habe. Zum Beispiel liegt Boden immer unter einem Tile, das halbtransparent ist (also z.B. nur in den unteren 16 Pixeln den oberen Teil einer Säule enthält). D.h. komplett undurchsichtige Tiles werden immer in den Layer 0 gemapped, und halbtransparente immer darüber. Die Details sind noch etwas komplizierter, aber das ist die grundlegende Idee dahinter. Weiters gibt es noch zusätzlich Modi die sich durch STRG bzw. SHIFT aktivieren lassen. Dabei handelt es sich um "lowest" bzw "highest". Das sorgt dann dafür, dass z.B. bei "highest" Bodentiles immer so weit wie möglich oben gezeichnet werden, d.h. sämtliche anderen Tiles überschreiben. Priorities werden dabei auch beachtete.
Im Endeffekt kann man sagen, dass wirklich in 95% der Fällen damit kein manueller Layerwechsel mehr notwendig ist. Für den Rest der Zeit kann man diesen Modus auch deaktivieren, aber wenn er aktiv ist, macht er das Mapping für mich signifikant schneller.

Map Cleanup:

Ebenso ein Algorithmus, der sich mit der Optimierung des Maplayouts beschäftigt. Dabei geht es darum, dass Mapping "Fehler" behoben werden. Zum Beispiel werden unsichtbare Tiles entfernt (wenn ein Bodentile auf Layer 3 liegt, und darunter andere Priority 0 Tiles sind), duplizierte Tiles (2x selbest Tile übereinander), Leerräume behoben (Ein Tile in Layer 2, darunter nichts), Priorities sortiert (Tile mit Priority 3 sollte immer über einem Tile mit niedriger Priority legen), etc... damit lassen sich je nach Map ganze überflüssige Layer löschen. Das Feature habe ich eingebaut, da viele meiner ersten Maps relativ schlimm waren, und ich jetzt endlich wieder Änderungen an ihnen machen kann, ohne für jede Position erstmal 3 Layer Chaos aufräumen zu müssen. Kleiner Fakt nebenbei, das "SmartMapping" erzeugt genau Maps die bereits vollkommen optimiert sind, d.h. es stecken diesselben Regeln dahinter.

Sonstiges:

Es gibt auch abseits davon kleinere Verbesserungen. Zum Beispiel lassen sich die Tileset-Parameter direkt im Tileset neben dem Game-View editieren, und somit die Änderungen von z.B. Passabilities life sehen. Die Richtungs-Passabilities lassen sich jetzt direkt per rechts-klick in die jeweilige Seite/Ecke anpassen. Es gibt eine Funktion, um ungenutze Tiles im Tileset anzuzeigen. Bei einer Multi-Selektion werden sämtliche Selektierte Tiles in der Tileset-Ansicht angezeigt (beim Maker wurde dann einfach nichts mehr gezeigt). Beim Mouse-Over wird in der Tileset-Ansicht die Tile-ID angezeigt. Etc...

Für die Dialoge gibt es ebenso einige Optimierungen. Auch wegen der automatischen Lokalisierung muss ich den Text nicht mehr selber Formatieren (Absätze, sichtbarkeit von Wörtern am Rand), sondern er passt sich selber auf die Textbox an. Befehle (Wait, Textspeed, Color) müssen nicht mehr als Commands in den Text geschrieben werden, sondern werden als "Markups" als Eigenschaft des Strings angehängt (das sorgt dafür dass der Text besser leserlich bleibt, und keine Probleme mit unterschiedlichen Sprachen entstehen). Wenn ein Charakter mit Namen spricht, brauche ich den Namen nicht mehr selber mit Formatierung in den Text einfügen, sondern kann einmal grundsätzlich den Namens-Local referenzieren. Noch besser geht es, dass ich einfach die sprechende Entity übergebe, dann sucht sich der Dialog selber über eine Komponente den Namen heraus, und positioniert auch noch die Textbox automatisch so, dass die sprechende Entity nicht verdeckt ist.

Ich habe mich für ein wesentlich simpleres Animationssystem entschieden, das nur über Frame-IDs, und nicht wie im Maker über genaue Position etc... funktioniert. Ich habe herausgefunden, dass das für meine Zwecke wesentlich besser und vielseitiger zu verwenden ist. Nun brauche ich lediglich die Frames nacheinander anordnern, wie ich es regulär machen würde, und kann dann daraus eine Animation abspielen. Das macht es viel angenehmer, als die 192x192-Felder belegen und positionieren zu müssen, und reicht vollkommen, da ich aktuelle noch keinen Fall habe wo ich wirklich z.B. in einem Frame mehrere Texturen anzeigen müsste, oder die Position so unterschiedlich ist dass es sich nicht als Verschiebung in der Frame-Texture darstellen lassen würde.

Inventar-Gegenstände werden viel simpler gehandhabt, nämlich werden dazu als Definition eines Items lediglich Prefabs verwendet. Eine "Item"-Komponente bestimmt den Typ (Item, Rüstung, Waffe...), und das Item selber übernimmt das Aussehen des Prefabs (d.h. ich kann z.B. eine "Animations" Komponente anhängen, wenn ich ein Item animieren wollte).

Das waren die wichtigsten Features aufs Spiel bezogen, welche ich als nennenswert erachtet habe. Auch hier gibt es wieder extrem viele Details, z.B. dass sich Sound-Effekte als Entity spawnen lassen, die dann frühzeitig entfernt werden kann um den Sound abzubrechen. Aber genau solche Details machen die Arbeit einfach viel einfacher, schneller und angenehmer.

Soweit zu den Änderungen durch die neue Engine. Jetzt fragen sich vermutlich die meisten (vor allem wer schonmal damit gearbeitet hat): Warum nicht einfach Unity/Unreal hernehmen? Meine eigene Engine schreiben macht mir einfach enormen Spaß. Klar, ich bin nicht ganz so produktiv wie ich sein könnte, aber nachdem ich jetzt erstmal den grundsätzlichen Point-of-Unproductivity überwunden habe, ist das Gefühl selber etwas derartiges geschaffen zu haben und damit wirklich Content erzeugen zu können, gewaltig.

Und zur Frage, ob ich nicht ohnehin mit dem Maker schneller wäre, da ich ja dort schon einen guten Drittel des Spiels habe, den ich jetzt portieren muss, abgesehen von den ganzen Systemen? Jein. Ich habe ja viele gute Gründe genannt warum ich meine Tools auf der Erfahrung mit dem Maker aufbauend verbessert habe. Es gibt hier und da natürlich immer Sachen die nicht gehen, und ich muss eine Menge Zeit reinstecken den Editor bzw. die Engine zu warten... ob ich jetzt so oder so schneller bin, bleibt dahingestellt. Sobald die nächsten großen Roadblocks (Kampfsystem, Story-Progression) abgeschlossen sind, sollte ich jedenfalls mit der Portierung extrem schnell vorankommen. Und ich verbringe lieber 1 Jahr mehr in meinen eigenen Tools, als nochmal nen Nachmittag lang 2000 Teleporter-Events zu überarbeiten

Man darf auch nicht außer acht lassen, dass ich viel Zeit investiere, um die jetzige Version besser zu machen. Ich habe nochmal sämtliche Dialoge neu geschrieben, manche Szenen überarbeitet bzw. verschoben, und werde auch nochmal z.B. Magiesystem überarbeiten. Im Endeffekt wird es sich sicher lohnen, und wer die aktuelle Demo mal angespielt hat dürfte mir zustimmen dass es sich bereits jetzt besser bzw. näher am Original anfühlt und spielt.

Soweit dazu...

TLR
Ich wollte mal wieder ein Lebenszeichen von mir geben und zeigen, dass das Projekt noch nicht tot ist. Leider gibt es relativ wenig neuen Kontent, aber ich würde trotzdem sagen, dass es sich für jeden der allgemein Interesse an Terranigma und/oder meinem Projekt lohnt, diese zu spielen (egal ob das alte Projekt schonmal angezockt wurde oder nicht), da sich doch einige Dinge geändert haben, und wie gesagt das Spielgefühl wesentlich besser ist. Die Savegames werden auch nach aktueller Vorraussicht weiter kompatibel sein, also lasst euch nicht davon abschrecken dass es jetzt erst ein paar Spielminuten im Prolog gibt

Mfg
The King