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

Grilling: Wellen- und Economy-Kurve für einen 10–20-Minuten-Run #8

New Issue
Closed
opened 2026-08-10 07:58:34 +00:00 by RDietermann · 2 comments
RDietermann commented 2026-08-10 07:58:34 +00:00
Owner
Copy Link

Part of #1
Blocked by: #3, #4

Eine Design-Frage, die nur ein Gespräch klärt, kein Ticket allein.

Der Kern: Ein Idle-Run braucht Spannung ohne Eingriff. Wann kippt ein Run vom „ich gewinne durch" ins „ich sterbe gleich"? Wie schnell wachsen Gegner-HP gegenüber dem Schaden, den In-Run-Upgrades liefern? Wie viel Währung nimmt der Spieler aus einem Run mit, damit sich der nächste spürbar anders anfühlt — ohne den dritten Run trivial zu machen?

Ergebnis: Zielwerte als Zahlen, keine Adjektive. Run-Dauer, Wellen-Wachstumsrate, Meta-Ertrag pro Run, Anzahl Runs bis zur nächsten spürbaren Stufe.

Fertig, wenn die Werte in diesem Ticket stehen und in die Spec wandern können.

Part of #1 Blocked by: #3, #4 Eine Design-Frage, die nur ein Gespräch klärt, kein Ticket allein. **Der Kern**: Ein Idle-Run braucht Spannung ohne Eingriff. Wann kippt ein Run vom „ich gewinne durch" ins „ich sterbe gleich"? Wie schnell wachsen Gegner-HP gegenüber dem Schaden, den In-Run-Upgrades liefern? Wie viel Währung nimmt der Spieler aus einem Run mit, damit sich der nächste **spürbar** anders anfühlt — ohne den dritten Run trivial zu machen? **Ergebnis**: Zielwerte als Zahlen, keine Adjektive. Run-Dauer, Wellen-Wachstumsrate, Meta-Ertrag pro Run, Anzahl Runs bis zur nächsten spürbaren Stufe. **Fertig, wenn** die Werte in diesem Ticket stehen und in die Spec wandern können.
RDietermann added the wayfinder:grilling label 2026-08-10 07:58:34 +00:00
RDietermann changed title from Grilling: Wellen- und Economy-Kurve fur einen 10-20-Minuten-Run to Grilling: Wellen- und Economy-Kurve für einen 10–20-Minuten-Run 2026-08-10 08:00:36 +00:00
RDietermann commented 2026-08-10 10:38:09 +00:00
Author
Owner
Copy Link

Harte Zielgröße aus dem Primärtext (#3, Verifikationsrunde): eine Normal-Welle dauert im Referenzspiel 26 s Spawn-Phase + 9 s Cooldown = 35 s bei x1 Speed. Damit:

Spieldauer Wellen Bosse (alle 10 Wellen)
10 min ~17 1
20 min ~34 3
30 min ~51 5

Die Kurve muss also so gebaut sein, dass ein Spieler mit frühem Workshop-Stand um Welle 20–40 stirbt — nicht bei Welle 300, nicht bei Welle 8. Bei einer Kauf-Entscheidung alle 2–3 Wellen sind das ~12–17 Kaufmomente pro 20-Minuten-Run; daran hängt, wie fein die In-Run-Upgrade-Kosten gestaffelt sein müssen.

Der Cooldown pausiert nur die Spawns, nicht das Spiel — Gegner laufen und kämpfen weiter. Keine Verschnaufpause zwischen Wellen.

Wichtig für die Economy-Rechnung: die Cap-Entscheidung (10 000 statt 150 Gegner) verschiebt das Einkommen um Faktor ~13 und, weil die Gegnerzahl über den Run steigt, nicht einmal konstant. Die Kurve muss gegen Kills pro Welle normiert werden, nicht gegen Wellen — sonst wächst das Einkommen quadratisch gegen linear wachsende Kosten. Details in den Kommentaren zu #1.

Nicht belegt und weiterhin offen: die HP-/Schadens-Skalierungsformel pro Welle. Das Wiki dokumentiert sie nicht — dieser Wert ist zu entwerfen, nicht abzuleiten.

Harte Zielgröße aus dem Primärtext (#3, Verifikationsrunde): eine Normal-Welle dauert im Referenzspiel **26 s Spawn-Phase + 9 s Cooldown = 35 s** bei x1 Speed. Damit: | Spieldauer | Wellen | Bosse (alle 10 Wellen) | |---|---|---| | 10 min | ~17 | 1 | | 20 min | ~34 | 3 | | 30 min | ~51 | 5 | **Die Kurve muss also so gebaut sein, dass ein Spieler mit frühem Workshop-Stand um Welle 20–40 stirbt** — nicht bei Welle 300, nicht bei Welle 8. Bei einer Kauf-Entscheidung alle 2–3 Wellen sind das ~12–17 Kaufmomente pro 20-Minuten-Run; daran hängt, wie fein die In-Run-Upgrade-Kosten gestaffelt sein müssen. Der Cooldown pausiert **nur die Spawns**, nicht das Spiel — Gegner laufen und kämpfen weiter. Keine Verschnaufpause zwischen Wellen. Wichtig für die Economy-Rechnung: die Cap-Entscheidung (10 000 statt 150 Gegner) verschiebt das Einkommen um Faktor ~13 und, weil die Gegnerzahl über den Run steigt, nicht einmal konstant. Die Kurve muss gegen **Kills pro Welle** normiert werden, nicht gegen Wellen — sonst wächst das Einkommen quadratisch gegen linear wachsende Kosten. Details in den Kommentaren zu #1. Nicht belegt und weiterhin offen: die HP-/Schadens-Skalierungsformel pro Welle. Das Wiki dokumentiert sie nicht — dieser Wert ist zu entwerfen, nicht abzuleiten.
RDietermann commented 2026-08-10 11:51:29 +00:00
Author
Owner
Copy Link

Entschieden.

Frage Entscheidung
Erster Run Tod bei Welle 10–15 — der Spieler sieht genau einen Boss und stirbt kurz danach. Bei 35 s/Welle sind das 6–9 Minuten.
Wachstum Konstant exponentiell pro Welle, plus ein Multiplikator auf Boss-Wellen. Zwei Regler: einer bestimmt die Runlänge, einer, wie sehr sich Welle 10/20/30 wie eine Prüfung anfühlt.
Kosten vs. HP im Run Erst vorne, dann überholt. Kosten wachsen anfangs langsamer als Gegner-HP, ab etwa zwei Dritteln der Runlänge überholt die HP-Kurve. Der Run endet entschieden statt zu versanden.
Meta-Ertrag Drop-basiert: Gegner haben eine Chance, Meta-Währung fallen zu lassen, Bosse droppen garantiert. Die gedroppte Menge ist wellenabhängig. Workshop-Kosten wachsen exponentiell pro Level.

Was der Drop-Mechanismus nach sich zieht

Der Ertrag pro Run wächst überproportional mit der Run-Tiefe. Drei Faktoren multiplizieren sich: mehr Wellen, mehr Gegner pro Welle (die Gegnerzahl steigt laut Karte über den Run), und höherer Wert pro Drop (wellenabhängig). Ein Run, der doppelt so tief kommt, bringt nicht doppelt, sondern ein Vielfaches.

Dem stehen exponentiell wachsende Workshop-Kosten gegenüber — aber exponentiell in der Stufe, nicht in der Run-Zahl. Das sind verschiedene Variablen, und welche gewinnt, entscheidet, ob sich die Schleife beschleunigt oder in einen Grind kippt. Das ist keine Geschmacksfrage mehr, das ist Rechnen. Und es ist der Grund, warum das Meta-Tempo hier nicht als Zahl festgelegt wird: es ist keine freie Größe, es folgt aus den drei Kurven.

Bosse werden zum eigentlichen Fortschrittsereignis. Ein garantierter Drop alle zehn Wellen bei wellenabhängigem Wert heißt: der Sprung von „ich schaffe Welle 19" auf „ich schaffe Welle 21" ist ein Ertragssprung, nicht ein gradueller Zuwachs. Das ist ein gutes Muster — es gibt der Zehner-Struktur eine zweite Funktion neben dem Schwierigkeits-Rhythmus. Es heißt aber auch: der Boss-Drop muss deutlich über dem liegen, was Normalgegner in zehn Wellen zusammentragen, sonst ist die Garantie folgenlos.

Kaufen läuft durchgehend, nicht an Wellengrenzen

Der Spieler kann jederzeit im Shop kaufen — kein Wellenende, keine Pause, keine Freigabe. Das Panel aus docs/design/hud-in-run.png ist während des Kampfes offen und bedienbar.

Das ändert, womit man diese Kurve tunt. Eine frühere Schätzung von „12–17 Kaufmomenten pro Run" ging von einer Entscheidung alle zwei bis drei Wellen aus — die trägt nicht mehr. Der Kaufrhythmus folgt der Einkommensrate, nicht der Wellenstruktur. Gekauft wird, sobald man es sich leisten kann.

Die Zielgröße ist damit die Zeit zwischen zwei bezahlbaren Käufen, nicht die Zahl der Käufe pro Welle. Zu kurz und der Spieler klickt im Sekundentakt, was in einem Idle-Spiel das Gegenteil des Versprechens ist; zu lang und die einzige Interaktion im Run verschwindet. Ein Anhaltspunkt für die erste Kalibrierung: früh im Run alle 10–20 Sekunden ein bezahlbarer Kauf, später seltener, weil die Kosten exponentiell steigen und die Einkommensrate nur linear mit der Kill-Zahl mitwächst.

Zwei Folgen, die daran hängen:

  • Die „erst vorne, dann überholt"-Form entsteht von selbst, wenn die Kosten schneller wachsen als die Einkommensrate. Man muss sie nicht zusätzlich einbauen — sie ist bereits das Ergebnis der beiden Kurven. Der Regler dafür ist das Verhältnis von Kosten-Exponent zu Einkommens-Wachstum, nicht ein separater Knick.
  • Die 24 Shop-Zeilen konkurrieren jetzt in Echtzeit. Wer laufend kaufen kann, kauft das jeweils Billigste, wenn nichts dagegen spricht. Damit die Kaufreihenfolge eine Entscheidung bleibt und keine Sortierung, müssen sich Kosten und Wirkung zwischen den drei Tabs merklich unterscheiden — sonst arbeitet der Spieler die Liste von unten nach oben ab.

Zwei harte Randbedingungen aus früheren Entscheidungen

Drops dürfen keine Entities sein. Die Cap-Analyse in #1 hat das für die In-Run-Währung schon festgehalten, und es gilt hier genauso: bei tausenden Kills pro Welle ist ein einsammelbares Objekt pro Drop ein Entity-Sturm. Gutschrift beim Tod, kein Pickup. Das Referenzspiel lässt Münzen fallen — dieses Muster verwerfen wir bewusst.

Die Drop-Chance ist ein dritter Regler, kein Detail. Bei 10 000 gleichzeitigen Gegnern ist selbst eine Chance von 0,1 % noch ein stetiger Strom. Die Chance muss gegen die Kill-Rate gesetzt werden, nicht gegen ein Bauchgefühl — bei hoher Gegnerzahl verhält sich eine niedrige Chance faktisch wie ein Durchschnittswert pro Kill.

Was jetzt fehlt, und wie man es bekommt

Vier Zahlen sind frei und nur durch Spielen zu finden: der Wachstumsfaktor pro Welle, der Boss-Multiplikator, die Drop-Chance mal Wellenwert, und der Kosten-Exponent des Workshops. Sie hängen so voneinander ab, dass man sie nicht einzeln raten kann.

ADR-0001 hat den Weg dahin bereits benannt und als Folgeaufgabe vermerkt: ein Debug-Panel mit Sprung-zu-Welle plus Run-Telemetrie. Ohne das kostet jede Iteration einen vollständigen Run von Welle 1 an — bei 35 s pro Welle sind das Minuten pro Datenpunkt. Mit Sprung-zu-Welle wird aus der Kurve ein messbares Objekt statt eines Gefühls. Das ist der eigentliche Hebel für dieses Ticket und gehört als Werkzeug in die Spec (#10), bevor die Zahlen festgelegt werden.

Prüfkriterium für die fertige Kurve, damit man weiß, wann sie stimmt: Run 1 endet zwischen Welle 10 und 15. Jeder Run trägt mindestens ein Workshop-Level ein. Und die Run-Tiefe wächst über die ersten zehn Runs monoton, ohne dass ein Run mehr als etwa das Doppelte des vorigen erreicht — schnelleres Wachstum heißt, die Ertragskurve hat die Kostenkurve überholt und die Schleife explodiert.

**Entschieden.** | Frage | Entscheidung | |---|---| | Erster Run | Tod bei **Welle 10–15** — der Spieler sieht genau einen Boss und stirbt kurz danach. Bei 35 s/Welle sind das **6–9 Minuten**. | | Wachstum | **Konstant exponentiell pro Welle, plus ein Multiplikator auf Boss-Wellen.** Zwei Regler: einer bestimmt die Runlänge, einer, wie sehr sich Welle 10/20/30 wie eine Prüfung anfühlt. | | Kosten vs. HP im Run | **Erst vorne, dann überholt.** Kosten wachsen anfangs langsamer als Gegner-HP, ab etwa zwei Dritteln der Runlänge überholt die HP-Kurve. Der Run endet entschieden statt zu versanden. | | Meta-Ertrag | **Drop-basiert**: Gegner haben eine *Chance*, Meta-Währung fallen zu lassen, **Bosse droppen garantiert**. Die gedroppte Menge ist **wellenabhängig**. Workshop-Kosten wachsen **exponentiell** pro Level. | ## Was der Drop-Mechanismus nach sich zieht **Der Ertrag pro Run wächst überproportional mit der Run-Tiefe.** Drei Faktoren multiplizieren sich: mehr Wellen, mehr Gegner pro Welle (die Gegnerzahl steigt laut Karte über den Run), und höherer Wert pro Drop (wellenabhängig). Ein Run, der doppelt so tief kommt, bringt nicht doppelt, sondern ein Vielfaches. Dem stehen **exponentiell wachsende Workshop-Kosten** gegenüber — aber exponentiell in der **Stufe**, nicht in der Run-Zahl. Das sind verschiedene Variablen, und welche gewinnt, entscheidet, ob sich die Schleife beschleunigt oder in einen Grind kippt. **Das ist keine Geschmacksfrage mehr, das ist Rechnen.** Und es ist der Grund, warum das Meta-Tempo hier nicht als Zahl festgelegt wird: es ist keine freie Größe, es folgt aus den drei Kurven. **Bosse werden zum eigentlichen Fortschrittsereignis.** Ein garantierter Drop alle zehn Wellen bei wellenabhängigem Wert heißt: der Sprung von „ich schaffe Welle 19" auf „ich schaffe Welle 21" ist ein Ertragssprung, nicht ein gradueller Zuwachs. Das ist ein gutes Muster — es gibt der Zehner-Struktur eine zweite Funktion neben dem Schwierigkeits-Rhythmus. Es heißt aber auch: der Boss-Drop muss deutlich über dem liegen, was Normalgegner in zehn Wellen zusammentragen, sonst ist die Garantie folgenlos. ## Kaufen läuft durchgehend, nicht an Wellengrenzen Der Spieler kann **jederzeit** im Shop kaufen — kein Wellenende, keine Pause, keine Freigabe. Das Panel aus `docs/design/hud-in-run.png` ist während des Kampfes offen und bedienbar. Das ändert, womit man diese Kurve tunt. Eine frühere Schätzung von „12–17 Kaufmomenten pro Run" ging von einer Entscheidung alle zwei bis drei Wellen aus — die trägt nicht mehr. **Der Kaufrhythmus folgt der Einkommensrate, nicht der Wellenstruktur.** Gekauft wird, sobald man es sich leisten kann. Die Zielgröße ist damit **die Zeit zwischen zwei bezahlbaren Käufen**, nicht die Zahl der Käufe pro Welle. Zu kurz und der Spieler klickt im Sekundentakt, was in einem Idle-Spiel das Gegenteil des Versprechens ist; zu lang und die einzige Interaktion im Run verschwindet. Ein Anhaltspunkt für die erste Kalibrierung: früh im Run alle 10–20 Sekunden ein bezahlbarer Kauf, später seltener, weil die Kosten exponentiell steigen und die Einkommensrate nur linear mit der Kill-Zahl mitwächst. Zwei Folgen, die daran hängen: - **Die „erst vorne, dann überholt"-Form entsteht von selbst**, wenn die Kosten schneller wachsen als die Einkommensrate. Man muss sie nicht zusätzlich einbauen — sie ist bereits das Ergebnis der beiden Kurven. Der Regler dafür ist das Verhältnis von Kosten-Exponent zu Einkommens-Wachstum, nicht ein separater Knick. - **Die 24 Shop-Zeilen konkurrieren jetzt in Echtzeit.** Wer laufend kaufen kann, kauft das jeweils Billigste, wenn nichts dagegen spricht. Damit die Kaufreihenfolge eine Entscheidung bleibt und keine Sortierung, müssen sich Kosten und Wirkung zwischen den drei Tabs merklich unterscheiden — sonst arbeitet der Spieler die Liste von unten nach oben ab. ## Zwei harte Randbedingungen aus früheren Entscheidungen **Drops dürfen keine Entities sein.** Die Cap-Analyse in #1 hat das für die In-Run-Währung schon festgehalten, und es gilt hier genauso: bei tausenden Kills pro Welle ist ein einsammelbares Objekt pro Drop ein Entity-Sturm. Gutschrift beim Tod, kein Pickup. Das Referenzspiel lässt Münzen fallen — dieses Muster verwerfen wir bewusst. **Die Drop-Chance ist ein dritter Regler, kein Detail.** Bei 10 000 gleichzeitigen Gegnern ist selbst eine Chance von 0,1 % noch ein stetiger Strom. Die Chance muss gegen die *Kill-Rate* gesetzt werden, nicht gegen ein Bauchgefühl — bei hoher Gegnerzahl verhält sich eine niedrige Chance faktisch wie ein Durchschnittswert pro Kill. ## Was jetzt fehlt, und wie man es bekommt Vier Zahlen sind frei und nur durch Spielen zu finden: der Wachstumsfaktor pro Welle, der Boss-Multiplikator, die Drop-Chance mal Wellenwert, und der Kosten-Exponent des Workshops. Sie hängen so voneinander ab, dass man sie nicht einzeln raten kann. ADR-0001 hat den Weg dahin bereits benannt und als Folgeaufgabe vermerkt: **ein Debug-Panel mit Sprung-zu-Welle plus Run-Telemetrie.** Ohne das kostet jede Iteration einen vollständigen Run von Welle 1 an — bei 35 s pro Welle sind das Minuten pro Datenpunkt. Mit Sprung-zu-Welle wird aus der Kurve ein messbares Objekt statt eines Gefühls. Das ist der eigentliche Hebel für dieses Ticket und gehört als Werkzeug in die Spec (#10), bevor die Zahlen festgelegt werden. **Prüfkriterium für die fertige Kurve**, damit man weiß, wann sie stimmt: Run 1 endet zwischen Welle 10 und 15. Jeder Run trägt mindestens ein Workshop-Level ein. Und die Run-Tiefe wächst über die ersten zehn Runs monoton, ohne dass ein Run mehr als etwa das Doppelte des vorigen erreicht — schnelleres Wachstum heißt, die Ertragskurve hat die Kostenkurve überholt und die Schleife explodiert.
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:grilling
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#8
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?