Spielablauf

[Smeagle]

to be defined

[murchandamus]

Entwurf:

• Brett wird eingelesen
• Wachen werden gesetzt
• Spielfigur spawnt
• while (Spielfigur.position != exit && Spielfigur.isAlive() == true) { Spielerzug; Wachenzug; }

[Smeagle]

Wegen den Benutzereingaben... wie stellst du dir das vor? Soll ich direkt Methoden der Agenten aufrufen wie z.B. step(Direction d)? Lass uns mal zusammen das Beispiel "spähen" (oder wie man das dann nennt) überlegen. Das ist eine Aktion, die ein Spieler später ausführen können soll. Dabei wählt er ein benachbartes Feld und sieht dann (für eine gewisse Zeit? bis er die Sicht abbricht?) das Sichtfeld, als stünde er auf dem Feld. Aber die Gegner sehen ihn nicht...

• Vom Ablauf her wählt der Spieler also diese Aktion (wie auch immer).
• Dann muss er ein benachbartes Feld selektieren.
• Dann befindet sich das Spiel im "Spähen-Modus" bis der Modus abgebrochen wird.
• Dann ist die Aktion beendet.

Was man hier schon herauslesen kann:

• Es gibt wahrscheinlich eine Art startPeek()-Methode für den Player.
• Das versetzt die GUI in einen speziellen Selektier-Modus (mit Einschränkung auf benachbarte Felder...)
• Der Player hat wahrscheinlich auch eine Art onSelect()-Methode, die dann abhängig vom Zustand des Players das entsprechende macht. Wie z.B. die Peek-Aktion fortzufahren. ...

Hast du da Ideen?

[Smeagle]

Irgendwie denke ich, dass der Player, abhängig von seinem Zustand irgendwie der GUI sagen können muss, welche Aktionen gerade durchführbar sind (Spähen, Feld selektieren, Spähen abbrechen). Die GUI stellt dann die Eingabemöglichkeit dazu bereit (registriert Tastaturtasten, malt Knöpfe, schränkt die Selektionsmöglichkeit ein, ...). Wenn die entsprechende Eingabe passiert, gibt es eine Art "Callback" zum Player.

Wäre cool wenn wir das so Framework-artig hinbekämen.

[murchandamus]

An viele dieser Dinge habe ich schon gedacht. Können wir vielleihct mal skypen oder so? ;)

[murchandamus]

Sonst würde ich jetzt anfangen, alle deine Punkte zu beantworten. ;)

[Smeagle]

Ja, lass uns demnächst mal skypen oder treffen etc. ^^

[murchandamus]

Spielablauf, wie ich ihn mir bisher vorgestellt habe:

Vor dem Spiel

In der MVP wohl erst mal mit einem Spieler und nur einem Brett, so lange startet das Spiel wohl einfach direkt ins Level. Später kann man das natürlich noch aufbohren.

• [ ] Anzahl Spieler werden festgelegt (später)?
• [ ] Spielerfiguren werden gewählt (später)?
• [ ] Level wird gewählt (später)?

Spielvorbereitung

Es wird vorerst die Karte eingelesen, die Wachen gesetzt und die Spielerfigur gesetzt.

• [x] Brett wird generiert: GameBoardUtils.java
• [x] Wachen Guard extends Agent werden dem Spielbrett hinzugefügt
• [x] Spielerfiguren Player extends Agent [werden dem Spielbrett hinzugefügt](https://github.com/Smeagle%28später%29 /dungeongame/pull/19/commits/832cf8f480ffe77350b0907987a3d2f531ce1f89#diff-4a7ae3181754b6fc5788ac4b65895a4dR46)
  • Dabei werden die Spieler in zufälliger Reihenfolge vorne in die Spielsteineliste geschoben werden.

Spiel

Gameboard hat wie angedeutet eine Liste aller Spielsteine (Spieler +Wachen): LinkedList<Agent> gamePieces

Die Logik des Spielzugs ist Teil der Agent-Klasse bzw. entsprechend der Unterklassen Guard und Player wo es sich unterscheidet. Die Klassen haben jeweils auch Methoden um gültige Spielzüge zu generieren.

Das Spiel startet indem es sich die Liste der Agenten holt und immer reihum auf jedem Agent.takeTurn() aufruft. Die Spieler fangen an, danach die Wachen. Guard und Player erben von Agent und haben deswegen jedenfalls die takeTurn()Schnittstelle.

• [x] Spiel ruft für jeden Spielstein immer der gleichen Reihenfolge nach Agent.takeTurn() auf.
• Spieler
  • [x] Player generiert die erlaubten Züge, verfügbar unter LinkedList<Coordinates> Agent.getMoveOptions(Coordinates c) Dabei sind Bodenfelder erlaubt, auf denen keine freundliche Einheit steht.
  • [ ] Player fragt an dieser Stelle am Frontend nach einer Eingabe vom Spieler. -> @Smeagle: Da brauche ich eine Schnittstelle die ich aufrufen kann oder ähnliches.
  • [ ] Dabei werden die moveOptions entweder dem Spieler zur Auswahl gestellt werden, oder die Eingabe des Spielers wird anhand ihrer auf Gültigkeit geprüft.
  • [ ] Spieler kann vor, während oder nach seinen Zügen Aktion peek(Direction dir) oder sprint() aufrufen. Wird Aktion aufgerufen, wenn Player.movesLeft > 0 && Player.movesLeft != Player.movesPerTurn verfallen die restlichen Schritte. (to be implemented)
  • [x] Hat der Spieler keine Züge mehr übrig, ist sein Zug beendet. Siehe Player.takeTurn().
• Wache
  • [x] Guard.takeTurn() ist schon vollständig implementiert:
  • [x] Guard.checkFieldOfView(), prüft 180°-Sicht, wenn alarmiert 360°-Sicht
  • [x] Guard.makeMove() Läuft Patrouille, außer wenn Gegner in Sicht, dann wird auf Gegner zugestürmt mit zusätzlichen Zügen

Spielende

• [ ] Spiel endet wenn der Spieler EXIT erreicht
• [ ] Spiel endet wenn für die letzte Spielfigure Player.kill() aufgerufen wird.

Abgehaktes ist schon implementiert. :)

[Smeagle]

Ich fände es gut, wenn die Spielfigur dem Frontend die möglichen Aktionen mitteilt (hast du ja auch geschrieben). Schnittstelle definiere ich noch. D.h. wenn die Spielfigur dran kommt (takeTurn), dann macht diese sowas wie:

• GameBoard/GameState .setSelectableCoordinates(Set)
• GameBoard/GameState .setSelectCallback(Action)
• GameBoard/GameState .setPlayerActions(List)

Action ist dann ein Objekt mit einer perform()-Methode (wird aufgerufen als Callback oder bei Tastatureingabe oder Knopfdruck) und einem Tastaturkürzel und weitere Informationen, um einen Knopf anzuzeigen.

Um die Schnittstellen kümmere ich mich als nächstes, damit du diese verwenden kannst...

[murchandamus]

Hatte heute leider doch weniger Zeit zum Programmieren als ich dachte. Morgen Abend bin ich voraussichtlich daheim. Dann geht es wieder etwas weiter. In meinem Player-backend Branch gibt es jetzt aber einen (hoffentlich) einigermaßen komfortablen Gameboard-Builder! Jetzt auch mit korrekter Felderadressierung. :)

[Smeagle]

Kein Stress! Ich möchte, dass ihr ganz entspannt an die Sache ran geht - und nur soviel ihr Lust habt. Es gibt wichtigeres als das Projekt. Z.B. auch mal nichts zu tun! Also: wenn mehrere Tage, Wochen, ... nichts am Projekt passiert, dann freue ich mich, weil ich weiß, dass ihr euch nicht selbst im Projekt verausgabt. Was schnell passieren kann. Ich kenne das.

[murchandamus]

Keine Sorge, mir hat es nur wirklich viel Spaß gemacht die letzte Woche. Ich hatte schon ewig nichts mehr mit Java gemacht und im Vergleich zu hardware-nahem C++ ist es fast als würde das Programm sich von alleine schreiben. ;)

[Smeagle]

Ich schließe das Issue, weil der Ablauf nun ziemlich klar ist. Für weitere Verbesserungen / Erweiterungen müssen neue Issues erstellt werden. Für Ablauf siehe GameState.finishTurn, Agent.takeTurn, Menu-Klasse, Action-Klasse und Selection-Klasse. Siehe Dummy-Agent oder "permanente Aktionen" im Menü für Beispiel-Implementierungen von Aktionen etc...