DEV Community: Steve Aragón

Discord Game Architecture!

Steve Aragón — Wed, 14 Oct 2026 01:39:44 +0000

I was working on a new integration with Discord. However, I didn't understand how to implement a multiplayer system with Godot as the client and a Node server because, as far as I knew, you had to pay for a server on AWS or switch engines (Colyseus or Photon). Then I used Claude Code and Cloudflare to build a multiplayer server with Workers and Pages. Everything about this service was new to me, and it was incredible: it solved all my problems with serving my app to users on Discord.

I tried a new architecture with Cloudflare: a single Worker serves both the game bundles and the server, with everything ready for rooms, players, settings, and so on.

The new architecture was overwhelming, but it let me build a new feature: persistent user progress. Then I combined it with Supabase to add SSO and a database for user badges and more.

The game is called Se Pudrió Todo: a party card game set in Argentina. Every round, one player is the judge, everyone else plays their funniest answer, and the table can throw red and yellow cards like in a football match. It runs as a Discord Activity, so you play it inside a voice call with your friends, and it also works in any browser.

The architecture

https://diagrams.stevearagonsite.com/se-pudrio-todo/infra.html

The whole idea fits in five lines:

The Godot client is only a view. It sends commands ("play this card", "vote") and draws whatever state the server sends back. No rules live in the client.
One Worker serves everything: the game files, the API and the WebSocket. One deploy, one address.
One Durable Object per room is the authoritative server. The rules engine is pure TypeScript (state + command → new state), the room keeps its own SQLite, and alarms handle the timers.
Each player gets a filtered snapshot. A card game has hidden information, so the server decides what each player can see: nobody gets another player's hand.
Inside Discord, everything goes through the discordsays.com proxy, and WebSocket is the only real-time option. That one rule shaped the whole design.

Why not a regular game server

Colyseus, Photon or a Node server on AWS all mean a machine running 24/7 that I have to pay for and maintain. A Durable Object is already a room: it's isolated, it keeps its state, and it hibernates when nobody is playing. I didn't have to switch engines or rent a server. I just had to stop thinking of "the server" as one big process.

Fitting Godot into a Worker

The Godot web export was bigger than the file size limit for Worker static assets. The fix was simple: I upload the build only compressed (Brotli and gzip), name each file by its hash, and the Worker sends the version the browser accepts with a one-year cache. A deploy that only changes GDScript only changes the game pack, so players don't download the engine again.

Accounts with Supabase

Accounts are optional: you never need one to play. When you sign in (Google or Discord), the Worker only notes which account the game belongs to. The client never touches the database: only the Worker talks to Supabase, with a secret key, through database functions. When a game ends, the room sends the result, and Supabase stores your progress, badges and favorite cards. I designed the schema for several games from day one, because this won't be my last one.

How it came together, day by day

I looked at the git history to see the order in which each tool came in. It all happened in one week, and during the first three days I also played about five games with friends:

Day 1: the Godot project automated from the terminal, the game rules, research on Discord Activities and the architecture decision. Then the rules engine on a Durable Object, the Worker serving the web build, the Discord Activity with a tunnel for local testing, and the first deploy. By the end of the day, people could also play in the browser as signed guests, and the game was on itch.io. That night, the first game with friends.
Day 2: fixes from my friends' feedback (more below), Discord on phones (real screen sizes, safe areas and the tiny picture-in-picture view), and the deck moved to a Google Sheet.
Day 3: Jev scored every card pair, and I trimmed the deck to the best ones. Then bots that live in the room, invitation previews and rematches. Discord avatars, Rich Presence and invites. And Supabase: accounts, badges, a profile and sign-in with Google or Discord.
Day 4: security (rate limits, Turnstile, a Content Security Policy), rooms that survive a deploy, automatic reconnection, faster loading with a service worker, and a landing page.
Day 5: infrastructure as code with Terraform, public rooms, an all-ages Discord app for the App Directory, and error tracking.
Day 6: the whole game in English.

Five games with friends

Before polishing anything, I wanted to know if the idea was fun. During the first three days, I played about five games with friends, and every game ended with their opinions. Each comment went straight into the backlog, and most were fixed before the next game:

The play button was far from the table, in the bottom-left corner. Now it shows up in the middle, where your eyes already are.
The judge wanted to flip any face-down answer, not always in order.
The shuffle "felt bad": cards you had just thrown away came back right away. Now the deck avoids repeats.
The cards needed more motion: dealing, flipping and picking.
Some friends wanted to play with the keyboard only.
With three players, voting on a red card made no sense, so the red card started removing the answer directly.

Real people found things that no automated test would catch.

Balancing the deck: a Google Sheet and Jev

A card game lives or dies by its cards, so I needed a way to edit hundreds of them without touching JSON. All the cards live in a Google Sheet, and a script syncs it with the game in both directions, so the sheet is always the source of truth. Each card has a theme and an "In the game" checkbox, and a Balance tab compares the deck with its targets: 35% Argentina, 25% vices and partying, 20% dark humor and 20% adult jokes.

To score the cards, I used Jev, TypeSafe's System One model, through OpenRouter. Jev crosses every black card with every white card and rates each pair on four axes: does it make sense, is it funny, does it feel Argentine, and is it witty? Each card gets the average of its pairs, and the final score (MIX) counts wit and Argentine flavor twice. Then a script keeps the best cards of each theme in the game.

The last word is still mine: when I mark a card as "Updated", no script changes its score or whether it's in the game.

The lesson

The hard part wasn't the code. It was deciding where the rules live. Once that was clear (the server is the truth and the client is a view), and once I wrote it down as an architecture decision, vibe coding with Claude Code moved fast, because every new feature had an obvious place to go. And play it with real people as soon as you can: five games with friends taught me more than any test.

So if you think multiplayer means paying for a server or switching engines, look at edge platforms first. A Durable Object per room was all my game needed.

Play it: https://se-pudrio-todo.stevearagonsite.com/en

Join the Discord server: https://discord.gg/UudNQzBAkw

Experience Working with OpenClaw (Clawbot)

Steve Aragón — Wed, 18 Mar 2026 18:58:24 +0000

Experience Working with OpenClaw (Clawbot)

I want to share my experience as a developer working with OpenClaw (Clawbot), including a real-world setup and some practical insights after using it in production-like scenarios.

My setup is based on:

AMD Ryzen 5 5600X
32GB RAM
RTX 3060 (LHR)
NVMe SSD storage
Ubuntu Server (headless environment)

I also experimented with multiple Ollama local models as part of a fallback strategy, along with cloud models like Kimi 2.5.

From a configuration standpoint, OpenClaw is a powerful and flexible system — but that flexibility comes at a cost.

Real Setup (Explained)

Instead of showing raw configuration, here’s how my setup is structured conceptually:

Primary model: Claude Opus 4.6
Cloud alternative: Kimi 2.5
Fallback #1: Local models via Ollama (GPU)
Fallback #2: OpenAI models
Interface: Telegram
Remote access: Tailscale as a service

Flow:

Primary cloud model → Alternative cloud → Local fallback → Secondary cloud fallback

This setup aims to balance:

Performance
Reliability
Offline capability

Infrastructure & Tooling

Ubuntu Server

I chose Ubuntu Server to fully utilize the machine:

Lower overhead (no GUI)
Better resource allocation for models
More predictable performance for long-running processes

Tailscale (as a service)

I used Tailscale running as a background service to access the machine remotely.

The experience was excellent:

Fast and stable connections
Zero-config networking
Secure remote access without exposing ports

This made it extremely easy to:

Manage OpenClaw remotely
Debug issues
Interact with the system from anywhere

Claude Code for Setup

I used Claude Code to bootstrap and configure the environment.

This significantly reduced setup friction:

Faster iteration
Easier debugging
Better guidance wiring models and fallbacks

Local Models Tested (Ollama)

I tested several local models using Ollama:

Gemma 3 (12B)
Qwen 3 (14B, abliterated)
Qwen 3.5 (9B)

Model Performance Ranking

🧠 Overall Ranking (Reasoning + Speed)

Kimi 2.5 (cloud) → Best overall performance
Gemma 3 (local)
Qwen 3 (local)
Qwen 3.5 (local)

☁️ Provider Ranking

Anthropic (Claude models) → Most reliable reasoning
OpenAI models → Strong and consistent
Ollama (local models) → Significantly weaker

My Experience with Local Models

Using Ollama with local models is a great idea in theory.

Pros:

Works without internet
Fully local
Good fallback strategy

Reality:

Even running on an RTX 3060 and testing multiple models:

Local models were, in practice, a major downgrade.

It almost feels like the system gets “lobotomized” when switching to them:

Weak reasoning
Poor context handling
Inconsistent outputs

This becomes very clear when compared to:

Claude (Anthropic)
OpenAI models
Kimi 2.5 (which performed surprisingly well)

Key Challenges

1. Opacity in the TUI

The TUI feels like a black box.

You don’t know:

Which model is active
When fallbacks trigger
Why decisions are made

This makes debugging painful.

2. Lack of Cross-Channel Consistency

Telegram ≠ TUI
No shared continuity
Fragmented sessions

3. Configuration Complexity

You must carefully align:

Models
Providers
Fallbacks
Channels

Otherwise:

Silent failures
Weird behaviors
Hard-to-debug issues

Final Thoughts

OpenClaw has a strong architectural foundation:

Multi-model orchestration
Fallback strategies
Multi-channel interaction

But it needs improvements in:

Transparency (TUI)
Cross-channel consistency
Developer experience
Local model performance

Conclusion

Combining:

Ubuntu Server
Tailscale
Cloud + local models

creates a very powerful personal AI infrastructure.

However:

Today, cloud models still massively outperform local ones, even on decent hardware like an RTX 3060.

The idea is solid.

The execution is promising.

But the ecosystem — especially around local models — still has a long way to go.