Spielherstellung

[negaH]

Zu DOS Zeiten habe ich ein Spiel programmiert das auch mit 6'ecken als Map gearbeitet hat.

Dein Konzept wie du dein Spielfeld im Source umsetzt wird primär bestimmt durch die logsiche Verknpfung der 6'Ecke untereinander. Also je nachdem ob deine 6'eckigen Spielbereich untereinander eine Beziehung haben, welcher Art diese ist, usw. musst du deinen Source konzeptionieren.

An Hand meines damaligen Spiels möchte ich dies erklären.

Spieldfeld ist ein großes grafisches 6'Eck unterteilt in viele kleinere 6'Ecke. Exakt im Mitelpunkt dieses Spielbrettes gab es ebenfalls ein 6'Eck damit die Anzahl aller kleinen 6'Ecke aus denen sich das Board zusamenstze ungerade war.
Jedes dieser 6'Ecke konnte eine bestimmte Farbe aus einer rotierenden Palette annehmen, das war konfigurierbar und bestimmt auch die Spielstärke des Rechners, eg. Komplexität des Spieles. Angenommen wir spielen mit den Farben Rot->Grün->Blau also 3 Farben. Der Spieler kann nun die Farbe eines 6'Ecks verändern indem er darauf klickte. Aus einem roten 6'Eck wurde so ein grünes, aus einem grünen ein blaues und aus einem blauen wieder ein rotes, also immer Reihum. Das "Gemeine" dabei war aber das auch alle zu diesem 6'Eck angrenzenden 6'Ecke ebenfalls ihre Farbe änderten. Dies ist die logische Abhängigkeit zwischen den 6'Ecken des Boards. In diesem Falle musste also jedes 6'Eck mit seinen 6 Nachbar-6'Ecken verknüpft sein, per Zeiger in meinem Falle. Das Board wurde als 6 dimensionale verlinkter Baum organisiert wobei das 6'Eck das exakt in der Mitte des gesamten Board liegt (auf dem Bildschirm) als Root dieses Baumes benutzt wurde. Auf Grund dessen und dem Fakt das jedes 6'Eck auch seine grafische Position auf dem Board kennt, konnte ich dann während der Spieles sehr einfach von einer Pixel-Koordinate das darunter befindliche 6'Eck ermitteln.

Am Anfang des Spieles sind alle 6'Ecken des Boards in einer Farbe eingefärbt, zb. Rot. Der Computer vermischte nun das Board per Zufall. Dies erfolgt nach der Regel

1.) immer rotierend in der Farbpalette des Spieles (zb. rot->grün->blau->rot->....)
2.) alle Nachbarn eines 6'Eckes das in der Farbe geändert wurde müssen ebenfalls ihre Farbe ändern, aber nicht deren Nachbarn !

Die Aufgabe des Spielers ist es nun seinerseits dieses Vermischen des Computers wieder rückgngig zu machen, also alle 6'Ecken des Boards wieder in einer Farbe zu bekommen.

Auf Grund der Logik im Spiel war das beste Konzept der Datenstrukturen ein Baum aus 6'Eck-Objekten. Alle Objekte selber wurden einzeln und sortiert in einer Liste (verlinkte Liste) erzeugt. Dabei wurde die Verlinkung mit ihren 6 möglichen Nachbarn ebenfalls als Verlinkung per Zeiger in diesen 6'Eck-Objekten erzeugt. Bei 6'Eck-Objekten die am Rand des Spielfeldes lagen konnten einige dieser Verlinkung natürlich nil sein. Allerdings hatte ich auch eine Variante die quasi eine Sphäre darstellten indem diese NIL Zeiger auf die 6'Ecke am gegenüberliegenden Boardrand lagen verknüft wurden.

Das zentral in der Mitte gelegene 6'Eck wurde als Root in einem separatem Zeiger gespeichert. Ausgehend von diesem 6'eck und dem Fakt das es im Board exakt auf dem Mittepunkt liegt konnte die Zeichenroutine programiert werden. Diese hangelt sich ausgehend von der Root bis zu den Rand-Ecken vor.

Das Gleiche bei den Interaktionen. Wurde auf das Board mit der Maus geklickt so konnt man ausgehend von Root und dessen 6 Verlinkungen in die 6 Himmelsrichtungen das Eck ermittelt werden das seine Farbe wechseln musste. Dessen und die Farben der angrenzenden Ecken wurde daraufhin um 1 weiter rotiert.

Also ein sehr simples Spiel, denoch interessant, und ich habe es programmiert um zu lernen wie man mit mehrdimensionalen Bäumen und der grafischen Visualisierung solcher Spielfelder umgeht.




Gruß Hagen