Codebase beginnen #61
Labels
No labels
bug
duplicate
enhancement
est/∞
est/0
est/0.5
est/1
est/14
est/2
est/3
est/5
est/8
est/none
help wanted
kind/task
kind/user story
organisation
priority/high
priority/low
priority/mid
question
team
wontfix
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ufr/sopra10#61
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Konzepte und erste Implementierungen
Vorschläge zur Datenstruktur, Das habe ich vorher nicht optimal strukturiert. Die wichtigsten sind die Dateien der Kernebene. Ich hatte die gesamte Kernlogik zuvor in Game1.cs geschrieben, was es im späteren Verlauf zu unübersichtlich und schwer zu warten machte.
I. Kernmanagement-Ebene (Systems / Core Management Layer)
Diese Ebene koordiniert den Spielfluss, die Eingaben und die Interaktion der Objekte.
Game1.cs / GameplayManager:
Zweck: Dient als Hauptkoordinator und Programm-Einstiegspunkt.
Aufgabe: Verwaltet den obersten Spielzustand (GameState), ruft sequenziell die Update- und Draw-Methoden aller anderen Managern auf und koordiniert den Wechsel zwischen den Menüs.
EntityManager.cs (Einheiten-Manager):
Zweck: Zentrales Management aller beweglichen und statischen Entitäten (Spieler, Gegner, Gebäude).
Aufgabe: Speichert die Listen von Player- und Enemy-Objekten und führt die allgemeine Aktualisierungslogik (Update) für alle Einheiten aus.
CollisionSystem.cs (Kollisionssystem):
Zweck: Führt alle räumlichen Kollisionen durch und wendet die Konsequenzen an.
Aufgabe: Überprüft Kollisionen zwischen Projektilen und Gegnern, Gegnern und Spielern sowie die Interaktion mit Terrain-Kachel-Attributen (z.B. Eis, Wasser).
SkillSystem.cs (Fähigkeitssystem):
Zweck: Verwaltet alle aktiven und passiven Fähigkeiten sowie deren Abklingzeiten und Upgrades.
Aufgabe: Führt die Update-Logik für alle Skills durch und wendet den gewählten Upgrade-Effekt an (ApplyUpgrade).
PersistenceManager.cs:
Zweck: Verantwortlich für das Speichern und Laden des Spielzustands in externen Dateien (JSON).
Aufgabe: Konvertiert den Spielzustand in die GameData-Struktur und führt Dateisystem-Operationen durch.
II. Spielobjekt-Ebene (Entities / Game Object Layer)
Diese Ebene definiert die Daten und das Verhalten der einzelnen Einheiten.
Player.cs (Spielfigur):
Zweck: Kapselt alle spielerspezifischen Daten.
Aufgabe: Speichert die individuelle Position, Gesundheit (LP), Geschwindigkeit (GSW), Animationsstatus und die Skills (z.B. SnowballSkill, DashSkill) dieses spezifischen Spielers.
Enemy.cs (Gegner-Basisklasse):
Zweck: Basisklasse für alle Gegner und statischen Requisiten.
Aufgabe: Enthält die allgemeine KI-Logik (Verfolgung), grundlegende Kollisionsrahmen und die vererbbaren Eigenschaften wie Health und ExperienceDropValue.
Projectile.cs (Projektil):
Zweck: Verwaltet die Flugbahn, Geschwindigkeit und Fraktion (Faction) der von Spielern oder Gegnern abgefeuerten Projektile.
ExperienceGem.cs:
Zweck: Definiert das Sammelobjekt für Erfahrung.
Aufgabe: Verwaltet den Wert, den Attraktionsradius und die Bewegungslogik in Richtung des Spielers.
III. Daten- und Hilfs-Ebene (Data / Utility Layer)
Diese Ebene enthält statische Konfigurationen, UI-Komponenten und Hilfsfunktionen.
EnemyStats.cs:
Zweck: Dient als statisches Daten-Repository für alle Gegnertypen.
Aufgabe: Speichert alle Vorlagenwerte (z.B. MaxHealth, Speed, ShootRange) und ermöglicht dem EntityManager das datengetriebene Generieren von Gegnern.
LandmarkData.cs (im Data-Ordner):
Zweck: Definiert die festen Pixelkoordinaten, Texturen und Eigenschaften aller statischen Objekte (Häuser, Felsen, Wahrzeichen).
GameData.cs:
Zweck: Datenübertragungsobjekt (DTO). Definiert die Struktur der Daten, die in die JSON-Datei geschrieben werden.
Aufgabe: Enthält nur serialisierbare Felder (z.B. CurrentLevel, PlayerPositionX, Enemies).
UIManager.cs:
Zweck: Enthält Logik für die Erstellung und Anzeige aller UI-Elemente und Menüs (außerhalb der Weltansicht).
Aufgabe: Verwaltet die Draw-Logik für das HUD (Statistiken, Lebensbalken ) und die Menüfenster.
Camera2D.cs / MathUtils.cs:
Zweck: Enthält mathematische Hilfsfunktionen und die Matrixberechnung für die Kamera.
Aufgabe: Stellt Methoden zur Umwandlung von Welt- in Bildschirmkoordinaten und zur Begrenzung der Kamera bereit.
Lange Inheritance-Trees verringern Flexibilität und sind schwierig zu planen. Es sollte also, wenn möglich, Komposition vorgezogen werden. Eine pure Entity Component System-Architektur könnte flexibler sein, allerdings ist sie zu gewöhnungsbedürftig und benötigt viel Zeit zu Beginn, was sehr unpraktisch für dieses Projekt ist.
Der Entwurf basiert auf flexibel zusammensetzbaren Komponenten, die durch Dependency Injection verbunden werden. Jede Komponente ist zu Test-, Erweiterungs- und Wartungszwecken ein Interface. So sind Komponenten isoliert und von der tatsächlichen Implementation ihrer Abhängigkeiten weitgehend getrennt.
Die Architektur ist nicht vollständig, da einige Details noch unklar sind und die Implementationen von den konkreten Features abhängen. Sie sollte jedoch relativ leicht erweiterbar sein.
Zentrale Aspekte: Events, unabhängige Systeme, Manager und IWorld als zentrales Interface für sämtliche Komponenten, um mit der Welt zu interagieren (kann falls nötig weiter aufgetrennt werden).
Hi @chris,
This issue has exceeded our reasonable assumption of 10.00 hours per participant.
Please provide a reason why this ticket took so long.
ECS recherchieren (3h), Clean Code/Architecture Patterns (3h), Architekturkonzept (5h)
puh, das ist ja schon ein hinreichend unklares Ticket, dass der Soprabot passend angekreidet hat: Was hätte hier passieren sollen, und was war das erwartete Artefakt. Der @sopra-bot schaut nach Tickets die übermäßig viel Bearbeitungszeit haben, meistens weil da was beim loggen schief gegangen ist. Hier ist es halt, dass da schon von Anfang an unklar ist, was hätte das Erzeugnis sein sollen. ECS recherhche, Clean code (was auch immer das hier zu suchen hat), und Architektur sind ... drei getrennte Tasks, die auch drei getrennte Tickets haben sollten. Oder habe ich deine Zeitangabe falsch verstanden.
ah, @chris , damit es dich benachrichtigt :)
@vincent
Mir war zu Beginn auch noch nicht klar, wie viele Aspekte die Aufgabe hat. Die ECS-Recherche hat sich aus der Frage ergeben, welche grundlegenden Architekturansätze es gibt. Das war auch wichtig, weil die Grundidee von ECS sehr nützlich ist, aber das konnte ich vorher nicht wissen. Die ECS-Recherche hätte ich ja schlecht einfach verschieben können, weil sie in dem Moment wichtig war.
Das Artefakt sollte ein UML-Diagramm sein, das die Grundidee darstellt. Die Realisierung kann erst nach und nach folgen, weil die Architektur in der Gruppe besprochen werden muss.
@chris, alles klar.