DepthsOfGreed/HANDBOOK_HANDOVER.md

Handbuch / Gameplay – Übergabe

Stand: 2. November 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.

Aktuelle Grafikfelder: Book Icon, Preview Layers und Gameplay Prefab. Die Basis-/Geschütz-Hierarchie liegt vollständig im Gameplay-Prefab. Die alten separaten Basisfelder wurden am 03.11.2026 nach Migration entfernt.

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 Logs/HandbookValidation/basement-preview.png. Der Logs-Ordner wird nicht versioniert.

Mauer-Baubereich im Inspector (02.11.2026)

PlacementTest > BuildArea besitzt WallBuildArea; HandbookRoot > TestPlacementController > Build Area verweist darauf. Namenssuchen nach BackgroundTower/BackgroundOuterwall sind für die Grenzen entfernt.

• Boundary Source = Sprite Renderers: Inner Boundary Sprite und Outer Boundary Sprite zuweisen. Es wird der kleinere halbe Welt-Bounds-Durchmesser der zugewiesenen SpriteRenderer verwendet, wie bisher. Kreisförmige Sprites mit derselben Mitte wie BuildArea verwenden.
• Boundary Source = Custom Radii: Inner Radius und Outer Radius in Welt-Einheiten einstellen, unabhängig von Sprite- und BuildArea-Skalierung. 0 <= innen < außen. Die Mitte ist BuildArea.transform.position.
• BuildArea auswählen und Gizmos in der Scene-Ansicht aktivieren: orange = innen, cyan = außen. Show Selected Gizmos schaltet diese Hilfslinien.
• Die Testplatzierung liest Werte bei Spielstart. Einstellungen außerhalb von Play ändern und Play neu starten. Bestehende Szene: bisherige Sprites zugewiesen, Innenradius 3 / Außenradius 4 erhalten.
• Ein echtes IHandbookGameplay-Backend muss dieselbe WallBuildArea-Konfiguration für seine eigene Bauprüfung verwenden. UI und Prototyp übernehmen sie bereits. Der gesamte Turmfuß muss weiterhin in den Ring passen; Angriffsreichweite und Abstandskreis sind davon unabhängig.

WallBuildAreaValidation.Validate prüft die Zuweisung unabhängig vom Objektnamen, eigene Radien, ungültige Konfigurationen und das vollständige Einpassen der Basis. Das einmalige Einrichtungsscript wurde nach der Umstellung entfernt.

Ergänzungen vom 02.11.2026

Keller außerhalb des Spielfelds

Die bestehende Raumoberfläche liegt jetzt unter SupplyBasementRoom / RoomCanvas / SupplyBasement, außerhalb der Turmebene bei X=50. Das ist ein World-Space-Canvas mit austauschbaren Grafiken und unveränderter Raum-Anordnung. BasementCamera zeigt diesen Raum beim Aufzugwechsel. Die normale Kamera und alle Spielobjekte bleiben aktiv. Nur Canvas-Darstellung, UI-Raycaster und Kellerkamera werden umgeschaltet. Canvas_SupplyBasement enthält weiterhin Aufzugschild und Übergangstüren als Bildschirm-UI.

Die bisherige LKW-Fahrvorschau läuft auch bei geschlossenem Keller weiter und verwendet Spielzeit. Ein echtes ISupplyGameplay-Backend bleibt unverändert für die eigentliche Versorgung zuständig. Es muss dauerhaft aktiv sein und darf seine Berechnungen nicht von IsInBasement abhängig machen.

Angriffsvorschau und Zielgeometrie

Buildables besitzen unter combat zusätzlich minimumRange, coverage (Automatic / Circle / Sector) und forwardAngleOffset. range, unlimitedRange und coneAngle werden wiederverwendet. Automatic zeigt bei fest gerichteten Kegelwaffen einen Sektor, bei frei drehbaren Waffen einen Kreis. Ein kegelförmiger Angriff beschränkt bei frei drehbaren Geschützen nicht automatisch den erreichbaren Rundumbereich.

AttackRangeGeometry.CanReach(combat, origin, target, baseAngleDegrees) ist ein gemeinsamer optionaler Helfer für die Zielprüfung. Ein echtes Schießsystem muss diese Grenzen beachten; die Vorschau allein verhindert noch keine Schüsse. Winkel in XY: 0=rechts, 90=oben; forwardAngleOffset standardmäßig 90 relativ zur Platzierungsrotation.

PlacementTest / PlacementPreview / AttackRangePreview enthält die vier dauerhaft angelegten Linien. Dort sind Farbe und Sichtbarkeit einstellbar. Blau = Angriff, der bisherige grün/rot/graue Kreis = Platzierungsabstand. Der ausgesparte Innenbereich wird über den inneren blauen Rand markiert. Unbegrenzte Reichweite bekommt keinen irreführenden endlichen Außenkreis; der General nennt sie beim Platzieren. Bei flächengezielten Einmalaktionen zeigt der Kreis stattdessen die Wirkungsfläche.

Howitzer: vorläufig minimumRange=1.5. Flammenwerfer, Pusher, Knocker und Laser Shotgun dürfen beim Bauen mit R gedreht werden. Bestehende Schadens-, Kosten- und Versorgungswerte bleiben gleich. Die Mindestreichweite bleibt bei Reichweiten-Upgrades zunächst unverändert.

Statistikseite

OpenBook / PageArea / Page_Statistics / StatisticsContent ist dauerhaft angelegt, ohne Scrollen oder Seitenwechsel. Links stehen Bauplätze/Kaufressourcen und die drei Versorgungspools mit Lager, Verteiler, gemessenem Verbrauch und geschätzter Verteiler-Restzeit ohne weitere Lieferungen. Rechts stehen bis zu acht versorgte Türme, nach Typ und Instanz sortiert, mit Magazin und gemessenem Verbrauch. Die Einheit lässt sich zwischen pro Sekunde und pro Minute umstellen.

Die Statistik liest vorhandene ISupplyGameplay-Snapshots. consumedPerSecond muss tatsächliche Entnahmen über ein Messfenster (beispielsweise die letzten zehn Sekunden) beschreiben, keine theoretische Feuerrate. null = unbekannt (Strich), 0 = kein Verbrauch. Die Schätzung buffer / consumedPerSecond nimmt ausdrücklich keinen weiteren Nachschub an. Sie ist keine Garantie für den wirklichen Leerzeitpunkt. Ohne Versorgungssystem zeigt die Seite vorhandene Turmtypen und Bauressourcen, aber keine erfundenen Verbrauchs- oder Magazinwerte.

Schleusenübersicht im Keller

Die kleine Ebenenkarte oben am Raum zeigt vier Richtungen, HP, offene Schleusen, Angriffe und kritische Zustände. Datenquelle: optionale MonoBehaviour-Komponente mit ICombatOverview, zugewiesen an BattleOverview > Basement Battle Overview > Combat Backend. Geschlossen/offen und angegriffen sind getrennte Zustände. hitSequence erhöht sich bei Treffern und löst kurzes Blinken aus; bei kritischen HP bleibt die Warnung bestehen. Ohne Daten stehen Striche. Die UI implementiert keine Schleusen- oder Schadenslogik.

Noch tatsächlich offen

Echte Waffen/Verbrauch, LKW-Versorgung und Schleusenzustände müssen vom Gameplay-System geliefert werden. Die dafür erforderlichen Schnittstellen und Anzeigen sind vorbereitet. Endgültige Grafik, Sound, Balancing und spätere Statistik-Erweiterungen (z.B. Abschüsse/Schaden) bleiben Teamaufgaben.

Zusätzliche Prüfung

UINotesValidation.Validate prüft den aktiven Raum, Hintergrund-Vorschau, Kreise/Sektoren/Mindestreichweite, Statistik und Einheiten sowie Schleusenwarnungen. Mit Grafikunterstützung schreibt sie Ansichten nach Logs/HandbookValidation. Die einmalige Szenenumstellung wurde nach Verwendung entfernt.

Grafik- und Vorschau-Struktur (03.11.2026)

Die bisherigen Felder baseSprite, basePrefab und previewSprite sind nach Migration entfernt. Im Inspector: Book Icon (intern weiterhin icon), Preview Layers und Gameplay Prefab. Die Ebenenliste hat standardmäßig zwei Plätze, oben = vorne, unten = hinten. Alle Sprite-Pivots liegen auf demselben Anker; offset, scale und rotation sind optionale Korrekturen. Gleiche Pixels-per-Unit verwenden, wenn die Zeichnungen denselben Pixelmaßstab haben. previewScale ist eine gemeinsame Skalierung für alle Ebenen; 0 passt sie anhand der untersten belegten Ebene an die Basisgröße an. rotateWithAim lässt sich pro Ebene abschalten, etwa für die Basis. Leere Ebenen werden ausgelassen. Änderungen beim nächsten Ziehen prüfen.

Vorhandene Vorschau-/Basisgrafiken wurden in die unterste Ebene übertragen. Wo Gameplay Prefab zuvor leer war, wurden vorhandene Basis-Prefabs als vorläufiges Gameplay-Prefab übernommen; echte Geschützmodelle und Spiellogik folgen durch den Gameplay-Programmierer. Bereits zugewiesene Gameplay-Prefabs bleiben erhalten. Der Prototyp instanziiert das zugewiesene Prefab ohne nachträgliche Größenänderung; bei weiterhin leerem Feld bleibt der bisherige Test-Platzhalter. Eigene IHandbookGameplay-Backends müssen ebenfalls gameplayPrefab instanziieren und die Instanz-ID melden.

Die Ziehvorschau richtet sich während des gesamten Ziehens weich zur Arenamitte aus. alignPreviewToCenter am TestPlacementController kann dies abschalten. R versetzt bei erlaubter Rotation die Blickrichtung zusätzlich. Der Bauauftrag verwendet die tatsächlich sichtbare Rotation. Die fertige Geschütz-/Basis-Hierarchie muss das echte Gameplay-Prefab selbst behandeln.

Angriffsvorschau: dünne blaue Grenzen und sehr schwache blaue Fläche; Mindestreichweite ausgespart/gestrichelt. RangeArenaClip begrenzt die Darstellung auf den Innenradius von WallBuildArea, da Gegner nur dort existieren. Bei abweichender tatsächlicher Arenageometrie die Quelle entsprechend anpassen. Die wirklichen Kampfwerte bleiben unverändert. Der grün/rot/graue Abstandskreis ist davon unabhängig und unverändert.

Der Keller besitzt zusätzlich einen Hintergrundaufzug als anklickbaren Rückweg, einen Versorgungsmonitor sowie Wandnischen, Schattenstreifen und einen Vordergrundabschluss. Ein großer Hintergrund deckt auch freie Bildschirmbereiche ab; Bedienelemente bleiben im sicheren Referenzrahmen. Alle Teile sind austauschbare, graue Platzhalter. Die separate Ebenen-/Schleusenanzeige bleibt außerhalb des Monitors. Aktuelle Werte stammen weiterhin ausschließlich aus den Gameplay-Schnittstellen.

Decke, Boden, Wandhintergrund und äußere Seitenbegrenzungen passen ihre Breite an die Kellerkamera an. Die Bedienelemente bleiben im sicheren Referenzbereich; auch auf breiten Bildschirmen entstehen keine freien Seitenflächen außerhalb des Raums.