Warum ich Browserspiele baue
Ein persönlicher Essay
Veröffentlicht: April 2026 · Aktualisiert: · Über mich
Neulich hat mich jemand gefragt, warum ich Browserspiele baue — statt auf Steam zu veröffentlichen, auf itch.io, oder gleich eine Mobile-App zu machen. Die Frage hat mich überrascht, weil die Antwort für mich völlig offensichtlich ist. Aber als ich versucht habe, sie auszuformulieren, habe ich gemerkt: So offensichtlich ist sie gar nicht. Hier also mein Versuch einer Antwort.
Die Sache mit der Reibung
Ein Browserspiel hat eine Eigenschaft, die keine andere Vertriebsform hat: null Reibung. Nicht wenig Reibung — null. Du schickst jemandem einen Link. Die Person klickt drauf. Sie spielt. Kein App Store, kein Installations-Dialog, keine Konto-Erstellung, kein Ladebildschirm mit einem Balken, der bei 97 Prozent hängen bleibt. Das Spiel ist einfach da, sofort, in einem Tab, den jeder zu bedienen weiß.
Das klingt trivial, bis man einmal zusieht, wie jemand versucht, ein Handyspiel mit einem Familienmitglied zu teilen. „Es ist im App Store, such mal nach…“ — in dem Moment, in dem Reibung entsteht, ist die Hälfte der potenziellen Spieler weg. Bei einem Browserspiel steckst du den Link in eine WhatsApp-Nachricht, und das war's. Die Hürde ist ein einziger Fingertipp.
Ich denke viel über diese Reibungslosigkeit nach, weil ich Spiele für Menschen baue, die keine Gamer sind. Meine Eltern zum Beispiel. Meine Eltern werden niemals eine App installieren, um ein Spiel von mir zu spielen. Aber einen Link klicken sie an. Das ist mir wichtig.
Die Beschränkung ist der Punkt
Ich habe eine Regel: keine Abhängigkeiten, keine Build-Tools, keine Bundler. Das Spiel muss als einzelne HTML-Datei funktionieren (oder als eine Handvoll Dateien). Kein npm, kein Webpack, kein TypeScript-Compiler, keine Deployment-Pipeline. Datei öffnen. Fertig.
Wenn ich das erzähle, denken manche, das sei eine Einschränkung, die ich widerwillig ertrage. Es ist das Gegenteil — eine kreative Entscheidung, die ich aktiv will. Beschränkungen erzwingen Klarheit. Wenn man nicht zur Bibliothek greifen kann, schreibt man einfacheren Code. Wenn es keinen Build-Schritt gibt, kann keiner kaputtgehen. Wenn alles in eine Datei passt, kann man es tatsächlich im Kopf behalten.
Der beste Code, den ich je geschrieben habe, entstand unter den engsten Beschränkungen.
Das Partikelsystem von Easter Hop hat rund 40 Zeilen. Die Physik besteht aus drei Konstanten und drei Zeilen Mathematik pro Simulationsschritt — auf der Technik-Seite kann man sie unverändert nachlesen. Auf diese kleinen Systeme bin ich auf eine Art stolz, wie ich es auf deutlich größere Codebasen aus meinem Berufsleben nie war. Klein, vollständig, verstanden — das ist das Gefühl, um das es mir geht.
Etwas fertig machen
Die meisten Nebenprojekte werden nicht fertig. Sie werden angefangen, erreichen vielleicht 30 Prozent, und dann kommt etwas anderes dazwischen. Ich bin da keine Ausnahme — auf diversen Festplatten liegt ein Friedhof unfertiger Dinge, und ich vermute, das kennt jeder, der abends programmiert.
Browserspiele sind für mich das Format, in dem ich Dinge tatsächlich abschließe. Der Umfang begrenzt sich von selbst: Man braucht keinen Level-Editor, kein Tutorial-System, keinen Cloud-Save, kein Einstellungsmenü mit 40 Reglern. Man braucht einen Kern-Loop, der Spaß macht, und ein Grunderlebnis, das funktioniert. Damit kann man an einem Wochenende etwas Vollständiges ausliefern — und es danach wochenlang polieren, wenn man mag. Genau so ist es bei Easter Hop gelaufen; der komplette Weg vom weißen Rechteck zum fertigen Spiel steht in „Wie ich Easter Hop gebaut habe“.
Dieses Gefühl, etwas abgeschlossen zu haben — ein Ding, das funktioniert, das jemand anderes jetzt sofort benutzen kann, das vor drei Tagen noch nicht existierte — ist der eigentliche Antrieb. Es geht nicht um Reichweite oder Einnahmen. Es geht um das Fertig-Gefühl. Aus Arbeitsprojekten bekomme ich es selten. Aus diesen kleinen Spielen bekomme ich es zuverlässig.
Das offene Web ist immer noch gut
Es gibt eine verbreitete These, das offene Web liege im Sterben — alles wandere in geschlossene Gärten, App Stores, Plattform-Ökosysteme. Ich finde diese Sicht traurig, und ich halte sie für falsch, zumindest für unvollständig. Das Web ist noch da. HTML funktioniert noch. Canvas rendert mit 60 Bildern pro Sekunde. Eine Seite, die ich heute auf GitHub Pages lege, ist auf absehbare Zeit für jeden Menschen mit einem Browser erreichbar — und kein Plattform-Betreiber kann sie entfernen, auslisten oder die Konditionen ändern.
Browserspiele zu bauen ist, im Kleinen, eine Stimme für diese Version des Internets: eine, in der man ein Ding unter eine URL legen kann und jeder es erreicht. Das ändert im Großen nichts. Aber ich verbringe meine Hobby-Zeit lieber damit, für das offene Web zu bauen, als für eine Plattform, die jederzeit den Teppich wegziehen kann.
Und noch etwas, das mir erst beim Schreiben dieses Textes klar geworden ist: Ein Browserspiel altert würdevoll. Die Flash-Spiele meiner Jugend sind tot, weil ihre Laufzeitumgebung gestorben ist. Ein Spiel aus purem HTML, CSS und JavaScript hat keine Laufzeitumgebung außer dem Browser selbst — und der Browser ist die am besten gepflegte Software der Welt. Es gibt keine Garantie, aber die Wette, dass diese eine HTML-Datei in zehn Jahren noch läuft, würde ich eingehen.
Darum baue ich Browserspiele. Klein, fertig, reibungslos, kostenlos — und meins.
Über den Autor
Ich bin Peter Jacob, Webentwickler aus Hamburg. Easter Hop ist mein Feierabend-Projekt — hier kannst du es spielen, und auf der Über-mich-Seite steht, warum es das gibt. Feedback gern per E-Mail.