Da hast du mich falsch verstanden: Es passiert im Backend, aber es soll sich eben nicht genau auf diese Weise im Frontend äußern. Dass Heldenkarten kurzzeitig auf 30HP zurücksetzen, hat was mit interner Code-Logik zu tun. In der Datenbank wird irgendwo eine >Klasse< festgehalten sein, welche die Gesetzesmäßigkeiten für Helden beschreibt.
Diese Klasse definiert alle Basics wie z.B. Waffen anlegen oder eine Heropower zu haben, bei 0HP zu sterben, Rüstung erhalten zu können und eben auch standardgemäß mit 30HP in’s Spiel einzutreten (Spielbeginn).
Da Heldenkarten auch der Klasse >Held< zugewiesen sind um als solcher funktionieren zu können, kommen sie auch mit dessen Attributen in’s Spiel, daher wird die HP kurzzeitig auf 30 gesetzt, bevor der tatsächliche Wert wiederhergestellt wird.
Aber das ist eben etwas, das eigentlich nur im Backend passieren soll und lediglich die interne Code-Logik benötigt, um operieren zu können. Im Frontend (=der Spiellogik) soll natürlich kein Heal ausgeführt oder Schaden genommen werden, der Effekte auslöst, die auf Heal oder Schaden basieren.
Demnach ist das was man im Backend findet keine verlässliche Quelle für die Spielregeln oder Logik, weil der Backend-Dev bei dem was er da macht in erster Linie die Funktionalität gewährleistet und keinerlei Obligation hat, mit seinem Code auch 1:1 die Spielregeln abzubilden. Dieser Bug ist ein sehr gutes Beispiel dafür.
Erst auf dem Weg vom Backend in’s Frontend wird definiert, wie sich allerlei Abläufe aus dem Backend für den User äußern sollen. Hier hat man diese Wechselwirkung übersehen und vergessen, für die Banshee eine Exception zu implementieren die verhindert, dass sie auf Pseudo-HP Veränderungen reagiert, die durch das abrufen der Klasse ausgelöst werden.
Das Frontend umfasst nicht nur die Anzeige von Elementen sondern auch die Interaktion und Handlungsabläufe.
