Hier mal ein kleines Update, um die bisherigen und (hoffentlich) demnächst folgenden Veränderungen zu beschreiben.
Damit man mich besser verstehen kann, hier meine derzeitigen Gedankengänge dazu:
Bei den Mapobjekten mache ich mir derzeit noch ein paar Gedanken bezüglich der Skriptverwaltung/-ansteuerung. Für jedes Mapobjekt kann für diverse Events (active, enter, ...) festgelegt werden, welches Skript ausgeführt werden soll. Da bin ich derzeit noch am Überlegen, was grubndsätzlich sinnvoll ist und in wie weit "Überladungen" sinnvoll sein könnten. Einerseits kann jedes Gebiet (bzw. jede Maop) beliebig viele Skripte beinhalten, andererseits kann dies auch jede Objektdefinition (bzw. jedes nicht-lokale Mapobjekt). Dass übergeordnete Skripte "nach unten durchgereicht" werden, sofern sie nicht überschrieben werden, halte ich in beiden Fällen für sich gesehen in Ordnung (übergeordnete Objektdefinition zu untergeordneten oder übergeordnetes Gebiet zur untergeordneten). Allerdings bin ich mir nicht sicher, ob Objektdefinitionsskripte die Gebietsskripte überlagern sollten oder umgekehrt und in welchen Fällen dies überhaupt möglich sein soll.
Zur Orientierung überlege ich mir anhand ein paar einfacher Beispielobjekte und einer exemplarischen Umgebung Fälle, in denen diese Konstrukte sinnvoll sein könnten bzw. suche mir Situationen aus bereits vorhandenen Spielen, die sich damit abdecken oder nicht abdecken lassen. So zum Beispiel wird es auf jeden Fall den Helden (nicht-lokale Objektdefinition), Schalter (benannte Instanz) und Monster (unbenannte Instanzen) geben. Der Held beispielsweise dürfte in quasi keiner Situation in (direkter) Abhängigkeit von der Umgebung Aktionen (Skripte) ausführen, weshalb aus dieser Sicht das Überschreiben der Objektskripte durch die Mapskripte nicht gewollt ist. Die unbenannten Instanzen (beispielsweise ein gewöhnliches Monster, welches im Gegensatz zu den anderen eine besondere Bedeutung hat) sollten grundsätzlich die Skripte der Definitionen verwenden und nur für diverse Ereignisse Umgebungsspeziefisches Verhalten aufweisen (öffnen einer Tür) - dafür könnte beim "instanziieren" das Skript festgelegt werden. Das Gleiche gilt auch für benannte Instanzen, wobei diese eher Skripte der Umgebung nutzen würden - wieder ohne "Überschreibung" festgelegte Skripte.
Sollte ich mich konkret entschieden haben, wie ich es umsetzen will, werde ich nochmal schreiben und evtl. den Eingangspost aktualisieren.
Was ich tatäschlich geschafft habe:
Es ist zwar nicht viel, aber der Text der Dialoge passt sich dem vorhandenen Platz an. Bisher heißt das bloß, dass Leerzeichen als Abgrenzung der Wörter verwendet werden und nur so viele Wörter in einer Zeile ausgegeben werden, wie auch in diese Zeile passen.
Es fehlt aber immernoch das Verhalten für das "weiterblättern", sollte ein Text zu lang sein, als dass er auf einmal ausgegeben werden kann. Außerdem soll es später möglich sein, ein Mapobjekt oder eine ID eines solchen zu übergeben und anhand dessen automatisch den (Anzeige-)Namen mit einer Farbe, abhängig von den Objektvariablen, anzuzeigen. Außerdem soll es später möglich sein, eine Text-ID zu übergeben, anhand derer der eigentlich anzuzeigende Text ermittelt wird. Dies wiederum würde eine Übersetzung eines Spiels wesentlich vereinfachen (siehe
Internationalisierung und
Lokalisierung). Weiterhin sollen noch Formatierung möglich sein, wobei das wichtigste wohl erstmal nur das integrieren von Bildern in den Text sein wird (beispielsweise zur Erklärung der Steuerung).
Ich habe mich eigentlich auch nur daran begeben und nicht mit den Mapobjekten weiter gemacht, weil ich (u. a. während einer Zugfahrt) weiter machen wollte, aber in dem Moment nicht die "Motivation" für die Mapobjekte hatte...
Die Dialoge weiter auszubauen bleibt also aufgeschoben und Mapobjekte sind derzeitiges Entwicklungsziel. Um konkreter zu sein: derzeit verwende ich noch die alte
Mapobject-Klasse mit den beiden Ausprägungen
Character und
Trigger und ich möchte so bald wie möglich zumindest dahin übergehen, dass man kein
Character-Objekt mehr herumscheucht, sondern ein
Objectdefinition-Objekt (zukünftig vlt.
Mapobject) herumkommandieren kann. Der Zugriff auf die Objektdefinitionen und deren Variablen ist bereits möglich, allerdings gibt es noch nicht die Möglichkeit, (benannte und anonyme) "Instanzen" anzulegen.
Worüber ich mir auch schon ein paar Gedanken gemacht habe, was ich aber noch nicht so direkt angesprochen habe:
Welche Ressourcen sollte ich zu Beginn einmal auslesen und die ganze Zeit im Speicher halten und welche sollte ich nur bei Bedarf laden und ggf. wieder entladen?
Eine Möglichkeit wäre es, zu sagen: alle dynamischen Sachen (bspw. Variablen) am Anfang komplett einlesen und alle statischen (Mapdaten, Bilder, Sounds) erst, wenn sie benötigt werden
Zu den Ressourcen an sich: Es gibt bisher Maps, Objektdefinitionen, Tilesets, Charsets, Skripte und Variablen (Sound und Musik ist bisher noch nicht implementiert). Mit Map meine ich die Levelinformationen (welches Tile befindet sich an welcher Stelle, wo befindet sich welches Objekt), welche grundsätzlich klein sein sollte, die Tilesets und Charsets sind bisher die einzigen Ressourcen, die auch grafiken enthalten (Maps und Mapobjekte verweisen auf diese).
Die ersten paar Demos bzw. das Spiel an sich, welches ich hiermit entwickle, dürften wohl so klein sein, dass quasi alles in den Arbeitsspeicher geladen werden könnte, allerdings denke ich nicht, dass ich dies machen sollte, nur weil es möglich ist...
Es wäre ganz interessant zu wissen, wir ihr solche Ressourcen, die nicht im gesamten Spielverlauf benötigt werden, verwaltet bzw. wie dies von größeren Engines (Cry-Engine, Soruce-Engine, Unreal-Engine, "Unity-Engine", ...) gehandhabt wird.