Als begeisterter Computerspieler bin ich ungefähr 2017 auf die Speedrunning-Szene gestoßen, in der es darum geht, ein Videospiel (oder Teile davon) so schnell wie möglich durchzuspielen, wofür Glitches ausgenutzt werden.
Als Entwickler dachte ich "Glitches? Das ist doch nichts anderes als ein Programmierfehler!" Und damit begann ich, die Speedruns nicht nur mit den Augen eines Spielers, sonder mit den Augen eines Entwicklers zu sehen. Eines meiner Erkenntnisse - Spieleentwicklung und Frontendentwicklung teilen sich gewisse Konzepte und Gedanken - genug, dass es Frontend-Javascript-Frameworks gibt, mit denen Videospiele entwickelt werden können.
Beide Entwicklungs-Umgebungen besitzen Stores zur Datenhaltung und verwenden Events, um Benutzereingaben zu verarbeiten, und bei beiden gibt es ähnliche Fallstricke, wenn ein Benutzer zum falschen Zeitpunkt bestimmte Events auslöst. Bei beiden sollte der Store zentral verwaltet sein und nur definierte, klare Zustände annehmen können.
Als Beispiel für einen Glitch, der sich auf Frontend-Anwendungen abbilden lässt, gibt es zum Beispiel einen der bekanntesten Glitches aller Zeiten - der Backwards Longjump (kurz BLJ) aus Super Mario 64.
In diesem Spiel ist die Geschwindigkeit, welche Mario aufbauen kann, nach oben hin begrenzt - Rückwärts kann man jedoch beliebig schnell werden, wenn man die korrekten Tasten am Controller drückt. Dadurch kann man so schnell werden, dass Mario sich rückwärts durch eine unsichtbare Wand durchmogeln kann, welche ihn eigentlich immer wieder an den Anfang einer Treppe setzen soll.
Durch die Geschwindigkeit befindet man sich in einem Frame vor der Wand und im nächsten Frame dahinter, die Kollision an sich findet nie statt. Durch solche Beispiele werde ich als Programmierer gerne daran erinnert, dass ich beim Validieren von User-Eingaben keine Abkürzungen nutzen sollte, und auch nicht davon ausgehen sollte, dass der User nur Daten sendet, die ich auch erwarte, sondern theoretisch jeder beliebige Wert gesendet werden könnte.
Weitere Probleme beim Entwickeln sind oft Features, die man "nur noch schnell" einbaut, welche gut gemeint sind, aber vielleicht nicht hundertprozentig notwendig oder nach dem üblichen Qualitätsstandard. Da kann es dann gerne passieren, dass der neue Code Nebenwirkungen hat, welche man als Entwickler nicht erwartet hat. Als Beispiel dafür sehe ich das Spiel The Legend of Zelda - Link's Awakening, welches voll von derartigen Features ist. Ursprünglich sollte das Spiel ein "Demake" eines Zelda-Spieles auf dem Super Nintendo sein, doch die Entwickler haben ein paar Features implementiert, damit es sich vom Original abhebt.
Eines dieser Features ist der Bombenpfeil - wenn man eine Bombe innerhalb ein paar Frames nach einem Pfeil einsetzt, wird die Bombe an den Pfeil angehängt und explodiert bei Kontakt. Der Fehler dabei - schafft man es, zwei Bomben hintereinander in diesem kurzen Zeitraum zu legen (beispielsweise durch ein Loch im Boden oder einen Bildschirm-Wechsel), dann weiß das Spiel nicht, wo die zweite Bombe angehängt werden soll, und löst eine Zwischensequenz eines Spiel-Objektes an einer bestimmten Stelle im Code aus. Im Falle von einsammelbaren Gegenständen bedeutet dies, dass man diese aus beliebiger Distanz und durch Wände einsammeln kann. An anderen Stellen im Spiel kann man damit Wege freischalten, die erst später oder durch andere, länger dauernde Methoden geöffnet werden sollten.
Solche Beispiele zeigen mir, dass "nur mal schnell" ein Satz ist, über den man sehr genau nachdenken sollte.
Außerdem sollten Frontend-Entwickler immer daran denken, dass man im Browser jederzeit auf den ausgeführten Code schauen kann, und dass die diversen Build-Tools wie WebPack, Rollup und Vite oft von den Entwicklern selbst so eingestellt werden, dass Sourcemaps erzeugt werden, welche den Code explizit lesbar machen. Dies bedeutet natürlich, dass jede noch so gute Sicherheitsmaßnahme im Code jederzeit nachvollziehbar ist, und man sich lieber doch auf die Security im Backend-Code verlassen sollte.
Bei Videospielen zeigt sich dies auf zweierlei Arten. Zum einen gibt es die Möglichkeit, auf den Arbeitsspeicher des ausgeführten Spieles zu schauen, um nachvollziehen zu können, welcher Wert z.B. für die Lebenspunkte steht, die Munition oder ähnliches. Wenn man diese Werte versteht und bestenfalls sogar noch manipulieren kann, kann man "perfekte" Speedruns gestalten. Zum Anderen gibt es Projekte, welchen den kompilierten Code von Spielen analysieren und die Abläufe erklären. Dadurch werden z.B. internas wie der verwendete Zufallsgenerator oder auch das Verhalten von Gegnern und anderen Spielmechaniken bekannt gemacht, wodurch neue Glitches und Strategien entwickelt werden können.
Alles in Allem lässt sich feststellen, dass alle Programmierer - sei es Backend, Frontend, Spiele, Desktop-Anwendungen, ... - auch nur mit Wasser kochen, und auf ziemlich ähnliche Probleme achten müssen. Wieso also nicht mal mit Spiel, Spaß und Speed?
