Grilling: Auslöse-System für Ultimate und Card-Fähigkeiten #12
Assignees
RDietermann
Clear assignees
RDietermann
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: RDietermann/InfiniTower#12
Reference in New Issue
Block a user
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?
Part of #1
Blocked by: #6
Ultimate (#9) und Card-Fähigkeiten (#11) feuern beide automatisch nach Regel. Es soll ein Auslöse-System geben, nicht zwei. Dieses System hat bisher kein Ticket — es steht als Nebensatz in #9 und #11 und würde bei #10 erfunden statt entschieden.
Warum es ein eigenes Ticket verdient: die Stat-Pipeline aus #6 ist an einem Nachmittag umgebaut — ein Turm, sechs bis acht Stats, zwei Ebenen. Das Auslöse-System dagegen sitzt zwischen Ultimate, jeder Fähigkeiten-Card und dem gesamten Kern-Gefühl „Idle". Es ist das Stück, das man später am schwersten rausoperiert, und genau deshalb gehört es entschieden, bevor die erste Fähigkeit gebaut wird.
Der Kern
Der Slice hat keinen Knopf. Der Spieler stellt ein, der Turm handelt. Damit ist die Auslöse-Regel das Gameplay der Fähigkeiten — sie ersetzt vollständig, was in anderen Spielen der Spieler entscheidet. Eine Ultimate, die feuert, sobald der Cooldown abgelaufen ist, fühlt sich dumm an. Eine, die auf den richtigen Moment wartet, fühlt sich klug an. Der Unterschied ist die Regel, und die ist Design, kein Implementierungsdetail.
Randbedingung aus der Cap-Entscheidung
Bedingungen, die den Weltzustand abfragen („N Gegner in Reichweite"), laufen gegen bis zu 10 000 Entities. Bei sechs Fähigkeiten jeden Frame ist das kein Selbstläufer — #4 hat gemessen, dass
tower_firemit seinem naiven O(n)-Zielscan der nächste Hotspot nach dem Rendering ist. Eine Auslöse-Bedingung, die dasselbe nochmal tut, verdoppelt ihn. Die Antwort ist wahrscheinlich, den Reichweiten-Scan einmal zu machen und das Ergebnis zu teilen — aber das ist eine Architektur-Entscheidung, keine Optimierung von später.Fertig, wenn die Form der Auslöse-Bedingung festgelegt ist, das Konflikt-Verhalten benannt ist und klar ist, wo die Regel im Datenmodell lebt — sodass die Spec (#10) sie nur noch mit konkreten Fähigkeiten füllen muss.
Entschieden.
Was daraus folgt
Der Reichweiten-Scan wird einmal gemacht und geteilt. Das ist keine Optimierung für später, sondern die Bedingung, unter der diese Entscheidung überhaupt tragfähig ist. #4 hat gemessen, dass
tower_firemit seinem naiven O(n)-Zielscan der nächste Hotspot nach dem Rendering ist — bei 10 000 Gegnern und bis zu sechs Fähigkeiten, die jeweils „N Gegner in Reichweite" prüfen, wäre das derselbe Scan siebenmal pro Frame. Ein System ermittelt den Reichweiten-Zustand, alle Auslöse-Bedingungen undtower_firelesen das Ergebnis.„Alle feuern" ist bewusst gewählt, nicht vergessen. Bei maximal sechs gleichzeitigen Fähigkeiten ist ein gemeinsamer Auslöser kein Balancing-Problem, sondern ein Belohnungsmoment. Sollte sich später zeigen, dass der Bildschirm unlesbar wird, ist eine globale Sperre nachrüstbar — sie ändert nichts am Datenmodell, nur am auswertenden System.
Fest verdrahtete Bedingungen bleiben trotzdem Daten. Die Bedingung gehört laut ADR-0002 zur Fähigkeits-Component und kommt wie alle Zahlen aus
Res<Balance>. Sie im Code zu vergraben wäre ein Verstoß gegen ADR-0001. Damit ist „später einstellbar machen" ohnehin nur noch UI-Arbeit, ohne dass wir das jetzt bauen.Eine Entscheidung, die hier zusätzlich gefallen ist
Die Sichtbarkeitsantwort legt nebenbei fest, dass der Slice eine tab-basierte UI-Hülle bekommt: In-Run-Upgrades, Workshop, Cards und jetzt ein eigener Tab für Ultimates. Das ist die erste UI-Struktur-Entscheidung im Projekt und stand vorher nirgends.
Sie hat eine Konsequenz, die benannt gehört: ein Cooldown in einem geschlossenen Tab ist während des Kampfes unsichtbar. Wer die Arena beobachtet, sieht ihn nicht. Für ein Idle-Spiel ist das vertretbar — man muss nicht zusehen, und der radiale Sweep erklärt sich beim Feuern selbst. Aber es heißt auch: die Auslösung ist im laufenden Spiel nicht vorhersehbar, nur nachvollziehbar, wenn man nachschaut. Falls sich das im Spielgefühl als Verlust zeigt, ist die kleinste Korrektur ein Ring am Turm zusätzlich zum Tab, nicht statt seiner.
Die restliche Tab-Struktur — welche Tabs es gibt, was Default ist, ob sie im Run und zwischen Runs dieselben sind — gehört in die Spec (#10) und bekommt kein eigenes Ticket: UI-Layout ist billig zu ändern, im Gegensatz zum Auslöse-System selbst.
Offen für die Spec (#10): die konkrete Schwelle je Fähigkeit, die Cooldown-Dauern, und ob der Weltzustand pro Fähigkeit unterschiedlich ist oder alle dasselbe Prädikat benutzen. Das sind Zahlen und gehören zu #8.