# Vortragsvorbereitung

### Ablauf

* Präsentation, Spielprinzip, Demo - Fynn (für Outro und Intro 7 Min)
* Architektur - Hannes / Anton (8 min)
* Entscheidungen; je 5 min
* Spielzeit - Nils
* Tower - Raban
* Observer - Simon
* Reflexion, Ausblick, Ende

### Vortrag
* Einleitung mit Vorstellung des Spielprinzips -> 0.25 Mensch
* Live Demo des Spiels (Screencast nur als Backup) ~ onTheFly
* Architektur (Anton, Hannes)
* Manchmal: Verhaltenstechnische Zusammenhänge
* GameEntities <--> Game
* Controlling <--> Game
* aufbau
* tower macht enemy platt
* einmal die
* Tower haut Enemy wie aufs Maul? <-- Interaktionsdiagram
* Tower fragt game
* redet dann direkt mit enemies
*

* 2 - 3 Entwurfsentscheidungen (3 Menschen) (Nils, Raban, Simon)
Kontext > Problem > Alternative > Fazit
* [X] (Simon) Observer zwischen Controllpanel und Game, sowie Abwägung warum Enemy mit Game über Methoden kommuniziert
* an den anderen Vorträgen orientieren
* Enemy 1 zu 1 Kommunikation, spricht nur mit Game da direkter Message Fluss bekannt
* [X] (Raban) Towervariation als Hybrid zwischen TemplateMethod und Strategy
* verschiedenes Towerverhalten (Sniper, Laser, Canon etc. pp)
* mit vielen gleichbleibendem Behaviour (spawning, angriff, )
* TemplateMethod -> benötigen hier noch komplexeren Tower um die eigenen Klassen zu begründen

* [ ] Scheduler (Nils / Fynn)
* Orchestriertes Zusammenspiel
* gut erweiterbar (e.g. Events "Säureregen")
* Alternative: Jeder stept selbst
* AddAlarm für Schüsse
* Kontext
* Gegner kommen typischerweise in Wellen
* diese Wellen erfolgen hintereinander und werden zunehmend schwerer
* Die Gegner in einer Welle kommen nacheinander
* Zeitabstände innerhalb der Wellen sind variabel
* Zu lösendes Problem
* Must have
* Flexible Zeitabstände
* Nice to have
* Pause / Beschleunigen
* Alternativen und Bewertung
* Wellen messen ihre Lebenszeit mit und lösen zur richtigen Zeit die Ereignisse aus
* WaveManager auch?
* \- duplication / nicht modular
* \- Fehleranfällig da selbsstgemacht
* \+ Kapselung
* \+ Nachvollziehbar
* O Pause / Beschleunigen möglich, aber Information muss verteilt werden
* Eingebautes Morph>>addAlarm:in: nutzen
* Waves und WaveManager müssten Morphs sein
* \- Keine Visuelle Repräsentaion, daher unerwartet in Domäne
* \+ Eingebautes scheduling -> weniger Fehleranfällig
* \- Beschleunigung / Pause schwierig
* Einfaches stepping genügt nicht
* \- keine ausreichende Varianz
* \+ simpel und bekannt, lesbarer code
* wie `addAlarm:in:`
* GameTime Objekt mit generischem Interface
* \+ wiederverwertbar
* \- Fehleranfällig da selbsstgemacht
* Da nur eine Implementierung: einfacher zu reparieren
* \- Kopplung
* \- weniger Lokalität des Control Flows
* \+ Nachvollziehbare Funktionalität
* \+ Pause / Beschleunigung relativ einfach (hoffentlich) sobald vollständig genutzt
* Details:
* Event Objekte: canceln möglich
* Sucht in jedem Step die Events raus, arbeitet sie in richtiger Reihenfolge ab undsorgt für die richtige Spielzeit im Kontext der Ausführung
* Wenn Event bei 57 Sekunden gescheduled ist, ist die `GameTime passedDuration` bei der Ausführung *genau* 57 Sekunden - egal, wie oft die GameTime in Echtzeit gescheduled wird -> Folgeereignisse werden richtig gescheduled.
* Diagramm?
* Abarbeitung der Ereignisse: **Spielzeit** 'läuft' auch zwischen updates mit -> keine Rundungsfehler durch zu geringe Updaterate
* Fazit
* Patterns
* Event -> Command?
* Nicht (sehr) domänenspezifisch, praktisches Hilfskonstrukt
* Lösung, die erweiterbar ist auf zukünftige Features

* Reflexion zum Projekt
* Brainstorming mit allen am Ende -> einer trägt vor

* Abschluss / Ausblick / Zusammenfassungn