From 062b98f041f0623a5b809dfbd965b95af514220e Mon Sep 17 00:00:00 2001 From: Dennis Westermann Date: Mon, 10 Aug 2026 21:19:31 +0200 Subject: [PATCH] docs(feedback): Testbericht T-01 vom 10.08.2026 zerlegen (#85-#94) Der Bericht zu Build 4053c15 bewertet die mit #80 eingefuehrte AE-Verknappung. Zehn Befunde, alle neu, drei mit benannter Abgrenzung zu #50, #52 und #12. Kritisch ist #85: SkirmishAiSystem.TryGetOwnFieldCell waehlt das Erntefeld allein nach Distanz und prueft IsExhausted nicht. Der Spielerpfad in RtsDeviceInput filtert bereits korrekt -- der KI-Pfad wurde bei #80 nicht nachgezogen. Daraus wird ein Livelock: EconomySystem raeumt die Feldzuordnung des leeren Feldes, die KI weist genau dadurch dasselbe Feld erneut zu. Die Datei liegt in der exklusiven Schreibhoheit des Einheitenstrangs (Sprint 13B), deshalb Issue statt Fix. Neu: - anonymisierte Fassung des Berichts als T-01 nach Nutzerfeedback_Ablauf.md - Vorschlag zur Sprintbildung, geschnitten nach Schreibhoheit, mit ausgewiesenen Vertragsflaechen (#89, #90, #94) Kein Sprint ist damit festgeplant. Co-Authored-By: Claude Opus 5 --- CHANGELOG.md | 16 + .../20_Vorschlag_Verknappungsfolgen.md | 125 ++++++++ .../Testberichte/2026-08-10_4053c15_T-01.md | 301 ++++++++++++++++++ 3 files changed, 442 insertions(+) create mode 100644 docs/production/hashkrieg/20_Vorschlag_Verknappungsfolgen.md create mode 100644 docs/production/hashkrieg/Testberichte/2026-08-10_4053c15_T-01.md diff --git a/CHANGELOG.md b/CHANGELOG.md index cdd6d71..ef68543 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -30,6 +30,22 @@ die Versionierung folgt (in der aktuellen Doku-Phase) dem Dokumentationsstand de spielerisch abgenommen und kein Meilenstein-Nachweis ### Hinzugefügt +- **Testbericht T-01 vom 10.08.2026 (Build `4053c15`) zerlegt — zehn Issues + (#85–#94) und ein Sprintvorschlag.** Der Bericht bewertet die mit #80 + eingeführte AE-Verknappung und zeigt, dass diese eine Änderung acht weitere + Systeme betrifft, die noch auf der alten Annahme stehen. Kritisch ist #85: + `SkirmishAiSystem.TryGetOwnFieldCell` wählt das Erntefeld allein nach Distanz + und prüft `IsExhausted` nicht — der Spielerpfad in `RtsDeviceInput` filtert + bereits korrekt, der KI-Pfad wurde bei #80 nicht nachgezogen. Daraus entsteht + ein Livelock: `EconomySystem` räumt die Feldzuordnung des leeren Feldes, die + KI weist genau dadurch dasselbe Feld erneut zu, und die Wirtschaft der KI + steht. Neu abgelegt sind die anonymisierte Fassung des Berichts + (`docs/production/hashkrieg/Testberichte/2026-08-10_4053c15_T-01.md`, Kennung + `T-01` nach [Nutzerfeedback_Ablauf.md](docs/production/Nutzerfeedback_Ablauf.md)) + und der Vorschlag zur Sprintbildung + (`docs/production/hashkrieg/20_Vorschlag_Verknappungsfolgen.md`), der die zehn + Befunde nach Schreibhoheit trennt und die Vertragsflächen ausweist. Kein + Sprint ist damit festgeplant - **Die Welle der Skirmish-KI kann in Kampfstärke statt in Köpfen messen (Verhalten `r6`):** `CombatStrength` bewertet eine Einheit als `Schaden × Leben / Feuerintervall` — ganzzahlig, eine Division, eine diff --git a/docs/production/hashkrieg/20_Vorschlag_Verknappungsfolgen.md b/docs/production/hashkrieg/20_Vorschlag_Verknappungsfolgen.md new file mode 100644 index 0000000..35b4079 --- /dev/null +++ b/docs/production/hashkrieg/20_Vorschlag_Verknappungsfolgen.md @@ -0,0 +1,125 @@ +# Vorschlag zur Sprintbildung: die Folgen der AE-Verknappung + +**Status:** Vorschlag zur Sprintbildung — **kein Sprint, keine Nummer, keine Zusage** | **Quelle:** [Testbericht T-01 vom 10.08.2026](Testberichte/2026-08-10_4053c15_T-01.md), Build `4053c15` | **Issues:** #85–#94 | **Ablauf:** [Nutzerfeedback_Ablauf.md](../Nutzerfeedback_Ablauf.md) | **Leitsatz:** endliche Felder sind kein Wert, sondern ein Systemwechsel + +## Worum es geht + +Mit [#80](https://github.com/VibecodingGermany/HashKrieg/pull/80) bekamen die +Aetherium-Felder eine endliche Reserve. Der Testbericht vom 10.08.2026 zeigt, +dass diese eine Änderung acht weitere Systeme betrifft, die noch auf der alten +Annahme stehen. Der Tester formuliert es selbst so: + +> „Die Einführung endlicher Ressourcen ist wesentlich größer als nur: ‚AE-Spawns +> haben jetzt einen Maximalwert.'" + +Zehn Befunde, alle neu, keiner ein Duplikat. Drei liegen nahe an bestehenden +Issues (#50, #52, #12); der Unterschied ist jeweils im Issue benannt. + +## Die Befunde nach Schreibhoheit + +Der Schnitt läuft über die Schreibhoheit, nicht über das Thema — sonst hebt ein +thematisch schlüssiges Paket die Trennung auf, die den Parallelbetrieb trägt +([13-15_Parallelbetrieb.md](13-15_Parallelbetrieb.md)). + +### A · Einheitenstrang (Sprint 13B, externer Beitragende) + +| Issue | Befund | Priorität | +|---|---|---| +| #85 | KI erntet nach Erschöpfung endlos auf dem leeren Feld weiter | **kritisch** | + +`Assets/_Project/Scripts/AI/` — exklusive Schreibhoheit des Einheitenstrangs. +Deshalb als Issue gemeldet und **nicht** von Maintainer-Seite gefixt. + +Der Befund ist kein Strategiemangel, sondern ein Livelock aus einer fehlenden +`IsExhausted`-Prüfung in `TryGetOwnFieldCell`. Das Minimum, das ihn beendet, ist +klein und in einem PR machbar. Die strategische Anforderung aus Abschnitt 8 des +Berichts (Erschöpfung prognostizieren, Felder sichern und bestreiten, Eskorten) +ist davon getrennt zu schneiden — wie, entscheidet der Stranginhaber im Rahmen +von Paket B4. + +### B · Maintainer-Strang, Wirtschaft und Oberfläche + +| Issue | Befund | Priorität | +|---|---|---| +| #86 | AE-Vorkommen zeigen ihren Restbestand nicht | **kritisch** | +| #87 | Startvorkommen: 9.000 AE gemessen, 10.000 gewünscht | hoch | +| #88 | Mehrfachauswahl: Befehle vom Anführer statt von der Schnittmenge | hoch | +| #91 | Baubereich ist unsichtbar | hoch | +| #93 | Kartendichte: fünf Felder auf 128×128 | hoch | + +Alles in `Simulation/Economy/`, `Gameplay/Match/` und `Presentation/` — keine +Berührung mit dem Einheitenstrang, parallel zu A lauffähig. + +### C · Vertragsflächen — bewusst keinem Strang zugeschlagen + +| Issue | Befund | Naht | +|---|---|---| +| #89 | Patrouille-Befehl | Register/Payload ↔ Bewegungsverhalten | +| #90 | „Bewachen"-Befehl für Eskorten | Register/Payload ↔ Begleit-/Reaktionsverhalten | +| #94 | Zentrale AE-Zone mit Chokepoints | Kartenlage ↔ `CostField`/`IsWalkable` | + +Beide Befehle brauchen einen Eintrag im **eingefrorenen** `CommandKind`-Register +(Schema v1, heute 1–17), eine neue Payload und Zustand pro Einheit im Snapshot. +Das ist ein API-/Schema-Vorgang: @api-guardian ist Pflicht, und die +Versionsrelevanz ist eher `major` als `minor`. Wer sie einem Strang still +zuschlägt, bricht entweder die Hoheit oder das Schema. + +### D · Inhaberentscheidungen + +| Issue | Frage | +|---|---| +| #92 | Wie wächst Territorium — zweites HQ, jedes Gebäude, etwas anderes? | +| #94 | Wird die Kartenmitte ein Gebiet mit Chokepoints? | + +#92 ist die dringendere der beiden. Der Code beantwortet die Frage heute schon, +nur hat es niemand ausgesprochen: `BuildInfluenceRadiusCells` misst ab **jedem +eigenen Bauanker**, nicht ab dem HQ — die Bauzone kriecht also mit jedem Gebäude +mit. Ob das gewollt ist, ist eine Festlegung, keine Implementierung. + +## Reihenfolge — nur wo eine Abhängigkeit besteht + +``` +#92 (Territorium entscheiden) + └─> #91 (Baubereichs-Overlay) ein Overlay auf eine Regel, die sich + └─> #93 (Kartendichte) danach ändert, ist doppelte Arbeit + └─> #94 (zentrale Zone) erst die Gesamtzahl, dann die Verteilung + +#86 (Restbestand sichtbar) + └─> #87 (Startmenge) ohne Anzeige wird geschätzt statt gerechnet; + der Tester lag um 4.000 AE daneben + +#85 (KI-Livelock) + └─> #93 (Kartendichte) mehr Felder machen den Stillstand nur + auffälliger, solange die KI eines nimmt +``` + +Ohne Abhängigkeit und jederzeit einzeln machbar: **#88**. + +Zwei Beobachtungen zur Reihenfolge, die nicht im Diagramm stehen: + +- **#85 und #86 sind beide als kritisch gemeldet, aber ungleich dringend.** #85 + macht den Skirmish nach einigen Minuten sinnlos — das ist der Grund, warum + dieser Bericht überhaupt sofort bearbeitet wurde. #86 macht eine vorhandene + Mechanik unlesbar. Beide zuerst, in dieser Reihenfolge. +- **#87 ist eine Zeile und trotzdem nicht trivial.** Die Frage dahinter — wie + lange soll ein Startfeld tragen? — hängt an Ernterate, Harvester-Zahl und + Baukosten und sollte einmal gerechnet werden. + +## Was hier ausdrücklich nicht passiert + +Kein Sprint wird festgeplant, keine Sprintdatei angelegt, keine Nummer vergeben, +keine bestehende Sprintdatei erweitert. Ob aus diesem Vorschlag ein Sprint wird, +ob mehrere zusammengelegt werden oder ob etwas entfällt, entscheidet der Inhaber. + +## Nebenbefund für die Umsetzung + +Die Feldlage steht **doppelt** im Repo: `Gameplay/Match/MatchBootstrap.cs:164` +und `tools/Nova.SimRunner/Determinism10000Scenario.cs:659`. Wer #87 oder #93 +umsetzt und nur eine Stelle ändert, lässt das Determinismus-Szenario driften. +Die Verdopplung selbst wäre einen eigenen Aufräum-Issue wert. + +## Änderungsverlauf + +| Version | Datum | Änderung | Autor | +|---|---|---|---| +| 1.0.0 | 2026-08-10 | Erstfassung aus Testbericht T-01, Build `4053c15` | Orchestrator | diff --git a/docs/production/hashkrieg/Testberichte/2026-08-10_4053c15_T-01.md b/docs/production/hashkrieg/Testberichte/2026-08-10_4053c15_T-01.md new file mode 100644 index 0000000..4a80dfb --- /dev/null +++ b/docs/production/hashkrieg/Testberichte/2026-08-10_4053c15_T-01.md @@ -0,0 +1,301 @@ +# Testbericht — Hashkrieg Beta + +| Feld | Wert | +|---|---| +| Supabase-ID | `933c945a-2e8a-4148-b0a5-d29cff551b87` | +| Eingegangen | 2026-08-10 | +| Tester | `T-01` | +| Build | `4053c15` | +| Plattform | macOS | +| Testtyp | Gameplay / Economy / AI / UX / Map Design | +| Status bei Abruf | `neu` | + +> **Anonymisierte Fassung.** Wortlaut des Befundteils unverändert aus +> `public.testberichte`, nicht gekürzt und nicht geglättet. Entfernt sind +> ausschließlich personenbeziehbare Felder: Klarname, IP, User-Agent, +> Browser-Kennung, Tester-Token, Bildschirmauflösung, Sprache und Zeitzone. +> Die Auflösung der Kennung `T-01` liegt allein in Supabase. +> +> **Ein Name steht bewusst im Text.** Der Befundtext nennt in Abschnitt 8 +> zweimal den Beitragenden des Einheitenstrangs. Diese Nennung bleibt: sie +> weist eine Zuständigkeit zu und benennt keinen Feedbackgeber. Der Ablauf +> nimmt Rollennennungen von Inhaber und Maintainern ausdrücklich von der +> Ersetzungsregel aus, und der Strang ist in +> [13-15_Parallelbetrieb.md](../13-15_Parallelbetrieb.md) ohnehin öffentlich +> zugewiesen. +> +> Ablauf und Begründung: [Nutzerfeedback_Ablauf.md](../../Nutzerfeedback_Ablauf.md) + +--- + +Project Nova – Beta-Testbericht + +Testdatum: 10.08.2026 +Version: Aktuelle Version vom 10.08.2026 +Testtyp: Gameplay / Economy / AI / UX / Map Design + +Gesamtfazit + +Die aktuelle Version ist ein deutlicher Fortschritt. Viele der zuvor auffälligen Probleme sind behoben oder verbessert worden. Das aktuell größte Gameplay-Thema ist aus meiner Sicht die neu eingeführte Verknappung von Aetherium (AE). + +Dass Ressourcen endlich sind, halte ich grundsätzlich für eine gute Entscheidung. Dadurch entstehen strategische Ziele, Expansion und Konflikte um Ressourcenfelder. Aktuell fehlt aber noch die visuelle, spielmechanische und insbesondere die AI-seitige Umsetzung dieser neuen Logik. + +⸻ + +🔴 1. Aetherium-Vorkommen müssen ihren Restbestand visualisieren + +Priorität: Kritisch +Bereich: Economy / UI / Assets / Gameplay + +Aetherium-Vorkommen sind jetzt endlich, visuell ist ihr Verbrauch aber nicht erkennbar. + +Aktuell bleiben die blauen Platzhalter-Steine unverändert bestehen, selbst wenn das dazugehörige Vorkommen vollständig erschöpft ist. + +Gewünschtes Verhalten + +Aetherium-Vorkommen sollten anklickbar sein. Nach Auswahl sollte mindestens der verbleibende AE-Bestand angezeigt werden, beispielsweise: + +Aetherium-Vorkommen +6.420 / 10.000 AE + +Zusätzlich sollte das Vorkommen seinen Verbrauch auch direkt auf der Map visualisieren. + +Aktuell besteht ein volles Vorkommen beispielsweise aus sieben blauen Steinen. Diese könnten mit sinkendem Bestand schrittweise verschwinden: + +7 → 6 → 5 → 4 → 3 → 2 → 1 → leer + +Bei vollständiger Erschöpfung muss auch visuell eindeutig erkennbar sein, dass dort nichts mehr abgebaut werden kann. + +Warum wichtig? + +Der Spieler muss auf einen Blick einschätzen können: + +* Welche Vorkommen noch produktiv sind +* Welche fast erschöpft sind +* Welche bereits leer sind +* Für welche Ressourcenfelder sich Expansion oder Verteidigung noch lohnt + +Die Ressourcenknappheit wird dadurch von einer unsichtbaren technischen Mechanik zu einer tatsächlich strategisch lesbaren Spielmechanik. + +⸻ + +🔴 2. Startvorkommen enthält zu wenig Aetherium + +Priorität: Hoch +Bereich: Balancing / Economy + +Das Aetherium-Vorkommen an der Ausgangsbasis scheint aktuell ungefähr 5.000 AE zu enthalten. + +Das fühlt sich für den normalen Spielmodus zu knapp an. + +Vorschlag + +Das garantierte Startvorkommen sollte mindestens: + +10.000 AE + +enthalten. + +Der Spieler sollte damit genug wirtschaftlichen Spielraum bekommen, um eine grundlegende Basis aufzubauen und die Expansion zum nächsten Ressourcenfeld vorzubereiten. + +Die Verknappung soll strategischen Druck erzeugen, aber nicht bereits unmittelbar nach Spielbeginn die Basisökonomie abwürgen. + +⸻ + +🟠 3. Multi-Selection benötigt weiterhin ein Informationsmenü + +Priorität: Hoch +Bereich: UI / Unit Control + +Bei der Auswahl mehrerer Fahrzeuge bzw. Einheiten fehlt weiterhin eine vernünftige Übersicht über die aktuelle Auswahl. + +Der Spieler sollte erkennen können: + +* Welche Einheiten ausgewählt sind +* Wie viele Einheiten ausgewählt sind +* Einheitentypen +* Zustand / HP +* Mögliche gemeinsame Befehle + +Gerade mit größer werdenden Armeen wird dieses UI zunehmend wichtig. + +⸻ + +🟠 4. Patrouillenfunktion für Einheiten + +Priorität: Mittel / Hoch +Bereich: Unit Control + +Einheiten sollten auf Patrouille geschickt werden können. + +Gewünschter Ablauf + +1. Einheit(en) auswählen +2. Patrouille auswählen +3. Start- und Endpunkt definieren +4. Einheit bewegt sich dauerhaft zwischen diesen Punkten +5. Gegner im relevanten Bereich werden entsprechend der Combat-Logik bekämpft + +Das wird insbesondere für die Sicherung von Basen, Zufahrten und Ressourcenfeldern wichtig. + +⸻ + +🟠 5. „Bewachen“-Befehl für Einheiten + +Priorität: Hoch +Bereich: Unit Control / Combat + +Kampfeinheiten sollten andere Einheiten bewachen können. + +Beispiel: + +Panzer auswählen → Bewachen → Harvester auswählen + +Der Panzer begleitet anschließend den Harvester und reagiert auf Bedrohungen. + +Das wird durch die neue Ressourcenknappheit besonders relevant: Harvester müssen künftig weitere Strecken zwischen Basis und externen AE-Vorkommen zurücklegen. Spieler brauchen deshalb eine komfortable Möglichkeit, Eskorten zu organisieren. + +⸻ + +🟠 6. Baubereich muss sichtbar werden + +Priorität: Hoch +Bereich: Building / UI / UX + +Die Einschränkung des Baubereichs rund um die eigene Basis ist grundsätzlich sinnvoll. Aktuell ist die Grenze allerdings nicht ausreichend sichtbar. + +Gewünschtes Verhalten + +Beim Anklicken des Hauptquartiers sollte der erlaubte Baubereich beispielsweise als grüne Fläche / Radius / Grid-Overlay dargestellt werden. + +Damit versteht der Spieler unmittelbar: + +Innerhalb dieses Bereichs darf ich Gebäude platzieren. + +Beim Platzieren eines Gebäudes sollte die Grenze ebenfalls sichtbar sein. + +⸻ + +🟠 7. Expansion des Baubereichs benötigt eine klare Spielmechanik + +Priorität: Hoch +Bereich: Game Design / Building + +Durch den begrenzten Baubereich entsteht automatisch die Frage: + +Wie erweitert der Spieler sein Territorium? + +Falls die vorgesehene Mechanik lautet, dass weitere Hauptquartiere gebaut werden und dadurch neue Bauzonen entstehen, sollte diese Mechanik klar definiert und kommuniziert werden. + +Gleichzeitig muss der initiale Radius ausreichend groß sein. + +Momentan wirkt der Platz bereits nach einigen Kraftwerken und beispielsweise einer Fahrzeugfabrik relativ schnell ausgeschöpft. + +Zu klären + +* Erweitert ein zweites HQ den Baubereich? +* Gibt es später andere Gebäude zur Gebietserweiterung? +* Dürfen sich Bauzonen überschneiden? +* Wie groß muss der Startbereich sein, damit eine funktionierende Basis darin Platz findet? + +⸻ + +🔴 8. AI berücksichtigt die neue Ressourcenknappheit offenbar noch nicht + +Priorität: Kritisch +Bereich: AI / Economy +Relevant für: Arn + +Hinweis für Arn: Durch die Einführung begrenzter AE-Vorkommen hat sich eine zentrale Annahme der bisherigen Economy geändert. Die AI scheint aktuell noch auf der vorherigen Ressourcenlogik zu basieren. + +Das Verhalten im Test: + +1. AI baut zu Beginn drei bis vier Gebäude. +2. AI produziert einige Einheiten. +3. Es folgen einige Angriffswellen. +4. Das lokale AE-Vorkommen erschöpft sich. +5. Danach kommt die AI wirtschaftlich praktisch zum Stillstand. + +Ich konnte nicht beobachten, dass die AI aktiv weitere AE-Vorkommen erschließt bzw. um diese konkurriert. + +Neue strategische Anforderung + +Mit endlichen Ressourcen muss die AI Ressourcenfelder als strategische Ziele verstehen. + +Sie sollte unter anderem: + +* Restbestand eigener Ressourcen überwachen +* Erschöpfung prognostizieren +* Weitere AE-Vorkommen suchen +* Harvester rechtzeitig zu neuen Vorkommen schicken +* Ressourcenfelder sichern +* Bedrohungen rund um Ressourcenfelder bewerten +* Ressourcenfelder des Gegners angreifen bzw. bestreiten +* Eskorten für weit entfernte Harvester einsetzen +* Expansion beginnen, bevor das aktuelle Vorkommen vollständig erschöpft ist + +Das ist durch die neue Economy keine optionale Optimierung mehr, sondern eine Kernanforderung an die AI. + +Die Ressourcenknappheit verändert damit die strategische AI-Logik fundamental. + +⸻ + +🟠 9. Deutlich mehr Aetherium-Vorkommen auf der Map + +Priorität: Hoch +Bereich: Map Design / Balancing + +Die aktuelle Map benötigt mindestens ungefähr doppelt so viele AE-Vorkommen, eventuell sogar mehr. + +Endliche Ressourcen funktionieren strategisch vor allem dann gut, wenn Spieler mehrere Alternativen haben und tatsächlich Entscheidungen treffen müssen: + +* Welches Feld erschließe ich? +* Welches verteidige ich? +* Welches überlasse ich dem Gegner? +* Wo expandiere ich? +* Wo greife ich an? + +Zu wenige Vorkommen machen die Mechanik dagegen schnell zu einem reinen Engpass. + +⸻ + +🟢 10. Zentrales Aetherium-Gebiet als strategisches Endgame-Ziel + +Priorität: Designvorschlag +Bereich: Map Design / Game Design + +Für die Mitte der Map schlage ich einen besonders wertvollen Bereich vor. + +Konzept + +Im Zentrum befindet sich eine größere, abgeschlossene Zone mit etwa: + +4–6 Aetherium-Vorkommen + +Diese Zone ist von allen vier Seiten erreichbar, besitzt jedoch jeweils schmale Zufahrten / Chokepoints. + +Dadurch entsteht automatisch ein strategischer Hotspot. + +Wer die Mitte kontrolliert, erhält einen erheblichen wirtschaftlichen Vorteil. Gleichzeitig kann die Position aufgrund der schmalen Zufahrten mit Einheiten und Verteidigungstürmen befestigt werden. + +Damit entsteht ein natürlicher Final-Showdown-Bereich: + +Mitte erobern → Zugänge sichern → Verteidigung aufbauen → AE kontrollieren → wirtschaftlichen Vorteil ausspielen + +Die Map selbst erzeugt dadurch einen klaren Konfliktpunkt, ohne dass dem Spieler künstlich vorgeschrieben werden muss, dort zu kämpfen. + +⸻ + +Übergeordnetes Design-Thema dieser Testrunde + +Die Einführung endlicher Ressourcen ist wesentlich größer als nur: + +„AE-Spawns haben jetzt einen Maximalwert.“ + +Sie verändert mehrere Systeme gleichzeitig: + +Economy → Expansion → Map Control → Harvester-Routen → Eskorte → Base Expansion → Combat → AI-Strategie + +Genau darin liegt aber auch viel Potenzial. Wenn diese Systeme miteinander verbunden werden, werden AE-Vorkommen zu echten strategischen Objekten und die Map bekommt automatisch umkämpfte Gebiete, Frontlinien und Expansionsdruck. + +Der wichtigste nächste Schritt ist deshalb aus meiner Sicht, die neue Ressourcenknappheit für Mensch und AI vollständig lesbar und strategisch nutzbar zu machen.