DepthsOfGreed/HANDBOOK_HANDOVER.md

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.