[Demo 3] Terranigma 2 - Neue Engine

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.

http://fs1.directupload.net/images/1...p/26ba5fsr.pnghttp://fs1.directupload.net/images/1...p/n29yymnf.png

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).

http://fs2.directupload.net/images/1...p/eerdbjyi.png

- 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).

http://fs2.directupload.net/images/1...p/a4kgoemq.png

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).

http://fs1.directupload.net/images/1...p/he6lv4dv.png

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.

http://fs2.directupload.net/images/1...p/6xg73olu.pnghttp://fs2.directupload.net/images/1...p/dgmmby3d.png

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).

http://fs2.directupload.net/images/1...p/umkyp39e.png

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.

http://fs1.directupload.net/images/1...p/c8lb4bwo.png

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).

http://fs1.directupload.net/images/1...p/8gy9cd94.png

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.

http://fs2.directupload.net/images/1...p/kn9kfmyv.png

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...

http://fs1.directupload.net/images/1...p/n9q9yew4.png

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...

http://fs2.directupload.net/images/1...p/355hjony.png

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.

http://fs1.directupload.net/images/1...p/ucq3ti9x.png

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 :D

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...

TL;DR
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

Oha, das Zeugs hast du komplett selbst geschrieben? Nice.

Technisch ist was ich da lese schon verdammt beindruckend. Probier das ganze morgen aus, aber sieht schon vielversprechend aus. Alles allein auf die Beine gestellt?

Bin ich doof oder hat der bin-Ordner keine Terranigma2.exe?

@Corti, Mivey:

Danke! Ja, ich hab im Endeffekt alles selber von grundauf alleine geschrieben. Bis auf die notwendigsten Libaries (Win32, DirectX, XAudio...) habe ich auch keine vordefinierten Libaries verwendet. Mir ging es vor allem auch um den Lernfaktor, obwohl ich zugeben muss dass Sachen wie eine (Editorfähige) UI-Libary schreiben schon arg an Wahnsinn grenzt ;)

@goldenroy:

Ah, du hast vollkommen recht, derweil heißt die "Acclimate Player.exe". Merkwürdig, ich habe zwar die .exe manuell reinkopiert (heißt ursprünglich so wie jetzt und wird erst vom Packaging-Tool umbenannt), aber eigentlich hatte ich die umbenannt. Funktionieren tut es trotzdem - ich habe zwar eine neue Version hochgeladen, wo das behoben ist, musst die aber nicht extra runterladen, kannst einfach den Player so starten. Danke fürs finden/melden!

hah, wilkommen zurück The King2

irgendwie hab ich den thread hier wohl verpasst in 2013 schön das das projekt noch lebt und du weitermachst :)

So hab die Demo mal angespielt:

PC:
CPU: i7 3700 @ 3.4 GHZ
RAM: 16 GB
GPU: GTX 970
OS: Windows 7 x64 SP1

Also die Schrift wird nicht angezeigt. Die Font die in der Readme steht fehlt, es gibt kein Verzeichnis Game/Assets/. Sollte schnell korrigiert sein. (Und vielleicht am besten so eine wichtige Ressource in die exe einbinden und dynamisch laden, kann Windows das? )

Sonst kann ich nur sagen, dass das Intro entweder die Option haben sollte es zu überspringen, oder deutlich verlängert werden sollte: Ein normaler Schlafzyklus bei mir dauert etwa 7 bis 8 Stunden, und am besten die Musik dann auch nach 20 Minuten dämmen und in den letzten 20 Minuten langsam erhöhen. So ist das ein guter Schlaftablettenersatz.

Die kurze Spielbare Sektion mit der Möve fand ich toll, aber ohne die Schrift halt nicht so spannend^^.

@Mivey:

Zitat:

---

Also die Schrift wird nicht angezeigt. Die Font die in der Readme steht fehlt, es gibt kein Verzeichnis Game/Assets/. Sollte schnell korrigiert sein. (Und vielleicht am besten so eine wichtige Ressource in die exe einbinden und dynamisch laden, kann Windows das?

---

Ok, danke fürs Testen, das ist sehr interessant. An sich habe ich genau das gemacht - die Schrift ist zwar nicht in die .exe angebunden, sondern Teil der Assets und sollte dann per Win-API Funktion geladen werden. Soweit ich das getestet hatte, ging das noch, kann aber auch sein dass er die Font auf meinem PC nicht richtig deinstalliert hatte. Werde noch schauen dass ich irgendwo einen PC auftreibe, wo die Schriftart noch nicht standardmäßig installiert ist. Sollte ich das jetzt reproduzieren und fixen können lass ich es wie es ist, ansonsten leg ich nochmal die Schriftart im genannten Ordner bei (das war noch vor dem Packaging, da war der Ordner noch da).

Zitat:

---

Sonst kann ich nur sagen, dass das Intro entweder die Option haben sollte es zu überspringen, oder deutlich verlängert werden sollte: Ein normaler Schlafzyklus bei mir dauert etwa 7 bis 8 Stunden, und am besten die Musik dann auch nach 20 Minuten dämmen und in den letzten 20 Minuten langsam erhöhen. So ist das ein guter Schlaftablettenersatz.

---

Ich hatte früher Mal die Option das Intro zu überspringen, da war es aber noch ungefähr 2-3x so lang, was vom Feedback her deutlich zu lang war. Also deutlich verlängern möchte ich das Intro nicht, sofern ich keine gute Idee für Gameplay habe (einfach nur mehr Dialoge ist nicht so dolle). Vielleicht lässt sich was mit Melina machen, oder mehr mit der Möwe... werd mal schauen was sich machen lässt. Aber ich glaub allgemein dass es mit der Schriftart deutlich besser rübergekommen wäre, echt lästig das, hoffe ich find den Grund gleich mal. Andernfalls werde ich eventuell die Option einbauen, das Intro beim mehrmaligen Spielen zu überspringen, auch wenn ich davon nicht so der Fan bin (sollte ich weiter entsprechendes Feedback bekommen).

EDIT: Ok, wenn ich auf dem Rechner hier die Schriftart deinstalliere, sehe ich auch keinen Text. Dann mal schauen woran das liegt, sollte hoffentlich heute noch eine neue Version raufladen können.

@Lord of Riva:

Danke, schade dass du den Thread damals nicht gesehen hast, damals hätte ich dir noch unbedingt geraten die Vollversion anzuzocken, heute bin ich davon nicht mehr ganz so überzeugt, im Vergleich zur neuen Variante ;) Aber mal sehen wann die neue Vollversion rauskommt...

EDIT2:

Hab den Fehler gefunden, lag in der Reihenfolge in auf bestimmte Ressourcen zugegriffen wird. Das ursprüngliche Problem zu lösen wird etwas länger brauchen, hab es aber derweil mal temporär zum laufen gebracht, neue Version ist unterdemselben Link oben.

Jep geht es, und tatsächlich ist das Intro mit dem Text schon deutlich bekömmlicher. Nur das Prolog ist dafür auch mit dem Text langweilig^^ Aber ich mag halt diese Art von Storytelling überhaupt nicht, dieses ominöse langatmige Erzählen. Medias in Res hätte da besser gepasst, gerade da Terranigma (also der erste) ja selbst total am Anfang beginnt.
Aber nimm diese Kritik nicht zu ernst, JRPGs sind schon lange nicht mehr mein Ding. Dein Spiel macht aber Lust Terranigma auf der SNES mal wieder zu spielen. Technisch (und grafisch) hervorragend!

Meinetwegen könnten die Bilder und Texte im Intro ein wenig länger sichtbar bleiben. Insbesondere da bis zum Umschwung der Musik so lange an zwei Stellen ein Blackscreen zu "sehen" ist.
Und auch wenn die Rechtschreibprüfung sicher erst noch ansteht, kann ich einen groben Patzer nicht unkommentiert lassen (der mir, glaube ich, auch schon vor Jahren in einer Demo auffiel):
Beim König heißt es "seine Majestät". "Ihre Majestät" wird nur für die Königin verwendet. ;)

Frohes Schaffen, bin mal gespannt, wie weit diese Demo verglichen mit den älteren reicht.

EDIT: Die Kürbisse sprechen nicht mit mir und lassen sich nichtmal werfen. :(

EDIT 2: Ok, that was short. :)
Mal sehen, ob ich noch irgendwo eine frühere Demo auf der Platte habe. Ich entsinne mich, dass sie auf meinem alten Rechner etwas laggte und ich im zweiten(?) Dungeon nicht weiterkam, weil ein paar der Blüten, deren Seelen/Energie man sammeln musste, partout nicht spawnen wollten.
Hab jetzt irgendwie Bock, das nochmal zu probieren. :)

@Mivey:

Ich nehm das schon Ernst - 100% zufrieden bin ich gerade mit den Texten im Prolog auch noch nicht, ich hab ja grundsätzlich die Tendenz sehr ausschweifend zu werden, versuche das auch möglichst zu reduzieren - aber wenn ich präzises Feedback habe, was nicht passt, hilft mir das natürlich. Kannst du also genau beschreiben, was dir am Prolog nicht so gefallen hat? Also vor allem welche Abschnitte, die Teile in Krysta, oder die Texte ganz am Anfang? Ich versuche immer weiter "show, don't tell" umzusetzen, dafür brauch ich halt auch entsprechende Ideen bzw. Visionen, wie ich bestimmte Expositions-Dialoge vereinfachen könnte.

Aber immerhin konnte ich Lust auf Terranigma machen, das ist ja schonmal was ;)

@Ark_X:

Dank auch fürs Anspielen & für die Meldung. Bei Timings war ich mir selber nicht so sicher, da ist es gut Feedback zu bekommen.

Rechtschreibprüfung habe ich tatsächlich nicht wirklich durchgeführt, einige meiner Tester hatten mir ein paar einzelne Fehler gemeldet, aber ja... hm, hattest du mir den Fehler mit der Anrede damals schon gemeldet? Wenn ja, kann es sein dass mir der nochmal passiert ist, weil ich ja im Endeffekt die Dialoge neu geschrieben habe, werde ich jedenfalls ausbessern.

Kürbisse ansprechen lassen werde ich einbauen wenn mir sinnvolle Kommentare von ihnen einfallen, Werfen ist ein Feature was allgemein noch fehlt, das kommt in 1-2 Versionen.

Ja, das ist leider noch relativ kurz. Das Problem ist, dass Kampfsystem ungefähr 50% der Arbeit an den Spielsystemen ausmacht, und daher erst mit der nächsten Version kommt, wodurch ich auch erst die ganzen Dungeons etc... bringen kann. Wollte einfach mal eine spielbare Version mit der neuen Engine so schnell wie möglich haben, damit man ungefähr Steuerung, Audio-Qualität, Rendering etc.. sehen kann.

Im Original-Post findest du eh noch einen Download-Link zur Vollversion auf dem Rpg-Maker. Kann mittlerweile nur noch beschränke Spielempfehlung geben, vor allem Dialoge & Steuerung sind in der neuen Version nochmal überarbeite, und die Savegames sind nicht kompatibel. Aber wenn du Bock hast, wieso nicht, schaden tut es sicher nicht. Ich weiß nicht welche Version das war, die du zuletzt hattest, aber mit der aktuellen Version sollte es im 2. Dungeon mit den Pflanzen-Spawns keine Probleme mehr geben.

@Ihre/Seine-Fehler: Nein, damals war ich in keinem Forum bzgl. deinem Projekt aktiv. Bin eher zufällig auf die Demo gestoßen und hatte sie mir nur von deiner damaligen Seite gezogen. Aber bei dieser speziellen Textpassage hatte ich ein deutliches Deja vu-Gefühl :)

@Kürbisse: Ich dachte mir schon, dass solche Details aus der Originalvorlage noch irgendwann kommen werden (die Äpfel in der Küche kann man ja bereits verspeisen).
Und wenn wir schon bei Details sind: Ich fand es im Original ganz praktisch, dass man mit der "Abbrechen"-Taste(?) in der Truhe immer automatisch zur Tür zur Bibliothek wechselte. Vlt. übernimmst du das ja auch.

Inhaltlich lässt sich zur Demo natürlich noch nicht wirklich etwas sagen, aber alles läuft super flüssig, kein Vergleich zu den Maker-Varianten. Ich denke, da kannst du dir wirklich auf die Schulter klopfen. ;)
Das Rattern beim Erscheinen der (Dialog)Texte könnte mMn einen Tick leiser sein. Daran konnte ich mich aus dem Original erst garnicht mehr richtig erinnern, aber hier empfand ich es als etwas nervig.

Ein deutlicher graphischer Fehler ist mir während der Flugsequenz aufgefallen. Der Übergang zwischen dem (schrägen) Mode 7-Bild und dem untersten Bildschirmdrittel ist noch nicht fließend. Erkennt man besonders gut, wenn der Übergang gerade einen See passiert, dieser erscheint im unteren Bereich etwas zu früh.

Beim Infotext zum Demoende gibt es übrigens keine Umlaute (auch keine Sonderzeichen oder Lücken an den entsprechenden Stellen). Sicher nur zweitrangig, da dieser Text eh irgendwann verschwindet. Im eigentlich Spiel ist mir in dieser Hinsicht nichts aufgefallen.

P.S.: Kann man schon irgendwo die Tastenbelegung frei wählen? (A, S und X war erstmal ungewohnt und ich muss etwas rumprobieren, bis ich überhaupt diese Tasten als die richtigen identifiziert hatte). Leertaste als "Select" ist super, so halte ich es bei Emulator-Spielen auch immer.

Ok, dann hatte ich den Ihre/Seine Fehler wohl bis zur Vollversion, dass das keinem sonst aufgefallen ist ^^

Jup, es fehlen an manchen Stellen noch details - das Ziel ist es aber erstmal, mit den wichtigen Sachen voranzukommen, so kleinen details bau ich ein wenn ich gerade keinen Bock auf Maps portieren hab (und da bin ich ganz froh wenn ich bis zum Ende der Portierung immer noch paar Sachen zu tun hab).

Das es flüssiger läuft freut mich zu hören, das war ja auch erstmal das Demonstrations-Ziel dieser Demo. Das Text-Rattern kann ich immer noch leiser drehen, hatte ich eh schonmal um die Hälfe runtergeschraubt. Das Problem ist dass ich es in ner falschen Sampling-Rate aufgenommen hatte (kannte mich früher mit Audio nicht so aus), und jetzt wollte ich es nochmal neu aufnehmen damit es authentischer klingt, aktuell spackt aber meine Soundkarte.

Hm, kannst du den Mode7-Fehler genauer beschreiben bzw eventuell nen Screenshot posten? Eine Vermutung was mir eingefallen wäre könnte sein, wenn du eine Auflösung hast die nicht 1920x1080 entspricht, habe diesen Wert im Shader hardgecoded und ganz vergessen den dynamisch einzulesen *pfeif*

Ja, der sch*** Text macht ständig Probleme. Muss noch evaluieren woran es liegt, aber scheinbar kommt er aktuell nicht klar wenn ich Texte mit Umlauten direkt im Script verwende. Da speichert er zuerst mal die Umlaute ab, aber bei der nächsten Änderung speichert er irgendeine wirre Zeichenkette, die bei jeder Änderung länger wird:

Zitat:

---

Diese Demo endet hier. Es wird ein Savegame erstellt, mit dem sich zur n￯﾿ﾃ￯ﾾﾤchsten Demo weiterspielen l￯﾿ﾃ￯ﾾﾤsst (Demo1.axs).

---

IDK warum ich das überhaupt direkt reinschreibe, brauch für die englischsprachige Version eh ne Lokalisierung, kann ich also auch gleich richtig machen.

Aktuell kann man die Tastenbelegung noch nicht frei wählen. Je nach Zeit/Aufwand kommt das entweder in der nächsten oder übernächsten Version, hat definitiv Priorität, aber solang ich kein brauchbares Ingame-UI habe ist das bisschen schwer umzusetzen...

Hi The King2 , erstmal find ich cool das du ne Fortsetzung von Terranigma machst. Ich kenne das Spiel von früher und es hat mir sehr gefallen, besonders weil es zu damaligen Zeiten n sehr ausgereiftes Action KS hatte. Ich selber habe damals ein wenig mit dem Rpg Maker 2003 rumexperimentiert bin aber dann später zu Java und OpenGL umgestiegen.
Ich weis daher wie schwer es ist ne eigene Engine auf die Beine zu stellen, besonders ohne großartige GameLibraries. Dennoch stimm ich dir zu, dass man dabei viel lernt und es sich definitiv lohnt, auch wenn man ein wenig mehr low level arbeiten muss und das ganze sehr viel mehr Zeit in anspruch nimmt :). Also schonmal Hut ab für die Mühe, die du dir für ein Fanprojekt machst. Denke viele Leute wissen einfach nicht wieviel Arbeit in so einer Engine steckt :).

Zum Spiel selber kann ich leider noch nicht viel sagen, da bei mir folgender Fehler auftritt..Hier mal der Eintrag im CrashLog:

Code:

---


Initializing application!
CORE Info: Creating window...
GFX Error: #pragma pack_matrix( row_major )
#pragma ruledisable 0x0802405f
struct VERTEX_IN
{
float2 vPos: SV_POSITION0;
float2 vTex0: TEXCOORD0;
};

struct VERTEX_OUT
{
float4 vPos: SV_POSITION0;
float2 vTex0: TEXCOORD0;
};

VERTEX_OUT mainVS(VERTEX_IN In, uint VertexId : SV_VertexID, uint InstanceId : SV_InstanceID)
{
VERTEX_OUT Out = (VERTEX_OUT)0;
Out.vPos = float4(In.vPos, 0.5, 1.0);
Out.vTex0 = In.vTex0;

return Out;
}

cbuffer Instance : register(b0)
{
float4 vScreenTone;
};

struct PIXEL_OUT
{
float4 vColor: SV_TARGET0;
};

Texture2D Scene: register(t0);
sampler SceneSampler : register(s0);

PIXEL_OUT mainPS(VERTEX_OUT In)
{
PIXEL_OUT Out = (PIXEL_OUT)0;
float3 vColor = Scene.Sample(SceneSampler,  In.vTex0).rgb + vScreenTone.rgb;
float grayscale = dot(vColor,float3(0.3, 0.59, 0.11));
Out.vColor.rgb = lerp(vColor,float3(grayscale, grayscale, grayscale), vScreenTone.a);

return Out;
}

GFX Error: failed to load effect.
SYSTEM Warning: Stack trace
SYSTEM Error:  0 RaiseException
SYSTEM Error:  0 CxxThrowException
SYSTEM Error:  0 acl::gfx::EffectFile::CheckRequired
SYSTEM Error:  0 acl::gfx::CbufferUpdateBlock::SetConstant
SYSTEM Error:  0 acl::gfx::CbufferUpdateBlock::SetConstant
SYSTEM Error:  0 acl::core::ObjectContainer<acl::event::BaseMethod>::IsRegistered
SYSTEM Error:  0 acl::core::ObjectContainer<acl::event::BaseMethod>::IsRegistered
SYSTEM Error:  0 acl::core::ObjectContainer<acl::event::BaseMethod>::IsRegistered
SYSTEM Error:  0 acl::core::ObjectContainer<acl::event::BaseMethod>::IsRegistered
SYSTEM Error:  0 acl::math::BaseVolume::Intersect
SYSTEM Error:  0 acl::audio::Listener::Update
SYSTEM Error:  0 acl::math::BaseVolume::Intersect
SYSTEM Error:  0 acl::gfx::CbufferUpdateBlock::SetConstant
SYSTEM Error:  0 acl::asset::AssetIO::LoadBlockBinary
SYSTEM Error:  0 acl::asset::BlockHandler::AddBlockBinary
SYSTEM Error:  0 acl::core::ModuleLoader::LoadFromFileDataBinary
SYSTEM Error:  0 acl::core::EnumRegistry::CreateEnumArray
SYSTEM Error:  0 acl::asset::FileHandler::HandleAction
SYSTEM Error:  0 acl::asset::FileHandler::HandleAction
SYSTEM Error:  0 acl::game::GameLoader::LoadBinary
SYSTEM Error:  0
SYSTEM Error:  0
SYSTEM Error:  0
SYSTEM Error:  0
SYSTEM Error:  0 BaseThreadInitThunk
SYSTEM Error:  0 RtlInitializeExceptionChain
SYSTEM Error:  0 RtlInitializeExceptionChain
SYSTEM Error: (filename not available) 0 RtlInitializeExceptionChain
SYSTEM Warning: Caught signal 22 SIGABRT
SYSTEM Warning: Stack trace
SYSTEM Error:  0 acl::event::TriggerDeclaration::TriggerDeclaration
SYSTEM Error:  0 acl::render::getDevice
SYSTEM Error:  0 acl::render::getDevice
SYSTEM Error:  0 raise
SYSTEM Error:  0 abort
SYSTEM Error:  0
SYSTEM Error:  0 GetProfileStringW
SYSTEM Error:  0 RtlKnownExceptionFilter
SYSTEM Error:  0 RtlInitializeExceptionChain
SYSTEM Error: (filename not available) 0 RtlInitializeExceptionChain

---

Und letztendlich wollte ich noch drauf aufmerksam machen, dass das Spiel die Visual C++ Runtimes benötigt und ich weis nicht ob du darauf aufmerksam gemacht hast oder ob ich das übersehen habe :).

Hier ein Screenshot, auf dem die doppelte Darstellung des Sees gut zu erkennen sein sollte.
Anhang 22530

Originalgröße des Ausschnitts (und damit auch meine Bildschirmauflösung) ist 1366x768 Pixel.
Hoffe, das hilft dir weiter.

@Paddi:

Danke für die netten Worte! Es stimmt leider, wenn man artistisch begabt ist und z.B. Pixelgrafiken/Renderings hinbekomme, dann sieht man das relativ schnell. Für eine gute Engine braucht man Text in der Länge einer halben Bachelorarbeit, damit man überhaupt mal ansatzweise erklären kann, was man überhaupt gemacht hat :/ Aber man wird es im fertigen Projekt merken, dass sich allein die Game-bezogenen Änderungen einen weiteren großen Teil fürs Terranigma-Feeling ausmachen.

Zu deiner Fehlermeldung: Sieht aus als hättest du keine DirectX11-fähige Grafikkarte, zumindestens hatte jemand gerade denselben Fehler und der hatte noch eine GTX 285. Ich werd wohl doch mal entweder den DX9-Renderer betriebsfertig machen müssen, oder zumindestens den DX10-Kompatibilitätsmodus einstellen (da ich im Endeffekt eh keine DX11-Features benutze). Ich werde schauen wie schnell sich das lösen lässt und dann entweder gleich eine neue Version rausbringen, ansonsten erst mit der nächsten Demo.

Danke auch für die Meldung mit den Runtimes, eigentlich hatte ich eingestellt dass diese in die Anwendung kompiliert werden, muss wohl nochmal das Compile-Setup durchschauen.

@Ark_X:

Jup, das hilft mir weiter, das ist im Endeffekt genau der Fehler den ich vermutet habe. Werde ich fixen & dann in der nächsten Demo sollte das passen.

Habe die Demo auch vor kurzem Durchgezockt. Spielerisch war es natürlich arg mau. Zu viel Text, zu wenig Spiel. Aber es geht dir ja auch erstmal um die Engine und da hast du, soweit ich das beurteilen kann, astreine Arbeit geleistet! Für mich hat sich das Ding durch die Bank weg wie das alte Terranigma angefühlt. Okay, ist auch schon ne Weile her, dass ich das zuletzt gespielt habe ^^ Bin gespannt, wie sich das Projekt entwickelt. Ich habe jetzt jedenfalls tierisch Lust auf diesen Nachfolger zu Terranigma!

Gruß
Stoep

Zitat:

---

Habe die Demo auch vor kurzem Durchgezockt. Spielerisch war es natürlich arg mau. Zu viel Text, zu wenig Spiel

---

Jup, da geb ich dir 100% recht. Die Situation war halt etwas blöd, weil die wichtigen spielerischen Elemente (Kampfsystem, UI, ...) erstmal anstehen, bevor ich viel ansprechendes Gameplay herzeigen kann. Da es noch etwas dauern kann bis es soweit ist, wollte ich eben auch zwischendurch präsentieren, aber ganz ohne Demo war mir das dann auch nicht recht.

Aber schön dass es dir trotzdem Lust auf mehr macht. Ich habe ohnehin die Dialoge in diesem Spielabschnitt nochmal gekürzt, ich denke ich habe endlich einen guten Weg gefunden, nicht zu viel zu erzählen, aber auch nicht zu viele Fragen offen zu lassen, dass dann Plotholes entstehen. Die nächste Version wird dann das erste Kapitel, sowie den Prolog mit allen den Änderungen beinhalten, ich denke das sollte dann einen noch besseren Eindruck über das Spiel vermitteln ;) Ich suche auch nach Möglichkeiten, die Prolog-Szenen (Möwe, Melina, Krysta) noch spielerisch etwas aufzupeppen, hab aber gerade keine guten Ideen. Also falls dir (oder wem anderen) irgendetwas einfällt was man spielerisch in diesem Abschnitt spaßiges machen können, nur her damit^^

Zitat:

---

Aber es geht dir ja auch erstmal um die Engine und da hast du, soweit ich das beurteilen kann, astreine Arbeit geleistet! Für mich hat sich das Ding durch die Bank weg wie das alte Terranigma angefühlt.

---

Danke :) Wie gesagt, bei der neuen Engine ging es darum, nochmal die letzten gravierenden Unterschiede zum alten Spiel zu beseitigen. Bin selber richtig begeistert, wenn ich dran denke wie ich beim Maker immer schätzen/tricksen musste (z.B. mit dem Animationsspeed, 1-6? Ich hab allein jetzt schon mindestens 10 verschiedene Geschwindigkeiten aus dem Emulator gemessen). Der Plan scheint ja, von dem was ich höre durchaus aufzugehen, also danke nochmal für das Feedback.

Frage, da meine letzte Original-Terranigma-Session schon eine Weile her ist: Für Melina gibt es keinerlei Sprites/Animationen beim Treppe benutzen? Ich erinnere mich, dass ich es schon in der Maker-Version merkwürdig fand, wie sie für eine kurze Weile wie erstarrt in den Türrahmen zu stecken scheint.
KA wie begabt du selber beim Erstellen solcher Sprites bist, aber vlt findest du ja hier jemanden, der dir damit aushelfen kann. Wenn das auch in der Vollversion so bleiben sollte, wäre das nämlich ziemlich unansehnlich.

Zitat:

---

Frage, da meine letzte Original-Terranigma-Session schon eine Weile her ist: Für Melina gibt es keinerlei Sprites/Animationen beim Treppe benutzen? Ich erinnere mich, dass ich es schon in der Maker-Version merkwürdig fand, wie sie für eine kurze Weile wie erstarrt in den Türrahmen zu stecken scheint.

---

Nein, standardmäßig gibt es dafür keine Sprites. Dass es auch in der Maker-Version schon so war wage ich zu bezweifeln, da ich diese Keller-Szenen erst in der aktuellen Version eingebaut habe ;) Aber ja, das darf definitiv in der Vollversion nicht bleiben. Ich denke ich werd mir einfach mal Arks Treppenanimation als Vorbild nehmen und dort abmessen, um wieviel Pixeln jedes Frame verschoben um den Treppen-Effekt zu erzeugen. Die Frame/Dreh-Animation die noch dazu ist, wird schwierig nachzubauen, da ich wenig begabt bin was sowas angeht, aber mal schauen, vllt bekomm ich es ansehnlich hin. Ansonsten lass ich mir noch was anderes einfallen.