Dreieckiges Koordinatensystem

  • Vielleicht übersehe ich etwas, aber in meinem Kopf ist es gerade schrecklich einfach.

    Warum nimmst du nicht ein normales quadratische Koordinatensystem und bildest es über nested Arrays ab. Dort kannst du die Spielfelder drin ablegen und mit ihnen ein Typ und die Koordinaten. Nun könntest du einfach Bereiche über den Typ als außerhalb des Spielfeldes definieren (also weiß, schwarz, void). Alles weitere sind dann Muster wie sich die Spielsteine bewegen dürfen:
    links: gleiche y-Koordinate; x-Koordinate - Anzahl Schritte
    rechts: gleiche y-Koordinate; x-Koordinate + Anzahl Schritte
    schräg hoch: y+Schritte/2; x+Schritte/2

    usw.
  • lucia schrieb:

    Die Felder deines Spielfeldes adressierst Du wie folgt: x Reihen mit jeweils y Feldern. y ist ungerade. Es gilt, dass y für jede nächste Reihe (x+1) um 2 Felder kleiner wird. Alle ungeraden y sind Dreiecke mit Spitze nach oben, alle geraden y sind Dreiecke mit Spitze nach unten.
    Das hatten wir da schon: Dreieckiges Koordinatensystem

    Siehe Anhang.

    lucia schrieb:

    Deine 6 Bewegungen kannst du auf 3 Achsen durchführen. Ich beschränke mich mal daher nur auf 3 Richtungen, die anderen 3 ergeben sich dann von selbst.

    1) Die erste ist die einfachste: x verändert sich nicht, y erhöht sich (oder erniedrigt sich) pro Schritt um 1.
    2) Die zweite ist etwas komplizierter. Es gibt 2 Fälle
    2a) Beginnst Du auf einem Dreieck mit Spitze nach oben, geht es: x+0/y+1, x+1/y-1, x+0/y+1, ... usw.
    2b) Beginnst Du auf einem Dreieck mit Spitze nach unten, geht es x+1/y-1, x+0/y+1, ... usw.
    Entsprechend, wenn Du auf der gleichen Achse in die andere Richtung gehst.
    3) Die dritte Bewegung ist eigentlich wie die 2., nur umgedreht für die Spitzen nach oben oder unten. Und wieder entsprechend für die andere Richtung.
    Du siehst an dem Beispiel auch, wo es schon beim Konzept hakt: Bereits für diesen einfachsten Zugtyp, braucht man 4-5 bedingte Schritte um die Regel umzusetzen. Und wenn es Anfängt kompliziert zu werden? Das Konzept führt unweigerlich zu Code smell.

    lucia schrieb:

    Natürlich musst Du immer überprüfen, ob Du nicht an den Rand des Spielfeldes stösst.
    Und auch die zulässige Reichweite, Kollisionen mit anderen Figuren, etc. - Meinem Neffen hab ich den groben Gesamtablauf bereits skizziert.
    Bilder
    • Raster 2.png

      63,49 kB, 552×446, 18 mal angesehen
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von NSObject ()

  • manoh schrieb:

    Bei der Umsetzung in SpriteKit, SceneKit oder Unity3D brauchst Du kein
    No SpriteKit Co. Der realisiert das im Browser mit HTML5 und JavaScript. Der hat auch keinen Mac.

    manoh schrieb:

    NSObject schrieb:

    Das ist ein plattes 2D Brettspiel. Draufsicht. Kein 3D.
    Ich habe nicht 2D oder 3D gemeint. Sondern es gibt drei Achsen: AxisA, AxisB, AxisC => es gibt drei Systeme: SystemA, SystemB, SystemC (1 -> [1], 2 -> [1,2,3], 3 -> [1,2,3,4,5]).
    Du meinst entlang der Seiten? So?

    manoh schrieb:

    Die Position eines Dreiecks Triangle1 ist im SystemA 1/1, im SystemB 3,1 und im SystemC 3,5. Wenn man sich jetzt auf der Achse AxisB (...)

    Vllt. sind jetzt meine zwei Ansätze etwas anschaulicher.
    Sorry. Ich habe gerade keine Ahnung, wo bei Dir 1,1 und gleichzeitig 3,5 ist.

    Kannst Du das mal dort reinschreiben. Die Koordinaten, Werte, den Start- und den Endpunkt.
    Bilder
    • Raster leer.png

      22,7 kB, 453×395, 12 mal angesehen
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NSObject ()

  • ioscampus schrieb:

    Vielleicht übersehe ich etwas, aber in meinem Kopf ist es gerade schrecklich einfach.
    Ich hätte vielleicht kein einfaches Beispiel nehmen sollen.

    ioscampus schrieb:

    Warum nimmst du nicht ein normales quadratische Koordinatensystem und bildest es über nested Arrays ab. Dort kannst du die Spielfelder drin ablegen und mit ihnen ein Typ und die Koordinaten. Nun könntest du einfach Bereiche über den Typ als außerhalb des Spielfeldes definieren (also weiß, schwarz, void).
    Gib mal ein konkretes Beispiel, wie Du das Quadrat auf dem Dreieck abbildest.
    Und wie die Züge einfach und eindeutig definiert sein könnten.

    ioscampus schrieb:

    Alles weitere sind dann Muster wie sich die Spielsteine bewegen dürfen:

    links: gleiche y-Koordinate; x-Koordinate - Anzahl Schritte
    rechts: gleiche y-Koordinate; x-Koordinate + Anzahl Schritte
    schräg hoch: y+Schritte/2; x+Schritte/2
    Da musst Du noch berücksichtigen, ob der erste Zug Freiheiten nach oben oder unten hat. Schlimmer: Wie definierst Du damit eine Figur, die z.B. nur rechtsherum schlagen darf? ;)
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von NSObject ()

  • NSObject schrieb:

    No SpriteKit Co. Der realisiert das im Browser mit HTML5 und JavaScript. Der hat auch keinen Mac.
    Wobei Unity3D auch unter Windows läuft und auch ein Webspiel erstllen kann. Man programmiert in C# und es gibt 'ne Menge an Tutorials (auch Deutsch), Bücher und Videos.


    NSObject schrieb:

    Du meinst entlang der Seiten? So?
    Keine Ahnung? Meinte ich das so? Jedenfalls ich kenn's nicht und hab's nur kurz überflogen.


    NSObject schrieb:

    Sorry. Ich habe gerade keine Ahnung, wo bei Dir 1,1 und gleichzeitig 3,5 ist.

    Kannst Du das mal dort reinschreiben. Die Koordinaten, Werte, den Start- und den Endpunkt.
    Ich habe schnell was gezeichnet. Oben links, oben rechts und unten links sind Jeweils die drei Systeme A, B und C zu sehen. Sowie der selber Punkt und die Lage in dem jeweiligen System. Unten rechts bewege ich dann einen Punkt im System B (oder auf der B-Achse, wie ich das genannt habe). Jedenfalls ist eine Bewegung immer waagrecht, jedenfalls wenn man sich gedanklich das Dreieck dreht. Wie man allerdings die drei System transformiert, bzw. einen einfachen Lookup macht, dazu habe ich mir noch keinen Gedanken gemacht.


  • Interessante Aufgabenstellung. Ich habe auch mal ein bißchen 'rumexperimentiert'. Mit einfachen Koordinaten läßt sich das eigentlich ganz gut lösen.

    Die horizontalen Reihen seien die A-Reihen, die von der rechten Schräge nach unten führenden die B-Reihen und die von unten zur linken Schräge laufenden die C-Reihen. Damit hat jedes dreieckige Spielfeld auf dem Brett ein Dreiertuple als Koordinaten (A, B, C). Wenn man die Reihen mit 0 beginnend hochzählt, haben auf einem 4x4x4 großem Brett die Ecken folgende Koordinaten:

    Unten links: (0,0,0)
    Oben Spitze: (3,0,3)
    Unten rechts: (0,3,3)

    Jedes Feld hat links und rechts einen Nachbarn, sowie einen oben oder unten anhängig davon ob das Feld auf dem Kopf steht oder die Spitze nach oben zeigt.
    Mir ist aufgefallen, daß, wenn die Summe aller Koordinatenpunkte ungerade ist, das Feld auf dem Kopf steht; ist die Summe gerade, dann zeigt die Spitze nach oben. Dadurch lassen sich die Koordinaten der Nachbarn für ein gegebenes Feld (A, B, C) leicht berechnen:

    A) Nachbar rechts (A-Reihe)

    - Summe der Koordinatenpunkte gerade (Spitze nach oben) -> (A, B, C + 1)
    - Summe der Koordinatenpunkte ungerade (Spitze nach unten) -> (A, B + 1, C)

    B) Nachbar links (A-Reihe)

    - Summe der Koordinatenpunkte gerade (Spitze nach oben) -> (A, B - 1, C)
    - Summe der Koordinatenpunkte ungerade (Spitze nach unten) -> (A, B, C - 1)

    C) Nachbar vertikal

    - Summe der Koordinatenpunkte gerade (Spitze nach oben) -> (A - 1, B, C)
    - Summe der Koordinatenpunkte ungerade (Spitze nach unten) -> (A + 1, B, C)

    Ganze Linien kann man dann durch rekursives berechnen der Nachbarn erhalten.

    Die "Beschreibung der Spielzüge" für z.B. '3 Züge nach oben rechts' würde dann heißen: 3 mal rekursiv die Nachbarn mit gleicher B-Reihe und aufsteigender A-Reihe.

    Die Berechnung der Nachbarn habe ich in Swift mal ausformuliert.

    Quellcode

    1. struct Triangle: CustomStringConvertible {
    2. let a: Int
    3. let b: Int
    4. let c: Int
    5. init(_ a: Int,_ b: Int,_ c: Int) {
    6. self.a = a
    7. self.b = b
    8. self.c = c
    9. }
    10. var description: String {
    11. return "(\(a),\(b),\(c))"
    12. }
    13. var isUpsideDown: Bool {
    14. return (a + b + c) % 2 == 0 ? false: true
    15. }
    16. var neighbours: (left: Triangle, right: Triangle, vertical: Triangle) {
    17. return isUpsideDown ?
    18. (Triangle(a, b, c - 1), Triangle(a, b + 1, c), Triangle(a + 1, b, c)) :
    19. (Triangle(a, b - 1, c), Triangle(a, b, c + 1), Triangle(a - 1, b, c))
    20. }
    21. }
    Alles anzeigen
    Edit: Die Logik im Code war doppelt vertauscht...
    Twix heißt jetzt Raider!

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von torquato ()

  • manoh schrieb:

    Oben links, oben rechts und unten links sind Jeweils die drei Systeme A, B und C zu sehen. Sowie der selber Punkt und die Lage in dem jeweiligen System. Unten rechts bewege ich dann einen Punkt im System B (oder auf der B-Achse, wie ich das genannt habe). Jedenfalls ist eine Bewegung immer waagrecht, jedenfalls wenn man sich gedanklich das Dreieck dreht.
    Wo ist da die Vereinfachung? Dann muss man doch dann mit 3 Tupeln hantieren. Das Model sollte eher einfacher werden.

    manoh schrieb:

    Wie man allerdings die drei System transformiert, bzw. einen einfachen Lookup macht, dazu habe ich mir noch keinen Gedanken gemacht.
    Das wäre möglicherweise der interessante Teil gewesen.
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NSObject ()

  • NSObject schrieb:

    ioscampus schrieb:

    Warum nimmst du nicht ein normales quadratische Koordinatensystem und bildest es über nested Arrays ab. Dort kannst du die Spielfelder drin ablegen und mit ihnen ein Typ und die Koordinaten. Nun könntest du einfach Bereiche über den Typ als außerhalb des Spielfeldes definieren (also weiß, schwarz, void).
    Gib mal ein konkretes Beispiel, wie Du das Quadrat auf dem Dreieck abbildest.Und wie die Züge einfach und eindeutig definiert sein könnten.

    Ich habe die Skizze hier mal beigefügt. Ich denke das ist recht verständlich. Die möglichen Züge müssten so auch recht einfach beschreibbar sein. Du brauchst halt je ein Muster für schwarz und weiß.

    Bilder
    • Koordinaten.jpg

      52,06 kB, 720×540, 17 mal angesehen
  • torquato schrieb:

    Die horizontalen Reihen seien die A-Reihen, die von der rechten Schräge nach unten führenden die B-Reihen und die von unten zur linken Schräge laufenden die C-Reihen. Damit hat jedes dreieckige Spielfeld auf dem Brett ein Dreiertuple als Koordinaten (A, B, C). Wenn man die Reihen mit 0 beginnend hochzählt, haben auf einem 4x4x4 großem Brett die Ecken folgende Koordinaten:

    Unten links: (0,0,0)
    Oben Spitze: (3,0,3)
    Unten rechts: (0,3,3)
    Das sind klassisch wieder bartzentrischen Koordinaten,...

    ...aber nur die Knoten und nicht die Flächen.

    torquato schrieb:

    Jedes Feld hat links und rechts einen Nachbarn, sowie einen oben oder unten anhängig davon ob das Feld auf dem Kopf steht oder die Spitze nach oben zeigt.
    Mir ist aufgefallen, daß, wenn die Summe aller Koordinatenpunkte ungerade ist, das Feld auf dem Kopf steht; ist die Summe gerade, dann zeigt die Spitze nach oben. Dadurch lassen sich die Koordinaten der Nachbarn für ein gegebenes Feld (A, B, C) leicht berechnen:

    A) Nachbar rechts (A-Reihe)

    - Summe der Koordinatenpunkte gerade (Spitze nach oben) -> (A, B, C + 1)
    - Summe der Koordinatenpunkte ungerade (Spitze nach unten) -> (A, B + 1, C)

    B) Nachbar links (A-Reihe)

    - Summe der Koordinatenpunkte gerade (Spitze nach oben) -> (A, B - 1, C)
    - Summe der Koordinatenpunkte ungerade (Spitze nach unten) -> (A, B, C - 1)

    C) Nachbar vertikal

    - Summe der Koordinatenpunkte gerade (Spitze nach oben) -> (A - 1, B, C)
    - Summe der Koordinatenpunkte ungerade (Spitze nach unten) -> (A + 1, B, C)

    Ganze Linien kann man dann durch rekursives berechnen der Nachbarn erhalten.

    Die "Beschreibung der Spielzüge" für z.B. '3 Züge nach oben rechts' würde dann heißen: 3 mal rekursiv die Nachbarn mit gleicher B-Reihe und aufsteigender A-Reihe.
    Oh Mensch. Stimmt! Die Flächen brauchen wir für das Modell ja gar nicht. *Facepalm*

    Ich war fest der Meinung, in dem Fall (Bartzentrisch) braucht er immer alle 3 Tripel, um das Dreieck zu beschreiben, damit er auch immer die Richtung der Ecken hat, über die er nicht ziehen darf. – Aber das ist ja Quark!

    ...Wenn einer besoffen und einer übermüdet ist. :S

    torquato schrieb:

    Die Berechnung der Nachbarn habe ich in Swift mal ausformuliert.

    Quellcode

    1. struct Triangle: CustomStringConvertible {
    2. let a: Int
    3. let b: Int
    4. let c: Int
    5. init(_ a: Int,_ b: Int,_ c: Int) {
    6. self.a = a
    7. self.b = b
    8. self.c = c
    9. }
    10. var description: String {
    11. return "(\(a),\(b),\(c))"
    12. }
    13. var isUpsideDown: Bool {
    14. return (a + b + c) % 2 == 0 ? false: true
    15. }
    16. var neighbours: (left: Triangle, right: Triangle, vertical: Triangle) {
    17. return isUpsideDown ?
    18. (Triangle(a, b, c - 1), Triangle(a, b + 1, c), Triangle(a + 1, b, c)) :
    19. (Triangle(a, b - 1, c), Triangle(a, b, c + 1), Triangle(a - 1, b, c))
    20. }
    21. }
    Alles anzeigen
    Edit: Die Logik im Code war doppelt vertauscht...

    torquato schrieb:

    Ich habe mit meinem Ansatz spaßeshalber nochmal weiter im Playground rumgespielt.
    Um die Felder für einen Spielzug über mehrere Felder zu erhalten, bedarf es gar keiner Rekursion.
    Ich hänge meine Spielerei soweit hier mal an.

    Sogar mit vollfunktionsfähigem Sample Code. Das ist ja herrlich. :)
    * Kann Spuren von Erdnüssen enthalten.
  • NSObject schrieb:

    torquato schrieb:

    Die horizontalen Reihen seien die A-Reihen, die von der rechten Schräge nach unten führenden die B-Reihen und die von unten zur linken Schräge laufenden die C-Reihen. Damit hat jedes dreieckige Spielfeld auf dem Brett ein Dreiertuple als Koordinaten (A, B, C). Wenn man die Reihen mit 0 beginnend hochzählt, haben auf einem 4x4x4 großem Brett die Ecken folgende Koordinaten:

    Unten links: (0,0,0)
    Oben Spitze: (3,0,3)
    Unten rechts: (0,3,3)
    Das sind klassisch wieder bartzentrischen Koordinaten,...
    ...aber nur die Knoten und nicht die Flächen.

    Also ich habe mir das schon als Fläche vorgestellt. Vielleicht besser 'Feld' wie beim Schachbrett. Da bilden die A-, B, C-, D-... Reihen und die 1-, 2-, 3-, 4-,... Reihen ja auch Flächen/Felder. Hier hat man halt drei Seiten und damit drei Reihen, die so ein Feld beschreiben.

    Mmmh... *schulterzuck* Vielleicht müßig...

    Hauptsache das Ergebnis funktioniert. ;)

    NSObject schrieb:

    Sogar mit vollfunktionsfähigem Sample Code. Das ist ja herrlich. :)

    Bitteschön. Hat Spaß gemacht, mich da selber dran zu versuchen. ^^
    Twix heißt jetzt Raider!
  • ioscampus schrieb:

    Ich habe die Skizze hier mal beigefügt. Ich denke das ist recht verständlich. Die möglichen Züge müssten so auch recht einfach beschreibbar sein.
    Wenn ich das richtig sehe, hatten wir das schon hier, da und dort. (+ die Skizze vom Neffen selbst) Der Punkt war u.a. die unübersichtlichen if-Wälder, die in dem Fall, schon bei einfachsten Bewegungen entstehen, zu vermeiden, daher hatten wir/er den Entwurf auch wieder verworfen.

    Aber beim Stöbern in Torquatos Code, ist mir da heute (wieder halbwegs wach und zurechnungsfähig) eine ganz andere Lösung gekommen, wo das Problem vermutlich kaum mehr ins Gewicht fällt.

    Anm.: Irgendwie erinnert mich deine Skizze an das Wildcard Symbol auf dem C64.

    ioscampus schrieb:

    Du brauchst halt je ein Muster für schwarz und weiß.

    Torquato und linqus hatten da den richtigen Impuls geliefert.
    * Kann Spuren von Erdnüssen enthalten.
  • torquato schrieb:

    NSObject schrieb:

    Das sind klassisch wieder bartzentrischen Koordinaten,......aber nur die Knoten und nicht die Flächen.
    Also ich habe mir das schon als Fläche vorgestellt. Vielleicht besser 'Feld' wie beim Schachbrett. Da bilden die A-, B, C-, D-... Reihen und die 1-, 2-, 3-, 4-,... Reihen ja auch Flächen/Felder. Hier hat man halt drei Seiten und damit drei Reihen, die so ein Feld beschreiben.
    Die Koordinate bezeichnet einen Knoten bzw. einen Punkt. Da befindet sich in unserem Fall aber eine Fläche. Wie beim Schach, beim Bildschirm, beim Drucker... etc.

    torquato schrieb:

    Mmmh... *schulterzuck* Vielleicht müßig...
    Hauptsache das Ergebnis funktioniert. ;)
    Es sollte auch halbwegs intelligent implementiert sein. Das wird evtl. benotet.
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von NSObject ()

  • NSObject schrieb:


    Aber beim Stöbern in Torquatos Code, ist mir da heute (wieder halbwegs wach und zurechnungsfähig) eine ganz andere Lösung gekommen, wo das Problem vermutlich kaum mehr ins Gewicht fällt.

    Ah. Also da bin ich jetzt gespannt, wie diese ganz andere Lösung aussieht. Da würde ich zu gerne die weiteren Schritte sehe, wenn's sein muß, auch auch off-thread.

    NSObject schrieb:


    Es sollte auch halbwegs intelligent implementiert sein. Das wird evtl. benotet.

    Ach, das sind Hausaufgaben. ;) Jetzt bin ich gespannt, was ich für eine Note bekomme. :D
    Twix heißt jetzt Raider!
  • torquato schrieb:

    NSObject schrieb:

    Aber beim Stöbern in Torquatos Code, ist mir da heute (wieder halbwegs wach und zurechnungsfähig) eine ganz andere Lösung gekommen, wo das Problem vermutlich kaum mehr ins Gewicht fällt.
    Ah. Also da bin ich jetzt gespannt, wie diese ganz andere Lösung aussieht. Da würde ich zu gerne die weiteren Schritte sehe, wenn's sein muß, auch auch off-thread.
    Die Idee ist, mit Mengen zu arbeiten. D.h alle Spielfelder stecken in einem Set. Die theoretisch zulässigen Offsets der Spielfigur stecken in einem weiteren Set. Mit Addition der Position der Spielfigur und deren Offset-Set, bekommt man ein Set der theoretisch zulässigen Reichweite. Die Schnittmenge beider Sets (Spielfelder und Reichweite) ergibt die tatsächlich zulässigen Züge. - Die Spielfeldgeometrie spielt keine Rolle mehr und auf Überschreitung des Spielfeldrandes muss auch nicht mehr geprüft werden.

    Das ist die Grundidee, aber das muss ich noch mal in Ruhe durchdenken.

    torquato schrieb:

    NSObject schrieb:

    Es sollte auch halbwegs intelligent implementiert sein. Das wird evtl. benotet.
    Ach, das sind Hausaufgaben. ;) Jetzt bin ich gespannt, was ich für eine Note bekomme. :D
    In seiner Abschlussprüfung gibt es einen "Wahlteil". Da kann er sich ein Projekt selbst ausdenken, realisieren und dokumentieren.

    Müsste ich wetten, würde ich vermuten, dass er es in der in der Art wie ioscampus umsetzt. Denn so war auch einer seiner ersten Entwürfe. Und ich vermute deine und meine Ansätze sind ihm etwas zu abstrakt.
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NSObject ()

  • NSObject schrieb:


    Die Idee ist, mit Mengen zu arbeiten. D.h alle Spielfelder stecken in einem Set. Die theoretisch zulässigen Offsets der Spielfigur stecken in einem weiteren Set. Mit Addition der Position der Spielfigur und deren Offset-Set, bekommt man ein Set der theoretisch zulässigen Reichweite. Die Schnittmenge beider Sets (Spielfelder und Reichweite) ergibt die tatsächlich zulässigen Züge. - Die Spielfeldgeometrie spielt keine Rolle mehr und auf Überschreitung des Spielfeldrandes muss auch nicht mehr geprüft werden.
    Das ist die Grundidee, aber das muss ich noch mal in Ruhe durchdenken.

    Mmhhh... Ich glaube, darüber muß ich auch noch mal in Ruhe grübeln.

    Beim ersten Lesen klang das ziemlich kompliziert, aber jetzt nach einer guten 1/2 Stunde... In meinem Code berechne ich für einen Spielstein jedesmal sukzessiv die Nachbarn. Dabei habe ich am Anfang das Board erstellt mit allen vorhanden Feldern. Eine Bewegung auf der B-Reihe z.B. tangiert nur die Felder mit gleichen B-Koordinaten des Brettes. Die kann man schnell aus dem Felder-Array des Boards rausfiltern. Das Ausgangsfeld ist auch in diesem Array enthalten. Die Offsets ergeben sich dann aus der Position des Ausgangsfeldes in diesem gefilterten Reihen-Array....

    Mmhh... Ich glaube mit dem Gedanken werde ich auch noch mal ein bißchen rumspielen...

    Auf Überschreitung des Spielfeldrandes muß dann nicht mehr geprüft werden, aber eine Game-Controller-Instanz muß immer noch prüfen, ob da nicht andere Hindernisse, je nach Spielregeln, im Weg stehen.
    Twix heißt jetzt Raider!
  • Bildet man die Schnittmenge aus dem theor. Zugbereich der eigenen Figur und allen gegnerischen Figuren, erhält man die schlagbaren Figuren. Oder zieht man vom Zugbereich seiner Figur ein Set aller eigenen Figuren ab, bleibt die Menge der nicht blockierten Felder übrig. Ich denke stetig drüber nach, wie sich möglichst viel derart lösen lässt.

    Ich bin mir sicher, dass sich nicht die komplette Logik mit Set-Operationen abbilden lässt. Aber es erfreut mich, wie viel, mit so wenigen Operationen möglich ist.
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NSObject ()

  • wolf_10de schrieb:

    Vielleicht hilft das (ich kenne es noch aus der guten alten Zeit ;-):
    Dich kenne ich auch noch aus der guten alten Zeit. :)

    Wolfgang! Alter!

    wolf_10de schrieb:

    Lege mal gedanklich ein quadratisches Raster darüber (Stichwort tile-based).
    Ein Quadrat ist dann entweder "walkable" oder nicht.

    Nur so als Idee...
    Mit diesem Modell hat er (wie ich vermutete) auch angefangen es zu realisieren.

    Wenn ich mal Zeit finde, will ich einen Prototyp mit meinem Modell machen.
    * Kann Spuren von Erdnüssen enthalten.