search

Smeagle / dungeongame

Inspired by "Spar Wars"
2 stars 1 forks source link

Added test, fixed walking over occupied fields #38

Closed murchandamus closed 8 years ago

murchandamus commented 8 years ago

Habe Wachen beigebracht um Kameraden herumzulaufen. ;)

Ich habe GameState.finishTurn() rausgenommen, weil ich sonst den GuardTest nicht ohne GameState-Klasse ausführen kann. Das ist inkompatibel zu Master. :(

GameState sollte gegenüber den Agenten gekapselt sein. Es sollte nur sagen "mach deinen Zug" und der Agent sollte dann unabhängig seinen Zug machen können. Dann sagt GameState zum nächsten Agenten "mach deinen Zug". Bis das Spiel vorbei ist.

ABER… das funktioniert nicht mit der Test-Umgebung, die zur Zeit in DungeonGame ausgeführt wird. Hatte das nämlich gerade fertig so implementiert. Müssen mal schreiben/telefonieren, wie wir das machen können.

DON'T MERGE, NEEDS DISCUSSION.

Smeagle commented 8 years ago

Ich weiß nicht wie du das ohne den Aufruf von finishTurn machen willst. Du könntest vielleicht in GameState einen "Test-Modus" einbauen, so dass finishTurn in diesem Test-Modus nichts tut?

Smeagle commented 8 years ago

Wegen mir brauchst du die Tests nicht schreiben. Es ist ja unwahrscheinlich dass späterer Code das Verhalten der Algorithmen irgendwie ändert, weil es ja ziemliche Black boxes sind. Wie du magst.

murchandamus commented 8 years ago

Nein, das Problem ist ja, dass keine Instanz der Klasse GameState existiert, wenn ich nur Tests für Agent/Guard/Player laufen lassen will. Will ja nicht immer das ganze Spiel generieren um nur eine Klasse zu testen.

Die Tests helfen mir dabei zu Überprüfen ob Sachen auch funktionieren, wie ich mir das vorstelle, oder Fehler zu identifizieren. Ich glaube, dass ich damit Zeit spare. :)

Könnte man vielleicht eine "Wait for Player-Input" Methode einbauen? Wie das mit dem Selection, dass nichts läuft bis eine Taste gedrückt wird?

murchandamus commented 8 years ago

Könnte man vielleicht die Wachen automatisch ihren Zug beenden lassen und nur vom Spieler und Dummy den eigenen Aufruf GameState.finishTurn() verlangen? Dann könnte ich die Wachen unabhängig testen.

Smeagle commented 8 years ago

Woher weiß das Programm dann aber wann der nächste Spieler dran ist? Mann könnte es vielleicht mit Events entkoppeln. D.h. der Agent gibt nur Bescheid, dass er fertig ist und alle die es interessiert (GameState) können darauf reagieren. D.h. ich würde dann beim normalen Spiel beim Aufstellen der Agenten entsprechende Listener an den Agenten registrieren und bei den Tests würde man das einfach weglassen. So könnte ich mir das vorstellen. Wenn du willst kannst du das so umsetzen. Als Listener-Klasse kannst du ja die vorhandene event.EventHandler-Klasse verwenden. Oder soll ich das (heute Abend) umsetzen?

murchandamus commented 8 years ago

@Smeagle: Na, unsere gesamte Programmlogik ist doch single-threaded (außer die Interaktion mit dem User). Eigentlich reicht es dann doch, wenn takeTurn() komplett durchgelaufen ist? Dann ist der Zug rum. Dann wird der nächste Agent aus der Liste aufgerufen und auf "activeAgent" gesetzt, und auf den agent.takeTurn() aufgerufen. Spricht da was dagegen?

Kann man da irgendwie zwischendrin das Zeichnen anstoßen? Und sonst muss man halt anhalten und warten, wenn der Spieler eine Action auswählt oder Spielzüge animiert werden.

murchandamus commented 8 years ago 
    public static void runGame() {
        boolean isGameOver = false;
        while (board != null && board.getAgents().size() > 0 && isGameOver == false) {
            for (Agent agent : board.getAgents()) {
                activeAgent = agent;
                activeAgent.takeTurn();
                finishTurn();
            }
        }
    }

–Im Code

murchandamus commented 8 years ago

Man könnte das mit dem finishTurn(); auch so machen:

if (agent.getAffiliation().equals(Affiliation.DUNGEON) {
    finishTurn();
}
Smeagle commented 8 years ago

Eigentlich hängt es nicht an der Affiliation: Es könnte auch Player-Figuren geben, die automatisch ziehen (Pets o.ä.).

Vielleicht ist das auch ein guter Hinweis: Vielleicht brauchen wir noch ein Attribut am Agenten, sowas wie "computergesteuert / spielergesteuert". Anhand des Attributs können wir dann automatisch den nächsten Agenten agieren lassen oder eben nicht.

Ich glaube das geht so nicht mit der for-Schleife in runGame. Weil man die ja nicht stoppen / anhalten kann. Vielleicht so?:

Also so ähnlich wie du es hattest, nur dass die Schleife nicht in runGame ist.

murchandamus commented 8 years ago

@Smeagle: Okay, dann werde ich es so implementieren.

Smeagle commented 8 years ago

@Xekyo: Ich habe GameState schon dementsprechend geändert.

Smeagle commented 8 years ago

Wie schaut es mit dem Branch aus? Ich würde auch gerne am Backend programmieren, traue mich aber nicht, weil ich immer denke, dass deine Änderungen vorher noch rein sollten, um Konflikte zu vermeiden. Z.B. hätte ich total Lust den Player weiter zu entwickeln weil wir ja schon fast ein spielbares Spiel haben. :)

murchandamus commented 8 years ago

Naja, ich hatte meinen obigen Stand ja verlinkt. Du machst Verbesserungsvorschläge. 3/4 von dem was du vorgeschlagen hattest, war da schon drin. Ich signalisiere daraufhin, dass ich deine Vorschläge übernehmen will. Dann sagst du als nächstes, du hast es schon implementiert und ich stelle fest, dass der GameState-Teil meiner Änderungen komplett inkompatibel mit deinen Änderungen ist. Irgendwie reden wir etwas aneinander vorbei. ;)

Ich muss also erst mal wieder rausfinden, wie ich die beiden Sachen zusammenführen kann. Und offensichtlich sind meine Entwicklungszyklen gerade zu lange. :/

murchandamus commented 8 years ago

Okay, okay. Ich habe mich mal wieder vergallopiert. Beim zweiten Mergen habe ich glaube ich keinen Fehler gemacht und jetzt läuft das Spiel vor allem wieder. :)

Smeagle commented 8 years ago

Du hast Recht. Ich habe mir den Branch nicht angeschaut und dann habe ich das implementiert, was du gesagt hast was du machen würdest. Mein Fehler, tut mir leid. :/

Dass die Zyklen lange sind ist nicht so schlimm. Wenn wir später isoliertere und kleinere Issues haben und diese getrennt nacheinander angehen läuft das. Wir müssen halt nur aus dieser etwas chaotischen Anfangsphase heraus kommen.