Status: Beginn der Arbeiten an der neuen Engine

[Acclimate] Engine News

Ein frohes neues Jahr zusammen, ich hoffe ihr seit gut gerutscht Ich war trotz der Feiertage fleißig, und hab wieder paar Neuigkeiten zu verkünden. Mal abgesehen von den technischen Neuerungen geht die Portierung gut voran, ich bin mittlerweile an Crysta dran. Ich muss am Ende noch alle einzelnen Szenen irgendwie zusammenfügen, aber im großen und ganzen sollte es bald erledigt sein. Der größte Blocker dürfte noch das Inventar-System bzw. das Truhen-Menü werden.

Aber jetzt erstmal zu den ganzen tollen neuen Änderungen (die meisten das Event-System betreffend):

- Das neue Breakpoint-Debugging-System hat sich aus dem Bedarf ergeben, Code direkt im C++-Aufruf eines Triggers auszuführen. Bisher war das Sstem nämlich relativ komplex, und hat erfordert dass der Update-Schritt der Event-Entities speziell mit Breakpoint-Code ausgestattet wird. Das wäre zu viel Aufwand gewesen, wenn man das nun bei jedem Trigger-Aufruf machen müsste. Im Gamedev-Forum hat mich dann jemand auf die Idee gebracht, einfach den C++-Code an der Stelle mit einer while(true)-Schleife anzuhalten, wenn ein Breakpoint getroffen wird. So ein ähnliches System hatte ich bereits bei den Dialog-Boxen im GUI angewendet, also war das nicht allzu kompliziert zum implementieren. Faktisch ändert sich an der Verwendung recht wenig: Der Editor bleibt weiterhin responsiv, wenn ein Breakpoint getroffen wird, und das Spielgeschehen hält an. Der Unterschied ist bloß, dass dieses System nun 100% deterministisch ist, d.h. es macht keinen Unterschied in der Ausführung ob ein Breakpoint getroffen wurde oder nicht. Mit dem alten System konnten unter ganz bestimmten Umständen Seiteneffekt durch Breakpoints eintreten. Außerdem macht es das neue Breakpoint-System auch leichter im C++-Code zu debuggen, da der C++-Callstack jetzt genau dorthin zeigt, wo der Breakpoint aufgerufen wurde.

- Die direkte Ausführung des Trigger-Codes war ja wie gesagt an das neue Breakpoint-System geknüpft. Warum muss der Code überhaupt sofort ausgeführt werden? Weil es sonst zu Fehlern kommen kann. Das Player-Event z.B. regiert auf den BeginTalkTrigger, und hält die Bewegung des Spielers an. Ein Teleporter-Event aktiviert nun zuerst den Talk-Modus (d.h. BeginTalkTrigger wird abgefeuer), und bewegt den Spieler danach in Richtung des Teleporters. Würde jetzt der BeginTalkTrigger verzögert ausgeführt, hätte das zur Folge, dass der Spieler zuerst den Move-Befehl des Teleporters bekommt, und dann den StopMove-Befehl des BeginTalkTriggers, wodurch er im Endeffekt stehen bleibt. Die Lösung davor war es, einen "SkipFrame"-Befehl zwischen den "DoTalk" und "MovePlayer"-Block zu setzen, was bedeutet hat dass die Ausführung erst nächsten Frame fortgesetzt wurde und er Move-Befehl korrekt ankam. Dass das nicht sehr schön ist, weil es Wissen über diesen Seiteneffekt erfordert, und außerdem noch manuelles Eingreifen an bestimmten Stellen erfordert, ist klar. Die Lösung ist auch einfach: Sobald der Trigger aufgerufen wird, wird der angehängt Code direkt ausgeführt. Natürlich bloß solange, bis das erste blockende Event (Wait, While, etc...) kommt, das wird dann in die Ausführungsschleife gehängt. Dass ich es bisher nicht so gemacht habe, hat eigentlich lediglich historische Gründe, am Anfang war das System bei weitem nicht so komplex und groß wie jetzt.

- Das Stack-System. Oh Mann, das hab ich mir lange aufgehoben. Am Anfang des Systems, wo es noch nichts gab außer normalen Nodes und ein paar Triggern, war es eigentlich die logische einfachste Wahl, zur Ausführung einfach das Event zu kopieren, und dieses dann auszuführen. Mit dem aufkommen von Methoden, Ableitung, etc... wurde das langsam zum Problem. So müsste auf diese Weise jeder Methoden-Node eine Kopie der Methode besitzen, was unter Umständen einem enormen Speicherverbraucht bedeutet. Rekursion (eine Methode ruft sich selber auf) ist so auch nicht wirklich möglich, da das zu einer unendlichen Vervielfältigung der Methode geführt hätte. Die Lösung ist also simpel: Der Event-Code und die Ausführung gehört getrennt. Das läuft über eine Stack-Klasse, welche im Prinzip blop den aktuellen State des Events speichert (statt diese Information in den Nodes selber zu speichern). Damit braucht jede Event-Entity bloß noch einen Zeiger auf das Event, statt einer vollen Kopie. Technisch hat das mehrere Auswirkungen. Zum einen sinkt die Ladezeit, weil weniger kopiert werden muss. An vielen Stellen kann der Code vereinfacht werden, weil die Nodes selber nicht mehr resettet werden müssen. Die Auswirkung auf die Performance ist schwer abzuschätzen. Einerseits müssen im aktuellen System öfters Speicherallokationen gemacht werden. Das könnte ich wegoptimieren, allerdings könnte man dann Events wieder nicht zur Laufzeit verändern. Weiters sind mehr Map-Zugriffe notwendig, welche ich auf einen linearen Array-Zugriff verbessern könnte. Dafür fallen einige virtuelle Methoden und Benachrichtigungen über Signals im Vergleich zu vorher weg. Alles in allem schwierig zu sagen, einen echten Unterschied habe ich soweit nicht bemerkt, müsste ich aber einmal Benchmarken.

- Das Local-System für die Event-Commands ist vor allem nötig, um den Event-State serialisieren zu können, um eben z.B. exakte Replay-Savestate erzeugen zu können. Denn bestimmte Nodes mussten einen State speichern. zB. wieviel Zeit von einem "Wait"-Node noch zu warten ist. Das war bisher einfach eine Member-Variable der Node, und daher nicht automatisch serialisierbar. Das hätte ich dann extra für jeden Node ausimplementieren müssen, was sehr aufwändig wäre. Mit dem neuen System werden jetzt solche Variablen mit meinem dynamischen Typsystem deklariert, als "Variable"-Klasse gespeichert, und können dann vom System automatisch ausgewertet werden. Das hat einen leicht negativen Einfluss auf die Performance, sollte sich aber in Grenzen halten.

_____________________________________________________________________________-

Das waren die wichtigsten Änderungen. Leider muss ich noch das Debugging mit dem Stack-System reimplementieren. Danach werde ich vmtl die Serialisierung das Stack-States einbauen, und die Anzeige der Locales im Debugging-Modus. Dann halt weiter im Portieren, und dann sollte schon das Inventar-System drankommen.

So, die letzten Monate gab es ja eher weniger zu hören. Die letzten Wochen habe ich auch keine Zeit gehabt etwas zu arbeiten, aber ich hab jetzt mal die Änderungen von davor gepostet.

Grob gesagt habe ich vor allem das Scene-Stacking eingebaut, welches das Truhen-Menü ermöglicht. Als nächstes steht das Item-System an, um die Truhe fertigzustellen, da häng ich bloß gerade an paar Detailfragen. Im Großen und Ganzen geht es aber eigentlich recht gut vorran. Ich konnte die Truhe diesesmal, entgegen dem Maker, als normale Szene erstellen, was die Erstellungen und Wartung wesentlich unkomplizierter macht. Fürs Itemsystem plane ich eine Implementierung mit dem Event-System, bloß muss ich da wie gesagt paar Details klären. Ich füge heute im laufe der Zeit zum letzten Update noch paar Screenshots bei. Ansonsten mal schauen wann es weitergeht. Dieses Semester an der Uni habe ich extremen Stress, mit einer Bacchelor-Arbeit (mit praktischem Teil in meiner Engine) sowie einem seperaten Bacchelor-Game-Projekt. Ich poste halt wieder ein Update, wenn es weitergeht.

Gut, nun kommt mal wieder ein "richtiges" Update

[Acclimate] Engine News

Zuerst möchte ich noch anmerken, dass es unzählig viele weitere kleine Änderungen gegeben hat, vor allem Bugfixed & Improvement-of-life Sachen. Diese sind jedoch nicht unbedingt nennenswert, vor allem da sie Probleme betrafen, die keiner hier kennt (Weil er selber nicht mit der Engine gearbeitet hat). Von daher ist die Liste eigentlich relativ kurz, hat sich aber mehr getan als es scheint.

Nun aber zu den wichtigen Sachen:

- Module extern vom Projekt zu laden war schon eine längere Idee, ich hatte aber irgendwie nie die richtige Idee, wie ich das angehen sollte (bis vor kurzem). Denn einige der Plugins, die Terranigma 2 verwendet, kommen von der Engine selber (GameInput, GameEvent, GUI). Base2D, Tilemap, Audio2D, Dialoque2D und Terranigma sind alles Plugins die für das Terranigma-Projekt selber sind, und kommen daher im Prinzip von 2 verschiedenen Quellen. Da vorher die Plugins nur von einem Pfad geladen werden konnten, musste ich jedesmal, wenn ich an den Engine-Plugins etwas geändert habe, eine .bat-Datei ausführen, die die Plugins ins Projektverzeichnis kopiert. Das erspare ich mir jetzt damit, und das macht auf die Dauer schon ne ordentliche Zeit und Nervenersparnis.

- Ich habe ja schon länger gesagt, dass beim Picking einige Vorschauen fehlen, z.B. für Entitites/Prefabs/... nun, jetzt habe ich das erst mal für die Prefabs nachgeholt. Macht die Auswahl des richtigen Prefabs etwas leichter, geschweige denn dass ich nun auch im Editor sehen kann, wenn ich etwas an einem Prefab ändere, ohne direkt eine Entity davon anlegen zu müssen. Jetzt fehlt im Prinzip noch eine Vorschau für die Entities, dazu muss ich halt erstmal das 2D-Rendering umstellen, sodass ich einen zusätzlichen Ausschnitt der Szene in eine Textur rendern kann. Folgt jedenfalls auch noch...

- Das Editor-Layout hatte mich schon eine Zeit lang gestört. Leider habe ich immer noch kein grafisches Talent, also habe ich mir einfach ein bestehendes Layout zusammengeschnippselt (das ist natürlich nur zu testzwecken, wenn ich die Engine mal rausbringen sollte muss ich das natürlich ändern).

- Tools für die Animationen habe ich auch schon länger vor mir hergeschoben. Beim Portieren fielen aber gerade in letzter Zeit an unzähligen Stellen Animationen an, sodass ich keine Lust mehr hatte ständig in den Textfiles rumzuschrauben. Nun, hier haben wir also einen Animationseditor. Das Prinzip ist recht simpel, da es sich ja nur um direkte Texturanimation handelt (an Animations-Frame X, zeige TexturFrame Y) ist der Editor relativ unkompliziert. Oben hat man eine Vorschau der Animation, die man auch abspielen kann. In der Mitte hat man alle Frames angezeigt, wo man auch das zu bearbeitende auswählen kann. Und unten hat man eine Übersicht über alle existenten Frames. Details wie verwendete Textur, Framezeit etc.. kann man aktuell nur beim anlegen einer Animation festlegen, da werde ich auch noch Tools zum bearbeiten einbauen müssen, aber das wird derweil nicht benötigt.

- Filter-Boxen waren ursprünglich erstmal nur fürs Picking gedacht, jedoch kamen in letzter Zeit extrem viele Assets wie Texturen, Localization-Strings etc... dazu, dass es auch Sinn machte das bei jedem Tree zu erlauben. Damit kann man jetzt in so gut wie jedem Tree nach Objekten mit bestimmtem Namen suchen (bei manchen ist das aus guten Gründen deaktiviert).

- Das Inventarsystem war gameplaymäßig der nächste logische Schritt, da ich gerade dabei bin Krysta/Die Truhe zu portieren, womit als nächstes Items anfallen. Das war auch einer der Gründe warum ich kurzfristig die Motivation verloren hatte, da ich mir eine Zeit lang nicht sicher war, wie ich dieses Thema angehen sollte. Ich habe mich jetzt für eine relativ simple Implementierung entschieden: Nämlich gibt es eine Item-Komponente, welche lediglich den Typ des Items (Item, Rüstung, Waffe, Ring) beinhaltet. Um ein Item anzulegen, legt man ein Prefab mit dieser Komponenten an. Wenn man jetzt irgendwo ein Item hinzufügen oder verwenden will, passiert das immer über so ein Prefab. Das Prefab selber muss sämtliche Komponenten haben, um es anzeigen zu können (Sprite), sowie um es verwenden zu können (Event). Und überall, wo es angezeigt/verwendet wird, wird eine Instanz des Prefabs erstellt. Sprich, in der Truhe wird am entsprechenden Slot eine Entity mit Prefab "Heilknolle" für die Heilknolle erstellt. Über das Eventsystem wird jetzt die Verwendung bestimmt: Es gibt eine Basis-Klasse namens "BaseItem", mit einer Menge virtueller Methoden wie "OnUse". Damit kann ich jetzt Subtypen anlegen, wie "Heilitem", das dann eine integer-Variable für den geheilten Wert erhält.
Ich finde, dass dies das Itemsystem relativ gut löst. Einersetzt kann ich sehr viel duplizierte Information vermeiden, z.B. hatte der Maker bei jedem Item alle möglichen Stats drauf (Heilung, Manareg, +Def, +Stärke, ...) auch wenn das großteils nicht benötigt wurde. Weiters hatte der Maker getrennte Implementationen für Waffen, Items und Rüstungen, und ich brauche jetzt nichtmal eine einzige Spezialimplementierung für das gesamte Itemsystem. Außerdem kann ich mit dem Event-System durch Vererbung auch gut praktische Benutzeneffekte einbauen, z.B. das Öffnen von Türen mit Schlüsseln, etc... Alles in allem bewährt sich das Event und Entity-System auch hier wieder extrem gut.

Was funktioniert jetzt also schon genau? Über Truhen kann man Items erhalten (die Animation dazu muss ich noch einbauen). Die Truhen sind natürlich wieder geprefabt bzw. mit Basis-Event-Klassen umgesetzt, sodass ich zum anlegen einer neuen Truhe bloß ein Template instanziieren muss, und dann das Item eintragen. Im Truhen-Menü selber werden erhaltene Items bereits angezeigt und können benutzt werden (auch wenn derzeit der Effekt selber noch nicht implentiert ist, da ein Stat-System für Ark noch fehlt). Somit bin ich eigentlich schon extrem weit, was das anbelangt.

_______________________________________________________________________________________________________________________________________________________

Die Pläne für die nächste Zeit sehen also wie folgend aus:

- Krysta fertig portieren (sämtliche Cutszenes, etc..)
- Ark soweit spielbar machen (Rennen, Truhenmenü nur nach aktivierung, ...)
- Statsystem implementieren

Wenn das fertig ist, kann ich eine erste Beta über den Prolog rausbringen. Da werden dann noch genug Sachen fehlen, z.B. bestimmte Animationen, die Möven-Flug-Szene mit Mode7, ... aber das werde ich dann mit der Zeit nachbessern. Es geht nur darum so schnell wie möglich etwas spielbares rauszubringen, damit ich erstes Feedback einholen kann, eventuelle grundlegende Bugs finden kann, etc...

Bis dahin werd ich mich wieder melden, wenn es etwas neues gibt...

Ein kleines Statusupdate,

leider mit halbwegs schlechten Nachrichten, denn der Progress wird sich noch etwas verzögern. Ich habe mich nach langem hin und her nun doch dazu entschieden, ein ziemlich großes Themengebiet aufzugreifen: Die Überarbeitung des Asset-Handlings.

Dabei geht es darum, wie Ressourcen wie Texturen, Sounds etc... geladen, gespeichert und verwaltet werden. Nun, das bisherige System ist extrem veraltet. Ich habe es als eine der ersten Sachen begonnen, als ich vor ~2 Jahren meine Engine begonnen hatte, und damals war es gut genug. Nun aber, vor allem da der Editor große Fortschritte gemacht hat, funktioniert es einfach nicht mehr gut genug. Das größte Problem ist, dass für jede neue Ressource eine Vielzahl an Code angelegt werden muss, der im Prinzip extrem ähnlich zu den vorherigen ist (für Laderoutinen, Editor-Anbindung, ...).

Das neue System verallgemeinert also das Asset-Handling, sodass wesentlich weniger Custom-Code für eine Asset-Art notwendig ist. Es gibt aber noch weitere Gründe, warum ich das System überarbeiten muss und warum ich es jetzt machen will:

- Automatisches Importieren von neuen Assets, indem man sie in den Projektordner verschiebt. Dieses Feature habe ich die längste Zeit für nicht notwendig erachtet, aber spätestens wie ich jetzt dabei bin, sämtliche Texturen des alten Terranigma-Projekts zu übernehmen, ist ein manueller Import, sogar mit Editor-Tools, nach der Zeit extrem anstrengend. Ohne ein einheitliches System ist es aber nicht gut möglich, für die verschiedenen Ressourcen ohne großen Aufwand ein solches System umzusetzen.

- Hot-Reload. Wenn ich z.B. in einem Zeichenprogramm Änderungen an einer Textur mache, soll diese sofort in der Engine neu geladen werden. Im Prinzip genau dasselbe wie beim letzten Punkt, das ging aktuell auch nicht (und wäre nur kompliziert umzusetzen gewesen).

- Partielles speichern (nur von Sachen die sich geändert haben): Aktuell sind sämtliche Assets und Assetdaten nach Typ getrennt in einer XML gespeichert. Wenn sich jetzt also ein Asset ändert, müssen alle neu rausgeschrieben werden, was bei steigender Projektgröße eine merkbare Verzögerung beim Speichern zur Folge hat. Außerdem ist es aktuell noch gar nicht möglich zu sehen ob sich bloß bestimmte Assets geändert haben, also muss sowieso immer alles gespeichert werden, was ich eben auch nach Möglichkeit vermeiden möchte. Mit dem neuen Asset-System ist es dann relativ leicht, bloß Assets zu speichern die sich wirklich geändert haben. Außerdem sind die Asset-Daten dann in getrennten Files gespeichert, sodass tatsächlich nur relevante Änderungen rausgeschrieben werden müssen.

- Binäres Packing (zur Auslieferung des Spiels): Ebenso gefehlt hat noch ein Feature, um wie im Rpg-Maker die Game-Dateien in ein Binäres File zu packen, sodass a) nicht direkter Zugriff auf die Files besteht und b) das ausgelieferte Game-File möglichst kompakt ist. Aktuell werden die Asset-Daten bloß in XML-Form gespeichert (sprich, Text-Form), war einerseits nicht gerade klein ist, und andererseits liegen in jedem Fall die einzelnen Files rum. Spätestens für die erste Beta hätte ich sowieso ein Packing benötigt, und das neue Asset-System erlaubt mir dies im Prinzip ohne großen Aufwand von oben herab zu implementieren. Ohne diese Änderung müsste ich dafür wieder einen extra Fall für jeden Asset-Typ einbauen, was wieder extremen Aufwand bedeutet.

- Die Möglichkeit, User-Daten zu speichern. Es gibt eine Stelle, an der es aktuell extrem interessant ist, Daten mit einem Asset zu assoziieren, die selber nicht zum Asset-Format gehören. In dem Fall geht es darum, zu einer Textur die Anzahl der Animationsframes zu speichern. Der Textur-Typ ist selber generisch und soll im Prinzip keine solche Information speichern (da ich ja Texturen auch für den 3D-Teil meiner Engine hernehme), deswegen muss es möglich sein, per Plugin die Information "NumFrames" hinzuzufügen. Das Asset-System erlaubt genau soetwas, worauf ich dann im Editor einstellen kann, dass z.B. Arks Lauftextur 7 Animationsframes hat, und das dann ähnlich wie im Maker automatisch anwenden kann (bloß dass man das beim Maker im Filenamen einbetten musste, was recht hässlich war und auch mehr als einmal dafür gesorgt hat, dass ich global wieder tausende Texturen austauschen durfte).

Ihr seht, viele gute Gründe für dieses System. Der Nachteil ist, dass dieses umzusetzen erstmal einen enormen Zeitfaktor hat. Das System selber steht soweit schon rudimentär, bis auf ein paar Features, jetzt muss ich es aber noch in den bestehenden Code integrieren. Weiters muss ich alle bisher bestehenden Assets auf das neue System konvertieren, was allein eine enorme Zeit in Anspruch nehmen wird. Das ist auch der Grund warum ich das System jetzt gleich umsetzen und nicht warten will, denn je länger ich warte, desto mehr bestehenden Content gilt es manuell oder mit einem Helper-Tool zu konvertieren. Sobald diese Schritte abgeschlossen sind, sollte es aber wieder einen enormen Sprung in Produktivität geben.

Nun, das wars auch schon wieder. Ich halte euch weiter am Laufenden.

Ein kurzes Statusupdate,

ich habe jetzt erstmal das Asset-System für alle Grafik-Assets eingebaut (Texturen, Shader, ...). Das ging wieder Erwarten doch relativ schnell - einerseits weil sich nicht so viel am Code geändert hat, wie ich dachte, andererseits weil doch relativ wenig manuelles Tuning an den eigentlichen Assets notwendig war (da die Engine jetzt sämtliche Ressourcen im Ordner selbstständig importiert). Auch bin ich derweil mit dem Ergebnis sehr zufrieden - es haben sich an vielen Stellen im Code implizite Probleme, die schon seit längerer Zeit bestehen, gelöst. Außerdem hat sich dadurch ebenso implizit z.B. das Handling der Tilesets verbessert (es wäre einigermaßen schwierig gewesen, diese zuvor im Editor bearbeitbar zu machen).

Nun zu dem was jetzt ansteht: Vor allem das Editor-Interface zum ansehen/bearbeiten der Assets wieder einzubauen, genau wie ein Speichersystem. Dann einige groß angelegte Änderung am Spielsystem selber - dank dem Prinzip der UserData kann ich jetzt Daten wie Anzahl der Frames/Richtungen und Animationsgeschwindigkeit direkt in der Textur ablegen, was ziemliche Vorteile bietet (wodurch ich aber auch einige grundlegende Komponenten verändern muss). Dann muss ich mir noch über einige Konventionen in Bezug auf das Datenformat klar werden - da ich andernfalls in ein paar Monaten wieder alles überarbeiten darf. Je nachdem was dabei herauskommt, muss ich auch eventuell sämtliche Entities und Prefabs händisch überarbeiten - bei der Idee geht es nämlich vor allem darum, beim Referenzieren eines Assets statt bloß dem Namen immer auch den dazugehörigen Block (Plugin/Projekt/Scene) vorzustellen, um so Namenskollisionen zu vermeiden. Außerdem überlege ich, ob ich für Assets die Tree-Struktur direkt aus dem Windows-Ordner übernehme. Beide Ideen haben vor und Nachteile, besitzen auch entsprechend viel Implenentierungs (und vor allem überarbeitungsaufwand), daher will ich das gut durchdacht haben.

Sobald das alles abgeschlossen ist, muss ich das natürlich noch auf die nicht-Grafik-Assets anwenden - Event-Scripte, Audofiles, Prefabs, ... . Das heißt, bis zum nächsten Punkt wo ich aktiv am Spiel weiterarbeiten kann, wird noch einige Zeit vergehen. Dennoch bin ich sehr überrascht wie schnell eigentlich alles ging, und dass sich doch gleich von Anfang an ziemlich coole Möglichkeiten für die weitere Arbeit ergeben haben. Ich bereue definitiv nicht, dass ich dieses Feature direkt implementiert habe, ganz im Gegenteil. So, wenns wieder was neues gibt melde ich mich hier wieder...

Nochmal ein "kleines Statusupdate",

die Arbeiten an der Asset-Implementierungen gehen gut voran. Mittlerweile sind die meisten Resourcen auf Assets umgestellt (ausgenommen Events). Auch die Editor-Tools dafür sind großteils bereits eingebaut.

Dazu hab ich auch ein paar Screenshots angehängt. Assets.png zeigt das neue Interface wo alle Assets aufgelistet sind & bearbeitet werden können. AssetAttributes zeigt auf der rechten Seite die allgemeinen Attribute des jeweiligen Asset-Typs, die nun bearbeitet werden können. Oben sind die Typ-Attribute, unten die User-Attribute (sowas wie Anzahl der Frames bzw. Animationsgeschwindigkeit, die von jeweiligen Game selber zur Verfügung stehen). AssetCreate zeigt das Tool zum anlegen von Assets, welches jetzt auch verallgemeinert wurde.

Der Editor ist soweit wieder betriebsfähig. Jedoch muss ich eben noch die Events auf Asset-Format portieren, was noch eine Menge Aufwand werden wird. Bei der Gelegenheit werde ich auch gleich das Szenen-Format überabeiten, damit dieses ähnlich wie die Assets funktionieren, aus ähnlichen Gründen wie bei den Assets. Vor allem habe ich bemerkt, dass einige Sachen mit dem aktuellen Szenenformat auch gar nicht gut passen. Beispielsweise hielt ich es zuerst für eine gute Idee, keine Information über die Hintergrundmusik der jeweiligen Szene zu speichern, sondern jeweils eine Entity zu verwenden, jedoch hat sich das in der Praxis als sehr unpraktisch herausgestellt. Allerdings kann ich nicht einfach Hardgecoded ein Feld für Musik ins Szenenformat machen, daher werde ich es ähnlich wie bei den Assets machen, dass die Szene UserAttribute haben kann. Auf diese Weise würde ich dann auch die Teleporter handhaben, da diese mit dem neuen Assetformat nicht mehr so gut funktionieren.

Immer noch nicht sicher bin ich, wie ich das Speichern der Asset-Referenzen handhaben will. Vmtl werde ich da, sobald alle Assets portiert wurden, auch noch was anderes überlegen. Weil ganz zufrieden bin ich mit der Referenzierung per Name nicht, da einerseits Strings (also Texte)- im Code nicht allzu performant sind, außerdem gibt es dann Probleme mit gleichen Namen von Assets. Da habe ich leider noch keine gut Lösung, werd aber vmtl nochmal vieles umstellen müssen.

In der Zwischenzeit habe ich auch einige Verbesserungen am UI vorgenommen, unter anderem an dem Fenster-Docking-System, da dieses schon sehr betagt war und viele Probleme verursacht hat. Weiters habe ich die die Entity-Attribute-Area (rechts unten im Editor) verallgemeinert und aufgeräumt, sodass diese jetzt auch für andere Zwecke verwendet werden kann (z.B. um Attribute der Szene darzustellen). Außerdem können dort Attribute vom Typ "Struct" aufgeklappt werden, sodass ihre einzelnen Elemente bearbeitet werden können (siehe StructAttributes.png, wo "Position", "Tone" und "Size" aufgeklappt sind). Das macht das Arbeiten einerseits in bestimmten Situationen etwas angenehmer, hat aber auch den Hintergrund dass ich als nächstes spezialisierte Typboxen anbieten will, z.B. für Farben. Dort kann dann über einen Farbwähler der Farbwert ausgewählt werden, jedoch kann es trotzdem noch gewünscht sein, direkt in die einzelnen Komponenten zu schreiben.

Soweit zu den (wichtigsten) Änderungen. Sobald die genannten Änderungen abgeschlossen sind, kann ich wahrscheinlich schon den Prolog fertigmachen, und dann eine erste Beta rausbringen. Hoffentlich geht sich das bald aus, da ich gegen Ende des Semesters diesesmal einen enormen Stress bekomme. Hoffe dass ich da noch Zeit finde... Nun, ich halt euch jedenfalls auf dem laufenden.

Nochmal ein Update,

mittlerweile habe ich im Prinzip alle Arten von Ressourcen auf das neue Asset-System umgestellt. Auch die Szenen habe ich auf das neue Format portiert. Ganz entfallen ist mir dabei aber, dass ich das auch noch für die Plugins und die Game-Daten allgemein machen muss, damit ich dann das ganze dann nacher packen kann. Von demher sind das die nächsten Aufgaben, obwohl das eh relativ ähnlich funktionieren sollte, weswegen nicht allzu viel Aufwand notwendig sein sollte. Danach muss ich auch noch das binäre Laden bzw. packen selber einbauen. Im weiteren Verlauf werd ich nochmal das ganze Intro von vorne bis hinten durchgehen müssen, weil durch die Änderungen noch einige Sachen kaputt gegangen sind. Dann noch die ganzen Editor-Features wie hot reload, etc.. einbauen, sowie für sämtliche Aktionen im Editor eine notifizierung, dass sich die Szene/das Asset/das Game geändert hat. Denn mit dem neuen System wird aktuell nur noch gespeichert, wenn sich auch wirklich etwas geändert hat, bloß muss ich das für alle Aktionen einbauen, die Änderungen hervorrufen (Tilemap bearbeiten, Entities bearbeiten, ...). Dafür warnt einen der Editor jetzt z.B. auch, wenn man eine Szene wechselt, dass es noch ungespeicherte Änderungen gibt.

Weiters eingebaut habe ich auch PositionMarker für den Editor (siehe PositionMarker.png). Die sind vor allem dazu da, um andernfalls unsichtbare Objekte leichter erkennen und auswählen zu können. Außerdem kann man damit auch Objekte, die grafisch unter anderen Objekten liegen, direkt auswählen (normal wird bei einem Klick immer das oberste Sprite ausgewählt).

Naja, wie immer gibts viel zu erledigen. Ich halt euch auf dem laufenden...

Update,

in den letzten 2 Wochen hat sich doch einiges getan. Der Portierungsvorgang aufs neue Format ist so gut wie abgeschlossen. Sowohl die Gamedaten als auch die Plugins laufen jetzt über die neue Format-Art und können dadurch in Zukunft auch noch binär gepacked werden. Was nun nur noch fehlt ist eine Möglichkeit, ähnlich wie bei der Szene Spieldaten über ein allgemeines Interface setzen zu können, wie z.B. die Textbox-Textur. Aktuell läuft das über die Settings ab, diese sind aber eigentlich nur für Usergesteuerte Daten zuständig.

Zusätzlich habe ich auch einige Sachen vom Game selber eingebaut. Einerseits Rotationen für Sprites (siehe Rotation.png). Dann noch Textoptionen, womit ich jetzt auch ein Startmenü habe (siehe TextOptions.png), zusätzlich dazu auch noch den Textsound. Weiters habe ich begonnen, die Spieler-Attribute und Level-Daten einzubauen. Dazu gibt es aktuell noch kein grafisches Interface - ist auch noch nicht so wichtig, da in der ersten Demo sowieso noch nicht gelevelt werden kann, ist aber eine wichtige Grundlage für später.

Und noch viele Kleinigkeiten, die ich u.a. aus Zeitgründen nicht alle aufliste. Die nächste Zeit wird bei mir nämlich noch knapper als sonst, ich werde versuchen so bald es geht den Prolog fertigzustellen (vor allem da ich selber auch etwas spielbares rausbringen will). Grundsätzlich fehlt nicht mehr viel, aber einigen Sachen müssen noch gemacht werden, damit dann nicht bei der nächsten Version wieder die Savegames inkompatibel werden. So brauche ich z.B. noch ein System um globale Information über den Fortschritt des Spielers zu speichern. Lokalen Fortschritt kann ich ja relativ leicht über die statischen Variablen des Event-Systems machen, aber das würde nach der Zeit extrem kompliziert werden, vor allem da ich dann sämtliche Szenen-spezifischen Events global verfügbar machen müsste. Ich tendiere daher zu einem System ähnlich den Maker-Switches, bloß mehr spezifisch und eben wirklich nur für Story-Fortschritt und nichts anderes verwendet.

Nun, wie gehabt, ich meld mich wenn es wieder neues gibt.

Unkn0wn5:

Danke, freut mich sehr zu hören

@Topic:

Wieder ein kleines Update,

habe nun auch das neue Dateisystem auf die Savegames angewandt. Für die Tests werden Savegames zwar vmtl als Textformat gespeichert, könnten aber auch binär abgelegt werden.

Weiters habe ich die letzten Wochen eine grundlegende Überarbeitung des Entity-Systems vorgenommen.Sagen wir es mal so, als ich begonnen haben es einzubauen dass du im Editor starten kannst, habe ich ein System dafür verwendet das eigentlich extrem umständlich & schlecht war, und auch immer wieder für Probleme gesorgt hat. Nun habe ich das entsprechend umgebaut, damit hat sich wieder mal der Code ziemlich vereinfacht. Außerdem gibt es wieder ein bisschen bessere Performance, und das Szenen Push/Pop für die Truhe funktioniert nun ohne Schwierigkeiten.

Außerdem habe ich die Prefabs erweitert - ein Prefab kann nun ein anderes Prefab als Parent haben und erbt dessen Komponent, das ist dazu da um z.B. für spezifische Prefabs (Ark, diverse verschiedenen Truhen) eine gemeinsame Basis anlegen zu können, um bestimmte Kombinationen von Komponenten nicht immer kopieren zu müssen und Änderungen auch über mehrere Ebenen weiterreichen zu können. Im Prinzip merkt man davon ingame wieder nichts, aber es macht das arbeiten nochmals leichter.

Weiters habe ich mich dem Sound angenommen. SPCs werden nun im Thread gestreamed, und sogar damit nicht mehr für Ruckler. Da hier kein gutes System dahinter steckt, sondern ich die Threads erstmals nur direkt im SPC-Code angelegt habe, werde ich das demnächst mal erweitern, auch um Threads allgemein in der Engine benutzen zu können.
Weiters habe ich Unterstützung für das Mp3 Format eingebaut, um für alle normalen Sounds Speicherplatz sparen zu können.

Die Spielsystem wurden um Ausrüstung (Ringe, Waffen, Rüstung) erweitert.

Das Event-System hat viele neue Commands bekommen, und einige Bugfixes erhalten. Ich habe jetzt für die Zukunft gelernt, Sequenz-Nodes effektiv einzusetzen um Cutscenes sauberer zu gestalten. Dazu passend habe ich ein "ParallelSequenz"-Node gemacht, welches die ersten Ausgänge parallel ausführt, und danach einen Folgeausgang bietet. Weiters habe ich eine Option eingebaut, um Attribute-Eingänge per Rechtsklick und Contextmenü direkt mit anderen Attributausgängen zu verbinden. Das dient dazu, um z.B. auch weit entfernte Nodes noch schnell & flexibel mit einem Attribut zu verbinden (wenn z.B. viele Nodes auf die Spieler-Entity aufgerufen werden müssen).

Dann habe ich mich auch dran gemacht, den Player zu reaktivieren, damit das Spiel auch außerhalb des Editors läuft. Es ist nämlich so, dass ich auch kontentmäßig im Prinzip mit dem Prolog bis Ark ins Portal in Krysta springt fertig bin. Hier und da noch Sachen fixen und verbinden, und dann kann ich eigentlich schon eine spielfähige Version rausbringen. Das wird aber erst nach Juni passieren, nachdem ich meine Bachelor-Arbeit fertig habe. Dennoch dürfte das auch für die alteingesessenen spannend werden, da ich wieder einige Verbesserungen an der Story & an den Dialogen vorgenommen habe. Zwar kennt ihr dann trotzdem die ganzen Twists, aber ich habe z.B. bestimmte Informationen für den Spieler erst nach weiter hinten verlegt (also werden bestimmte Details noch nicht in Krysta verraten). Das dürfte vor allem für neue Spieler, aber auch für euch interessant werden.

Freue mich schon wenn ich neues verkünden kann.

Quote

Ich wünsche ich noch viel Erfolg, natürlich auch für die Bachelorarbeit.
Darf man fragen, was das Thema der Bachelorarbeit ist?

Danke Bei der Arbeit geht es um Terrain-Rendering mit DirectX11, also vor allem mit Tessellation, was es erst seit ein paar Jahren gibt. Umgesetzt hab ich das ganze natürlich in meiner Engine, deswegen hab ich auch das Thema gewählt (Tessellation etc.. wollte ich schon lange verfügbar machen).

@Topic:

Ich hab jetzt schon nen elends langen Text geschrieben und bin dann auf "Seite zurück" im Browser gekommen...

... Kurz und knapp, in nächster Zeit könnt ihr etwas spielbares erwarten. Ich habe den gesamten Prolog fertig und schon getestest, will aber nochmal auf Nummer sicher gehen und alles nochmal durchgehen, damit ich ja keine kritischen Fehler übersehe (am Anfang kann es noch leicht passieren dass sich Änderungen ungeahnt grob auswirken). Es werden anfangs noch einige Kleinigkeiten fehlen, wie z.B. das Aufheben Werfen von Töpfen etc... sowie bestimmte Animationen, da ich diese erst im Laufe der Zeit einbauen werde (aktuell ist es mir wichtiger etwas spielbares rauszubringen). Werde dann beim Test selber eine Liste von Sachen veröffentlichen die bewusst/gewollt noch nicht gehen, damit es da zu keinen Verwirrungen kommt. Ich werde dann die Tage mal einen eigenen Thread für den Test starten und hoffe auf rege Beteiligung

Hallo,

das Projekt ist aktuell auf dem Stand der letzten Demo, ich komme zur Zeit leider nicht zu viel. Das sollte im neuen Jahr bzw. in den Weihnachtsferien besser werden. Hoffe das klärt deine Frage.

Bin erst noch im Master, Beruf kommt Ende dieses Jahres

Spenden geht über meinen Paypal-Account - https://www.paypal.com/cgi-bin/webscr…d=ARNG94M7593QL der entsprechende Link dazu. Spenden sind natürlich nicht notwendig, und ich freue mich über jeden Betrag der gespendet wird.

Danke für den Kommentar!

Eigentlich wollte mal jemand die Texte übersetzen, hab aber bis jz nix mehr gehört.

Die hochzustellen ist kein Problem, das ist eine eigene Datei im XML-Format, das lässt sich mit jedem Text-Editor öffnen (Editor.exe formatiert das halt grausam). Unten ist ein langer Block <Language name="german">, mit allen Texten auf Deutsch. Drüber ein kleiner Block für "english", da müsste man nur den unteren Block drüberkopieren & die Texte ersetzen.
Das ist eben Vorteil von der eigenen Engine - mit dem Rpg-Maker wäre das ein graus gewesen

Ich stell das File einfach mal hoch - falls du es schaffst das zu übersetzen, wäre das echt toll

Ob ich die Engine mal kommerziell vermarkten kann, wird sich zeigen. Interesse wär schon da, aber tatsächlich ist der Markt sehr überfüllt mit robusten & öfters kostengünstigen Konkurrenzprodukten. Unity, Unreal, CryEngine sind die nur größten, es gibt nen ganzen Rattenschwanz an Gamenegines, die alle viel mehr leisten können als der Rpg-Maker.
Vllt müsste ich mir ne Nische suchen, in der ich vermarkten könnte - aber das ist alles nur Gedankenspielerei, aktuell bin ich einfach froh dass ich ein Projekt habe, was mit technisch herausfordert & auf längere Sicht motiviert.