Wegfindesysteme an sich sind nicht besonders schwer, man kann an schlüsselstellen Waypoints setzen und um
diese herum zugehörige Wayareas definieren und für den Weg zu diesen einen mehr oder weniger
ausgereiften rekursiven Wegfindealgorithmus schreiben. Das Problem dabei ist, wie bei allen anderen Situationen
auch, dass man Events nicht als Objekte ansehen kann und ihnen so keine Variablen auf ihre Referenz zuweisen kann,
sondern sich aus dem globalen Variablenpool bedienen muss. Auch kann man keine eventspezifischen Methoden
deklarieren, sondern nur globale, die sich aus dem selben Variablenpool bedienen und bei mehrfacher, gleichzeitiger
Ausführung, auf den selben Variablen schreiben.
Das macht es natürlich sehr schwer, da wirklich jedes Event seine eigenen Variablen und Methoden benötigt
und man den Code so ständig kopieren und anpassen muss.
Hinzu kommt die unperformante Ausführungsgeschwindigkeit des Maker-Scriptcodes, welcher viele gleichzeitige
oder komplexe Prozeduren nahezu unmöglich macht.

Bei einem Echtzeitstrategiespiel muss jede Einheit auf jede reagieren, da obige Features der Objektorientierung
im Maker fehlen, müsste man unglaublich komplexen Code schreiben, für jede einzelne Einheit, der ausserdem
äußerst Ressourcenhungrig ist. Man müsste sich bei der Anzahl der Einheiten stark beschränken, ich wage es
zu bezweifeln, dass auch nur mehr als 10 Einheiten bei einer mittelmäßigen KI überhaupt laufen würde, eher
noch weniger.

Thema Fog of War:
Das Verdecken der Spielkarte ist nur eine Möglichkeit, dem Spieler das frühzeitige Auskundschaften der Map
ohne Späheinheiten zu erschweren. Im Maker wäre das nur dadurch zu reallisieren, auf jedes Feld ein Event zu
legen, welches den Untergrund verdeckt. Eine sehr ressourcenlastige Angelegenheit.
Besser wäre es, die Bewegung der Maus auf dem Feld durch Koordinatenabfragen einzuschränken. So könnte
der Spieler auch keine Areale erreichen, die noch nicht erspäht wurden. Kundschafter könnte man über eine
Minikarte in unbekanntes Terrain lotsen.




Pixelmovement ist möglich, auch mit völlig freiem laufen, indem man für alle Pictureobjekte eine Positionskorrektur
laufen lässt, sobald sich der Screen mitbewegt. Das ist keine große Sache. Auch Kollisionsabfragen sind dank Terrain ID
und deren Umrechnung auf Pixelkoordinaten einfach und ressourcenschonend zu lösen.
Die Schwierigkeit liegt darin, dass man Pictures nicht variabel, sondern nur statisch anzeigen lassen kann.
Das wird dann zum Problem, wenn sich zwei Objekte (beide durch Pictures dargestellt) drohen, zu überschneiden.
Welches wird über bzw. unter dem anderen dargestellt? Je nach Position lässt sich da keine feste Regel aufstellen
und die Pictures müssten zur laufzeit ihre Z-Position ändern. Man müsste für jedes Objekt die Pictureanzeigen
für alle 50 möglichen Z-Positionen in reserve halten, um dies dynamisch gestalten zu können.
Ein ungeheurer Skriptaufwand für eine eher triviale Sache, der bloßen Darstellung.




Pseudo 3d gibt es bereits in Maker spielen, z.B. Scrolling des Untergrunds in die Tiefe. Richtungswechsel sind dabei
allerdings nicht möglich, lediglich änderungen am Scrollspeed.
Auch kann man Parallax-Scrolling als eine Form von pseudo-3d ansehen.
In dem Spiel Deathcat hingegen ist der Hintergrund z.B. in statischem 3d gehalten. Man kann sich aber dreidimensional
über die Map bewegen und die Spielfigur ändert dabei, abhängig von der Entfernung zur Kamera, ihre Größe.




Was Schach eingeht, so ist die KI wirklich die einzige Schierigkeit, die sich bei einer Reallisierung stellt und das
sprachenunabhängig. Allerdings hat es diese Schwierigkeit so richtig in sich.
Über die Umsetzung zur Bewegung der Figuren oder der Einhaltung der Regeln braucht hier nicht diskutiert zu
werden, das sind triviale Angelegenheiten, die sich durch ein bis zwei Tage Skriptaufwand leicht reallisieren
lassen.
Eine KI hingegen müsste erst einmal alle möglichen Züge der eigenen noch auf dem Feld stehenden Figuren
ermitteln und zwischenspeichern. Dazu müsste man eine Art virtuellen Stack deffinieren, in dem diese gespeichert
werden. Nun muss ausgewertet werden, welcher dieser Züge den größtmöglichen Vorteil bieten würde, dabei
werden Züge, die eine gegnerische Figur vernichten, natürlich höher gewertet . Bei Zügen, die sich ins
Nichts verlaufen, müsste man natürlich wieder eigene Regeln deffiniert werden, welche denn nun bevorzugt werden,
z.B. Züge, die die Spielfiguren denen des Gegners näher bringen.
Jedenfalls ist das alles schon ein gehöriger Aufwand und dabei sind noch nicht einmal die Reaktionen des Gegners
berücksichtigt, geschweige denn Strategien über mehrere Runden.
Ab hier wird der Aufwand auf dem Maker sehr hoch. Den Stack, den man dazu definieren müsste, wäre riesig.
Man könnten dies aber beschränken, in dem man nur die gegnerischen Züge speichert, die eine eigene Figur
vernichten könnten.
An dieser Stelle mache ich mal Schluss, da es von nun an nur noch um das Referenzieren einer exponentiell
steigenden Anzahl von Spielzügen und deren Auswertungen geht.