Browsernative Spiele werden ernstzunehmend: Was Open-Source-Kampfprojekte zeigen

Ich begann diese Recherche in der Erwartung, eine Handvoll interessanter Experimente mit Browserkämpfen zu finden. Stattdessen stieß ich auf ein deutlich breiteres Ökosystem: echte Third-Person-Actionprototypen mit Lock-on-Zielerfassung, verzweigten Combo-Bäumen, perfekten Paraden, Unverwundbarkeit beim Ausweichen, Haltungssystemen, Luftangriffen, Angriffssignalen von Bossen, Motion Warping, Hit-Stop, physischen Waffenkollisionen, Gamepad-Unterstützung, Touch-Steuerung und deterministischer Simulation.

Das ist das entscheidende Ergebnis. Das sind nicht mehr nur kleine Spiele, die zufällig in einer Webseite gerendert werden. Einige von ihnen lösen dieselben technischen Probleme wie herkömmliche Actionspiele, werden aber als URL ausgeliefert und lassen sich sofort spielen.

Für mich als Webentwickler ist genau das der faszinierende Teil. Das alte Bild von Spielen war geprägt von Installationsprogrammen, großen Downloads, Patchern, Launchern und einer Verzögerung zwischen dem Entdecken eines Spiels und dem tatsächlichen Ausprobieren. Der Browser verkürzt diesen Weg drastisch: Link öffnen, Assets laden und losspielen.

Diese Recherche konzentrierte sich auf Projekte mit einer spielbaren Browser-Version und öffentlich zugänglichem Quellcode. Unity-WebGL-Exporte habe ich bewusst ausgeschlossen, weil ich Spiele untersuchen wollte, die auf Webtechnologien aufbauen, statt Spiele, die lediglich ins Web exportiert wurden.

Die stärksten Projekte, die ich gefunden habe

Die nützlichsten Funde waren nicht alle aus demselben Grund stark. Manche hatten die tiefsten Combo-Systeme. Andere boten eine bessere Third-Person-Architektur, eine sauberere Kampfsimulation oder überzeugendere physische Treffer.

Warum mich die Ergebnisse überrascht haben

Überraschend war nicht einfach, dass die Grafik gut aussah. Eine ausgereifte Szene zu rendern ist nur ein Teil der Spieleentwicklung. Die Projekte, die herausstachen, implementierten Systeme, die sich nur schwer überzeugend vortäuschen lassen: Eingabepufferung, Übergänge zwischen Kampfzuständen, Zielauswahl, Bewegung während eines Angriffs, Animations-Timing, Treffererkennung, Gegnerreaktionen, Zeitfenster für Verteidigung, Kameraverhalten und Trefferfeedback.

Daraus ergibt sich eine nützliche Unterscheidung:

• Animations-Timing ist nicht dasselbe wie Kampf-Timing;
• die Rendering-Bildrate ist nicht die Simulationsrate;
• eine Kollision ist nicht automatisch ein gültiger Treffer;
• eine Animation muss nicht zwangsläufig die Bewegung bestimmen;
• sichtbarer Kontakt ist nicht dasselbe wie wahrgenommene Wucht.

Diese Unterschiede tauchten bei den stärksten Projekten immer wieder auf und sind wichtiger als das Logo des Renderers im README.

Voxel Musou: Browserkämpfe können eine echte Move-Grammatik haben

Voxel Musou war eines der deutlichsten Beispiele dafür, dass Browserkampf nicht mehr bedeuten muss, dass eine Angriffsanimation an eine einzige Taste gebunden ist. Der Quellcode ist unter mike007jd/voxel-musou verfügbar.

Das Projekt verwendet lange Ketten normaler Angriffe und Verzweigungen für aufgeladene Angriffe statt einer rein linearen Combo. Architektonisch ist das wichtig, weil sich das System so modellieren lässt:

current move + buffered input + combat state -> next move

Das ist für ein Character-Action-Spiel eine deutlich bessere Grundlage als eine ständig wachsende Sammlung von Sonderfall-Bedingungen. Es zeigt außerdem Luftangriffe, Spezialsequenzen, mehrere Charakter-Kits, Bossverhalten, Hit-Stop und Kämpfe gegen große Gegnergruppen.

Die allgemeinere technische Erkenntnis lautet: Moves sollten zu Daten werden und Übergänge explizit sein. Sobald das der Fall ist, muss für einen weiteren Charakter nicht mehr der gesamte Kampf-Controller neu geschrieben werden.

Long Wind: am nächsten an einem modernen Browser-Actionspiel

Long Wind war eine der stärksten All-in-one-Referenzen, weil es Third-Person-Bewegung mit leichten und schweren Angriffen, Lock-on, Blocken, perfekter Parade, Unverwundbarkeit beim Ausweichen, Haltungsdruck, Exekutionen, Hochschleuder- und Knockdown-Reaktionen, Projektilen, Bossen und mehreren Gegnertypen kombiniert. Der Quellcode ist unter jbang2004/long-wind verfügbar.

Es ist nicht deshalb wertvoll, weil jedes einzelne Feature beispiellos wäre, sondern weil diese Features in einem einzigen browsernativen Actionprototyp zusammenkommen. Dadurch eignet es sich gut, um den gesamten Weg von der Eingabe über Zielauswahl, Angriffszustand, Animation, Kontakt, Reaktion und Hit-Stop bis zum Kamera-Feedback nachzuverfolgen.

Motion Warping löst ein Problem, das Web-Demos oft ignorieren

Samurai Third-Person Template ThreeJS ist besonders interessant, weil es ein klassisches Problem des Third-Person-Nahkampfs angeht. Der Quellcode ist unter achrefelouafi/SamuraiThirdPersonTemplateThreeJS verfügbar.

Eine vorgegebene Angriffsanimation setzt voraus, dass sich das Ziel in einer bestimmten Entfernung befindet, wenn der Schlag seinen Kontakt-Frame erreicht. In einem echten Spiel steht das Ziel fast nie perfekt. Spielt der Charakter die Animation einfach an Ort und Stelle ab, kann das Schwert sichtbar danebengehen, obwohl das Spiel Schaden verursacht. Teleportiert sich der Charakter dagegen in Position, wirkt der Angriff künstlich.

Motion Warping bietet eine bessere Lösung: Rotation und Translation werden während des Angriffs so angepasst, dass der Charakter zum richtigen Zeitpunkt die erwartete Kontaktposition erreicht.

Die wichtige Unterscheidung lautet:

animation intent != movement authority

Ein Charakter kann die visuelle Absicht einer vorgegebenen Animation bewahren, während der Gameplay-Controller weiterhin bestimmt, wohin sich der Charakter tatsächlich bewegt.

Kollisionserkennung und Treffervalidierung sind unterschiedliche Probleme

Stick & Steel untersucht ein ganz anderes Kampfmodell. Der Quellcode ist unter Rabneba/stick-steel verfügbar.

Statt das Schwert in erster Linie als Animation mit einem Schadensvolumen zu behandeln, verleiht das Projekt Waffen eine physische Präsenz. Kontaktgeschwindigkeit, Waffenorientierung, Körperregion, Blocks, Zusammenstöße, Knockdowns und Entwaffnen spielen alle eine Rolle.

Die am besten übertragbare Erkenntnis ist nicht, dass jedes Actionspiel vollständig physische Waffen verwenden sollte. Sie lautet:

Eine Kollision sagt dir, dass sich zwei Dinge berührt haben. Sie sagt dir nicht, ob ein relevanter Treffer stattgefunden hat.

Ein überzeugendes Kampfsystem benötigt häufig eine zweite Ebene, die entscheidet, ob der Kontakt genügend Geschwindigkeit hatte, aus der richtigen Richtung kam, den richtigen Waffenbereich betraf, zum richtigen Zeitpunkt stattfand und auf einen gültigen Zielzustand traf, damit er als Schaden zählt.

Zentrale Kampfauflösung macht komplexe Verteidigung leichter nachvollziehbar

Hollowmere, dessen Quellcode unter euuuuuuan/hollowmere-public verfügbar ist, fiel weniger durch visuelles Spektakel als durch seine Softwarearchitektur auf.

Die Kampfsimulation ist vom Rendering getrennt, und die Abwehrentscheidung wird zentral getroffen. Das verhindert einen häufigen Fehler in Actionspielen, bei dem Ausweichsystem, Paradesystem, Trefferreaktionssystem und Animationsschicht unabhängig voneinander zu unterschiedlichen Ergebnissen darüber kommen können, ob derselbe Angriff getroffen hat.

Ein klareres Denkmodell ist:

incoming attack -> evade | parry | hit

Der Renderer sollte das Ergebnis darstellen und nicht eine zweite Version der Kampfwahrheit erfinden.

Diese Unterscheidung wird umso wichtiger, je komplexer das Kampfsystem wird. Deterministische Simulation und explizite Zustandsübergänge sind keine glamourösen Features, machen komplexe Kämpfe aber leichter zu testen, zu debuggen und zu erweitern.

Game Feel ist ein technisches System, keine Dekoration

Fabled Revolutions, dessen Quellcode unter ericrius1/FabledRevolutions verfügbar ist, ist gerade deshalb nützlich, weil es die Effekte isoliert, durch die Treffer wuchtig wirken.

Ein logisch korrektes Kampfsystem kann sich trotzdem schwach anfühlen. Die Kollision kann präzise sein, der Schaden kann im richtigen Frame angewendet werden, und trotzdem kann es sich so anfühlen, als würden zwei Modelle einfach durcheinander hindurchgleiten.

Die wahrgenommene Wucht entsteht häufig aus einem Stapel kurzlebiger Effekte:

• Hit-Stop;
• Kamerawackeln oder -ruck;
• Waffenspuren;
• Trefferpartikel;
• Trefferblitz;
• Knockback;
• Animationsreaktion;
• gut getimter Sound.

Daraus ergibt sich eine weitere nützliche Unterscheidung: Die Korrektheit des Kampfsystems ist nicht dasselbe wie das Kampfgefühl. Ein Browserspiel braucht beides.

Der Renderer war nicht der wichtigste Indikator für Kampfqualität

Eines der interessanteren Muster in der Recherche war, dass die Qualität der besten Kampfsysteme nicht davon bestimmt wurde, ob ein Projekt die neueste Rendering-API verwendete.

Three.js tauchte immer wieder auf. Einige Projekte verwendeten Rendering-Technologien rund um WebGPU, andere konventionelle WebGL-basierte Stacks. Physik-Engines, TypeScript, JavaScript, Vite, WebAssembly und unterschiedliche Rendering-Ansätze kamen in der Recherche gleichermaßen vor.

Ausgereifte Kampfsysteme hingen jedoch deutlich konsistenter von der Architektur ab: Simulation mit festem Zeitschritt, explizite Zustände, zuverlässige Zielerfassung, klare Zuständigkeit für Animationen, datengesteuerte Moves, zentrale Schadensauflösung und gutes Trefferfeedback.

Das ist für Webentwickler ermutigend. Man muss nicht darauf warten, dass jeder Nutzer den neuesten Grafik-Stack hat, bevor man mit anspruchsvollem Kampfsystem-Design experimentiert.

Warum Browser-Distribution die Ausgangslage verändert

Der Browser hat einen Vorteil, der nur wenig mit Grafik zu tun hat: extrem geringe Hürden bei der Distribution.

Bei traditionellen Spielen liegen zwischen Entdeckung und Interaktion oft mehrere Schritte: Store-Seite finden, ein großes Paket herunterladen, installieren, starten, auf Updates warten und manchmal noch ein Konto anlegen, bevor man überhaupt zu relevantem Gameplay kommt.

Ein Browserspiel kann diesen Weg auf einen Link verkürzen.

Das verändert, wie Prototypen geteilt und getestet werden können. Ein Entwickler kann einen Build veröffentlichen, eine URL verschicken, eine andere Person sofort in dieselbe Version bringen, Feedback sammeln und eine weitere Iteration bereitstellen, ohne den Tester zur manuellen Installation eines neuen Pakets zu zwingen.

Dieser Vorteil ist besonders für experimentelle Spiele und unabhängige Entwicklung wichtig. Der Browser ist nicht nur eine Laufzeitumgebung, sondern auch ein Distributionssystem.

Wo der Browser noch das Nachsehen hat

Die Recherche hat mich nicht davon überzeugt, dass Browser native Spieleplattformen ersetzt haben. Das haben sie nicht.

Mehrere Einschränkungen bleiben wichtig:

• Große Asset-Datenmengen. Sofortiger Zugriff fühlt sich nicht mehr sofort an, wenn ein Spiel einen sehr großen initialen Download benötigt.
• Speicherdruck. Browser müssen mit anderen Tabs und dem Betriebssystem koexistieren, und ihr Speicherverhalten ist weniger vorhersehbar als in einem dedizierten nativen Prozess.
• Thermische Grenzen auf Mobilgeräten. Ein technisch funktionierendes 3D-Spiel kann während einer längeren Sitzung trotzdem stark drosseln.
• Unterschiede zwischen Browsern. Grafik, Audio, Pointer Lock, Vollbildverhalten, Controller und Performance-Eigenschaften sind nicht vollkommen einheitlich.
• Shader- und Asset-Vorbereitung. Kompilierungs- oder Upload-Arbeit kann weiterhin sichtbare Hänger verursachen, wenn die Pipeline nicht sorgfältig entworfen ist.
• Einschränkungen bei Offline-Nutzung und lokaler Persistenz. Native Anwendungen behalten mehr direkte Kontrolle über große lokale Installationen und Dateien.
• Sicherheit im kompetitiven Umfeld. Ernstzunehmender Anti-Cheat und Annahmen über einen feindlichen Client werden deutlich schwieriger, wenn der Client eine Webanwendung ist.

Diese Einschränkungen sind wichtig, weil sie definieren, wo Browserspiele heute ihre größten Stärken haben: bei Spielen, die von sofortigem Zugriff, schneller Iteration, plattformübergreifender Auslieferung und beherrschbaren Asset- und Laufzeitbudgets profitieren.

KI verkürzt die Schleife vom Prototyp zur URL deutlich

KI ist hier relevant, aber nicht, weil sie einen Satz auf magische Weise in ein fertiges, hochwertiges Spiel verwandelt. Der realistischere Vorteil ist die Geschwindigkeit der Iteration.

Moderne Spieleentwicklung umfasst viele kleine Aufgaben, die in Summe teuer werden: Zustandsautomaten einrichten, Debug-Ansichten bauen, Tests schreiben, mit Gegnerverhalten experimentieren, Datenformate für Moves erstellen, Eingabecode refaktorieren, Shader prototypisieren, Physikfehler untersuchen und temporäre Inhalte verdrahten.

KI kann viele dieser Schleifen verkürzen. Zusammen mit der Distribution über das Web wird der Ablauf ungewöhnlich direkt:

idea -> prototype -> deploy -> open URL -> test -> iterate

Der Browser macht die Bereitstellung bereits schnell. KI kann auch die Implementierungsseite derselben Schleife beschleunigen.

Die wichtige Einschränkung ist, dass schnelle Generierung weder gestalterisches Urteil noch Validierung ersetzt. Ein generierter Kampf-Controller kann strukturell falsch sein. Das Timing von Animationen braucht weiterhin menschliches Urteilsvermögen. Physik muss weiterhin debuggt werden. Performance muss weiterhin gemessen werden. KI senkt die Kosten, Ideen auszuprobieren; sie nimmt einem aber nicht die Entscheidung ab, welche Ideen gut sind.

Was das für Webentwickler bedeutet

Die Grenze zwischen Webentwicklung und Spieleentwicklung wird weniger starr.

Ein anspruchsvolles Browserspiel kann heute vertraute Webwerkzeuge nutzen und zugleich klassische Konzepte der Spieleentwicklung erfordern:

• feste Simulationsschritte;
• Zustandsautomaten;
• Eingabepufferung;
• Animationsgraphen;
• räumliche Abfragen;
• Physik;
• Frame-Budgets;
• GPU-Ressourcenverwaltung;
• Audio-Timing;
• deterministische Systeme.

Gleichzeitig erhalten Spieleentwickler, die den Browser als Zielplattform nutzen, Dinge, in denen das Web bereits außergewöhnlich gut ist: URLs, sofortige Bereitstellung, CDN-Auslieferung, schnelle Updates, Telemetrie, Kontosysteme, responsive Oberflächen und reibungsloses Teilen.

Die Recherche hat mein eigenes Bild verändert. Ich sehe Browserspiele nicht mehr in erster Linie als vereinfachte Versionen nativer Spiele. Ich sehe den Browser als eine zunehmend leistungsfähige Spieleplattform mit anderen Stärken: sofortige Distribution, schnelle Iteration, immer ernstzunehmendere 3D-Fähigkeiten und ein riesiges bestehendes Entwicklungsökosystem.

Das Web wird nicht bloß besser darin, Spiele anzuzeigen, die anderswo entwickelt wurden. Es wird zunehmend zu einem Ort, an dem anspruchsvolle Spielsysteme direkt entworfen, implementiert, getestet, verteilt und gespielt werden können.