00: Software Guidebook - ZHAW-Team-Toxic/PM4-Team-Toxic GitHub Wiki

1. Kontext (Context)

Frontier ist ein 2D-Tower-Defense-Spiel im Retro-Stil, das klassische Verteidigungsmechaniken mit strategischem Ressourcenmanagement und einer einzigartigen Zeitreise-Funktion kombiniert. Entwickelt wird es im Rahmen des PM4-Moduls an der ZHAW als spielbarer Prototyp mit vollständiger Gameplay-Loop.

Ziel des Spiels ist es, das eigene Hauptquartier (HQ) gegen zunehmend stärkere Gegnerwellen zu verteidigen. Spieler:innen platzieren Verteidigungstürme, errichten Ressourcen- und Produktionsgebäude und nutzen das taktische "Tages-Wiederholen"-Feature, um durch Zeitreise strategisch aus Fehlern zu lernen.

Produziert wird ein Prototyp in Java mit der libGDX-Engine. Die Umsetzung erfolgt durch ein interdisziplinäres Team von sieben Studierenden mit Fokus auf Spieleentwicklung, UI/UX und Softwarearchitektur. Das Spiel wird als Desktop-Applikation mit Low-Resource-Footprint entwickelt, wodurch es auf verschiedensten Systemen lauffähig bleibt.

Das Spiel richtet sich an Fans klassischer Tower-Defense-Spiele, Retro-Gaming-Enthusiasten sowie an Spieler:innen mit Freude an taktischem Denken und Ressourcenmanagement. Die Benutzeroberfläche ist bewusst schlicht und intuitiv gehalten, um den Einstieg zu erleichtern.

2. Ziele und Hauptfunktionen (Objectives and functional overview)

Ziel von Frontier ist die Entwicklung eines funktionalen Prototyps mit einer vollständigen Gameplay-Loop. Das Spiel soll die zentralen Mechaniken eines Tower-Defense-Systems abbilden und um strategisches Ressourcenmanagement sowie eine innovative Zeitreise-Funktion erweitern. Dabei stehen Spielbarkeit, technologische Machbarkeit und Erweiterbarkeit im Fokus.

Die wesentlichen Funktionen des Spiels sind:

  • Verteidigung durch Türme und Strukturen: Spieler:innen platzieren Verteidigungstürme und andere Strukturen strategisch auf einer Karte, um sich gegen Wellen von Gegnern zu verteidigen.
  • Ressourcenmanagement: Rohstoffe wie Holz, Stein, Eisen und Gold werden durch Gebäude generiert und müssen effizient verwaltet werden, um Bau, Upgrades und Reparaturen zu ermöglichen.
  • Zeitreise-Mechanik: Das Hauptquartier (HQ) kann nach einer bestimmten Anzahl an Spieltagen einen "Rewind" auslösen, um den letzten Tag zu wiederholen. Diese Funktion erlaubt taktisches Experimentieren und Lernen aus Fehlern.
  • Dynamisch steigender Schwierigkeitsgrad: Gegnerwellen werden progressiv, Welle für Welle, anspruchsvoller, wodurch sich das Spiel stetig weiterentwickelt und die Spieler:innen zu Optimierungen zwingt.
  • Modulare Gebäudestrukturen: Unterschiedliche Gebäudearten mit individuellen Eigenschaften und Lebenspunkten können errichtet und verbessert werden.
  • Benutzerfreundliches UI: Intuitive Steuerung, reduzierte Menüs und klare Rückmeldungen erleichtern den Einstieg und fördern den Spielfluss.
  • Audiovisuelle Atmosphäre: Hintergrundmusik, Soundeffekte und Ambience-Sounds erzeugen ein stimmiges Spielerlebnis.

Ein erfolgreicher Projektabschluss ist erreicht, wenn:

  • Die definierte Gameplay-Loop (Bauen, Ressourcen sammeln, Welle abwehren, Zeitreise) vollständig implementiert ist
  • Das Spiel fehlerfrei lauffähig ist (inkl. Build)
  • Die Zeitreise-Funktion spielentscheidend nutzbar ist
  • und das Spiel mindestens eine manuell erstellte Karte vollständig unterstützt

Zusätzlich sollen im Hintergrund folgende technische und organisatorische Grundlagen umgesetzt werden:

  • Automatisiertes Testing: Aufbau einer Teststruktur für Kernmechaniken, z. B. Ressourcenverteilung, Gegnerverhalten und Siegbedingungen
  • Codequalität: Einheitliche Codekonventionen, Clean Code Prinzipien und Peer-Reviews zur Sicherstellung der Wartbarkeit
  • Versionskontrolle & CI/CD: Kontinuierliche Integration über GitHub inklusive Build-Überprüfung und Deployment-Skripten
  • Dokumentation: Laufende Pflege des Software Guidebooks und technischer Doku im GitHub-Wiki zur Nachvollziehbarkeit der Entwicklung

3. Qualitätsattribute (Quality Attributes / non-functional requirements)

Die folgenden nicht-funktionalen Anforderungen und Qualitätsattribute bilden die Grundlage für die technische Ausgestaltung von Frontier. Sie wurden realistisch und projektbezogen formuliert, um die Entwicklungsziele im Rahmen von PM4 zu unterstützen.

  • Performance: Das Spiel soll mit mindestens 30 FPS flüssig laufen, auch auf ressourcenschwächeren Systemen. Durch den Einsatz von libGDX, Ashley ECS und Atlas-Spritesheets wird eine effiziente Rendering- und Ressourcenverwaltung sichergestellt.

  • Plattformkompatibilität: Die Anwendung wird als Desktop-Spiel für Windows entwickelt und läuft grundsätzlich auf allen Plattformen, die eine aktuelle Java-Umgebung unterstützen.

  • Benutzerfreundlichkeit: Die Benutzeroberfläche ist minimalistisch und selbsterklärend. Das Spiel soll ohne Anleitung intuitiv spielbar sein. Ein integriertes Tutorial ist nicht vorgesehen; stattdessen wird eine Anleitung mit Tipps, Lore und Spielführung im begleitenden Game-Booklet bereitgestellt.

  • Erweiterbarkeit: Architektur und Code sind modular aufgebaut. Funktionen wie neue Gebäude, Gegnerarten oder zufällige Kartengenerierung können später ohne Redesign ergänzt werden.

  • Wartbarkeit: Der Code folgt Clean-Code-Prinzipien. Ein Code Formatter wird verwendet. SonarQube ist bereits integriert und aktiv im Einsatz; die Konfiguration wird derzeit noch feinjustiert, um die Codequalität gezielt zu überwachen und Verbesserungspotenziale zuverlässig aufzuzeigen.

  • Zuverlässigkeit: Es besteht keine spezielle Fehlerbehandlung oder Failover-Logik. Das Spiel wird als Prototyp mit einfacher Stabilität entwickelt.

  • Internationalisierung: Die Spielsprache ist Englisch. Mehrsprachigkeit ist nicht vorgesehen.

  • Transparenz & Debugging: Ein einfaches Logging-System unterstützt die Fehlersuche während der UI- und Gameplay-Entwicklung. Umfangreiche Logging- oder Analysefunktionen sind nicht Teil des Endprodukts.

Diese Anforderungen sind bewusst schlank und fokussiert formuliert, um dem Charakter eines agilen Spielprototyps gerecht zu werden.

4. Bekannte Beschränkungen (Constraints)

Die Entwicklung von Frontier erfolgt im Rahmen eines akademischen Moduls mit begrenzten Ressourcen. Daraus ergeben sich technische, zeitliche und organisatorische Einschränkungen, die den Projektrahmen klar definieren:

  • Zeitlicher Rahmen: Das Projekt wird innerhalb eines Semesters (ca. 14 Wochen) realisiert. Es wird in zweiwöchentlichen Sprints entwickelt, wobei jeweils eine Demo beim betreuenden Dozenten gezeigt wird.

  • Teamgrösse und Verfügbarkeit: Das Entwicklerteam besteht aus sieben Studierenden, entsprechend der vorgegebenen Teamgrösse. Die Kompetenzen orientieren sich am Niveau von Teilzeit-Studierenden im dritten Studienjahr Informatik. Mehrere Mitglieder bringen vertiefte Programmiererfahrung mit. Zwei Teammitglieder haben bereits ein RPG in libGDX umgesetzt, einer davon zusätzlich ein Tower-Defense-Spiel.

  • Technologie-Stack: Die Wahl der Technologien war frei. Es wurde Java mit dem Framework libGDX gewählt. Damit ist die Plattformwahl auf Systeme mit Java-Unterstützung begrenzt. Web-, Mobile- oder Cloud-Plattformen werden nicht berücksichtigt.

  • Fehlende Infrastruktur: Es gibt keinen dedizierten Build-Server. Allerdings ist geplant, mithilfe von GitHub Actions eine automatisierte Prüfung beim Spielstart zu implementieren, die erkennt, ob eine neue Version verfügbar ist. Falls ein Update erkannt wird, kann dieses direkt aus dem Git-Repository heruntergeladen werden. Die Builds erfolgen weiterhin lokal, das Deployment wird dadurch jedoch teilautomatisiert.

  • Sicherheitsaspekte: Aufgrund des rein lokalen Charakters werden keine sicherheitsrelevanten Funktionen implementiert. Highscores, Modding oder Account-Systeme sind nicht vorgesehen.

  • Fokus auf Prototyp statt Produkt: Es wird kein voll ausgereiftes Spiel angestrebt, sondern ein funktionaler Prototyp. Savegames sollen lediglich lokal gespeichert werden können. Cloud-Integration oder persistente Spielstände über mehrere Systeme hinweg werden nicht umgesetzt.

  • Kein Multiplayer-Modus: Der bewusste Verzicht auf einen Mehrspielermodus wurde frühzeitig getroffen. Einerseits passt Multiplayer nicht zu den Kernmechaniken klassischer Tower-Defense-Spiele, andererseits würde dessen technische Umsetzung den Rahmen des Projekts sprengen. Der Fokus liegt auf einer starken Einzelspieler-Gameplay-Loop.

  • Verwendung freier Assets: Für die grafische Darstellung werden kostenlose, frei verfügbare Pixelart-Sprites verwendet, darunter auch Ressourcen, die standardmässig mit libGDX ausgeliefert werden.

  • Designentscheidungen zugunsten der Umsetzbarkeit: Pixelart wurde bewusst gewählt, da sich 2D einfacher umsetzen lässt und die grafischen Ressourcen dadurch besser kompatibel und leichter erweiterbar sind.

  • Bewusste Begrenzung der Komplexität: Features, deren Implementierung den zeitlichen Rahmen überschreiten würde, werden in Sprint-Retrospektiven identifiziert und ggf. verworfen. Der Fokus liegt jederzeit auf der Fertigstellung der Gameplay-Loop.

  • Balancing noch in Planung: Das Balancing-System ist derzeit noch nicht umgesetzt. Geplant ist eine mathematische Funktion, die den Schwierigkeitsgrad abhängig von der Spielrunde anpasst, um eine dynamische Spielerfahrung zu gewährleisten.

Diese Beschränkungen sind bewusst gesetzt, um den Fokus auf eine stabile, spielbare Kernversion mit vollständiger Gameplay-Loop zu legen.

5. Verwendete Prinzipien (Principles)

Die Entwicklung von Frontier orientiert sich an bewährten Prinzipien aus Softwarearchitektur, Programmierpraxis und agilem Arbeiten. Ziel ist es, ein wartbares, strukturiertes und nachvollziehbar entwickeltes Produkt zu schaffen.

Architekturprinzipien

  • Entity-Component-System (ECS): Das Spiel verwendet das Ashley-Framework, ein leichtgewichtiges ECS-Modell, das Flexibilität und Trennung von Zuständigkeiten in der Spiellogik ermöglicht. Diese Entscheidung basiert auf den Erfahrungen aus dem vorherigen PM3-Projekt, wo eine klassische objektorientierte Architektur zu hoher Komplexität und Unübersichtlichkeit geführt hat. Die Struktur von Ashley wird im gesamten Projekt strikt durchgezogen.
  • Modularisierung: Spiellogik, UI und Rendering sind klar getrennt, um Erweiterbarkeit und Wiederverwendbarkeit zu fördern.
  • Single Responsibility Principle (SRP): Komponenten und Systeme erfüllen jeweils genau eine klar definierte Aufgabe.
  • TODO: Besprechung weiterer möglicher Architekturprinzipien mit dem Entwicklungsteam (z. B. Eventsystem, IoC).

Programmierprinzipien

  • Clean Code: Der Code wird nach sauberen Stilrichtlinien geschrieben, unterstützt durch automatisierte Formatierung und die Analyse durch SonarQube.
  • Testgetriebene Entwicklung (TDD-Light): Wo sinnvoll, werden Unit-Tests geschrieben – insbesondere bei neuen Features durch die jeweiligen Entwickler. Es kommen JUnit für Unit-Tests und Mockito für Mocking von Eingaben und Umgebungszuständen zum Einsatz.
  • Dokumentation: Funktionen und zentrale Mechaniken werden über Kommentare, Markdown-Dateien und ein begleitendes GitHub-Wiki dokumentiert.
  • TODO: Detailabsprache zu spezifischen Namenskonventionen und Design-Patterns im Code.

Entwicklungsprozess

  • Agiles Vorgehen: Die Entwicklung erfolgt in zweiwöchentlichen Sprints mit regelmässigen Demos. Beim Planen jedes Sprints wird eine kurze Retrospektive zum vorherigen Sprint durchgeführt.
  • GitHub-Workflow: Entwicklung erfolgt über Feature-Branches mit Pull Requests und Code Reviews. Als unterstützende Tools werden Desktop-Git-Clients verwendet, um eine übersichtliche Versionskontrolle zu gewährleisten.
  • Kontinuierliche Integration: GitHub Actions übernimmt Build-Checks und perspektivisch Update-Prüfungen im Spiel selbst.
  • Aufgabenverwaltung: Das Team nutzt GitHub Projects zur Verwaltung von Tasks, User Stories und Issues. Die Kommunikation erfolgt über Microsoft Teams.
  • Rollenverteilung: Es besteht eine klare interne Rollenverteilung, wie sie in der Projektskizze dokumentiert ist.

6. Architektur (Architecture)

Die Architektur von Frontier basiert auf einem modularen Aufbau unter Verwendung eines Entity-Component-System-Modells (ECS) mit dem Ashley-Framework. Das Design orientiert sich an klaren Trennungen zwischen Spiellogik, Daten und Darstellung und folgt den Prinzipien der Wiederverwendbarkeit und Erweiterbarkeit.

Technologischer Überblick

  • Programmiersprache: Java (OpenJDK 21)

  • Framework: libGDX

  • ECS-Framework: Ashley

  • Build- und Deployment: Gradle, GitHub Actions (CI/CD)

  • Projektstrukturierung: Modularisiert in UI, Rendering, Logic, ECS-Komponenten

C4-Architekturmodell (Ausblick)

Das Team plant, die Architektur entlang des C4-Modells zu dokumentieren:

  • Context Diagram (Level 1): Zeigt Benutzer, Spiel, Speichersystem, GitHub-Update-System frontier_context_diagram

  • Container Diagram (Level 2): Trennung in UI, Game-Loop-Controller, Logiksysteme, Ressourcensystem, ECS-Layer frontier_container_diagram

  • Component Diagram (Level 3): Feinere Aufteilung innerhalb der Container, z. B. EntitySysteme für Türme, Gegner, Ressourcen frontier_ecs_component_diagram

  • Code/Classes Diagram (Level 4 – optional): Nur bei Bedarf, z. B. für komplexe Subsysteme wie das Zeitreise-Feature.

Platzhalter: Ein detailliertes Klassendiagramm für das Zeitreise-Subsystem ist geplant, sobald die Implementierung konkretisiert wurde. Fokus liegt auf dem Speichern und Wiederherstellen von Entity-Zuständen und Spielstatus. TODO: in Zusammenarbeit mit einem Entwickler modellieren.

TODO: Die C4-Diagramme werden im weiteren Projektverlauf gemeinsam mit einem Entwickler konkret ausgearbeitet.

Kernkomponenten

  • ECS-Systeme: Gegnerbewegung, Angriff, Ressourcenproduktion, Bauen, Schaden, Sieg/Verlust
  • Komponenten: Position, Lebenspunkte, Bewegung, Angriffsverhalten, Typzuordnung, Ressourcenproduktion
  • UI: Minimales HUD, Ressourcenanzeige, Build-Menü, Ready-Knopf
  • Input-System: Verarbeitung von Maus und Tastatur zur Platzierung und Steuerung
  • Save-System (lokal): Persistiert Spielfortschritt lokal

Besonderheiten

  • Zeitreise-System: Speicherung von Spielzuständen (Entity-Zustände, Ressourcen, Karte) zur Wiederholung einer Runde
  • Kartenaufbau: Unterstützt manuelle oder prozedural generierte Karten mit Zonenlogik (HQ, Ressourcenzonen, Gegnerzonen)
  • Balancing-Logik: Geplant durch mathematische Kurvenfunktion basierend auf Runde/Tag

7. Externe Schnittstellen (External Interfaces)

Frontier ist als vollständig lokales Einzelspieler-Spiel konzipiert. Externe Schnittstellen beschränken sich deshalb auf ein Minimum:

  • Update-Prüfung via GitHub: Beim Start des Spiels wird optional über eine einfache Schnittstelle geprüft, ob im GitHub-Repository eine neue Version verfügbar ist. Falls ja, kann diese heruntergeladen und installiert werden. Die Implementierung erfolgt über GitHub Actions und ggf. einen einfachen HTTP-Request auf eine Raw-Datei oder Release-API.

  • Dateibasiertes Speichern und Laden: Der Spielfortschritt wird lokal auf dem Dateisystem gespeichert. Dies stellt eine einfache externe Schnittstelle zum Betriebssystem dar.

Weitere klassische externe Schnittstellen wie Web-APIs, Multiplayer-Verbindungen, Authentifizierung oder Modding-Interfaces sind bewusst nicht Teil des Prototyps. Der Fokus liegt vollständig auf der Spielmechanik und der lokalen Ausführung.

8. Code

Aufbau und Grundstruktur

Das Spiel basiert auf einem modularen Entity-Component-System (ECS) mit dem Ashley-Framework. Die Spiellogik ist in Systems und Components aufgeteilt:

Element Beispiele
Systems ResourceSystem, DamageSystem, EnemySystem, BuildSystem
Components PositionComponent, HPComponent, ResourceComponent, EnemyComponent

Der Game-Loop wird vom zentralen Controller gesteuert, der die Ereignisse in die jeweiligen Systeme verteilt.

Zeitreise-Mechanik

Die Zeitreise-Funktionalität speichert zum Ende eines Spieltages den Zustand aller relevanten Entitäten. Beim Aktivieren der Zeitreise wird dieser Zustand wiederhergestellt.

Gespeicherte Elemente:

  • Gebäude (Position, Typ, Lebenspunkte)
  • Ressourcenstände
  • Gegnerzustände (optional je nach Implementierung)
  • Spielstatus (aktueller Tag, Fortschritt)

Format: Speicherung erfolgt als JSON-Daten.

Save/Load-Mechanik

Speicherungen erfolgen lokal auf dem Dateisystem in JSON-Format. Der Speichervorgang erfasst:

Gespeicherte Daten Beschreibung
Gebäude-Status Typ, Position, Lebenspunkte
Ressourcen Gold, Holz, Stein, Eisen
Tageszyklus Aktueller Tag, Zeitreise-Status

Der Ladevorgang beinhaltet den Tag und beginnt an diesem neu in der Phase bevor die Gegnerwelle startet.

Balancing-Mechanik

Das Balancing erfolgt über eine exponentielle Funktion, die die Schwierigkeit progressiv steigert.

Beispiel: Gegneranzahl = Basiswert × 1.2^Runde

Beispiel:

  • Runde 1: 5 Gegner
  • Runde 5: ca. 11 Gegner
  • Runde 10: ca. 30 Gegner

(Muss noch getestet und klar definiert werden)

Dadurch ergibt sich eine stetige, aber kontrollierbare Zunahme der Herausforderung.

Testing-Strategie

Eine strukturierte Teststrategie wird verwendet, bestehend aus Unit-Tests und Integrationstests.

Testtyp Ziel Beispiel
Unit-Tests Testen isolierter Logik (z. B. Schadenberechnung) Test eines einzelnen Systems
Integrationstests Zusammenspiel mehrerer Module (z. B. UI + Logic) Game-Loop + Stage
Screenshot-Tests Visuelle Überprüfung von UI/Spielbildschirmen Nur bei wichtigen UI-Elementen

Eine detaillierte Test-Decision-Matrix ist im README.md des Projekts dokumentiert.

Logging

Für Debugging und Fehleranalyse werden einfache Konsolenlogs genutzt:

Geloggte Informationen:

  • Statusänderungen bei Ressourcen
  • Platzierung und Schaden von Gebäuden
  • Fortschritt und Ablauf von Gegnerwellen
  • Aktivierung der Zeitreise-Funktion

Ziel ist es, Entwicklungs- und Spielfehler während der Tests frühzeitig zu erkennen.

9. Data

Datenmodell

Das Spiel Frontier nutzt ein einfaches Datenmodell, um den Spielstand zu speichern. Die wichtigsten gespeicherten Elemente sind:

Datenobjekt Beschreibung
Hauptquartier (HQ) Position, Lebenspunkte, Aufladezustand Zeitreise
Ressourcengebäude Typ (Holzfällerei, Steinbruch, Eisenmine), Position, Produktionsstatus
Verteidigungstürme Typ, Position, Upgrade-Level, Lebenspunkte
Ressourcenbestand Gold, Holz, Stein, Eisen (Mengenwerte)
Tagesfortschritt Aktueller Tag, Status Zeitreise verfügbar/nicht verfügbar
Gegnerinformationen (optional) Falls nötig: aktive Gegnerpositionen, Zustände

Speicherort

  • Alle Spielstände werden lokal auf dem Client-Rechner gespeichert.
  • Die Speicherung erfolgt im JSON-Format.
  • Es gibt keine externe oder cloudbasierte Speicherung.

Datenverantwortung (Ownership)

  • Die vollständige Verantwortung über die gespeicherten Daten liegt beim Spieler.
  • Keine Server- oder Backend-Synchronisation.
  • Die Anwendung bietet keinen Schutz vor lokalem Datenverlust (z. B. Löschen der Datei).

Mengengerüst

  • Erwartete (grob geschätzte) Grösse eines Savegames: ca. 10–50 KB.
  • Optimierung auf minimale Dateigrösse: Nur notwendige Informationen (keine redundanten Daten).
  • Jede Ressource, jedes Gebäude und jede Spielfortschrittsinformation wird effizient serialisiert.

Archivierungs- und Backup-Strategien

  • Standardmässig ist nur ein aktiver Spielstand vorgesehen.
  • Beim Speichern wird der vorhandene Spielstand überschrieben.
  • Die Implementierung mehrerer Speicher-Slots oder automatischer Backups könnte in zukünftigen Versionen als Feature ergänzt werden.

Besonderheiten

  • Das Spiel führt beim Start einen Update-Check über GitHub durch.
  • Der Update-Mechanismus beeinflusst nicht die lokalen Spielstände.
  • Spielstände bleiben lokal erhalten, auch wenn eine neue Version installiert wird.

Diese schlanke und robuste Datenhaltung entspricht dem Fokus von Frontier auf ein lokal und einfach verwaltetes Spielerlebnis.

10. Infrastructure Architecture

Infrastrukturübersicht

Das Spiel Frontier wird vollständig lokal auf Systemen betrieben.

Element Beschreibung
Zielplattform Desktop-Computer oder Laptop
Betriebssysteme OS mit Java-Unterstützung
Java-Umgebung Entwickelt unter der Javaversion 21 (OpenJDK oder vergleichbare Distribution)
Ausführung Lokale Installation

Hardwareanforderungen

  • Jedes Gerät, das Windows 11 oder eine vergleichbare moderne Umgebung flüssig betreiben kann, genügt.
  • Empfohlene (geschätzte) Mindestanforderungen:
    • 4–8 GB RAM
    • 500 MB freier Speicherplatz

Besonderheiten

  • Keine Server, Cloud-Komponenten oder externe Infrastrukturanforderungen.
  • Keine Redundanz-, Failover- oder Disaster-Recovery-Strategien notwendig.
  • Keine Skalierungsanforderungen, da Einzelspieler-Offlinebetrieb.
  • Alle Ressourcen-Ownerships liegen beim lokalen Nutzer.

10. Installation (Deployment)

Installationsübersicht

Die Installation und das Deployment von Frontier erfolgt über GitHub und den eigens entwickelten Launcher.

Schritt Beschreibung
1. GitHub-Download Clone oder Download des aktuellen Releases von GitHub
2. Ausführung des Launchers Der Launcher prüft automatisch auf neue Versionen via GitHub.
3. Start des Spiels Erfolgt über den Launcher, der die lokal gespeicherte oder aktualisierte JAR-Datei startet.

Deployment-Details

  • Update-Prüfung: Der Launcher führt bei jedem Start eine Prüfung gegen das GitHub-Repository durch.
  • Download und Aktualisierung: Falls eine neue Version verfügbar ist, wird diese automatisch heruntergeladen und ersetzt die lokale Version.
  • Start des Spiels: Erfolgt manuell über den Launcher.
  • Rollback: Keine explizite Rollback-Strategie vorhanden. Bei Problemen muss eine ältere Version manuell neu installiert werden.

Automatisierungsgrad

  • Update-Check: Automatisiert.
  • Deployment: Teilautomatisiert (Updates), Spielstart manuell.

Besonderheiten

  • Die lokalen Spielstände werden bei Updates nicht überschrieben.
  • Keine weitere Konfiguration notwendig: Das Spiel läuft direkt nach dem Update und Start.

Diese einfache Infrastruktur- und Deployment-Strategie unterstützt den Fokus von Frontier auf ein unkompliziertes, lokal spielbares Tower-Defense-Erlebnis.

11. Operation und Support

Überwachungs- und Support-Funktionen

Das Spiel Frontier setzt einfache Debugging-Mechanismen für den Entwicklungsprozess ein. Diese Funktionen unterstützen die Entwickler, sind aber für Spieler:innen im normalen Betrieb nicht sichtbar.

Funktion Beschreibung
Debug-Logging Gezielt gesetzte Konsolen-Ausgaben während der Laufzeit zur Unterstützung der Fehleranalyse
Fehlermeldungen Fehler werden als Konsolen-Ausgaben während des Spiels angezeigt
Laufzeitanalyse Entwickler können während des Spiels über die Konsole Statusinformationen überprüfen

Hinweis: Die Art und Menge der Debug- und Status-Logs wird von den jeweiligen Entwickler:innen je nach Komplexität und Bedarf des bearbeiteten Issues individuell festgelegt.

Fehler- und Statuslogging

  • Alle Logs sind volatile: Sie werden nicht gespeichert, sondern existieren nur während der aktuellen Spielsitzung.
  • Unterschiedliche Issues führen zu unterschiedlich detaillierten Log-Ausgaben (je nach Problemkomplexität).
  • Spieler:innen sehen keine Debug-Ausgaben im Spiel selbst.

Logauswertung und Aufbewahrung

  • Keine strukturierte Speicherung oder Analyse der Logs vorgesehen.
  • Logs dienen ausschliesslich der kurzfristigen Fehlererkennung im Entwicklungsprozess.

Manuelle Administration

  • Für Spieler:innen sind keine manuellen Administrationsaufgaben erforderlich.
  • Savegames werden automatisch verwaltet und benötigen keine Eingriffe.

Konfigurationsänderungen und Neustart

  • Aktuell gibt es keine Grafikeinstellungen im Spiel.
  • Soundeinstellungen (z. B. Lautstärke) können dynamisch während des Spiels angepasst werden, ohne dass ein Neustart erforderlich ist.
  • Sollte in Zukunft eine Konfigurationsänderung für Grafikoptionen implementiert werden, könnte ein Neustart notwendig werden.

Besonderheiten

  • Das Spiel wurde bewusst so gestaltet, dass Betrieb und Support minimal sind.
  • Ziel ist ein reibungsloses Einzelspieler-Erlebnis ohne technische Barrieren oder Verwaltungsaufwand für Endnutzer:innen.

Frontier ist damit auf eine einfache Bedienung und wartungsarme Nutzung optimiert.

12. Entscheidungs-Logbuch (Decision Log, ADR/MADR)\

12.1 Entscheidungen vor SW 6

Game Engine: LibGDX

  • Status: accepted
  • Date: Vor beginn des semseters
  • Drivers: Sercan Ay, Kevin Sonnek, Oliver Hearn

Context

Für die Entwicklung unseres Spiels musste eine passende Game Engine gewählt werden. Zur Auswahl standen unter anderem Unity, und LibGDX.

Decision

Wir haben uns für LibGDX entschieden.

Consequences

Die Entscheidung fiel zugunsten von LibGDX, da zwei Teammitglieder bereits fundierte Erfahrungen aus dem Modul PM3 mitbringen. Dadurch profitieren wir von einer flachen Lernkurve, schnelleren Entwicklungsschritten und weniger Einarbeitungszeit. Zudem ist LibGDX leichtgewichtig, Java-basiert und gut geeignet für 2D-Spiele – passend zu unserem Projektumfang.

12.2 Entscheidungen vor SW 7

Entscheidung: Assets können unterschiedliche Tile-Größen haben (z. B. 1 oder 3 Tiles breit)

  • Status: accepted
  • Datum: [03-04-2025]
  • Entscheidungsträger: gesamtes Team
  • Technische Story: [Kein Ticket verlinkt]

Kontext und Problemstellung

Bisher unterstützt der Code nur Assets, die genau eine Kachel (Tile) breit sind. Dies limitiert das visuelle und funktionale Design der Spielwelt erheblich. Wir möchten auch größere Assets ermöglichen, z. B. Gebäude, die drei Kacheln breit sind, um mehr Vielfalt und strategische Tiefe im Gameplay zu schaffen. Daher muss der Code angepasst werden, damit verschiedene Asset-Größen unterstützt werden.

Entscheidungsgründe

  • Flexibleres Game Design
  • Bessere visuelle Vielfalt
  • Vorbereitung auf zukünftige Gebäudetypen mit größeren Abmessungen
  • Reduktion von Workarounds im Level-Design

Betrachtete Optionen

  • Status quo beibehalten (nur 1-Kachel-große Assets)
  • Unterstützung für mehrere Breiten (z. B. 1 oder 3 Tiles)
  • Dynamische Größen für Assets vollständig einführen (beliebige Breiten)

Ergebnis

Ausgewählte Option: Unterstützung für mehrere Breiten (z. B. 1 oder 3 Tiles)

  • einfache Erweiterung ohne komplettes Rewriting
  • deckt die aktuellen Anforderungen ab
  • kompatibel mit bestehenden Datenstrukturen bei minimalen Änderungen

Vor- und Nachteile der Optionen

Option 1: Nur 1-Tile-Assets

  • einfach zu implementieren
    – limitiert Designmöglichkeiten, wirkt eintönig

Option 2: 1 oder 3 Tiles erlaubt

  • gute Balance zwischen Flexibilität und Komplexität
    – Spezialfälle erfordern zusätzliche Logik

12.3 Entscheidungen vor SW 8

Entscheidung: Nur wichtige Punkte im Spiel testen

  • Status: accepted
  • Datum: [05-05-2025]
  • Entscheidungsträger: Team

Kontext

Wartbarkeit und spätere Refaktorierbarkeit verbessern.

Entscheidung

Nur zentrale Systeme testen, die direkt mit der Engine oder Helferklassen wie dem BuildingPlacer/Remover interagieren.

Konsequenzen

Einfacheres Debugging und sicherere Änderungen.

Entscheidung: Verwendung einer separaten Test-Map

  • Status: accepted
  • Datum: [05-05-2025]
  • Entscheidungsträger: kevin Sonnek

Kontext

Isolierter Kartenkontext war notwendig für Systemtests.

Entscheidung

Verwendung einer Mock-Map mit Testengine.

Konsequenzen

Schnellere und fokussiertere Tests.

Entscheidung: Stil von 16x16 auch für größere Gebäude beibehalten

  • Status: accepted
  • Datum: [05-05-2025]
  • Entscheidungsträger: Team

Kontext

Visuelle Konsistenz und technische Einfachheit.

Entscheidung

Keine detaillierteren Tiles (z. B. 32x32). Falls nötig, größere Strukturen durch Upscaling von 16x16 mit Nearest-Neighbor erzeugen.

Konsequenzen

Weniger Sprite-Aufwand, konsistentes visuelles Erscheinungsbild.

Entscheidung: Mehrkachelige Ressourcen zulassen

  • Status: accepted
  • Datum: [05-05-2025]
  • Entscheidungsträger: Team

Kontext

Wird bereits durch Gebäudelogik unterstützt.

Entscheidung

Ressourcen dürfen auch mehr als eine Kachel belegen (z. B. große Steine).

Konsequenzen

Mehr Designmöglichkeiten mit minimalem Mehraufwand.

12.4 Entscheidungen vor SW 9

Entscheidung: Trennung von kontinuierlichen und einmaligen Animationen

  • Status: accepted
  • Datum: [05-05-2025]
  • Entscheidungsträger: Kevin Sonnek

Kontext

Bessere Steuerung z. B. von Angriffen vs. Idle/Weglauf-Animationen.

Entscheidung

Getrennte Systeme mit gemeinsamer Animations-Queue verwenden.

Konsequenzen

Animationen einfacher steuer- und kombinierbar.

12.5 Entscheidungen vor SW 10

Entscheidung: Wände nur noch 1x1 statt 2x2 oder 3x3

  • Status: accepted
  • Datum: [05-05-2025]
  • Entscheidungsträger: Kevin Sonnek

Kontext

Mehrkachelige Wände erhöhen Komplexität und Sprite-Aufwand.

Entscheidung

Nur 1x1-Wand-Tiles zulassen.

Konsequenzen

Vereinfachte Implementierung, Verzicht auf Festungs-Optik.

12.6 Entscheidungen vor SW 11

Entscheidung: Verzicht auf Progress-Phase im Rundenverlauf

  • Status: draft
  • Datum: [05-05-2025]
  • Entscheidungsträger: Team

Kontext

Progress-Phase brachte kaum spielerischen Mehrwert.

Entscheidung

Nur noch Collection- und Angriffsphase, Progress wird vorerst übersprungen.

Konsequenzen

Vereinfachter Turnablauf, Test der Spieltiefe ohne diese Phase.

12.7 Entscheidungen vor SW 12

Entscheidung: Drei standardisierte Gegnertypen

  • Status: accepted
  • Datum: [2025-05-04]
  • Entscheidungsträger: Thomas Hilberink

Kontext

Klare, einfache Gegnertypen erleichtern Balancing und Gameplay-Logik.

Entscheidung

Einführung von drei Grundtypen:

  • Orc: Standardgegner
  • Goblin: schneller, schwacher Gegner
  • Dämon: langsamer, starker Tank-Gegner

Konsequenzen

  • Einfacheres Balancing
  • Klare visuelle Unterscheidbarkeit
  • Grundlage für spätere Spezialeinheiten

Entscheidung: Gegneranzahl und Typenverteilung per Funktion bestimmen

  • Status: accepted
  • Datum: [2025-05-04]
  • Entscheidungsträger: Kevin Sonnek

Kontext

Starre oder lineare Modelle boten zu wenig Skalierbarkeit und Herausforderung.

Entscheidung

Gegneranzahl wird pro Runde durch Funktion berechnet:
`f(x) = a * b^(x * c) + d * sin(x + e) + f Die Gegnertypverteilung erfolgt prozentual anhand definierter Schwellenwerte (z. B. Runde 5, 8, 12).

Konsequenzen

  • Schwierigkeit skaliert automatisch
  • Mehr Abwechslung mit Fortschritt
  • Balancing über Funktion und Prozente leicht anpassbar