Spielherstellung

[Hirnsausen]

Hallo!

Ich will ein "Brettspiel" herstellen, welches aus sechseckigen Feldern bestehen soll.

Wie kann ich ein Spielfeld aus interaktiven Sechsecken(Objekten?) erstellen?

[mbamler]

Zitat von Hirnsausen:

Hallo!

Ich will ein "Brettspiel" herstellen, welches aus sechseckigen Feldern bestehen soll.

Wie kann ich ein Spielfeld aus interaktiven Sechsecken(Objekten?) erstellen?

Hmmm ... gar nicht mal so unknifflig ...

Ich würde ein array von Objekten generieren, die unter anderem 6 "NachbarZeiger" haben,
über die du dann auf die Nachbarfelder zugreifen kannst

Delphi-Quellcode:

TFeld = object .....
begin
 .... //irgednwelche Eingenschaften und Methoden

  Nachbar1 : TFeld;
  Nachbar2 : TFeld;
  Nachbar3 : TFeld;
  Nachbar4 : TFeld;
  Nachbar5 : TFeld;
  Nachbar6 : TFeld;

 ....
end;

hat ein Feld in einer bestimmten Richtung kein Nachbar ist der Wert nil
ansonsten zeigt er eben auf das Object, das sein entsprechender Nachbar ist.

Pfadfindungsalgorithmen und Kürzeste-Wege-Berechnungen müssen entsprechend angepasst sein ...

Gruß
Matthias

[SirThornberry]

das einfachste wäre wohl von TCustomControl abzuleiten und im SetBounds mit CreatePolygonRgn die sechseckige Form setzen
Je nach Muster zum Beispiel so

Delphi-Quellcode:

procedure TMyComp.SetBounds(ALeft, ATop, AWidth, AHeight: Integer);
var
  HR  : Cardinal;
  lPoints: Array[0..5] of TPoint;
  lWidth: Integer;
begin
  lWidth := AWidth div 4;
  lPoints[0] := Point(lWidth, 0);
  lPoints[1] := Point(AWidth - lWidth, 0);
  lPoints[2] := Point(AWidth - 1, AHeight div 2);
  lPoints[3] := Point(AWidth - lWidth, AHeight - 1);
  lPoints[4] := Point(lWidth, AHeight - 1);
  lPoints[5] := Point(0, AHeight div 2);
  HR:= CreatePolygonRgn(lPoints, 6, ALTERNATE);
  SetWindowRgn(Handle, HR, True);

  DeleteObject(HR);
  inherited;
end;

[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

[Sidorion]

Man kann ein Hexfeld auch intern als 2Dim-Array darstellen. Beim Zeichnen versetzt man dann jede 2. Zeile um ein halbes Feld nach rechts.
Die Nachbarn eines jeden Feldes ergeben sich dann wie folgt:
1. links oben: x-1+(y and 1);y-1
2. rechts oben: x+(y and 1);y-1
3. links: x-1;y
4. rechts: x+1;y
5. links unten: x-1+(y and 1);y+1
6. rechts unten: x+(y and 1);y+1
wobei x und y die koordinaten des aktiven Feldes sind.

[Hirnsausen]

Hi.

Ich muß erst mal alles nachvollziehen, bitte gebt mir etwas Zeit. Aber schon jetzt vielen Dank an MBamler, Sir Thornberry, NegaH und Sidorion für Eure sehr guten Antworten!

[Hirnsausen]

Hmmm...... Ich denke, was sehr nützlich wäre, ist eine Unit, die ein Spielfeld darstellt. Voll konfigurierbar. Zum Beispiel, ob sie sechseckig ist, rechteckig oder quadratisch. Und ob und in welcher Farbe die Umgrenzung gezeichnet wird, wie dick. Und ob das Feld-Innere ansonsten transparent ist (zum Beispiel wenn über Bildern platziert), oder ein eigenes Bild hat, ein Icon oder eine Farbe.

Weitere Eigenheiten dieser Unit wären Interaktionen mit benachbarten oder als Ziel angegebenen Spielfeldern, der Status Besetzt (0 oder die Menge der besetzenden Einheiten), Farb-Änderungen, Blink-Modus, Wegepunkte (die das Überqueren oder Besetzen dieses Spielfeldes verbraucht), und so weiter. Auch ein "Strecken"-Modus wäre gut, das heißt, ein dicker Balken, der sich von einer der vier oder sechs Seiten in die Mitte oder zu einer anderen der vier oder sechs Seiten hinzieht (gerade oder abgeknickt). Auch diese Strecke sollte konfigurierbar sein: Semi-transparent oder deckend, Farbe, Blink-Modus, und so weiter.

Ich habe leider noch nie selbst eine Klasse erstellt, geschweige denn eine Unit. Ich würde schon sehr, sehr gerne so etwas erstellen. Aber ich kann es leider nicht.

Wichtig wäre dann auch noch eine Routine, die einen Untergrund automatisch oder bei Aufruf mit diesen Spielfeldern überzieht. Und eine Methode, um einzelne Felder, oder bestimmte Gruppen, anzusprechen.