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 weniger ein Studio und mehr ein bewusst gesetzter Rahmen. Ein Ort, an dem ich Spiele bauen kann, die zwei Dinge miteinander verbinden, die selten zusammen auftauchen: technisch anspruchsvolle Echtzeit-Infrastruktur und ein Spielerlebnis, das man tatsächlich mehr als einmal starten möchte.
Viele kleine Multiplayer-Spiele scheitern nicht am Konzept, sondern an der Ausführung. Latenz, Race Conditions, hakelige Reconnects, unklare Spielzustände – all das sind Probleme, die man als Nutzer nicht benennen kann, aber sofort spürt. Genau dort setzt played an: Die Infrastruktur ist nicht das, was man sieht, aber das, was entscheidet, ob ein Spiel sich "richtig" anfühlt.
Das erste Projekt: reMemed
Das aktuelle 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. Die spannenden Probleme sind dabei 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?
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:
- Echtzeit-Nutzererfahrungen – alles, was mit synchronisiertem State, WebSocket-basierter Kommunikation, optimistischen UI-Updates und sauberem Umgang mit Netzwerk-Realität zu tun hat.
- 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
reMemed ist der erste Schritt, nicht das Ziel. Die Infrastruktur, die dahinter entsteht – von Game-Event-Systemen über Session-Management bis hin zum Umgang mit ephemerem Spiel-State – soll die Basis für weitere Spiele unter played werden. Kleine, fokussierte Multiplayer-Erlebnisse, die sich angenehm anfühlen, schnell gespielt sind und den technischen Anspruch unter einer leichten Oberfläche tragen.
Mehr dazu bald hier.