Treffen 13.12.13

Tagesordnung

Gemeinsame Besprechung

• Model mutable oder immutable
• dazu auch: getParent oder Pfad speichern
• Ausschließen von Wunschkriterien
• Gründe, warum wir libgdx verwenden
• allgemeine Konzeptentscheidungen

Gruppenbearbeitung

• Entwurfsdokumenttexte schreiben (Lena, Vincent, Tobi)
• Liste von eigenen Exceptions (Jonas, Iris)(to be continued)
• JSON Levelbeschreibung (Lukas)
• Funktionalität zum Laden von Leveln in Diagramm
• Screens mit Controllern verbinden (Jonas, Iris)
• Achievement-/Statistiksystem (Tobi)
• /F236/ Kameraführung
• Ladebildschirm, mit Trivia
• Renderelemente (Vincent, Tobi, Lena)
• Datenbank umarbeiten (Jonas)
• Sequenzdiagramme/zumindest mal auf Zusammenhang und Funktionalität prüfen; ev. Diagramm anpassen:
  • Simulation (z.B.: eine Beta-Reduktion)
  • einen Schritt auswerten und zurücksetzen
  • ein Drag&Drop Vorgang
  • Wiederherstellen des Spielstandes
  • Erstaufruf der App (automatisches Öffnen der Profilerstellung)

Ergebnisse

• Vorteile mutable
• Baum muss nicht neu aufgebaut werden
• getParent
• Referenz ist eindeutig für Position
• Probleme mutable
• Referenzchaos
• unübersichtlich wegen übrigbleibenden Referenzen (globale Auswirkungen)
• Vorteile immutable
• übersichtlicher/ leichtere Fehlersuche
• kein unnötiges Kopieren von Teilbäumen
• für Rückwärtsschritte müssen keine Kopien gemacht werden
• Referenzen können weiter verwendet werden
• Probleme immutable
• Positionsidentifikation
• Einfügen ist kompliziert -> Entscheidung: Mutable, weil Intuition ("ein unvertrautes Konzept")

Ausgeschlossene Wunschkriterien

• /F260/ Sandboxlevel speichern/laden
• /F130/ Avatarerstellung
• /F236/

Konzeptentscheidungen

libgdx

• ist auf Anforderungen angepasst
• spezifisch für Spiele
• Vereinfachung
• überzeugt durch Effizienz
• Android verkompliziert
• "das Rad nicht neu erfinden"
• einfacher UI-Aufbau ("excellent")
• Scenegraph ist ein gutes Pattern
• vereinfachtes Rendering
• open source & freeware
• gute Dokumentation
• multiplatform
• Alternativen sind alle doof

MVC

• Hier Standardbegründung einsetzen
• Aufteilung in packages
• Model hat keine UI-spezifischen Attribute

Mutable Model

• siehe oben

Visitor-Pattern

• Standardbegründung
• weil Baumstruktur

Sonstige

• Datenbanken
• JSON Beschreibung der Level