DEV Community: Rory

How I Built a Spinning Schulte Table Game

Rory — Thu, 12 Nov 2026 10:41:46 +0000

Every developer has that moment: you're scrolling through X at 11 PM and see someone post a tiny game they made over the weekend. "I could do that," you think. But then Sunday comes and goes, and you never start.

I decided to stop just thinking about it. Over one weekend, I built Spinning Schulte Table — a brain-training focus game that runs entirely in the browser. No React, no Three.js, no complex build pipeline. Just HTML, CSS, and vanilla JavaScript.

Here's how I did it.

What is a Schulte Table?
If you've never heard of it, the Schulte table is a classic focus and attention exercise. You get a grid of scattered numbers, and your goal is to tap them in order: 1, 2, 3, … all the way to the final number. A timer tracks how fast you finish.

It is widely used for focus training, and even pilots use it to improve peripheral vision and sustained attention.

My twist: the whole table slowly rotates while you play. Now your eyes have to track numbers on a spinning board, which adds a fun extra challenge.

The core idea
The game has three core pieces:
Generate a grid — randomize numbers and place them on screen
Rotate the container — run a smooth CSS animation to spin the whole board
Track taps — check whether the player clicks numbers in the correct order

Let me break each part down.

Generating the number grid
The simplest approach: create an array of sequential numbers, shuffle it, then render each number as an interactive tile.

function shuffle(array) {
for (let i = array.length - 1; i > 0; i--) {
const j = Math.floor(Math.random() * (i + 1));
[array[i], array[j]] = [array[j], array[i]];
}
return array;
}

function generateNumbers(size) {
const total = size * size;
const numbers = Array.from({ length: total }, (_, i) => i + 1);
return shuffle(numbers);
}

For positioning, I use absolute positioning inside a square container. Every number tile gets a random position inside the grid boundary, plus a small individual rotation:

function positionNumber(index, total, containerSize) {
const angle = (index / total) * Math.PI * 2;
const radius = containerSize / 2 * 0.8;
const x = containerSize / 2 + Math.cos(angle) * radius;
const y = containerSize / 2 + Math.sin(angle) * radius;
return { x, y };
}

This creates a spiral-like layout instead of a rigid grid, which makes it visually interesting and harder to track numbers.

The rotation trick
This part was simpler than I expected. I wrapped all number tiles inside one parent container and applied a continuous CSS rotation animation:

.game-board { position: relative; width: 500px; height: 500px; animation: rotate 60s linear infinite; } @keyframes rotate { from { transform: rotate(0deg); } to { transform: rotate(360deg); } }

That’s it. One CSS keyframe animation spins the whole board slowly. Players have to find and tap numbers while everything keeps turning.

Tracking taps
Each tile listens for click events. When a player taps, we check if this number is the next one in sequence.

let nextNumber = 1; let mistakes = 0; function handleNumberClick(value) { if (value === nextNumber) { value.classList.add('correct'); nextNumber++; if (nextNumber > gridTotal) { finishGame(); } } else { mistakes++; value.classList.add('mistake'); setTimeout(() => value.classList.remove('mistake'), 800); } }

The timer starts on the first click and stops once you finish all numbers.

What I learned
Vanilla JavaScript is enough for small browser games. You don’t always need heavy game engines or frameworks. The hardest part was balancing the rotation speed — fast enough to feel challenging, slow enough that players can still read the numbers.

CSS animations are surprisingly powerful. A single rotation animation creates almost all of the unique feeling of this game.

It’s easy to overbuild. I skipped multiplayer, save systems, and fancy visual effects. I shipped one core mechanic and polished it until it was fun.

Try it
The game is live, free to play directly in your browser:
👉 Spinning Schulte Table

No download or sign-up required. Open it, tap numbers in order to finish while the board spins. Let me know your best time!

Note: this demo is hosted locally on my PC, so please be patient if there is a connection hiccup.

What's next
The game already has adjustable difficulty levels (3×3 up to 10×10) and a leaderboard.
I'm planning to add:
Daily challenges

If you've built a tiny browser game with vanilla JS, I'd love to hear about it. Feel free to share!

I built a 3D survival game in a weekend and shipped it from my own PC

Rory — Thu, 05 Nov 2026 12:07:31 +0000

I wanted to see how far a weekend build could go, so I made a 3D survival game — dodge incoming fire, and don’t get sandwiched by enemies.

The whole thing runs on a bare Node HTTP server on my local machine and is exposed via a tunnel. No frameworks, no build steps, just plain ES modules.

The most fun part was balancing the difficulty. I set a fixed enemy spawn curve at first, but kept dying right around the 2-minute mark. That threshold is when ranged enemies start spawning and damage scaling begins compounding. Once I pushed back when shooters unlock, the curve felt fair instead of cheap.

My personal best is 4:39. A solid run should last roughly 10–14 minutes. How long can you survive?

Play it here:

Feel free to ask me anything about the difficulty tuning or this local hosting + tunnel setup.

The tunnel takes 30 seconds. The permissions take a weekend.

Rory — Thu, 29 Oct 2026 12:52:12 +0000

Most write-ups about exposing an MCP server stop at the step where you get a public URL. That's the easy half.

The half that actually costs you time is deciding who's allowed to call it — and being able to cut them off without a redeploy.

If you run an MCP server on your laptop, you've probably noticed it works in Claude Desktop and nowhere else.stdio transport means the client spawns the process locally. That's fine for one person on one machine, and it stops working the moment a teammate's Agent needs to call your tool, or your phone needs to reach something running on your desk.

This post walks through five options, what each one actually costs you, and when to pick something else instead. There isn't a single right answer, and the last section covers the cases where none of this applies.

What "reachable" actually requires

Before comparing tools, it's worth naming the four things you need:

A stable address — something that doesn't change every time you reconnect
Transport —stdio won't work across machines, so you need HTTP or SSE
Authentication — whoever connects needs to prove they're allowed
Revocation — the ability to cut someone off without restarting anything Most tools solve 1 and 2 and leave you to hand-roll 3 and 4. That's where the real work is.

Option 1: ngrok (and similar tunnels)

The default answer. One command and you have a public HTTPS URL.

ngrok http 3000

What you get: transport and a stable dev domain, in about three seconds.

What you don't get:

One address for everything. Free gives you a single auto-assigned dev domain, and it's the same domain for every service you expose. If you want a separate hostname per service, that's a paid tier.
Auth is per-endpoint, not per-caller. OAuth and traffic policy work on free (up to 5 MAUs), but the identity is a human account. Two Agents behind the same login look identical, and there's no per-call usage attached to either.
Revocation is all-or-nothing. You can kill the tunnel, which cuts everyone off at once. You also need ngrok installed on every machine running a server, and its config is a separate thing to maintain.

For a quick demo this is unbeatable. For anything with more than one caller, it gets thin fast.

Option 2: Cloudflare Tunnel

Better on the address problem — you get a stable hostname on a domain you control.

cloudflared tunnel create my-mcp
cloudflared tunnel route dns my-mcp mcp.example.com

What you get: stable address, transport, and Cloudflare's auth layer if you wire up Access.

What it costs: a domain, DNS management, and a Cloudflare account. Cloudflare Access can give you per-user auth, but you're now configuring policies in a dashboard that's designed for corporate SSO, not for "let this one Agent call this one tool."

It's a solid choice if you already run Cloudflare. If you don't, you're adopting a whole platform to solve one problem.

Option 3: Just open a port

Don't. Even with a firewall rule scoped to an IP, you've now got a long-lived inbound listener on a machine that also holds your source code, your SSH keys, and probably an unpatched dependency or two.

This is the option people fall back to when the others feel heavy, and it's the one that shows up in incident reports.

Option 4: Deploy it to a VPS

Move the server off your laptop entirely. Now it's always on, has a real IP, and you can put nginx in front of it.

The catch is that half the reason the server was local is that it talks to local things — a Postgres instance, files on disk, a GPU you paid for. Moving it to a VPS means moving or tunneling those too, and now you're paying monthly for a machine that idles 90% of the time.

Option 5: Outbound-only connection with a stable subdomain

This is the model I ended up using, via a service called UUMit. I'll describe the mechanism rather than the product, because the mechanism is the interesting part.

The server on your machine opens an outbound connection to a relay. Nothing listens on your machine. Your address is assigned at signup —yourname.uumit.ai — and stays attached to you even if you move to a different computer.

Inbound requests arrive through the relay and are pushed down the existing outbound connection. From your firewall's perspective, this is indistinguishable from a browser tab talking to a web server.

The parts that matter beyond transport:

Identity is signed. Each machine gets a keypair, and the public card is signed by the platform. A caller can verify that the address they're hitting actually belongs to you, rather than to someone who squatted the subdomain.

Permissions are per-caller, not per-network. Four levels — off, only me, invite only, everyone — set per exposed service. Opening one thing doesn't open the others.

Revocation is a state change, not a restart. You flip it, the next request is rejected. No tunnel to kill, no process to bounce.

Calls can be metered. If you want to charge per call, there's a counter and a settlement path instead of you building a billing table.

Setting it up is one prompt into your Agent, or one command:

Install UUMit and claim the address xiaolong

Then you point it at the services already running locally. The desktop client supports macOS, Windows 10/11, Linux, and Docker.

When none of this applies

Three cases where I'd tell you not to bother:

Your machine isn't always on. A relay can't reach a laptop that's asleep. If your server needs to be up 24/7, put it somewhere that is.

You need sub-100ms latency. Every hop through a relay adds some. For Agent tool calls this has never mattered to me, but for a real-time game backend it would.

You're serving thousands of callers. At that point you want a proper load balancer and a real ops setup, not a personal address.

There's also the honest limitation that this is a young product. If you need an SLA and a support contract, use Cloudflare.

What I'd actually recommend

Your situation Use Demo, one-off, nobody else needs it ngrok Already on Cloudflare, want per-user SSO Cloudflare Tunnel Server is stateful and tied to local resources Outbound relay with a stable address Needs 24/7 uptime and an SLA Deploy to a VPS

The thing I'd push back on is treating "reachable" as the whole problem. Transport is the easy half. Deciding who's allowed in, and being able to take it back without a redeploy, is the half that costs you a weekend if you build it yourself.

Giving a local MCP server a public address (without ngrok or a firewall change)

Rory — Thu, 29 Oct 2026 12:27:55 +0000

If you run an MCP server on your laptop, you've probably noticed the same thing I did: it works great in Claude Desktop, and nowhere else.

stdio transport means the client has to spawn the process locally. That's fine for one person on one machine. It stops working the moment you want your teammate's Agent to call your tool, or your phone to reach something running on your desk.

This post walks through the options I tested, what each one actually costs you, and the one that fit my setup. I'm not going to pretend there's a single right answer — there isn't, and the last section covers when you should pick something else.

What "reachable" actually requires

Before comparing tools, it's worth naming the four things you need:

A stable address — something that doesn't change every time you reconnect
Transport — stdio won't work across machines, so you need HTTP or SSE
Authentication — whoever connects needs to prove they're allowed
Revocation — the ability to cut someone off without restarting anything

Most tools solve 1 and 2 and leave you to hand-roll 3 and 4. That's where the real work is.

Option 1: ngrok (and similar tunnels)

The default answer. One command and you have a public HTTPS URL.

ngrok http 3000

What you get: transport and a temporary address, in about three seconds.

What you don't get:

A stable address. Free-tier URLs change on every restart. Every caller has to be re-told the new one.
Per-caller auth. There's one URL. If two people have it, they have the same access.
Granular revocation. You can kill the tunnel, which cuts everyone off.

You also need ngrok installed on every machine running a server, and its config is a separate thing to maintain.

For a quick demo this is unbeatable. For anything with more than one caller, it gets thin fast.

Option 2: Cloudflare Tunnel

Better on the address problem — you get a stable hostname on a domain you control.

cloudflared tunnel create my-mcp
cloudflared tunnel route dns my-mcp mcp.example.com

What you get: stable address, transport, and Cloudflare's auth layer if you wire up Access.

It's a solid choice if you already run Cloudflare. If you don't, you're adopting a whole platform to solve one problem.

Option 3: Just open a port

This is the option people fall back to when the others feel heavy, and it's the one that shows up in incident reports.

Option 4: Deploy it to a VPS

Move the server off your laptop entirely. Now it's always on, has a real IP, and you can put nginx in front of it.

Option 5: Outbound-only connection with a stable subdomain

This is the model I ended up using, via a service called UUMit. I'll describe the mechanism rather than the product, because the mechanism is the interesting part.

The server on your machine opens an outbound connection to a relay. Nothing listens on your machine. Your address is assigned at signup — yourname.uumit.ai — and stays attached to you even if you move to a different computer.

Inbound requests arrive through the relay and are pushed down the existing outbound connection. From your firewall's perspective, this is indistinguishable from a browser tab talking to a web server.

The parts that matter beyond transport:

Identity is signed. Each machine gets a keypair, and the public card is signed by the platform. A caller can verify that the address they're hitting actually belongs to you, rather than to someone who squatted the subdomain.

Permissions are per-caller, not per-network. Four levels — off, only me, invite only, everyone — set per exposed service. Opening one thing doesn't open the others.

Revocation is a state change, not a restart. You flip it, the next request is rejected. No tunnel to kill, no process to bounce.

Calls can be metered. If you want to charge per call, there's a counter and a settlement path instead of you building a billing table.

Setting it up is one prompt into your Agent, or one command:

Install UUMit and claim the address xiaolong

Then you point it at the services already running locally. The desktop client supports macOS, Windows 10/11, Linux, and Docker.

When none of this applies

Three cases where I'd tell you not to bother:

Your machine isn't always on. A relay can't reach a laptop that's asleep. If your server needs to be up 24/7, put it somewhere that is.

You need sub-100ms latency. Every hop through a relay adds some. For Agent tool calls this has never mattered to me, but for a real-time game backend it would.

You're serving thousands of callers. At that point you want a proper load balancer and a real ops setup, not a personal address.

There's also the honest limitation that this is a young product. If you need an SLA and a support contract, use Cloudflare.

What I'd actually recommend

Your situation	Use
Demo, one-off, nobody else needs it	ngrok
Already on Cloudflare, want per-user SSO	Cloudflare Tunnel
Server is stateful and tied to local resources	Outbound relay with a stable address
Needs 24/7 uptime and an SLA	Deploy to a VPS

Testing Lingjing vs Runway vs Pika for my daily workflow

Rory — Mon, 26 Oct 2026 12:08:08 +0000

I’ve tested these three AI video tools for content creation.

Pika: Fast & easy for social clips, perfect for quick concepts, weak on long scenes.

Runway: Great pro editing tools like motion brush & inpainting, but bloated for simple generates.

Lingjing surprised me: all-modal node canvas, multi-model in one place, great for chaining full projects without tab-switching.

Core tradeoffs: linear editing vs node pipelines, single flagship model vs multi-model flexibility, niche depth vs end-to-end breadth. Still testing long-form consistency. Which do you prefer for creator work?

I found an interesting shift: from C2C physical trading to A2A AI capability trading*

Rory — Sat, 24 Oct 2026 11:33:03 +0000

Hi folks,

I’ve been thinking a lot about marketplaces built for AI agents lately.

We’re all familiar with C2C secondhand platforms like Mercari, Vinted, and Carousell. These platforms are designed for humans trading physical goods. Their whole workflow revolves around human buyers and sellers: inventory tracking, shipping logistics, and mostly one-off transactions.

AI agents operate by a completely different set of rules, though.

What if agents themselves could discover, purchase, and invoke reusable skills automatically?
We’re talking about MCP tools, parsers, workflow modules, dispatch logic — building blocks an agent can call on demand.
Instead of a one-time purchase, creators get paid per API invocation.

I also ran across the idea of AEO, Agent Engine Optimization.
Where SEO optimizes content to be found by human searchers, AEO focuses on machine-readable metadata. It lets agents automatically match incoming tasks to available capabilities.

This feels like an entirely new marketplace paradigm, separate from the physical, human-first trading model we’re used to.

I’d love to get your take on these two questions:

Do you think autonomous agents will routinely trade skills with one another in the future?
What do you see as the biggest practical roadblock for functional A2A marketplaces?