played – Spiele, die sich anfühlen, wie sie aussehen

Unter der Marke played entwickle ich Spiele, die eines gemeinsam haben: Sie sollen sich im Moment des Spielens richtig gut anfühlen. Keine wackeligen Lobbys, keine gefühlten Ladezeiten zwischen Zügen, keine Momente, in denen man nicht weiß, ob der Klick gerade angekommen ist. Stattdessen: direktes Feedback, flüssige Interaktionen und eine Spielerfahrung, die sich poliert anfühlt – egal, wie simpel das Spielprinzip dahinter ist.

Warum played?

played ist der Rahmen für eine Idee: dass browserbasierte Multiplayer-Spiele mehr sein können, als sie es meistens sind. Schnelle, soziale Spiele, die in Sekunden mit Freunden gestartet sind – ohne Installation, ohne Launcher, ohne Account-Marathon – und die in jedem einzelnen Detail den Anspruch haben, neue Standards zu setzen, statt sich mit "okay für den Browser" zufriedenzugeben.

Mir geht es dabei um drei Dinge gleichzeitig: Spiele, die Spaß machen. Spiele, die gut aussehen. Und Spiele, die sich im Moment des Spielens tatsächlich so anfühlen, wie sie aussehen – flüssig, präzise, ohne die kleinen Unstimmigkeiten, die man bei Echtzeit-Multiplayer im Web zu oft als gegeben hinnimmt.

Der Browser ist als Plattform inzwischen erwachsen genug für genau diese Art von Spielen. Was meistens fehlt, ist nicht die Technik, sondern die Bereitschaft, sie konsequent zu nutzen – und die Sorgfalt, jedes Detail vom Lobby-Beitritt über die Animationen bis zum Übergang zwischen zwei Runden mit dem gleichen Anspruch zu behandeln wie das Spielprinzip selbst. Genau dort möchte ich mit played ansetzen.

Die Plaza: played.click

Inzwischen sind aus dem ersten Projekt mehrere geworden, und alle wohnen unter einem Dach: played.click. Die Plaza ist der zentrale Einstieg – eine Übersicht über alle Spiele, ein gemeinsamer Account, eine geteilte Profil- und Session-Schicht. Wer einmal angemeldet ist, kann zwischen den Spielen wechseln, ohne sich neu zu authentifizieren oder eine neue Identität aufzubauen.

Das ist kein Selbstzweck, sondern eine bewusste technische Entscheidung: Statt jedes Spiel als eigene Insel zu bauen, teilen sich alle played-Spiele die Basis – Auth, Lobbies, Realtime-Layer, Asset-Pipeline. So lassen sich neue Ideen schneller umsetzen, weil die unsichtbare Infrastruktur nicht jedes Mal neu erfunden werden muss. Und für Spielende heißt es: einmal "drin sein" reicht, der Rest fühlt sich an wie verschiedene Räume im selben Haus.

reMemed – Memes mit Captions

Das erste Projekt unter der played-Marke ist reMemed – eine Alternative zum bekanntesten Meme-Caption-Spiel. Die Idee ist simpel: Man bekommt eine Meme-Vorlage, schreibt die beste Caption dazu, alle stimmen ab, der oder die Lustigste gewinnt die Runde.

Was reMemed anders macht, ist weniger das Grundprinzip und mehr das, was drumherum passiert:

• Echter Echtzeit-Spielfluss – Zustände, Timer und Abstimmungen synchronisieren sich ohne spürbare Verzögerung über alle Spielenden hinweg.
• Saubere Spiellogik – Runden, Phasen und Übergänge sind klar definiert, sodass nie unklar ist, worauf man gerade wartet.
• Eine UI, die sich leicht anfühlt – trotz viel State, der im Hintergrund bewegt wird.

Technisch bedeutet das: durchdachte Pub/Sub-Strukturen für Spiel-Events, ephemerer State, der dort lebt, wo er schnell sein muss, und persistente Daten dort, wo sie es sollen.

remplir – Fill in the Blank

Das zweite Spiel ist remplir, ein Partyspiel im Fill-in-the-Blank-Format. Man bekommt einen Satz mit einer (oder mehreren) Lücken, die alle Spielenden gleichzeitig ausfüllen. Anschließend wird – wie bei reMemed – abgestimmt, welche Antwort die beste ist.

Mechanisch ist remplir mit reMemed verwandt, aber das Spielgefühl ist ein anderes: weniger visuell, mehr sprachlich. Es lebt von Tempo, Wortwitz und der gemeinsamen Sprachebene in der Runde. Genau deshalb ist remplir zweisprachig (Deutsch/Englisch) angelegt – mit einem Prompt-Katalog, der in beiden Sprachen idiomatisch funktioniert, statt einer einfachen Übersetzung. Ein Prompt, der auf Deutsch lustig ist, muss auf Englisch nicht der gleiche Satz mit anderen Wörtern sein. Manchmal ist es ein komplett anderer Witz.

Spannend war hier vor allem die Frage, wie man dieselbe Echtzeit-Basis für ein Spiel nutzt, das auf den ersten Blick völlig anders aussieht als reMemed. Die Antwort: Phasen, Übergänge und State-Synchronisation lassen sich weitgehend wiederverwenden. Was sich ändert, sind die Inhalte und die Eingabe-UI – nicht der Kern darunter. Genau dafür ist die geteilte played-Infrastruktur da.

resolu – Quiz mit Tempo

Das dritte Projekt ist resolu, ein Echtzeit-Quizspiel. Fragen erscheinen gleichzeitig bei allen Spielenden, die schnelle und richtige Antwort gewinnt – inklusive der Knife-Edge-Momente, in denen sich Millisekunden im Punktestand niederschlagen.

Quiz ist als Format auf den ersten Blick simpel, in der Umsetzung aber überraschend fies: Die Spielerfahrung steht und fällt damit, dass alle Spielenden eine Frage zur exakt gleichen Zeit sehen, dass Antworten fair gewertet werden, und dass Timing-Unterschiede zwischen Netzwerkpfaden nicht über Sieg und Niederlage entscheiden. Hier zahlt sich der Realtime-Layer aus, der bei reMemed und remplir schon viel Arbeit geleistet hat – nur dass das Genauigkeitsbudget bei resolu deutlich kleiner ist.

Inhaltlich ist resolu modular gedacht: Quiz-Packs lassen sich frei kombinieren, von klassischem Wissen über Pop-Kultur bis hin zu sehr spezifischen Nischen. Das Spiel selbst ist der Rahmen; die Packs sind das, was eine Runde immer wieder neu macht.

Was unter der Oberfläche passiert

Mit drei Spielen wird sichtbar, was am Anfang nur eine Behauptung war: Die spannenden Probleme sind fast nie die offensichtlichen – es sind die Randfälle.

• Was passiert, wenn jemand in der Abstimmungsphase die Verbindung verliert?
• Wie sieht der State aus, wenn zwei Events fast gleichzeitig ankommen?
• Wie fühlt sich der Übergang zwischen zwei Runden an, ohne dass es holpert?
• Wie überlebt eine Lobby, wenn der Host kurz die Seite neu lädt?
• Wie verhält sich ein Quiz-Timer, wenn ein Spieler vorübergehend offline geht und wieder zurückkommt?

Geteilte Antworten auf diese Fragen sind genau das, was die played-Basis ausmacht: ein Realtime-Layer, ein Session-Modell, ein Umgang mit ephemerem Spiel-State – und ein klarer Schnitt, an welchen Stellen ein neues Spiel eigene Logik mitbringt und an welchen es einfach mitspielt.

Was ich damit lernen möchte

played ist bewusst als Lernraum angelegt. Die beiden Felder, in denen ich mich mit diesen Projekten weiterentwickeln möchte:

1. Echtzeit-Nutzererfahrungen – alles, was mit synchronisiertem State, WebSocket-basierter Kommunikation, optimistischen UI-Updates und sauberem Umgang mit Netzwerk-Realität zu tun hat.
2. Hochwertige Spielerfahrungen – die weniger offensichtliche Disziplin: Wie wird aus einer funktionierenden Mechanik ein Spiel, das man gerne startet, gerne zeigt und gerne noch einmal spielt?

Beides geht nur zusammen. Eine brillante technische Umsetzung ohne Spielgefühl ist ein Tech-Demo. Ein tolles Spielgefühl auf einer wackligen Basis hält keine zehn Runden durch.

Was als Nächstes kommt

Mit reMemed, remplir und resolu steht inzwischen eine kleine Familie aus drei sehr unterschiedlichen Mechaniken auf derselben Basis – Caption-Comedy, Wortwitz, Wissen unter Zeitdruck. Genau das war die ursprüngliche Wette: eine Infrastruktur bauen, die mehr als ein Spiel trägt.

Die nächsten Schritte gehen weniger in die Breite als in die Tiefe: bessere Lobbys, klarere Übergänge zwischen den Spielen auf played.click, kuratiertere Inhalte (vor allem bei resolu und remplir), und eine Reihe kleiner Verbesserungen am Spielgefühl, die einzeln unscheinbar wirken, in Summe aber genau das ausmachen, worum es bei played eigentlich geht.

Mehr dazu bald hier.