# SoPra - Session 01: 07.09.21 - 17.09.21

## Organisatorisches

- commit message style
- Relevant für master
- Deutsche Sprache
- Nicht unter drei Emojis
- Bitte ausführlich
- Art, Was?
- Pull/Merge requests approven?
- Wer testet wessen Code?
- checkstyle anpassen?
- Featurebranches/Personenbranches, master, extra dev branch?
- Genereller Plan Implementierung/Testen

### ToDo
- [x] State Machine zeichnen (Robert)
- [x] Sequenzdiagramme updaten ()
- [x] alle überarbeiten
- [x] ändern/einfügen getCharById()
- [x] Klassendiagramm fertig ()
- [x] offene Punkte diskutieren (alle)
- [x] schönes Pattern für gegenseitig kennen
- [x] public/private im Klassendiagramm
- [x] Lebenslinien in Sequenzdiagramm richtig
- [x] der tolle Fehler bei Goal/Game...
- [x] Config vervollständigen (Robert)
- [x] Command Pattern und Visitor Pattern
- [x] fehlende Methoden (und Aggregationen ergänzen)
- [x] überschreibungen!!!
- [x] return values
- [x] siehe Tafel
- [x] Zeitplan
- [x] Olis TODO List
- [x] Konstruktoren richtig einfügen (siehe Sequenzdiagramme)

## Entwurfsplanung

### mögliche Änderungen
- Konstanten
- Spielphasen
- mehrere Fähigkeiten
- mehrere Spiele gleichzeitig?
- neue Fähigkeiten

### Module / Pakete
- Kommunikation
- Personen
- Spiel

### Klassen
- Game
- Konfiguration
- Kommunikationstool
- Reason (enum) -> Grund für Moralwechsel
- Würfel/Random Wrapper
- Infektionswürfel
- Überlebender
- Character
- Kind
- Standort
- Eingänge
- Barrikaden
- Spieler
- Kartenstapel
- Müll
- Karte
- Krisenkarte
- Handkarte
- LOCK
- SCISSORS
- STUFF
- FUEL
- FOOD
- MEDICINE
- Kolonie
- Moral
- Fähigkeiten
- Passive -> vielleicht als Decorator?
- WOUND
- NO-INFECTION
- SEARCH
- TRASH
- Active
- HEAL
- FEED
- BARRICADE
- KILL
- Aktionen
- ohne Würfel
- mit Würfel
- Krisen
- Nahrung
- Infektionen -> vielleicht lieber Verletzungen
- Wunde
- Erfrierung
- Biss
- Spiellogik
- Phasen
- Spielerphase
- Koloniephase
- Würfel
- Aktionswürfel
- Infektionswürfel
- Spielwelt

### Offene Punkte
- (done) State Pattern ordentlich wie?
- (done) welche Funktionen brauchen wir in den Game State Klassen?
- (done) Würfel?
- extra Infektionskettenwürfel?
- (done) Funktionen in Player (und anderen Klassen) hinzufügen
- (done) Aktionen als eigene Klasse oder nicht?
- (done) wie machen wir das mit den Würfeln? Wird im Charakter überprüft ob wir die brauchen oder schon im Player? Braucht der Charakter zu welchem Player er gehört? wo lösen wir auf welche Aktion gemacht wird und ob die Bedingungen erfüllt sind?
-> immer mitliefern, muss noch als Argument weitergegeben werden
- (done) Fuel bei Move
- **Zombie spawn**
- (done) invalid Action wenn einfach eine Fuel-Karte gespielt werden
- (done) in Character fehlen noch Funktionen
- remove Trash
- aktive Fähigkeiten ausführen
- überschreibende Methoden für passive Fähigkeiten
- (done) Zufallsbewegungen
- (done) wie kommunizieren wir mit der ServerConnection? nur über Server oder alle?
- (done) sendEvent als Observer??
- (done) Wie kann die Location auf das Game zugreifen? (benötigt für search)
- Game als static
- Feld Game in Location
- mitgeben -> JA
- (done) Ausrüstungsgegenstände können evtl. nur einmal pro Runde verwendet werden (bei der nächsten Anwendung muss nach Gegenständen weiter "unten" gesucht werden)
#### unwichtiger
- Charakter als Interface oder abstrakt?
### Abgehandelt
- (done) wo speichern wir wo Überlebende sind? Im Standort oder im Charakter? -> Gedanken über Sequenzdiagramme machen
- im Charakter die Location speichern
- in der Location eine Charakter-Liste
- jeder Spieler hat eine Charakter-Liste
- Map zwischen Location und Charakter (globales Objekt) -> NEIN
- (done) wie entfernen wir Charaktere?
-> Observer Pattern
- (done) wie Infektionen?
- Liste im Charakter
- mit Infektionen als Klassen -> JA
- mit Infektionen als Enumeration -> nein
- Infektion als Decorator -> NEIN
- Anzahl Wunden, Anzahl Erfrierungen im Charakter -> eher abraten
- (done) wie lassen wir die Karten ausspielen?
- wo bekommen wir die Events?
- wer handelt das?
- als Funktion in Klasse Karten
- mehrere Funktionen in Game/Game State
- speichern wir das Target in der Karte?
=> Karte kommt als Command rein und wird dann weitergeleitet
- (done) scissors kann bei krisen als stuff committed werden
-> als Enumeration

### Notizen (Besprechung mit Lauritz)
- SEQUENZDIAGRAMME
- ConfigWrapper kein reines Singleton
- Review:
- von Thomas
- generelles Feedback zu unserem Entwurf
- informelles Reden über den Entwurf, welche Gedanken gemacht (Fokus: was ist gut, was ist schlecht)
- was ist wichtig für Abnahme
- sehr entspannt (!!!), angenehm
- Freitag Nachmittag 16:00 (frühster Termin)

## Vortrag(Entwurfsreview)
- losgehen im Server (Oliver)
- State Machine (Robert)
- großes Ganze, Connection/Kommunikation (Oliver)
- Game, Location, Player (Elina)
- Survivor-Paket (Yasmine)
- Sequenzdiagramme (Iona)
### Protokoll Entwurfsreview (10.09.21 16:00-17:40)
**Notizen**:
-(done) es fehlt noch etwas wo das im Charakter die Ability aufgerufen wurde,
(done) -ConfigWrapper noch weiter ausführen (viele Getter-Methoden etc.),
-(done) es fehlt noch newRound()-Methode im Player, Game und so,
(done) -vielleicht können wir das mit Location-Wechsel auch noch irgendwie in den Observer integrieren?,
-Müllstapel: Karte auf Müll ablegen wie?

(done) wieso wird das Game erst später komplett gefüllt? -> braucht Anzahl Player zum Erstellen einiger Sachen
halten Informationen doppelt? einmal in der Config und einmal im Objekt
-> teilweise jedes Mal in der Config auslesen
-> mal so, mal so, einige Informationen sind auch in den Klassen gespeichert
-> an sämtlichen Stellen Zugriff auf den ConfigWrapper
-> eventuell schlecht?? -> fanden das ok

(done) Würfel: wann werden die erstellt, wann werden die geworfen? BasisWürfel
viel aneinander vorbeigeredet, hat aber eigentlich gepasst

(done) muss der Charakter die Location kennen?
-> Infektionchain
-> Aktion ausführen
muss das wirklich sein? -> unsere Meinung: JA

(done) wer teilt dem Game Sachen mit? -> das machen die States
(und noch einige Objekte mehr kennen das Game)

Vermischung von Modell und Controller (gegenseitiges Kennen):
unsere Idee: das jede Klasse sich darum kümmert was sie macht
-> die vielen Referenzen-hin-und-her: nicht vergessen alles immer zu updaten (dafür an einer Stelle auch der Observer)

müssen generell sehr viele Aufrufe berücksichtigen (wegen den ganzen Abhängigkeiten)

(done) Frage: was passiert genau wenn sich ein Charakter bewegt? muss bei Location aus und eingetragen werden und Observer umgetragen werden und muss eigene Location ändern

entityComponent

führt zu Clash wegen objektorienterer Methodik

(done) Müll: Müll Kartenstack kann nicht geshuffelt werden, Gemeinsamkeiten und Unterschiede von CardStack und GarbageStack überlegen, *Lösung*: CardStack abstrakt machen und dann neben dem GarbageStack noch ein NormalCardStack machen

(done) Barricade-Klasse löschen (wird nie benutzt), die magische Konstante im ConfigWrapper gespeichert

(done) was machen die Unterklassen von Karten? wieso existieren die überall? über alle Karten muss dann noch die play() Methode überschrieben werden (sonst könnte man generell einen Enum nehmen), in TargetfulCards gibt es eigentlich noch einen Setter für das Target

ToDo: wo fehlen noch Methoden, wo müssen noch Methoden überschrieben werden, wo fehlen noch Aggregationen, wo sind vielleicht Aggregationen zu viel
-> macht alles Sinn (?)

Achtung: ins Repo nicht nicht-lesbare Dateien legen, nur PDF, kein anderes Gedöns

Tikz: Diagramm noch schöner machen und das andere eintippen, Paddings, DocType standalone

(done) noch in Ruhe am Montag mit Lauritz einige Sachen besprechen

Olis Punkte:
**-Config einmal durch die Sachen anpassen, erstellen von Location und so vorverschieben, Config nach Einlesen einfach Löschen**
(done) -State vom Spiel speichern, teilweise in Colony, teilweise im Game -> eine schöne Datenklassen, etwas zusammen machen
(done) -Location und Observer ist Zeug doppelt, nochmal anschauen
-setterTarget bei TargetfulCards

-> mehr Trennung von Code und Daten
-> Config nochmal anschauen

**Lauritz Notizen aus dem Review (Dienstag Morgen Besprechung):**
- (done) PlayerState: Funktionstypen werden statisch aufgelöst, wir bekommen nur etwas vom Typ Command, nicht von den Unterklassen, es wird immer nur handleCommand(Command) aufgerufen, braucht Zugriff auf Sub-Typen
- Lösung wäre CommandPattern (haben das so halb und jetzt voll machen), Handler wegwerfen, State vorwarden
- State Machine Pattern ist auch irgendwie nur so halb
- Command Factory ist gut, mehr in die Commands verlagern (da die so halb abarbeiten), grundlegende Logik vom Command im Command
- kann noch State Machine bleiben, nur etwas abändern
- noch macht die Vererbungsstruktur der Commands nicht wirklich Sinn, da es keine Attribute/Methoden hat
- in State: Feld aktueller Command oder so?
- (done) putCard in CardStack muss in GarbageStack
- (done) wie funktioniert das alles mit Config, Random, ...
- statische Sachen können bei Tests Probleme machen
- (done, dagegen) resetDie im Player
- Targetless/Targetful Cards, das funktioniert nicht
- setTarget() fehlt
- Problem: wir bekommen nur Karte, wissen nicht was, dynamische Auflösung
- Command Pattern? => eher nicht
- Visitor für die Karten (um dann Target oder so hinzuzufügen)
- cardWithTarget, cardWithoutTarget
- MVC macht keinen Sinn :)
- wir haben auch reine Datenklassen, aber alle Controller Klassen haben auch Daten
- (done) Location hat eindeutige Id, müssen nicht (Referenz auf) Objekt haben, nur ID speichern
- über ID referenzieren ist evtl. einfacher
- Location und Charakter verändern sich halt ständig, müssen immer geändert werden => dafür Observer (update)
- zyklische Abhängigkeiten sind immer etwas doof, Charakter <=> Location ist ok und hier sinnvoll
- (done) Character muss umbenannt werden
- (done, dagegen) Game hatte noch keinen State (?)
- (done) Location setzen wir im Sequenzdiagramm (fehlt noch)
- (done) Erweiterung als Decorater-Pattern?
- zwei (offensichtliche) Möglichkeiten
- Lauritz behauptet das funktioniert ;)
- Decorator macht Faltung
- meine Notiz: Ausrüstung fehlen noch die Methoden und genauer Ablauf => Sequenzdiagramm
- (done) Command mit fuel falsch, muss da weg
- (done) Goal mit Unterklassen
- scheint gut zu sein
- Goal muss **nicht** das Game kennen
- ***Config***
- neue Version von Robert/Elina
- new Location von LocationBlueprint
- direkt Config Klasse? Interface ist nicht nötig
- Config direkt wegschmeißen
- getConfig fällt nach Erstellung weg (?)
- nur noch ein Interface das das getRandom() enthält, sodass das bekommen, Rest von Config braucht man nicht
- magischen Konstante könnte jetzt auch woanders stehen, also einfach in den Klassen/Objekte setzen (Konstanten-Klasse ist ein Antipattern)
- getConfigInstance wegschmeißen
- static Random irgendwas
- (done) Bedingungen Commands (/Aktionen) prüfen
- in dem Moment wo es failt, sendet eine Methode funktioniert nicht und sendet dann CommandFailed, über den gesamten Ablauf muss Möglichkeit zur Kommunikation gegeben sein
- Rückgabewert boolean und so zurückgegeben
- Exceptions => nicht benutzen für etwas was dem Kontrollfluss des Programms gehört, sehr viel teurer
- nur TimeOut und JSON-Parse
- Exceptions führen zu einem exitCode != 0 (wenn man sie nicht fängt)
- kann man System.exit() schreiben??
- in Top-Level alles entscheiden ist nicht möglich und nicht sinnvoll
- irgendeinen Datentyp zurückgeben (determinischte Abhandlung möglich), ist eigentlich ok
- Observer für Connection (die dann merkt wenn was schiefgelaufen ist), Observer sagen das etwas kaputt ist
- MVC, Entity: einfach mal schauen was es hier bedeutet

### Lauritz fragen
- **wie man etwas darstellt was zentral ist, aber keine Aggregation ist**
- stark zusammengehörend
- einfach Linie dazwischen

## Nützliches Material
- http://www.cheat-sheets.org/saved-copy/designpatternscard1.pdf

## Fragen und Antworten
- S. 10 mitte: Wenn man an einem Ort einen weiteren Überlebenden findet, schließt der sich dann der Gruppe an oder gelangt er magischerweise in die Kolonie?
-> zweiteres
- Wenn ein neuer Überlebender gefunden wird, welchem Spieler wird er dann zugeordnet?
-> der ihn gefunden hat vermutlich, vielleicht auch niemandem?
- Hat ein neuer Überlebender schon einen Charakter?
-> ja
- Ist ein Charakter nur durch seine Fähigkeit definiert?
-> Kap. 3.2.1
- S. 11 unten: Was heißt "wenn kein neuer Überlebender nachspawnen kann"?
-> vermutlich feste anzahl spieler, liste, zufall
- Bei Erfrierungen: Ist es richtig, dass man, wenn nicht geheilt wird, erst die Erfrierung kriegt, nächste Runde eine Wunde, die Runde danach wieder eine Wunde, und danach stirbt?
-> true
- Muss man zum Heilen neben dem Verwundeten stehen?
-> vermutlich ja
- Macht man pro Runde mit jedem seiner Charaktere einen Zug? In welcher Reihenfolge?
-> egal, egal
- (S. 35, Tabelle 1: Warum steht da manchmal ein Überlebender und manchmal eine Überlebende?) vermutlich unwichtig
- S. 18 unten: ein spieler oder ein charakter entsorgt karten?
-> vermutlich nur ein fehler, charaktere entsorgen müll
- S. 19 oben: ist mit anzahl survivors anzahl survivors in der kolonie gemeint? -> vermutlich wieder ein fehler
- Landen Krisenkarten (handkarten, mit denen die krise abgewendet wird) irgendwann auf dem Müll?
-> Nein
- Heilt heilen alle oder eine Verletzung?
-> vermutlich nur eine
- Muss man in der Kolonie sein, um Müll zu entsorgen?
-> wahrscheinlich ja
- Warum ist das mit dem Essen so komisch (nur menschen in der kolonie haben hunger, kinder essen gleich viel, warum durch 2 teilen)?
-> ist einfach so
- Welchen Sinn haben die Zombies vor den Eingängen?
-> keine besondere Bedeutung, Barrikaden können verhindern dass Zombies spawnen
- Wann hat man gewonnen?
-> nur wenn Ziel erreicht
- Wann hat man verloren? (immer wenn alle tot sind, automatisch wenn Moral=0, wenn Runden vorbei)
Kann man das Ziel erreichen obwohl alle tot sind? Hat man dann gewonnen oder verloren?
S.7 was passiert wenn alle tot sind?
-> direkt verloren, wenn Moral = 0, alle Spieler sind tot (siehe Formusbeitrag)
- was passiert wenn man zum gleichen Ort geht?
-> command failed, also müssen wir wohl doch wissen, wo der character sich befindet
- muss man alle Würfel benutzen?
-> nein, wenn am ende einer übrig ist, dann geht der verloren, man kriegt jede runde neue
- wie kann man Krisen vollenden? wie genau wie viele Karten abgeben? wie wird das genau gespeichert/übergeben?
-> jede krise hat genau einen kartentyp, es ist command failed, falls eine andere beigetragen wird
- Wie funktioniert das mit den Clients? Bekommen wir für jeden ein Objekt? Wie funktioniert generell die Kommunikation (Events??)?
-> steht in den Sequenzdiagrammen
- wenn es einen freien Platz und eine Barrikade vor dem Eingang gibt: wird zuerst die Barrikade zerstört oder wird erst der freie Platz belegt?
-> erst freie Plätze belegt, dann Barrikaden zerstört
- kann man in der Kolonie auch Zufallsbegegnungen haben? kann überhaupt in der Kolonie durchsuchen?
-> man kann nicht in der Kolonie durchsuchen (CommandFailed), Startkarten muss man danach nicht mehr beachten
- kann man die Karte Fuel überhaupt ausspielen?
-> man kann sie ausspielen und dann moven, der Command Move(id, id, bool fuel) ist falsch und wird entfernt
- gibt es vor der ersten Runde schon Zombies? wenn ja, nur bei der Kolonie oder bei allen Locations (wo sich noch keine Leute aufhalten)?
-> ja, gibt es, steht in der Konfigurations-Datei
- Goal: survive = true. Bedeutung??
-> Zwei Möglichkeiten:
- Gewonnen wenn alle Runden gespielt und nicht vorher gestorben
- anderen Zielbedingungen: Spiel verloren, wenn Rundenzahl = 0 und Ziel noch nicht erreicht
- wie funktioniert Müll rausbringen?
-> jeder Charakter kann pro Runde beliebig viel Müll rausbringen, nur beschränkt durch Anzahl von Würfeln, die passive Fähigkeit darf nur einmal pro Runde genutzt werden
- wie spielt man Ausrüstung aus?
- UseCard(survivorID, targetID), survivorID (beliebiger Charakter eines Spielers der die Handkarte besitzt), targetID (Charakter der die Rüstung angezogen bekommt, muss nicht vom gleichen Player sein)
- kann man jemanden heilen der keine Wunden hat?
- sendet kein Command Failed Event
- funktioniert

### offene Fragen
- wie funktioniert Kill? an welchem Eingang werden Zombies getötet?

## Klassendiagramm
Das aktuelle Klassendiagramm findet sich im GitLab-Branch `entwurf`.

### Ändern
- [x] Aggregation
- von ActionDieContainter zu Die
- von CardStack zu Card
- von Colony zu Card
- von Location zu CardStack
- von Server zu ConfigWrapper
- von Connection zu Player
- von Game zu Colony
- von Game zu Location
- von Player zu Card
- [x] Aggregation falsch rum
- Goal zu Game
- [x] Barricade-Klasse entfernen
- [x] Ausrüstungskarten hinzufügen
- [x] für jeden Command erst überprüfen ob der Command nicht failed
- [x] CardStack abstrakt machen, Unterklasse ShuffleCardStack
- [x] play()-Methode in Karte ergänzen
- [x] Observer ergänzen mit characterUpdate
- [x] wie legen wir den Müll ab, Methode fehlt noch -> siehe neues (Schema)-Sequenzdiagramm

## State Machine
bei PlayerPhase fehlen attack und search!!

## Ablenkung
https://youtu.be/YoU3r6ZK8xQ

## Zeitplan
- Freitag Abend müsste freigeschalten werden
- wann fangen wir an?
- insgesamt 2 Wochen
- Plan: nach 1/4-1/3 der Zeit fertig, Rest für BugFixes etc.
- Implementierung
- top down / bottem up
- erstmal groben Code schreiben
- in 5 Abschnitte aufteilen
- machen!!!
- initiale Implementierung (1-2 Tage)
- UnitTest
- relativ früh anfangen (nur bedingt empfehlen, lieber Code schreiben)
- für andere 5 Abschnitte schreiben
- triviale Unittests (3)
- mehr Unittests (4,5)
- **immer wenn Bug Fix dafür eins schreiben**
- Systemtest
- parallelisieren mit UnitTest
- wenn grundsätzlich Programm läuft
- anfangen (ab Tag 4/5)
- pullRequest

## Merken
- Freitag Morgen
- **grober Plan wer was sagt**
- CommandFailed
- Fuel
- Zombie-Spawn
- Müll (Card Play)
- Card Visitor
- **DIAGRAMME ANSCHAUEN**
- jedes nextRound() muss super() aufrufen
- die() muss auch super.die aufgrufen (notify observers)
- Sequenzdiagramme
- Extra: Card Play (mit Müll) -> siehe Bild Telegram
- Extra: Equipment ausstatten/anlegen
- player.playCard() -> Card.accept(TargetfulCardVisitor) -> TargetfulCardVisitor.visit(Card) -> EquippedCharacter(base) -> Observer.update()
- Extra: Zombies spawnen
- ColonyState.onEntry() 4/5 -> Colony.addZombies(colony.numSurvivors/2, Game), for l in location: l.addZombies(l.numSurvivors, Game)
- Extra: Move mit Snowboot und FrostBite
- nextCommand(), return moveCommand -> moveCommand.accept(playerState) -> playerState.visit(moveCommand) -> game.getPlayerById() -> player.getCharacterById() -> SnowbootCharacter.move() -> snowBootCharacter.equipmentPossible(), return true -> game.getLocationById(newLocationId), return newLocation -> newLocation.hasSpace(), return true -> überall austragen und neu eintragen (Observer geändert, ...) -> rollInfectionDie, return: Frostbite -> baseCharacter.addWound()
- in Sequenzdiagramm 2 & 3: zur Übersichtlichkeit Event senden weggelassen, in Sequenzdiagramm 1 steht es drin