DEV Community: hinezi

I built a collaborative pixel art game in a bottle — with 0 npm dependencies

hinezi — Fri, 06 Nov 2026 05:54:14 +0000

🌊 What is Dear Stranger?

I recently launched Dear Stranger (dearst.app) — a cozy, anonymous, collaborative pixel art web game.

The concept is inspired by the old tradition of casting a message in a bottle into the ocean:

Cast a bottle: You start by drawing a few pixel strokes on a small canvas (or choose from 8 classic masterpieces like Van Gogh's Starry Night or Monet).
Drift across the sea: Your bottle travels across the world to strangers.
Collaborate: 2 to 4 strangers take turns painting their fair share.
Returns home: Once complete, the bottle journeys back to everyone who participated, complete with a celebratory replay of each painter's strokes and a travel map showing the countries it sailed through!

Play it directly in your browser (no sign-up required):
👉 https://dearst.app

🛠️ The Tech Stack: Exactly 0 npm dependencies

As web developers in 2026, our node_modules folders often weigh hundreds of megabytes just to render a button. For Dear Stranger, I set a personal challenge:

Can we build a full-featured, persistent, real-time multiplayer collaborative web app with ZERO external npm dependencies?

The answer is yes.

1. Pure Vanilla JS on the Frontend

Zero build tools: No Webpack, Vite, or Babel. Browsers have supported native ES modules for years.
HTML5 Canvas & SVG: Custom pixel manipulation, touch-enabled zooming/panning, and color palette sampling.
Dynamic Voyage Map: Natural Earth 1:50m geographic landmass rasterized into an ultra-compact dot grid rendered with pure SVG paths and beacons.

2. Node.js Built-in Standard Library on the Backend

Built on Node's native HTTP server and node:crypto.
Pure Web Push: RFC 8291 payload encryption and RFC 8292 VAPID signatures implemented purely with node:crypto — no web-push npm package required.
SQLite with WAL mode: Fast, zero-config persistent storage with foreign keys and immediate transactions.

3. Internationalization (i18n) from Day One

The game natively supports 5 languages:

🇰🇷 Korean
🇺🇸 English
🇫🇷 French
🇯🇵 Japanese
🇨🇳 Chinese

Even the system NPC (Lighthouse · Keeper) and world country labels dynamically localize using the native Intl.DisplayNames API!

🎨 Game Design: Solving the "Trolling & Slacking" Problem

Collaborative art on the internet is notorious for two problems: trolls overwriting others' work and slackers drawing 1 pixel and dumping the rest on the next person.

Here is how Dear Stranger solves it through game mechanics:

The 75% Fair Share Quota: Each painter receives an equal allocation of the remaining blank cells. You must fill at least 75% of your quota before the game lets you send the bottle onward.
No Overwriting: Pixels already laid down by earlier strangers are immutable and locked.
Report & Restoration (Kintsugi for pixels): If someone draws something offensive, any player can report that layer. The offender's layer is immediately hidden, and a blank space is created so another stranger can step in to restore the painting!

🖼️ What's next?

We launched with 8 classic museum masterpieces in both guided tracing mode and 64-pixel challenge mode. We plan to continuously add more classical artworks and community features.

Feel free to pick up a bottle, paint a few pixels, and see where your art travels:

🌊 Play the game: https://dearst.app

I’d love to hear your thoughts, feedback, and questions in the comments below!

Building a K-pop ticketing game — and fixing a one-point scoring bug

hinezi — Tue, 03 Nov 2026 03:02:02 +0000

I built TicketKST, a browser game that recreates the pressure of booking K-pop concert tickets.

Players wait for the sale to open, click into a queue, type a captcha, and then have 30 seconds to select seats. Requests include adjacent seats, aisle seats, and seats within a budget. Other simulated fans keep buying seats while you choose.

The game uses a fictional venue and does not book real tickets.

You can try it here: https://ticketkst.com

The frontend is vanilla JavaScript, HTML, and CSS. The backend uses Flask and SQLite.

One surprisingly small implementation detail caused the score shown in the browser to disagree with the leaderboard.

JavaScript and Python don't always round the same way

Each completed seat request earns points based on seat quality and a combo multiplier.

Consider a request worth 645 base points with a 2.5× multiplier:

Math.round(645 * 2.5)
// 1613

The original Python calculation used:

round(645 * 2.5)
# 1612

Python's built-in round() uses ties-to-even rounding, while JavaScript's Math.round() resolves this positive halfway value upward.

Both calculations looked reasonable on their own. Together, they produced a one-point discrepancy.

For the game's nonnegative point values, the server now uses:

import math

def round_points(value):
    return math.floor(value + 0.5)

The result screen also uses the server's saved score once the response arrives.

Recalculating a score isn't enough

Another issue was what the server trusted.

Recalculating a total from client-reported success counts and seat-quality values still lets the client invent those inputs.

The updated version sends seat actions and their timestamps instead. The server reconstructs the daily hall and checks:

Whether the selected seats were available
Whether they matched the current request
Whether adjacent seats were actually together
How scheduled sell-outs affected availability
What score and combo followed from those actions

This validates the game state. It does not prove that a human made every move or eliminate automated play.

Testing both implementations together

The daily challenge gives everyone the same initial hall and requests for the same Korean date.

That makes consistency between the JavaScript simulation and Python replay important.

An offline test harness runs the actual JavaScript controller with a lightweight DOM and clock test double. It generates action transcripts, which are then replayed by Python.

Across 45 test rounds, the checks compare the initial hall, request sequence, outcomes, score, seat count, and best combo. The scenarios include delayed frames and the game's three surprise events.

These tests helped check the boundary between the two implementations, rather than testing each scoring function in isolation.

I'd be interested to hear how other developers handle this: do you replay browser-game actions on the server, share simulation code between environments, or make the server authoritative for every move?

Disclosure: AI tools assisted with implementation and drafting this article.

I built a daily puzzle from Wikipedia's pageview data (and rebuilt it when the results took too long)

hinezi — Sun, 01 Nov 2026 10:17:00 +0000

Every day, millions of people read English Wikipedia, and Wikimedia publishes how many times each article was viewed. I turned that into a small daily game called Fomorrow: five quick questions about what the internet read yesterday.

Which of these four articles had the most readers yesterday?
Which one rose the most against its own 7-day average?
How many people read "Halloween" yesterday?

You answer, and the real numbers show up right away. A round takes about two minutes. There's also one daily "call": a prediction about how an article does today, revealed with the next day's puzzle.

This post covers how it works, the mistake that forced me to rebuild the whole game, and a few things I learned about generating fair questions from real data.

The data

Everything comes from the Wikimedia Analytics API. Two endpoints do almost all the work.

Daily views for one article:

https://wikimedia.org/api/rest_v1/metrics/pageviews/per-article/en.wikipedia.org/all-access/user/Halloween/daily/20261024/20261031

The most-read articles for a day:

https://wikimedia.org/api/rest_v1/metrics/pageviews/top/en.wikipedia.org/all-access/2026/10/31

The user agent filter leaves out automated traffic, so the counts are (mostly) real readers.

The detail that ended up shaping the whole game is timing. A day's per-article numbers appear a few hours after that UTC day ends. When I checked, Oct 31 was available at about 05:05 UTC on Nov 1. The top list shows up later than the per-article data. There is no hourly per-article endpoint in the REST API. Hourly data exists only as raw dump files of about 40 MB per hour, published roughly three hours late.

Version 1: predict tomorrow (and wait)

The first version was a forecasting game. Every day you got three questions about tomorrow's pageviews: which topic will rise the most, which of two will get more readers, will this article beat its average.

It worked technically, but it had a fatal flaw: you waited 1.5 to 2 days for every result. A pick made on day D could only be scored after day D+1 ended and Wikimedia published it. First-time visitors saw no result at all. People forgot what they had picked. The share button could only say "my picks are locked in", which nobody wants to click.

I tried to fix it inside the forecasting model:

Predict today, close picks at 12:00 UTC. Results the next morning, but half the world would find the game closed.
Use hourly data for a 6-hour window. No hourly per-article API, so it means parsing 40 MB dumps every hour, and you still wait most of a day.
A personal 6-hour window from each pick. Fast results, but every player gets a different answer to the same question, which breaks the "same puzzle for everyone" feel that daily games depend on.

Then I looked at what the daily games people actually play have in common: an instant result, one shared puzzle per day, a spoiler-free share grid, and a streak. My game had none of the first one.

Version 2: yesterday's puzzle, today's call

So I flipped it.

The main game is about yesterday. The data is already published, so every answer is instant. A new puzzle opens at 06:00 UTC, after Wikimedia publishes the previous day, and stays the same for everyone for 24 hours.
The prediction survives as one daily "call" about today. It is always open, closes at midnight UTC, and its answer arrives with the next puzzle. That gives you a reason to come back tomorrow without making you wait to play today.

The previous version still settles its old picks, and its code lives on a git tag.

Generating questions that are actually fair

No LLM is involved. A rule-based generator builds the puzzle each day from two sources: articles from the previous day's most-read list (timely and often surprising) and a curated catalog of well-known articles (so estimation questions are about names people recognize).

The hard part is not building a question. It is building one that isn't trivially obvious or completely random. Some rules that made the biggest difference:

Keep head-to-heads close. A random pair is usually a blowout: one article has 10x the views of the other. I only pair articles whose counts are 1.02 to 1.3x apart.

"Most read" needs a real rival. One of the three alternatives must have at least 55% of the winner's views, so it's never "obviously the famous one".

Trend battles compare growth, not size. "Which rose the most against its own 7-day average?" lets a small article beat a giant. I limit the size spread between the four candidates and prefer races where the runner-up was close.

Ranges use human numbers. Answer bands are cut at roughly 80%, 100% and 125% of the article's weekly average, rounded to two significant figures:

// 12,345 → 12,000; 8,764 → 8,800
export function nice(n: number) {
  if (n <= 0) return 0;
  const p = 10 ** Math.max(0, Math.floor(Math.log10(n)) - 1);
  return Math.round(n / p) * p;
}

Bands where the real number sits right on a cut are skipped, so nobody loses on a rounding hair.

Filter what shouldn't be a game. The most-read list is full of things that don't belong in a casual puzzle: adult sites, "Deaths in 2026", shootings, disasters. A title filter drops those, along with lists, non-article namespaces and very long titles.

Don't repeat yourself. An article used in a puzzle or call can't come back for a week.

Same puzzle for everyone. The random generator is seeded with the date, so the puzzle is deterministic. It can be rebuilt identically, tested against real fixture data, and is the same no matter which request triggers the build.

Some real answers from Oct 31: Halloween drew 202,666 views (+485% against its usual week), Trick-or-treating jumped +584%, and Day of the Dead reached 38,440.

The daily call has its own timing problem

The call about day D opens at 00:00 UTC on D. At that moment, D-1 isn't published yet, so the call can only use data through D-2. Its "7-day average" is D-8 to D-2. Calls rotate through four formats (beat the average, head-to-head, range, trend battle) so consecutive days feel different, and they fall back to the simplest format if the day's data can't support the planned one.

There's also an honest weakness worth admitting: since the puzzle is about yesterday, you could look the answers up. For a casual game that's fine. It's also exactly why any future leaderboard will be built on the calls, which are about a day that hasn't finished yet.

Stack

Deliberately boring:

Next.js (App Router) + React
SQLite via Node's built-in node:sqlite, on one small Google Cloud VM behind Caddy
An hourly collector job that fetches data, settles calls and builds the next puzzle as soon as the data appears
GitHub Actions: typecheck, tests, build, then a locked-down SSH deploy
Verified daily backups copied to Cloud Storage
No account needed. Optional Google sign-in syncs your streak across devices

Tests include building a full puzzle from a real day's data saved as a fixture, which caught more generator bugs than anything else.

Try it

fomorrow.app: free, no sign-up, new puzzle every day at 06:00 UTC, and every past puzzle is in the archive.

It's brand new, so I'd love feedback: which questions felt too easy or too random, what was confusing in your first minute, and whether you'd come back tomorrow.