played

Multiplayer web games

Web
played logo

played — games that feel as good as they look

Under the played banner I build games with one thing in common: they should feel really good while you're actually playing them. No flaky lobbies, no perceived lag between moves, no moments where you're not sure if your click landed. Instead: direct feedback, fluid interactions, and a game experience that feels polished — no matter how simple the underlying mechanic is.

Why played?

played is the frame for an idea: that browser-based multiplayer games can be more than they usually are. Fast, social games you can start with friends in seconds — no installs, no launcher, no account marathon — that aim to set new standards in every single detail, instead of settling for "okay for the browser".

Three things matter to me at once: games that are fun. Games that look great. And games that actually feel, in the moment of play, the way they look — fluid, precise, without the small inconsistencies people too often take for granted in realtime multiplayer on the web.

The browser as a platform has long since matured enough for exactly this kind of game. What's usually missing isn't the tech, it's the willingness to use it properly — and the care to treat every detail, from joining a lobby to the animations to the transitions between rounds, with the same ambition as the game mechanic itself. That's exactly where I want played to come in.

The plaza: played.click

By now the first project has grown into several, and all of them live under one roof: played.click. The plaza is the central entry point — an overview of every game, a shared account, a shared profile and session layer. Once you're signed in, you can hop between games without re-authenticating or building a new identity.

That's not an end in itself — it's a deliberate technical decision: instead of building each game as an isolated island, every played game shares the same base — auth, lobbies, realtime layer, asset pipeline. New ideas come together faster because the invisible infrastructure doesn't need to be reinvented every time. And for players it means: signing in once is enough; the rest feels like different rooms in the same house.

reMemed — memes with captions

The first project under the played brand is reMemed — an alternative to the best-known meme-caption game. The idea is simple: you get a meme template, write the best caption you can, everyone votes, and the funniest answer wins the round.

What sets reMemed apart is less the core idea and more what happens around it:

  • Real realtime gameplay — states, timers and votes stay in sync across every player without perceivable delay.
  • Clean game logic — rounds, phases and transitions are clearly defined, so it's never unclear what you're waiting for.
  • A UI that feels light — even though a lot of state is moving in the background.

On the technical side that means: thought-through pub/sub structures for game events, ephemeral state that lives where it needs to be fast, and persistent data where it needs to be persistent.

remplir — fill in the blank

The second game is remplir, a party game in the fill-in-the-blank format. You get a sentence with one (or several) blanks that all players fill in simultaneously. After that — like in reMemed — everyone votes for the best answer.

Mechanically remplir is related to reMemed, but the feel is different: less visual, more linguistic. It thrives on pace, wordplay and a shared language register within the group. That's exactly why remplir is bilingual (German/English) by design — with a prompt catalog that works idiomatically in both languages, instead of being a flat translation. A prompt that's funny in German doesn't have to be the same sentence with different words in English. Sometimes it's a completely different joke.

The interesting question here was mainly how to use the same realtime base for a game that looks completely different from reMemed at first glance. The answer: phases, transitions and state synchronisation can be reused for the most part. What changes are the contents and the input UI — not the core underneath. That's exactly what the shared played infrastructure is there for.

resolu — quiz with pace

The third project is resolu, a realtime quiz game. Questions appear simultaneously for every player, and the fast-and-correct answer wins — including the knife-edge moments where milliseconds shift the scoreboard.

Quiz looks simple as a format at first glance, but it's surprisingly sneaky to implement: the experience stands and falls on every player seeing a question at exactly the same time, on answers being scored fairly, and on timing differences between network paths not deciding who wins. That's where the realtime layer pays off — the one that already did a lot of work for reMemed and remplir — except resolu's accuracy budget is much smaller.

On the content side, resolu is modular by design: quiz packs can be combined freely, from classic general knowledge to pop culture all the way to very specific niches. The game itself is the frame; the packs are what makes every round feel new.

What happens under the hood

With three games out, something becomes visible that was only a claim at the start: the interesting problems are almost never the obvious ones — they're the edge cases.

  • What happens if someone drops their connection during the voting phase?
  • What does the state look like when two events arrive almost simultaneously?
  • How does a transition between rounds feel — without any bumpiness?
  • How does a lobby survive if the host reloads the page for a moment?
  • How does a quiz timer behave when a player goes briefly offline and comes back?

Shared answers to these questions are precisely what makes up the played base: one realtime layer, one session model, one approach to ephemeral game state — and a clear cut showing where a new game brings its own logic and where it just plays along.

What I want to learn from this

played is intentionally set up as a learning space. The two areas I want to grow in through these projects:

  1. Realtime user experiences — everything to do with synchronised state, WebSocket-based communication, optimistic UI updates and clean handling of network realities.
  2. High-quality game experiences — the less obvious discipline: how do you turn a working mechanic into a game you actually want to start, show off, and play one more round of?

Both only work together. A brilliant technical implementation without game feel is a tech demo. A great game feel on a shaky foundation doesn't last ten rounds.

What's next

With reMemed, remplir and resolu there's now a small family of three very different mechanics on the same base — caption comedy, wordplay, knowledge under time pressure. That was the original bet: build one piece of infrastructure that supports more than one game.

The next steps go less wide and more deep: better lobbies, clearer transitions between games on played.click, more curated content (especially in resolu and remplir), and a series of small game-feel improvements that look inconsequential one by one but together make up exactly what played is really about.

More on that here soon.