100 lines
11 KiB
Markdown
100 lines
11 KiB
Markdown
# Handbuch / Gameplay – Übergabe
|
||
|
||
Stand: 15. Oktober 2026. Daten sind einsatzfähige Unity-Assets, aber vorläufig balanciert. Grafik und echtes Kampfverhalten werden nicht durch das Handbuch implementiert.
|
||
|
||
## Wo die Daten liegen
|
||
|
||
- `Assets/HandbookData/Buildables`: 19 Waffen, Gebäude, Fallen und Fähigkeiten.
|
||
- `Assets/HandbookData/Enemies`: 5 Gegnertypen.
|
||
- `Assets/HandbookData/TestTurmkatalog.asset`: gemeinsamer Katalog; Name historisch, Inhalte jetzt vollständiger.
|
||
- Bestehende `.meta`-GUIDs und Typ-IDs wurden erhalten. Asset-Dateien wurden mit Unity verschoben, nicht neu erzeugt. `special_0` (bisher generische Falle) ist jetzt Caltrops. `energy_0` heißt nun Laser Gewehr, `special_2` Sauger.
|
||
|
||
## Was feststeht / was erfunden ist
|
||
|
||
Die Screenshot-Tabelle ist die Quelle für Typen, Kostenverhältnisse, Munition, relative Bewertungen, Sonderfunktionen, Dropbereiche, 3–10 Zwerge und den 3/3-Sekunden-Wechsel der Whack-a-moles. Kosten im Gameplay = Tabellenverhältnis × 10 Energie. Diese Umrechnung ist unsere Annahme, kein Team-Beschluss.
|
||
|
||
Alle Assets sind mit `provisional` und `designNotes` gekennzeichnet. Konkrete Schäden, Feuerraten, Reichweiten, Energieverbrauch, HP, Objektlimits und drei Upgrade-Stufen sind vorläufig. `sourceCostRating` bewahrt den Tabellenwert. Keine Zahlen aus `summary` oder `description` parsen: diese Felder sind nur Anzeige.
|
||
|
||
Mauertürme sind nicht von Gegnern angreifbar und nicht durch Schaden zerstörbar. Sie können trotzdem bei Etagenverlust entfernt werden. Mauerlimit: 8. Prototyp-Innenfeldlimit: 6.
|
||
|
||
Vorläufige Specials:
|
||
|
||
| Typ | Fläche | Regel |
|
||
| --- | --- | --- |
|
||
| Generator | Mauer | zählt zu 8, max. 2; 5 Energie/s, Kapazität +100 |
|
||
| Sauger | Mauer | zählt zu 8, max. 2; 1 Leiche/s, 1 Energie/s Wartung |
|
||
| Spiegel | Innenfeld | max. 3; 80 HP, angreifbar, mit R drehbar |
|
||
| Reparaturtrupp | Schleuse | max. 1; 60 HP, angreifbar, Reparatur 2 HP/s |
|
||
| Bombardement | Innenfeld als Flächenziel | einmaliger Einsatz, 120 s Cooldown; kein dauerhaft gebautes Objekt |
|
||
| Caltrops | Innenfeld | Grundfläche 1×1, max. 3, 5 Kontakte; 60 s Cooldown |
|
||
| Barrikade | Innenfeld | Grundfläche 3×1, max. 2, 150 HP, 30 s Dauer; 180 s Cooldown; echte Pfadprüfung erforderlich |
|
||
|
||
Schaden pro Treffer in unseren Annahmen: Very Low=5, Low=8, Mid=20, High=40, Very High=60. Reichweite: Very Low=1, Low=2, Mid=3,5, High=5, Very High=7. Unendlich ist ein eigenes Flag; keine Infinity-Fließkommazahl. Kontinuierliche Waffen besitzen ein eigenes Flag. Feuerraten sind separat geraten. Wartung Low/Mid/High/Very High = 1/3/6/12 Energie/s. N/A bleibt 0.
|
||
|
||
## So implementiert dein Gameplay die Verbindung
|
||
|
||
1. Eigene `MonoBehaviour`-Komponente implementiert `IHandbookGameplay` aus `Assets/Scripts/HandbookUI/IHandbookGameplay.cs`.
|
||
2. Komponente in der Test-/Spielszene anlegen und bei `HandbookRoot > Handbook Controller > Gameplay Backend` zuweisen. Leer bedeutet: Prototyp-Backend.
|
||
3. `CheckAvailability` prüft Ressourcen, Cooldowns und Mengenlimits ohne Mutation.
|
||
4. `CheckBuild(BuildRequest)` prüft zusätzlich Fläche, Grundfläche, Überlappungen und gegebenenfalls Pfade. Vor der Mutation immer erneut prüfen.
|
||
5. `ExecuteBuild` bezahlt ausschließlich bei Erfolg, erzeugt das echte `gameplayPrefab` oder löst eine Fähigkeit aus und startet deren Cooldown. Ablehnung verändert nichts.
|
||
6. `BuiltObjects` beschreibt tatsächlich vorhandene Objekte auf der aktuellen Ebene mit stabiler Instanz-ID, Typ, Weltposition, Rotation und Upgrade-Stufe. Fähigkeiten nicht als Dauerobjekte auflisten. Entfernte/verbrauchte Objekte wieder herausnehmen.
|
||
7. `CheckUpgrade` / `ExecuteUpgrade` arbeiten auf der Instanz-ID. Nur Gameplay bezahlt und wendet echte Verbesserungen an.
|
||
8. `StateChanged` nach Bau, Upgrade, Ressourcenänderung, Verbrauch, Zerstörung und Etagenwechsel auslösen. Die UI aktualisiert dadurch Ressourcen, Karten und Ebenenplan.
|
||
|
||
`BuildCheck` enthält einen maschinenlesbaren `BuildFailure` und kurzen deutschen Meldungstext. `OutsideRegion` = graue Vorschau; andere Ablehnungen = rot. `BuildRequest` enthält das Asset, Weltposition und Drehung in Grad. Weltpositionen verwenden derzeit die XY-Ebene, Z=0.
|
||
|
||
UI-Mausbedienung und echte Spiellogik nicht vermischen. `TestPlacementController` steuert Vorschau, Buch und Hinweise; das separate `PrototypeHandbookGameplay` liefert nur Test-Spiellogik. Es ist keine Grundlage für echtes Schießen, sondern ein ausführbares Beispiel der Schnittstelle.
|
||
|
||
## Asset-Verwendung in echten Türmen
|
||
|
||
- `gameplayPrefab` pro Typ mit der echten Basis-/Geschütz-Hierarchie verknüpfen. Der Drehpunkt gehört zum Geschütz, nicht zur Basis.
|
||
- `CreateCombatSnapshot(upgradeLevel)` liefert eine neue Combat-Datenkopie mit kumulativen Upgrade-Multiplikatoren. Diese pro Instanz verwenden und bei Upgrades neu erstellen.
|
||
- Niemals gemeinsame ScriptableObjects im Play-Modus als Turmzustand ändern. HP, Munition, Upgrade-Level, Kontaktanzahl und Restdauer gehören zur einzelnen Instanz.
|
||
- `baseRadius` / rechteckige `baseSize` bestimmen die physische Grundfläche. `placementRadius` bestimmt Freiraum zwischen Objekten; `combat.range` oder `areaRadius` sind Angriff/Wirkung.
|
||
- Für den Keller-Magazinverbrauch gelten ausschließlich die Felder unter `supply`. Die älteren Combat-Verbrauchsfelder bleiben als historische Werte erhalten und dürfen nicht zusätzlich aus demselben Magazin abgebucht werden. Physische Waffen teilen vorläufig einen Pool, Energiewaffen einen zweiten. Siehe `SUPPLY_INTEGRATION.md`. Bei kontinuierlichem Schaden gilt `continuousDamagePerSecond` statt Schaden pro Einzeltreffer.
|
||
- `targetableByEnemies` und `destroyableByDamage` im tatsächlichen Ziel-/Schadenssystem prüfen. Ablaufdauer und Kontaktverbrauch sind davon unabhängig.
|
||
- `spawnWeight` der Gegner ist relatives Gewicht, kein direktes Prozent. Dropbereiche sind inklusiv. Werte bei Gegnern sind vorläufig, Prefabs noch nicht zugewiesen.
|
||
|
||
## Grenzen des Prototyps
|
||
|
||
Keine echte Waffen-, Gegner-, Heilungs-, Sammel-, Reflexions- oder Bombardementsimulation. Caltrops verschwinden noch nicht durch Gegnerkontakt. Die Daten dafür sind vorhanden, tatsächliche Effekte muss Gameplay implementieren. Barrikaden werden geometrisch geprüft, aber ohne echten Pathfinder: das Flag `requirePathValidation` muss dein Backend beachten. Rechteck-Abstandsprüfung verwendet im Prototyp konservative umschließende Kreise. Reparaturziele sind vorläufig die vier Himmelsrichtungen am Innenradius; echte Schleusenziele liefert dein Spiel.
|
||
|
||
UI: kein Scrollen und keine Seitenpfeile. Alle Einträge eines Filters werden gleichzeitig gezeigt. Bauen: Physisch, Energie, Anlagen, Einsätze. Index: Alle, Waffen, Anlagen, Einsätze, Gegner. Upgrades sind nach Typ gruppiert; der Ebenenplan zeigt Positionen relativ zur gemeinsamen Mitte.
|
||
|
||
## Oberfläche im Inspector bearbeiten
|
||
|
||
Die Oberfläche ist dauerhaft in `Assets/Scenes/Tim_Test_UI.unity` angelegt. Außerhalb von Play zeigt die gespeicherte Szene das offene Buch und die Bauen-Seite. Play startet trotzdem mit geschlossenem Buch. Zum Bearbeiten anderer Seiten im Editor nur die gewünschte `Page_*` aktivieren.
|
||
|
||
`Canvas_Handbook/HandbookRoot/OpenBook/PageArea` enthält die Baukarten, 24 Indexfelder und 14 Upgrade-Zeilen. `Page_Upgrades/UpgradesRight/FloorPlan` enthält den Ring, vier Schleusen und 14 Marker. General und `ActiveTabLayer` existieren ebenfalls vor Play. Die Skripte erzeugen keine UI-Objekte mehr; sie befüllen/verbergen vorhandene Slots. Bei größerem echtem Mengenlimit müssen zusätzliche Slots in der Szene und den Inspector-Arrays angelegt werden.
|
||
|
||
Wiederholte Elemente sind verbundene Prefab-Instanzen. Vorlagen liegen unter `Assets/UI_Prefabs`: `HandbookBuildCard_Left`, `HandbookBuildCard_Right`, `HandbookIndexTile`, `HandbookUpgradeCard`, `HandbookMapMarker`, `HandbookGeneralFeedback`, `Base_Physical`, `Base_Energy`. Änderungen in Prefabs außerhalb von Play wirken auf Instanzen ohne entsprechenden Override.
|
||
|
||
Grafiken: `Assets/Art/Handbook`. Original-PNGs sind unverändert übernommen; acht Marker und zwei Basisgrafiken sind über Unity Sprite Mode Multiple geschnitten. Beschriftungen gehören zur Grafik; zusätzliche Tab-Texte sind entfernt. Ein geschlossenes Buch und das Generalporträt fehlen noch als Zeichnung und verwenden Platzhalter. `HandbookPageSurface` bezeichnet flache, links oder rechts gewölbte Rahmenvarianten; die Rahmensprites selbst fehlen noch.
|
||
|
||
`category` ist Waffentechnik/Basisfarbe (physisch, Energie, Spezial), `menuGroup` die Buchkategorie. Spezialgebäude gehören vorläufig zu Anlagen, Fallen/Fähigkeiten/Reparaturtrupp zu Einsätzen. Die Gruppe bedeutet nicht automatisch eine Baufläche.
|
||
|
||
`baseSprite`/`basePrefab` sind die gezeichnete Basis, `previewSprite` vorerst ebenfalls diese Basis. `gameplayPrefab` bleibt frei für den echten vollständigen Turm. Zum Aufbau zuerst eine Basis instanziieren, darüber ein separat drehbares Geschütz; keine gezeichnete Basis als fertigen Turm behandeln.
|
||
|
||
Die einmaligen Aufbau- und Umbauwerkzeuge wurden nach Fertigstellung entfernt. Szene, Prefabs und Assets normal im Inspector bearbeiten; kein Generierungs- oder Einrichtungsschritt ist nötig.
|
||
|
||
## Morgen mit dem Team entscheiden
|
||
|
||
Generator/Sauger auf Mauer oder Innenfeld? Spiegel angreifbar und zerstörbar? Innenfeldlimit und Limits pro Typ? Reparaturtrupp frei beweglich oder Schleusenziel? Caltrops-Kontakte und Barrikaden-Lebensdauer? Dürfen Barrikaden Wege komplett schließen? Zielwahl bei Sniper/Howitzer? Bedeutung des Cooldowns beim Laser-Beam? Kostenressource und Wartungsverbrauch? Was genau passiert bei Hangry-Explosion und Etagenverlust?
|
||
|
||
Zum Einbinden: diesem Dokument, den Daten-Skripten, `IHandbookGameplay.cs` und `PrototypeHandbookGameplay.cs` an deine KI geben. Mit der bestehenden Schnittstelle arbeiten, keine zweite Drag-and-drop-Bedienung bauen.
|
||
|
||
## Versorgungsschnittstelle (15.10.2026)
|
||
Siehe SUPPLY_INTEGRATION.md für ISupplyGameplay, Zustandsdaten, Inspector-Zuweisung und Magazinverbrauch. Buildables besitzen jetzt supply-Konfiguration (Version 3). Alte Kampf- und Kaufwerte sind unverändert; Keller-Magazinverbrauch wird über supply angegeben. Echte Versorgungslogik bleibt Aufgabe des Gameplay-Backends.
|
||
|
||
|
||
## Prüfungen nach Änderungen
|
||
|
||
Die verbliebenen Editor-Prüfungen werden per Unity-Batchmode ausgeführt. Sie starten eine Play-Sitzung und beenden anschließend den Prüfprozess; keine Testobjekte werden in die Szene gespeichert.
|
||
|
||
- `HandbookInspectorValidation.Validate`: vorhandene UI, Kategorien, Platzierung, Upgrades und Index.
|
||
- `SupplyBasementValidation.Validate`: Keller ohne Backend, Anschlüsse, Priorität, Aufzug und LKW-Ausrichtung.
|
||
- `SupplyBindingValidation.Validate`: Versorgungsschnittstelle mit isolierter Testkomponente.
|
||
|
||
Beispiel: Unity mit `-batchmode -nographics -projectPath "<Projektpfad>" -executeMethod SupplyBindingValidation.Validate -logFile "<Logpfad>"` starten. Optional rendert `SupplyBasementValidation.Validate` mit Grafikunterstützung (ohne `-nographics`) und dem zusätzlichen Argument `-captureSupplyPreview` ein Bild nach `Temp/HandbookValidation/basement-preview.png`. Der Temp-Ordner wird nicht versioniert.
|