Christians Externes Gedächtnis

Mit meinem Kollegen Andreas aus der Comicbude habe ich ein Weihnachtsspielchen am Wickel, das kurz davor ist, fertig zu werden. Es trägt den schmissigen Titel Snowbot (danke, Regine! *g*).
Es läuft derzeit in einer Vorveröffentlichungsversion — “Beta” wäre zuviel gesagt — auf einem Testserver und kann gern mal ausprobiert werden: Snowbot Pre-Release.

Feedback / Bug reports / Wishlist für nächste Version erwünscht.

Bei diesem Artikel geht es darum, zu prüfen, ob sich die gewonnenen Einsichten auch auf ein ähnliches Spielsystem übertragen lassen.

Die in Abbildung 1 gezeigten Würfel kommen in einem Spiel vor. Am Ende eines Wurfs haben SpielerInnen (hier spielt der Einfachheit halber Max) 6 Würfel vor sich liegen, von denen jeder theoretisch eine andere Augenzahl und eine andere Farbe haben können.

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_1.gif”>
Abb. 1: Alle möglichen Würfel eines fiktiven Spiels

Die Farben der Würfel sind: Rot, Grün, Blau, Gelb, Türkis und Magenta. Die Augenzahlen reichen jeweils von 1 bis 6.

Gewinnkombinationsprüfung
Es soll jetzt, nachdem Max mit Würfeln fertig ist, der Wurf auf bestimmte Gewinnkombinationen (”GK”) hin untersucht werden:

• Paar: 2 Würfel gleicher Farbe und gleicher Augenzahl (z.B. 2 rote Vieren)
• 2 Paare: siehe Paar, aber 2 mal
• 3 Paare: siehe Paar, aber 3 mal
• Dreier: 3 Würfel gleicher Farbe und gleicher Augenzahl (z.B. 3 rote Vieren)
• 2 Dreier: siehe Dreier, aber 2 mal
• Vierer: 4 Würfel gleicher Farbe und gleicher Augenzahl (z.B. 4 rote Vieren)
• Fünfer: 5 Würfel gleicher Farbe und gleicher Augenzahl (z.B. 5 rote Vieren)
• Sechser: 6 Würfel gleicher Farbe und gleicher Augenzahl (z.B. 6 rote Vieren)
• Zahlen 1 bis 6, alle Würfel zeigen unterschiedliche Farben
• Zahlen 1 bis 6, alle Würfel zeigen die gleiche Farbe

Die Wertigkeit der jeweiligen GK nimmt nach unten stetig zu, also ein Sechser ist mehr wert als ein Paar.

Anders als in dem o.g. Artikel geht es also nicht nur um einen in die Prüfung einzubeziehenden Aspekt oder Faktor (Augenzahl), sondern zusammen mit der Würfelfarbe um zwei Faktoren. Daher gehe ich davon aus, dass ich für jeden untersuchten Wurf zwei Werte erhalte, nämlich die Anzahl der Augenzahlübereinstimmungen (”AÜ”) und die Anzahl der Farbübereinstimmungen (”FÜ”).

Beispiel-Tabellen
Um überhaupt eine Vorstellung zu bekommen, ob sich die Vorgehensweise bei der GK-Prüfung aus dem o.g. Artikel hier ebenfalls anwenden lässt, habe ich einige Tabellen aufgestellt, mit unterschiedlichen Wurfergebnissen gefüllt und per Hand die Treffer (engl. matches) abgezählt.
Jeder Würfel des Wurfs ist einmal horizontal und einmal vertikal in dieser Tabelle notiert. Beim Abzählen der Übereinstimmungen trage ich im Feld, in dem sich Zeile und Spalte schneiden, jeweils ein, wie das Ergebnis der Prüfung ausgefallen ist.
Felder in diesen Tabellen, die mit “X” gekennzeichnet sind, entfallen bei der Überprüfung. Ein “-” bedeutet: Keine FÜ und auch keine AÜ. “F” wird eingetragen, wenn eine FÜ bei den beiden miteinander verglichenen Würfel vorliegt, und ein “A”, wenn eine AÜ vorliegt.

GK 9 - Der “Regenbogenwurf”
In Abb. 2 ist der von mir so genannte “Regenbogenwurf” zu sehen, bei dem alle Farben und alle Augenzahlen genau einmal vorkommen. Dies würde GK 9 meiner obigen Liste entsprechen.
FÜ und AÜ betragen in diesem Fall beide 0.

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2.gif”>
Abb. 2: “Regenbogenwurf” — FÜ = 0; AÜ = 0

Meine Annahme ist, dass ich davon ausgehen kann, dass FÜ = 0 und AÜ = 0 immer bedeutet, dass GK 9 vorliegt. Aber schauen wir mal weiter.

GK 10 - Der “Normalfall”
Man könnte diese GK sicher auch “Straße” nennen, geht es doch hierbei darum, alle Zahlen einer Farbe zu erwürfeln.

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2l.gif”>
Abb. 2a: “Normalfall” — FÜ = 15; AÜ = 0

Hier (Abb. 2b) hat Max es mit einer einzigen AÜ zu tun (2 Einsen unterschiedlicher Farbe). Der Wurf ist, gemessen an der GK-Übersicht, ungünstig ausgefallen — close, but no cigar:

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2c.gif”>
Abb. 2b: FÜ = 0; AÜ = 1

Hier (Abb. 2c) ist ähnlich, nur liegt hier eine FÜ vor (2 mal rot, aber die Augenzahlen stimmen nicht überein):

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2d.gif”>
Abb. 2c: FÜ = 1; AÜ = 0

Paar(e) — GK 1 bis 3
Hier (Abb. 2d) hat Max mehr Glück, denn immerhin hat er sich ein Paar erwürfelt, was laut Definition oben GK 1 darstellt und ihm ein paar Punkte bringt (kein Wortspiel):

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2b.gif”>
Abb. 2d: FÜ = 1; AÜ = 1

Ich bleibe bei den Paaren und lasse Max ein wenig weiterwürfeln, bis sich zeigt, wie es um FÜ und AÜ bestellt ist, wenn zwei oder drei Paare vorliegen.
Erst einmal zwei Paare:

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2e.gif”>
Abb. 2e: FÜ = 2; AÜ = 2

Und jetzt 3 Paare:

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2f.gif”>
Abb. 2f: FÜ = 3; AÜ = 3

Ich stelle mir die Frage, ob es auch andere Würfe gibt, deren FÜ und AÜ so ausfallen wie bei den eben untersuchten Paar-Würfen. Obwohl ich fast sicher bin, dass die Antwort “nein” lauten muss, fehlt mir eine Art Beweis. Es steckt allerdings zu wenig Mathematiker in mir, und ich muss mich zunächst weiter mit Vermutungen und Annahmen zufrieden geben.

Mehrling(e) — GK 4 bis 8
Um die FÜ/AÜ-Sachlage bei Würfen zu prüfen, wo es Max gelungen ist, mehrere gleiche Würfel zu erwürfeln, erstelle ich mir die folgenden Tabellen.

Und da haben wir den Salat:

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2g.gif”>
Abb. 2g: Leider auch FÜ = 3; AÜ = 3

Wie anhand dieser Tabelle zu erkennen ist, habe ich mich nicht nur böse geirrt, sondern stehe mit meiner bisherigen Annahme auch noch vor einem Problem. Offenbar kann ich bei dem GK-Prüfungsergebnis FÜ = 3; AÜ = 3 nicht einfach davon ausgehen, dass hier die GK “3 Paare” vorliegt, denn dasselbe Ergebnis kommt auch bei einem einfachen “Dreier” (vgl. Abb. 2f) heraus.

Es sieht so aus, als bestünde dieses Problem nur in genau dem zuletzt untersuchten Fall. Aber sicher kann ich nicht sein. Daher erstelle ich noch flink die fehlenden Tabellen.
GK 5 (”2 Dreier”):

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2h.gif”>
Abb. 2h: FÜ = 6; AÜ = 6

Auch hier bei der GK 6 (”Vierer”) gibt es Ärger:

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2i.gif”>
Abb. 2i: Wie beim “Dreier” leider auch hier FÜ = 6; AÜ = 6

GK 7 (”Fünfer):

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2j.gif”>
Abb. 2j: FÜ = 10; AÜ = 10

GK 8 (”Sechser”):

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_2k.gif”>
Abb. 2k: FÜ = 15; AÜ = 15

Lösungsansatz
Ich sollte bei der GK-Prüfung noch jeweils notieren, welche der Einzelprüfungsergebnisse zusammenhängen. Stoße ich also bei einem Würfelvergleich auf eine Farb- und Augenzahlübereinstimmung (”FuAÜ”), lege ich diese Würfel in einen Topf, den ich gedanklich mit “Möglicher Anwärter auf GK” beschrifte.
Finde ich die nächste FuAÜ, würde ich die zwei an dem Vergleich beteiligten Würfel wieder in einen Topf legen. Wenn sich Augenzahl und Farbe der aktuellen Würfel mit den Würfeln gleichen, die bereits in einem Topf liegen, werden die aktuellen Würfel nicht in einen neuen Topf, sondern eben den bereits existierenden gelegt.
Das alles erinnert mich stark an meine Gedanken vom letzten Mal, als ich mich mit Gewinnkombinationsprüfung beschäftigt habe. Ob ich farblich und von der Augenzahl her zusammenpassende Würfel in einen Topf oder eine Gruppe packe, ist ja egal. Im Unterschied zu meinen damaligen Überlegungen ergänze ich heute das Modell um den Schritt, am Ende der Topf/Gruppen-Zuordnung alle Töpfe/Gruppen zu verwerfen, die nur ein Element (einen Würfel) enthalten. Was übrig bleibt, sind die Töpfe/Gruppen, die GK darstellen.

Das alles gilt, wohl gemerkt, nur für GK 1 bis 8. GK 9 (”Regenbogenwurf”) müsste ich im Vorwege bereits überprüft haben, denn dort geht es ja gerade darum, 6 Töpfe mit nur einem Würfel darin zu haben.

(Schnellere?) Variante
Gerade fällt mir auf, dass ich vielleicht auch schneller als Ziel kommen kann. In Abb. 3 ist Max’ letzter Wurf zu sehen — für mich sofort als ein “Vierer” zu erkennen. Für Flash erstmal nur Böhmische Dörfer. Das soll sich ändern.

<img alt=”" src=”http://www.christianscholz.com/img/wuerfel_problem_3.gif”>
Abb. 3: Nummerierte Würfel

Mein Plan ist es, jeden der sechs Würfel nacheinander daraufhin prüfen zu lassen, ob es bereits einen Topf gibt, der genau den gleichen Würfel (also einen Würfel gleicher Farbe und gleicher Augenzahl). Wenn ja, kommt der aktuelle Würfel mit in den Topf. Wenn nicht, lege ich ihn in einen eigenen Topf.
Das macht genau 6 Prüfungen, was sehr viel weniger ist, als ich oben noch angenommen hatte durchführen lassen zu müssen (15 Prüfungen).

Ablaufschema:
1) Gibt es bereits einen Topf für blaue Dreien?
Nein.
Hole einen neuen Topf für blaue Dreien.
Anzahl Töpfe: 1 (Topf/Elementanzahl: Topf1/1)
<hr>
2) Gibt es bereits einen Topf für grüne Einsen?
Nein.
Hole einen neuen Topf für grüne Einsen.
Anzahl Töpfe: 2 (Topf/Elementanzahl: Topf1/1; Topf2/1)
<hr>
3) Gibt es bereits einen Topf für blaue Dreien?
Ja!
Lege diesen Würfel in den Topf für blaue Dreien.
Anzahl Töpfe: 2 (Topf/Elementanzahl: Topf1/2; Topf2/1)
<hr>
4) Gibt es bereits einen Topf für blaue Dreien?
Ja!
Lege diesen Würfel in den Topf für blaue Dreien.
Anzahl Töpfe: 2 (Topf/Elementanzahl: Topf1/3; Topf2/1)
<hr>
5) Gibt es bereits einen Topf für gelbe Vieren?
Nein.
Lege diesen Würfel in den Topf für gelbe Vieren.
Anzahl Töpfe: 3 (Topf/Elementanzahl: Topf1/3; Topf2/1; Topf3/1)
<hr>
6) Gibt es bereits einen Topf für blaue Dreien?
Ja!
Lege diesen Würfel in den Topf für blaue Dreien.
Anzahl Töpfe: 3 (Topf/Elementanzahl: Topf1/4; Topf2/1; Topf3/1)
<hr>

Anhand der Anzahl der Töpfe würde ich sofort nach dieser Prozedur feststellen, ob die GK 9 vorliegt, bei der die Anzahl der Töpfe 6 sein muss. Das ist hier nicht der Fall. Durch diese Feststellung kann ich alle Töpfe des eben erhaltenen Ergebnisses verwerfen, die nur ein Element enthalten. [Hier habe ich mich geirrt, wie mir durch einen Einwand meines Kollegen Lars klar geworden ist.]

Was übrig bleibt, ist ein Topf mit drei Elementen, sprich: ein “Dreier”.
“Paare”, “Vierer”, “Fünfer” und “Sechser” kann ich ebenso leicht voneinander unterscheiden. Und auch Mischungen mehrerer GK in einem Wurf sollten damit erfasst werden können.

Allmählich wird mir klar, dass es keine allgemein gültige Vorgehensweise zur GK-Prüfung geben kann, wenn sich von Spiel zu Spiel die Parameter und GK ändern. Aber einen großen Teil der Möglichkeiten decke ich mit dem oben geschilderten Verfahren sicher ab.

Dies hier wird kein nostalgisch-melancholischer Beitrag, eher eine Mini-Linksammlung, die bei meiner Recherche entstanden ist.

In heutigen Browsergames (Abteilung: Rollenspiele) werden Kämpfe gern rein textlich gelöst, unter anderem um Datentraffic und die Notwendigkeit der Visualisierung von Spielwelt und -elementen zu umgehen, was einerseits verständlich ist, auf der anderen Seite aber den Spielen auch eine Menge Charme nimmt.

Schon im Jahre 1988 haben es uns die Entwickler des C64-Titels Pool of Radiance vorgemacht, wie es besser gehen könnte. Dort gab es nämlich ein sehr ausgefeiltes taktisches Kampfsystem, das eine Menge mehr Spaß und Abwechslung bringt, als die weit verbreiteten Umsetzungsvarianten aktueller Browsergames.

<img width=”384″ height=”282″ src=”http://www.christianscholz.com/wiki/images/por_battle.gif” alt=”" />
Abb. 1: Kampf in Pool of Radiance

Um sich davon selbst zu überzeugen, sind allerdings ein C64-Emulator (1) und die entsprechenden Dateien (2) nötig, die das Spiel, welches heutzutage als Abandonware (3) gilt, auch auf modernen PCs zum laufen bringt.

1 Link zur Website des C64-Emulators ccs64
2 Link zu c64games.de, wo es reichlich Spiele für den C64 gibt
3 Ursprünglich urheberrechtlich geschütztes Material, von dem allgemein aber angenommen wird, dass die Rechteinhaber im Falle der Verbreitung beide Augen zudrücken.

Wahnsinn, was man mit der Google-Schaufel mitunter für Schätze ausgraben kann: Amit’s Game Programming Information ist die heftigste Know-How-Sammlung, die ich bisher zum Thema Spieleprogrammierung finden konnte.

LOS oder die Berechnung oder Herleitung derselben für meine seit Jahren gehegten “Kachelbasierten Spiele” (engl.: tile-based games) hat mich schon sehr lange gefesselt, frustriert und beschäftigt.

Vor ein paar Tagen habe ich es aufgegeben, eine wirkliche Berechnungsmethode zu schaffen. Statt dessen arbeite ich seit gestern erstmal mit einer LUT oder Look-up table, in der für eine auf 10 Felder begrenzte Sichtweite einer Spielfigur Werte abzulesen sind.

Was sind “tile-based games”?
Für den uneingeweihten Mitleser (oder für mich selbst, sollte ich jemals einen Gedächtnisverlust erleiden) hier kurz noch die Hintergründe.
In tile-based games wird die Spielwelt aus kleinen “Kacheln” zusammengesetzt. Eine “Kachel” kann dabei - je nach Maßstab - ein Stück Grasland, ein Baum, ein Haus, ein Dorf oder ähnliches darstellen. Wenn man genügend verschiedene “Kacheln” gestaltet hat, kann man eine nette Landschaft zusammenbauen. Wie mit einem Baukasten.
In der Regel unterliegt so einem Spiel ein schlichtes Raster, das stark an Schiffeversenken oder eine Exceltabelle erinnert; es gibt Felder in horizontaler und in vertikaler Richtung und jedes davon lässt sich eindeutig benennen, z.B. mit “A1″ oder “(3,5)”, je nach Bezeichnung der zwei Achsen.
Nun faszinieren mich besonders KoSims oder Konfliktsimulationsspiele. Berühmte Vertreter dieses Genres sind Risiko, Axis and Allies oder Diplomacy. Bei diesen Spielen geht es also um die Inszenierung von Konflikten und der spielhaften Auseinandersetzung mit der jeweiligen Rolle des Spielers dabei. Langer Rede kurzer Sinn: es wird Krieg gespielt. Spieler A haut Spieler B, der haut zurück, usw.
Ein Aspekt unter vielen bei solchen Spielen kann die “Sichtlinie” (engl. “Line Of Sight” oder kurz “LOS”) sein, d.h. kann Spielfigur X die Spielfigur Y sehen oder stehen/liegen Hindernisse dazwischen, die den Sichtkontakt verhindern?

Träumereien
Da ich bereits seit Flash 4 kleine tile-based games entwickele, habe ich inzwischen genügend Erfahrungen gesammelt, die das Erschaffen einer ansehnlichen Spielwelt erlauben. Daher wurde es allmählich Zeit, ein, zwei Dinge zu finden, die in heute im Internet verfügbaren Flashspielen noch nicht oder nur schwach umgesetzt enthalten sind.
Ich stelle mir vor, dass zwei oder mehrere Spieler mit ihren Einheiten (welcher Art auch immer) durch meine Spielwelt laufen/fahren/schleichen/fliegen und einen Konflikt austragen, ohne die jeweils gegnerischen Einheiten ständig sehen zu können, wie es z.B. beim Schach möglich ist. Eher in Richtung Stratego, wo zwar die Einheiten sichtbar sind, aber nicht deren Rang. Um ehrlich zu sein, will ich eines Tages auf ein Niveau von Fallout Tactics hinaus. Ja, ich weiß - ich hab’ ‘nen Vogel, aber träumen werde ich wohl noch dürfen. Auf dem Weg zu diesem (zumindest mit Flash) unerreichbaren Ziel fällt sicher das eine oder andere markttaugliche Produkt ab. Da bin ich mir sicher.

Sichtlinie
Zurück zur LOS. Kurz die Problembeschreibung:
In einem 2D-Raster gibt es einerseits freie Flächen (Felder) und auf der anderen Seite für Spielfiguren undurchsichtige, undurchdringliche Hindernisse, wie z.B. Wände. Die Aufgabe, die gelöst werden soll, lautet, “besteht zwischen zwei gegebenen Feldern in diesem Raster eine Sichtlinie?”
Der Einfachheit halber wird festgelegt, dass die Sichtlinie blockiert ist, wenn sich auf dem Weg zwischen dem Start- und dem Zielfeld auch nur ein einziges Wand-Feld befindet.
Zur Ermittlung der LOS werden die Mittelpunkte der beiden Felder verbunden mit der vermeintlichen Sichtlinie.

Handarbeit statt Mathematik
Da mir keine mathematische Formel einfallen will, mittels derer ich herausfinden kann, welche Felder bei einer beliebigen Start-/Zielfeld-Paarung auf Vorhandensein einer Wand kontrolliert werden müssen, nehme ich diese Überprüfungen manuell vor und speichere diese Werte in Arrays. Die in Abb. 1 rot gekennzeichneten Felder müssten bei der Ermittlung der LOS auf Vorhandensein einer Wand geprüft werden.

Abb. 1: “Sehstrahl” (Anm. “LOT” ist falsch; “LOS” ist gemeint)

Mir geht es bei dieser manuellen Lösung darum, die Werte, die ich durch viel Handarbeit erhalten werde, möglichst unabhängig von der späteren Beschaffenheit des Rasters einsetzen zu können. Daher bilde ich im ersten Schritt so genannte Delta-Werte, die die aktuelle “Prüfsituation” beschreiben sollen.
Das Startfeld liegt bei (3,3), das Zielfeld bei (0,0), daher notiere ich als varDeltaX eine -3 (0 minus 3 gleich -3) und als varDeltaY ebenfalls eine -3.
Es mag bei allem, was ich hier beschreibe, sehr viel elegantere Wege geben. Da meine Kenntnisse auf dem Gebiet der OOP (Objekt Orientierte Programmierung) allerdings begrenzt sind, nehme ich das, was mir vertraut ist. In diesem Fall eine Kombination aus Variablen, Funktionen und Arrays. Am Ende soll eine Funktion entstehen, die aus Start- und Zielfeldkoordinaten einen Wert zurückgibt, der aussagt, ob LOS besteht oder nicht.

Das Array arDeltas…
Für meinen nächsten Schritt gebe ich jedem Feld meines Rasters noch eine eindeutige Nummer (Abb. 2).


Abb. 2: Durchnummerierte Felder

In einem Array arDeltas speichere ich nun zunächst die folgenden Werte:
-3, -3, 1. Warum das? Das sind die drei Werte, die die “Prüfsituation” beschreiben, wie sie in der Abbildung zu sehen ist; varDeltaX, varDeltaY und die zugehörige Feldnummer. Die fertige Funktion soll später erst im Array arDeltas nachschauen, welche Feldnummer bei der gerade aktuellen “Prüfsituation” zum tragen kommt.

…und die Arrays arDelta1 bis arDeltan
Dann, in einem weiteren Array, dessen Name etwa arDelta1 lautet, wird gezielt nachgeschaut, welche Felder auf Hindernisse geprüft werden müssen. Bei arDeltas und der Durchnummerierung des Rasters handelt es sich also lediglich um einen nötigen Umweg, da ich in Flash nicht direkt schreiben kann delta_-3_-3 = …; Dies führte zu einem Syntaxfehler.
Wie auch immer. In arDelta1 notiere ich jetzt tatsächlich die Delta-Werte der zwei oben rot gekennzeichneten Felder, so dass ich erhalte…
// arDeltas = new Array (-3,-3,1);
arDelta1 = new Array (-1,-1,-2,-2);

Der große Zusammenhang
Die fertige Funktion bekommt ja später die X- und Y-Koordinaten des Start- und Zielfeldes übergeben, zwischen denen auf Vorhandensein einer LOS geprüft werden soll, also wie im Beispiel oben…
function LOS (3,3,0,0) {
…
}

Daraus ermittelt die Funktion LOS dann die zwei Abstände oder Delta-Werte varDeltaX = -3 und varDeltaY = -3.

Diese Werte werden in arDeltas gesucht und die damit verknüpfte Feldnummer 1 gefunden.

Daraufhin werden in genau einem weiteren Array, nämlich hier arDelta1, die Delta-Werte gefunden, die relativ zur aktuellen infrage kommenden Spielfigurposition geprüft werden müssen, hier also |-1, -1| und |-2,-2|.

Die Funktion prüft daraufhin effektiv die zwei Felder 2,2 (denn 3,3 als Startfeld mit Delta |-1,-1| bearbeitet führt zu Feld 2,2) und 1,1…

[codestart]if (feld2,2 == “wand” or feld1,1 == “wand”) {
// dann keine LOS gegeben!
}[codeend]

So etwas in der Art jedenfalls.

Nun ist der oben abgebildete Fall einer der einfachsten. Wenn alle “Prüfsituationen” so überschaubar wären, bräuchte ich nicht auf eine handgemachte LOT ausweichen. Sind sie aber nicht, wie Abb. 3 zeigen soll. Dort ist zu erkennen, dass der “Sehstrahl” vom Start zum Ziel mehrere Felder kreuzt, schneidet oder durchläuft, die alle auf Vorhandensein einer LOS behindernden Wand geprüft werden müssten.


Abb. 3: Kompliziertere “Prüfsituation”

Wie man sich denken kann, ist das Linienziehen und Array-Füllen einige Arbeit, um wenigstens eine halbwegs brauchbare LOT für Sichtweiten bis 5 Felder zu erhalten. Aus diesem Grund erstellte ich mir per Flash, PHP und lokalem Webserver eine kleine Hilfsapplikation, mit der das ganze Unterfangen schon einfacher und fast schon unterhaltsam wurde (einfache Gemüter sind leicht zu erfreuen).
Diese Applikation ergab dann ein arDeltas-Array mit 1323 Elementen und 441 arDeltaX-Arrays, die für Sichtweiten bis 10 Felder und entsprechende LOS-Ermittlungen ausreichen dürften. Klar, dieselbe Arbeit würde ich mir erneut machen müssen, wenn ich größere Sichtweiten zulassen wollte. Aber fürs erste reicht das.

Mein Plan für heute ist es, die fertige Funktion einzusetzen in einem “Spiel”, wo der Spieler lediglich durch einen Irrgarten rennen kann. Vor Spielbeginn hat der Computer eine Handvoll Felder des Irrgartens mit “Gegnern” besetzt, per Zufall verteilt. Die Positionen dieser “Gegner” sind dem Spieler verborgen.
Immer wenn die Spielfigur ein neues Feld betritt, wird die LOS-Funktion abgefeuert und geprüft, ob die Spielfigur in den Sichtbereich einer der “Gegner” geraten ist. In dem Fall wird der “Gegner” sichtbar.
Das soll’s auch schon sein - ich habe die Angewohnheit, beim Programmieren nur kleine Schritte zu unternehmen. Danach sehen wir weiter.