---
# System prepended metadata

title: Vortragsvorbereitung

---

# 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




