RDietermann/InfiniTower
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

Karte: Vertical Slice InfiniTower #1

New Issue
Open
opened 2026-08-10 07:57:26 +00:00 by RDietermann · 1 comment
RDietermann commented 2026-08-10 07:57:26 +00:00
Owner
Copy Link

Destination

Eine Spec plus die tragenden Architektur-Entscheidungen für einen spielbaren Vertical Slice von InfiniTower — inklusive Meta-Progression. Nicht das komplette Spiel, nicht nur Technik.

Fertig ist die Reise, wenn ein Spieler einen Run starten, sterben, permanent aufwerten und einen sichtbar stärkeren Run starten kann — und wenn die Entscheidungen, die diesen Loop tragen, schriftlich begründet sind.

Decisions so far

  • Genre-Fidelity: Inspiration im Stil von „The Tower — Idle Tower Defense", kein 1:1-Klon. Das Wiki ist Kalibrierungs-Referenz, keine Spezifikation.
  • Plattform: Desktop nativ zuerst. Mobile und Web später — deshalb keine Plattform-APIs im Spielkern.
  • Zweck: Lernprojekt (Rust/Bevy), Produkt eventuell später. Alles Server-seitige (Guilds, Tournaments, Cloud-Saves, Accounts, IAP) ist out of scope.
  • Kern-Gefühl: Idle — der Turm schießt selbst, der Spieler greift nur über Upgrades ein.
  • Arena: ein Turm in der Mitte, radiale Wellen. Kein Pfad, kein Turm-Platzieren, kein Maze-Building.
  • Rendering: 2D, bevy_sprite, orthographische Kamera.
  • Pause und Cards im Run: ein Pause-Button friert die gesamte Simulation ein und gibt Einsicht in die ausgerüsteten Cards — nur ansehen, nicht wechseln. Das Loadout steht vor dem Run fest. Folge für ADR-0002: Fähigkeits-Components werden im laufenden Run nie entfernt, der Entfernungspfad reduziert sich auf Run-Ende (Entity despawnt) und Save-Laden (frischer Spawn).
  • Card-Slots werden aus der Meta-Währung im Workshop gekauft, neben den Stat-Upgrades und mit exponentiell wachsenden Kosten. Kein zweiter Freischalt-Mechanismus. Damit ist Breite gegen Stärke die eigentliche Meta-Entscheidung des Slice — und die Slot-Kosten sind keine freie Zahl, sondern an das Abnahmekriterium gebunden (Slot 2 muss früh fallen).
  • Utility-Tab trägt Ökonomie-Upgrades (Coin-Ertrag pro Kill, Coins am Wellenende), keine Kampf-Stats — wie im Referenzspiel. Diese Upgrades sind keine ADR-0002-Stats; §3 dort wird dafür ergänzt.
  • Gegner-gegen-Gegner-Kollision: Spatial Grid mit weicher Separation. Das Grid ist geteilte Infrastruktur — dieselbe Nachbarschaftsabfrage bedient die Separation, tower_fires Zielauswahl und den geteilten Reichweiten-Scan des Auslöse-Systems. Eigene ADR-0004.
  • Kaufen im Run: der Spieler kann jederzeit im Shop kaufen — kein Wellenende, keine Freigabe. Der Kaufrhythmus folgt damit der Einkommensrate, nicht der Wellenstruktur; die Zielgröße beim Tunen ist die Zeit zwischen zwei bezahlbaren Käufen (#8).
  • In-Run-HUD: links das Gameplay-Fenster, rechts ein vertikales Panel mit vier Tabs — Attack Shop · Defence Shop · Utility Shop · Ultimates. Die drei Stat-Kategorien der Kalibrierung sind damit die In-Run-Shop-Struktur; Ultimates sind ein gleichrangiger vierter Tab und tragen die Cooldown-Anzeige. Kauf einzeln (Buy x1) mit Kosten pro Kauf. Workshop und Cards sind nicht in diesem HUD — sie leben auf einem eigenen Meta-Screen. Mockup: docs/design/hud-in-run.png.
  • Meta-Achsen im Slice: Workshop (permanente Stat-Upgrades) + Cards.
  • Offline-Progress: nicht im Slice. Save/Load ja.
  • Assets: Programmer-Art. Ein Art-Strang gehört nicht auf diese Karte.
  • Ultimates: genau eine aktive Fähigkeit im Slice, als Muster für den Rest. Es ist Death Wave — radialer Sweep, passt zur Geometrie, braucht kein Zielsystem. Sie feuert automatisch nach Regel, nicht auf Knopfdruck: der Turm handelt, der Spieler stellt ein (#9).
  • Auslösen von Fähigkeiten: Ultimate und Card-Fähigkeiten feuern nach einer Regel — Cooldown und ein Weltzustand (z. B. „N Gegner in Reichweite"). Fest verdrahtet je Fähigkeit, nicht vom Spieler einstellbar; die Werte kommen wie alle Zahlen aus Balance. Feuern mehrere gleichzeitig, feuern alle. Der Reichweiten-Scan wird einmal gemacht und geteilt, sonst läuft er siebenmal pro Frame gegen 10 000 Entities (#12).
  • Cards: fallen als Drop aus Fortschritt (Boss-Kill, neuer Wellen-Rekord), werden nicht gekauft. Sie schalten auch Fähigkeiten frei, nicht nur Stat-Modifikatoren, und die feuern nach derselben Regel wie die Ultimate — ein Auslöse-System für alles. Slots starten bei 1 und wachsen auf 5, drei Seltenheitsstufen (#11).
  • Währungen: zwei. Die In-Run-Währung (Coins, verfällt am Run-Ende) und eine Meta-Währung für den Workshop — beide fallen aus denselben Kill-Events, sind aber nicht ineinander konvertierbar, damit eine In-Run-Ausgabe keinen Meta-Fortschritt kostet. Cards brauchen keine dritte, weil sie gedroppt werden. Achtung: unser Coins entspricht dem Cash des Referenzspiels, dessen Coins ist die Meta-Währung.
  • Run-Struktur: eine endlose Wellenkurve mit einem Schwierigkeitsgrad. Tiers bleiben im Nebel.
  • Sprache: Issues, CONTEXT.md, ADRs und Spec auf Deutsch. Code, Bezeichner und Commit-Messages bleiben englisch.
  • Gegner-Obergrenze: 10 000 gleichzeitig, und die Zahl wächst mit dem Run-Fortschritt. Das Original deckelt bei 150 (120 normal / 20 elite / 10 boss) — eine Mobile-Grenze, die wir bewusst nicht übernehmen: Desktop hat die Leistung, und eine steigende Gegnerzahl ist selbst ein Teil der Schwierigkeitskurve. 10 000 ist der in #4 gemessene Wert mit belastbarer Reserve (5,04 ms von 16,67 ms Budget); der eigentliche Bruch liegt bei ~70 000, aber die Messung gilt für untexturierte, gleichfarbige Sprites ohne UI und Audio — dort ist keine Reserve mehr. Die kategorisierten Sub-Caps des Originals übernehmen wir sinngemäß, damit Trash-Mobs nie die Boss- und Elite-Slots verhungern lassen.

Fog

Ungeklärt, absichtlich noch nicht entschieden:

  • Die vier freien Zahlen der Kurve: Wachstumsfaktor pro Welle, Boss-Multiplikator, Drop-Chance mal Wellenwert, Kosten-Exponent des Workshops. Form und Prüfkriterien stehen (#8), die Werte findet nur Spielen — Werkzeug dafür ist das Debug-Panel mit Sprung-zu-Welle aus ADR-0001.
  • Wie die Meta-Währung heißt: Coins ist bei uns schon an die In-Run-Währung vergeben.
  • Der Meta-Screen zwischen den Runs: Aufbau für Workshop, Cards und Slot-Fortschritt. Das In-Run-HUD steht (docs/design/hud-in-run.png), der Screen dazwischen nicht.

Bewusst im Nebel gelassen, nicht Teil dieser Reise: Labs, Modules, Perks, Tiers, Offline-Earnings, Art-Direction, alles Server-seitige.

Kinder

Die Tickets stehen in Reisereihenfolge. Blocker als Blocked by:-Zeile im jeweiligen Ticket.

  1. #2 — CONTEXT.md anlegen ✅
  2. #3 — Genre-Kalibrierung ✅
  3. #4 — Perf-Spike Bevy 2D ✅
  4. #5 — ADR Balancing-Daten ✅ Rust-Konstanten hinter Balance-Resource
  5. #6 — ADR Stat-/Modifier-Pipeline ✅ 3 Akkumulatoren + Direct/Interval-Bit
  6. #7 — ADR Save/Load ✅ TOML via bevy_settings, Feldnamen als Vertrag
  7. #8 — Grilling Wellen-/Economy-Kurve ✅ Tod bei Welle 10–15, exponentiell + Boss-Spitzen, Drop-basierte Meta
  8. #9 — Grilling Ultimate-Auswahl ✅ Death Wave, automatisch
  9. #11 — Grilling Card-Mechanik ✅ Drop, Fähigkeiten, 1→5 Slots
  10. #12 — Grilling Auslöse-System ✅ Cooldown + Weltzustand, fest verdrahtet
  11. #10 — Vertical-Slice-Spec ✅ docs/spec-vertical-slice.md

Destination erreicht. Alle Kinder geschlossen. Vier ADRs, eine Spec, ein HUD-Entwurf. Was offen bleibt, steht im Fog und im Widersprüche-Abschnitt der Spec — beides bewusst, nicht vergessen.

## Destination Eine **Spec plus die tragenden Architektur-Entscheidungen** für einen spielbaren Vertical Slice von InfiniTower — inklusive Meta-Progression. Nicht das komplette Spiel, nicht nur Technik. Fertig ist die Reise, wenn ein Spieler einen Run starten, sterben, permanent aufwerten und einen sichtbar stärkeren Run starten kann — und wenn die Entscheidungen, die diesen Loop tragen, schriftlich begründet sind. ## Decisions so far - **Genre-Fidelity**: Inspiration im Stil von „The Tower — Idle Tower Defense", **kein 1:1-Klon**. Das [Wiki](https://the-tower-idle-tower-defense.fandom.com/wiki/The_Tower_-_Idle_Tower_Defense_Wiki) ist Kalibrierungs-Referenz, keine Spezifikation. - **Plattform**: Desktop nativ zuerst. Mobile und Web später — deshalb keine Plattform-APIs im Spielkern. - **Zweck**: Lernprojekt (Rust/Bevy), Produkt eventuell später. Alles Server-seitige (Guilds, Tournaments, Cloud-Saves, Accounts, IAP) ist **out of scope**. - **Kern-Gefühl**: **Idle** — der Turm schießt selbst, der Spieler greift nur über Upgrades ein. - **Arena**: ein Turm in der Mitte, radiale Wellen. Kein Pfad, kein Turm-Platzieren, kein Maze-Building. - **Rendering**: **2D**, `bevy_sprite`, orthographische Kamera. - **Pause und Cards im Run**: ein Pause-Button friert die **gesamte** Simulation ein und gibt Einsicht in die ausgerüsteten Cards — **nur ansehen, nicht wechseln**. Das Loadout steht vor dem Run fest. Folge für ADR-0002: Fähigkeits-Components werden im laufenden Run **nie** entfernt, der Entfernungspfad reduziert sich auf Run-Ende (Entity despawnt) und Save-Laden (frischer Spawn). - **Card-Slots** werden aus der **Meta-Währung im Workshop gekauft**, neben den Stat-Upgrades und mit exponentiell wachsenden Kosten. Kein zweiter Freischalt-Mechanismus. Damit ist Breite gegen Stärke die eigentliche Meta-Entscheidung des Slice — und die Slot-Kosten sind keine freie Zahl, sondern an das Abnahmekriterium gebunden (Slot 2 muss früh fallen). - **Utility-Tab** trägt **Ökonomie-Upgrades** (Coin-Ertrag pro Kill, Coins am Wellenende), keine Kampf-Stats — wie im Referenzspiel. Diese Upgrades sind keine ADR-0002-Stats; §3 dort wird dafür ergänzt. - **Gegner-gegen-Gegner-Kollision**: **Spatial Grid mit weicher Separation**. Das Grid ist geteilte Infrastruktur — dieselbe Nachbarschaftsabfrage bedient die Separation, `tower_fire`s Zielauswahl und den geteilten Reichweiten-Scan des Auslöse-Systems. Eigene ADR-0004. - **Kaufen im Run**: der Spieler kann **jederzeit** im Shop kaufen — kein Wellenende, keine Freigabe. Der Kaufrhythmus folgt damit der Einkommensrate, nicht der Wellenstruktur; die Zielgröße beim Tunen ist die **Zeit zwischen zwei bezahlbaren Käufen** (#8). - **In-Run-HUD**: links das Gameplay-Fenster, rechts ein vertikales Panel mit vier Tabs — **Attack Shop · Defence Shop · Utility Shop · Ultimates**. Die drei Stat-Kategorien der Kalibrierung sind damit die In-Run-Shop-Struktur; Ultimates sind ein gleichrangiger vierter Tab und tragen die Cooldown-Anzeige. Kauf einzeln (`Buy x1`) mit Kosten pro Kauf. Workshop und Cards sind **nicht** in diesem HUD — sie leben auf einem eigenen Meta-Screen. Mockup: `docs/design/hud-in-run.png`. - **Meta-Achsen im Slice**: **Workshop** (permanente Stat-Upgrades) **+ Cards**. - **Offline-Progress**: nicht im Slice. Save/Load ja. - **Assets**: Programmer-Art. Ein Art-Strang gehört nicht auf diese Karte. - **Ultimates**: **genau eine** aktive Fähigkeit im Slice, als Muster für den Rest. Es ist **Death Wave** — radialer Sweep, passt zur Geometrie, braucht kein Zielsystem. Sie feuert **automatisch nach Regel**, nicht auf Knopfdruck: der Turm handelt, der Spieler stellt ein (#9). - **Auslösen von Fähigkeiten**: Ultimate und Card-Fähigkeiten feuern nach **einer** Regel — Cooldown **und** ein Weltzustand (z. B. „N Gegner in Reichweite"). Fest verdrahtet je Fähigkeit, nicht vom Spieler einstellbar; die Werte kommen wie alle Zahlen aus `Balance`. Feuern mehrere gleichzeitig, feuern alle. Der Reichweiten-Scan wird **einmal** gemacht und geteilt, sonst läuft er siebenmal pro Frame gegen 10 000 Entities (#12). - **Cards**: fallen als **Drop aus Fortschritt** (Boss-Kill, neuer Wellen-Rekord), werden nicht gekauft. Sie schalten **auch Fähigkeiten** frei, nicht nur Stat-Modifikatoren, und die feuern nach derselben Regel wie die Ultimate — **ein** Auslöse-System für alles. Slots starten bei **1 und wachsen auf 5**, drei Seltenheitsstufen (#11). - **Währungen**: **zwei**. Die In-Run-Währung (`Coins`, verfällt am Run-Ende) und eine Meta-Währung für den Workshop — beide fallen aus denselben Kill-Events, sind aber nicht ineinander konvertierbar, damit eine In-Run-Ausgabe keinen Meta-Fortschritt kostet. Cards brauchen keine dritte, weil sie gedroppt werden. **Achtung**: unser `Coins` entspricht dem `Cash` des Referenzspiels, dessen `Coins` ist die Meta-Währung. - **Run-Struktur**: eine **endlose Wellenkurve** mit einem Schwierigkeitsgrad. Tiers bleiben im Nebel. - **Sprache**: Issues, `CONTEXT.md`, ADRs und Spec auf **Deutsch**. Code, Bezeichner und Commit-Messages bleiben **englisch**. - **Gegner-Obergrenze**: **10 000 gleichzeitig**, und die Zahl **wächst mit dem Run-Fortschritt**. Das Original deckelt bei 150 (120 normal / 20 elite / 10 boss) — eine Mobile-Grenze, die wir bewusst nicht übernehmen: Desktop hat die Leistung, und eine steigende Gegnerzahl ist selbst ein Teil der Schwierigkeitskurve. 10 000 ist der in #4 gemessene Wert mit belastbarer Reserve (5,04 ms von 16,67 ms Budget); der eigentliche Bruch liegt bei ~70 000, aber die Messung gilt für untexturierte, gleichfarbige Sprites ohne UI und Audio — dort ist keine Reserve mehr. Die **kategorisierten Sub-Caps** des Originals übernehmen wir sinngemäß, damit Trash-Mobs nie die Boss- und Elite-Slots verhungern lassen. ## Fog Ungeklärt, absichtlich noch nicht entschieden: - Die vier freien Zahlen der Kurve: Wachstumsfaktor pro Welle, Boss-Multiplikator, Drop-Chance mal Wellenwert, Kosten-Exponent des Workshops. Form und Prüfkriterien stehen (#8), die Werte findet nur Spielen — Werkzeug dafür ist das Debug-Panel mit Sprung-zu-Welle aus ADR-0001. - Wie die Meta-Währung heißt: `Coins` ist bei uns schon an die In-Run-Währung vergeben. - Der Meta-Screen zwischen den Runs: Aufbau für Workshop, Cards und Slot-Fortschritt. Das In-Run-HUD steht (`docs/design/hud-in-run.png`), der Screen dazwischen nicht. Bewusst im Nebel gelassen, nicht Teil dieser Reise: Labs, Modules, Perks, Tiers, Offline-Earnings, Art-Direction, alles Server-seitige. ## Kinder Die Tickets stehen in Reisereihenfolge. Blocker als `Blocked by:`-Zeile im jeweiligen Ticket. 1. ~~#2 — `CONTEXT.md` anlegen~~ ✅ 2. ~~#3 — Genre-Kalibrierung~~ ✅ 3. ~~#4 — Perf-Spike Bevy 2D~~ ✅ 4. ~~#5 — ADR Balancing-Daten~~ ✅ Rust-Konstanten hinter `Balance`-Resource 5. ~~#6 — ADR Stat-/Modifier-Pipeline~~ ✅ 3 Akkumulatoren + Direct/Interval-Bit 6. ~~#7 — ADR Save/Load~~ ✅ TOML via `bevy_settings`, Feldnamen als Vertrag 7. ~~#8 — Grilling Wellen-/Economy-Kurve~~ ✅ Tod bei Welle 10–15, exponentiell + Boss-Spitzen, Drop-basierte Meta 8. ~~#9 — Grilling Ultimate-Auswahl~~ ✅ Death Wave, automatisch 9. ~~#11 — Grilling Card-Mechanik~~ ✅ Drop, Fähigkeiten, 1→5 Slots 10. ~~#12 — Grilling Auslöse-System~~ ✅ Cooldown + Weltzustand, fest verdrahtet 11. ~~#10 — Vertical-Slice-Spec~~ ✅ `docs/spec-vertical-slice.md` **Destination erreicht.** Alle Kinder geschlossen. Vier ADRs, eine Spec, ein HUD-Entwurf. Was offen bleibt, steht im Fog und im Widersprüche-Abschnitt der Spec — beides bewusst, nicht vergessen.
RDietermann added the wayfinder:map label 2026-08-10 07:57:26 +00:00
RDietermann commented 2026-08-10 10:38:07 +00:00
Author
Owner
Copy Link

Folgen der Cap-Entscheidung (10 000 statt 150)

Die Entscheidung, die Gegner-Obergrenze auf den gemessenen Perf-Wert statt auf die 150 des Originals zu setzen, ist keine reine Zahlenänderung. Sie bricht neun Mechaniken des Referenzspiels, weil deren Konstanten gegen 120 gleichzeitige Normal-Gegner kalibriert sind. Herausgearbeitet bei der Verifikation von #3, Dichtefaktor ~13.

Gehört in die Balancing-Tickets (#8):

  • Sub-Caps zerfallen in zwei Klassen. Die Modifikator-Caps (Protector 8, Elite pro Typ 8) müssen mit dem Normal-Cap mitskalieren, sonst verschwindet die Mechanik statistisch — ein Protector wäre 1 von 250 statt 1 von 15. Die Event-Caps (Boss 10, Elite gesamt 20) müssen absolut bleiben; zieht man 120/20/10 naiv hoch, stehen 133 Bosse gleichzeitig auf dem Schirm und die Boss-Welle verliert ihre Funktion als Rhythmusgeber.
  • Coin-Wert pro Kill ist der dichte-empfindlichste Wert im Design. Einkommen skaliert linear mit Kills, also 13×. Weil unsere Gegnerzahl zusätzlich über den Run steigt, ist der Faktor nicht einmal konstant. Die Economy-Kurve muss gegen Kills pro Welle normiert werden, nicht gegen Wellen — sonst wächst das Einkommen quadratisch gegen linear wachsende Kosten.
  • Heat-up (+4 % Schaden pro Treffer) ist nicht übertragbar. Bei 13× Angreifern endet der Run durch schiere Menge, bevor Heat-up wirkt; skaliert man die Turm-Defensive entsprechend hoch, wird aus der Rampe eine Klippe. Die Rate muss gegen die erwartete Zahl gleichzeitiger Angreifer neu bestimmt werden.
  • Spawn-Zahl-Multiplikatoren werden wirkungslos. Bei 150 bindet das Cap selten. Bei uns ist das Cap die Design-Zielgröße, es bindet ständig — eine Karte „mehr Gegner pro Welle" gibt dann exakt null, ihr Nachteil ebenfalls null, ihr Vorteil (mehr Ertrag pro Kill) voll. Solche Effekte müssen bei uns das Cap anheben, nicht die Spawn-Zahl.

Gehört in die Architektur:

  • Flächeneffekte brauchen ein Ziel-Limit. Der Commander-Puls ist pro Gegner auf 8 Stapel gedeckelt (1,15⁸ ≈ 3,06×), explodiert also nicht — was explodiert, ist die Zahl der getroffenen Gegner bei gleichem Radius. Ein Ziel-Limit pro Puls ist robuster als ein schrumpfender Radius, weil es gleichzeitig die Kostenseite deckelt: ein Aura-System, das jeden Frame gegen tausende Entities auflöst, ist auch ein Perf-Problem.
  • Coins dürfen keine Entities sein. Das Original lässt sie fallen und einsammeln. Bei tausenden Kills pro Welle ist das ein Entity-Sturm — Gutschrift beim Tod, kein Pickup.
  • Massenvernichtung muss gebatcht werden. Eine Nuke auf Stufe 1 tötet bei 2 000 Gegnern 500 Stück in einem Tick, auf Stufe 7 alle. Im Original sind es maximal 150. Das ist ein Stabilitäts-, kein Balancing-Problem.
  • Gegner-gegen-Gegner-Kollision. Der Primärtext führt „Fleet enemies do not collide with other enemies" als Ausnahme — normale Gegner kollidieren also. Bei tausenden radial konvergierenden Körpern kommen zwei Probleme zusammen: O(n²) und ein Stau am Turmring, den keine DPS-Menge auflöst. Entweder Gegner-Gegner-Kollision fallen lassen (Stapeln akzeptieren, bei Programmer-Art in 2D vertretbar) oder Spatial Grid mit weicher Separation.
  • Der Spawner muss cap-getrieben sein, nicht plan-getrieben. Die Spawn-Phase dauert im Original 26 s; um 2 000 lebende Gegner zu halten, braucht es ≥ 77 Spawns/s gegenüber ~6/s im Original. „Fülle bis zum Cap auf" statt „spawne N nach Zeitplan" — und Entity-Erzeugung gehört damit selbst ins Perf-Budget.

Nicht betroffen (damit wir dort keine Zeit investieren): Coin Decay, Mass-Wachstum und der Commander-Stapel-Deckel sind alle per-entity definiert und dichte-neutral, ebenso Boss-Immunitäten und Wellen-Timer. Bruchgefährdet ist ausschließlich, was eine Zahl pro Welle, pro Fläche oder pro Bildschirm nennt.

Eine Anmerkung zur Spielgeschwindigkeit wurde aufgeworfen: der Perf-Spike hat bei x1 gemessen, ein Idle-Spiel mit 35-Sekunden-Wellen will fast sicher einen Speed-Multiplikator, und ein bei x1 tragbares Cap sei bei x4 keins. Das ist hier entschärft: #4 hat gemessen, dass die gesamte Gameplay-Logik bei 10 000 Gegnern 0,114 ms von 16,67 ms kostet — 0,7 % des Budgets. Rendering läuft weiter mit der Display-Rate, nur die Simulation skaliert mit der Spielgeschwindigkeit. Selbst x4 kostet damit rund 0,3 ms. Der Punkt gilt für die Spawn-Rate (77/s wird zu 308/s), und dort ist er ebenfalls gemessen: der Population-Maintainer kostet bei 50 000 Gegnern 6,1 µs. Kein Handlungsbedarf, aber bei echten Texturen neu zu prüfen.

## Folgen der Cap-Entscheidung (10 000 statt 150) Die Entscheidung, die Gegner-Obergrenze auf den gemessenen Perf-Wert statt auf die 150 des Originals zu setzen, ist keine reine Zahlenänderung. Sie bricht neun Mechaniken des Referenzspiels, weil deren Konstanten gegen 120 gleichzeitige Normal-Gegner kalibriert sind. Herausgearbeitet bei der Verifikation von #3, Dichtefaktor ~13. **Gehört in die Balancing-Tickets (#8):** - **Sub-Caps zerfallen in zwei Klassen.** Die *Modifikator*-Caps (Protector 8, Elite pro Typ 8) müssen mit dem Normal-Cap mitskalieren, sonst verschwindet die Mechanik statistisch — ein Protector wäre 1 von 250 statt 1 von 15. Die *Event*-Caps (Boss 10, Elite gesamt 20) müssen absolut bleiben; zieht man 120/20/10 naiv hoch, stehen 133 Bosse gleichzeitig auf dem Schirm und die Boss-Welle verliert ihre Funktion als Rhythmusgeber. - **Coin-Wert pro Kill ist der dichte-empfindlichste Wert im Design.** Einkommen skaliert linear mit Kills, also 13×. Weil unsere Gegnerzahl zusätzlich über den Run steigt, ist der Faktor nicht einmal konstant. Die Economy-Kurve muss gegen *Kills pro Welle* normiert werden, nicht gegen *Wellen* — sonst wächst das Einkommen quadratisch gegen linear wachsende Kosten. - **Heat-up (+4 % Schaden pro Treffer) ist nicht übertragbar.** Bei 13× Angreifern endet der Run durch schiere Menge, bevor Heat-up wirkt; skaliert man die Turm-Defensive entsprechend hoch, wird aus der Rampe eine Klippe. Die Rate muss gegen die erwartete Zahl gleichzeitiger Angreifer neu bestimmt werden. - **Spawn-Zahl-Multiplikatoren werden wirkungslos.** Bei 150 bindet das Cap selten. Bei uns ist das Cap die Design-Zielgröße, es bindet ständig — eine Karte „mehr Gegner pro Welle" gibt dann exakt null, ihr Nachteil ebenfalls null, ihr Vorteil (mehr Ertrag pro Kill) voll. Solche Effekte müssen bei uns **das Cap anheben**, nicht die Spawn-Zahl. **Gehört in die Architektur:** - **Flächeneffekte brauchen ein Ziel-Limit.** Der Commander-Puls ist pro Gegner auf 8 Stapel gedeckelt (1,15⁸ ≈ 3,06×), explodiert also nicht — was explodiert, ist die Zahl der getroffenen Gegner bei gleichem Radius. Ein Ziel-Limit pro Puls ist robuster als ein schrumpfender Radius, weil es gleichzeitig die Kostenseite deckelt: ein Aura-System, das jeden Frame gegen tausende Entities auflöst, ist auch ein Perf-Problem. - **Coins dürfen keine Entities sein.** Das Original lässt sie fallen und einsammeln. Bei tausenden Kills pro Welle ist das ein Entity-Sturm — Gutschrift beim Tod, kein Pickup. - **Massenvernichtung muss gebatcht werden.** Eine Nuke auf Stufe 1 tötet bei 2 000 Gegnern 500 Stück in einem Tick, auf Stufe 7 alle. Im Original sind es maximal 150. Das ist ein Stabilitäts-, kein Balancing-Problem. - **Gegner-gegen-Gegner-Kollision.** Der Primärtext führt „Fleet enemies do not collide with other enemies" als *Ausnahme* — normale Gegner kollidieren also. Bei tausenden radial konvergierenden Körpern kommen zwei Probleme zusammen: O(n²) und ein Stau am Turmring, den keine DPS-Menge auflöst. Entweder Gegner-Gegner-Kollision fallen lassen (Stapeln akzeptieren, bei Programmer-Art in 2D vertretbar) oder Spatial Grid mit weicher Separation. - **Der Spawner muss cap-getrieben sein, nicht plan-getrieben.** Die Spawn-Phase dauert im Original 26 s; um 2 000 lebende Gegner zu halten, braucht es ≥ 77 Spawns/s gegenüber ~6/s im Original. „Fülle bis zum Cap auf" statt „spawne N nach Zeitplan" — und Entity-Erzeugung gehört damit selbst ins Perf-Budget. **Nicht betroffen** (damit wir dort keine Zeit investieren): Coin Decay, Mass-Wachstum und der Commander-Stapel-Deckel sind alle *per-entity* definiert und dichte-neutral, ebenso Boss-Immunitäten und Wellen-Timer. Bruchgefährdet ist ausschließlich, was eine Zahl **pro Welle, pro Fläche oder pro Bildschirm** nennt. **Eine Anmerkung zur Spielgeschwindigkeit** wurde aufgeworfen: der Perf-Spike hat bei x1 gemessen, ein Idle-Spiel mit 35-Sekunden-Wellen will fast sicher einen Speed-Multiplikator, und ein bei x1 tragbares Cap sei bei x4 keins. Das ist hier **entschärft**: #4 hat gemessen, dass die gesamte Gameplay-Logik bei 10 000 Gegnern 0,114 ms von 16,67 ms kostet — 0,7 % des Budgets. Rendering läuft weiter mit der Display-Rate, nur die Simulation skaliert mit der Spielgeschwindigkeit. Selbst x4 kostet damit rund 0,3 ms. Der Punkt gilt für die Spawn-Rate (77/s wird zu 308/s), und dort ist er ebenfalls gemessen: der Population-Maintainer kostet bei 50 000 Gegnern 6,1 µs. Kein Handlungsbedarf, aber bei echten Texturen neu zu prüfen.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
wayfinder:grilling
Wayfinder: offene Design-Frage
 wayfinder:map
Wayfinder-Karte
 wayfinder:prototype
Wayfinder: Prototyp/Spike
 wayfinder:research
Wayfinder: Recherche-Ticket
 wayfinder:task
Wayfinder: umsetzbare Aufgabe
No Label wayfinder:map
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
RDietermann
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: RDietermann/InfiniTower#1
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?