DEV Community: Dumb Game Lab

My fortune app made 4 won in two weeks and I patched it three times anyway

Dumb Game Lab — Sat, 14 Nov 2026 02:12:13 +0000

4 won. That's about $0.003, from 4 ad impressions, for the first two weeks of a small fortune app I shipped on October 16

The app does Saju animal compatibility inside Toss. Toss is a big Korean finance app, and other people can run small apps inside it as mini apps. Saju is the Korean four pillars reading. Your birth date and hour become pillars, and each day pillar maps to an animal and an element. There are 60 day pillars, and I wrote a reading for every one of them before launch

I also went deep on the calendar side. The Saju year turns over at the exact minute of Ipchun, the start of spring, so early February birthdays can land in the previous year. Korea ran daylight saving time in some years, which shifts birth hours from those summers. Then there's true solar time, because the clock in Seoul and the sun over Seoul don't agree. All of that is in there

Six people used it in two weeks

All six were us, testing

Real users: 0. For five days in a row daily actives were 0 and I was still opening the code every morning

I pushed three updates after launch. Only 30% of the people who started the input screen got to the end, so I made "I don't know my birth time" the default. Then I took out the greyed-out submit button and put in a message that points at the field you missed

Both fixes are fine. Neither one could move anything. 30% of six testers isn't a measurement, and with zero real users there was nobody to convert. I kept working on the input screen because it was the part I could edit. Nobody arriving had no file I could open

Same month, we put a jjimjilbang idle game into Toss too. First day there was also 0 users. As far as I can tell Toss doesn't give mini apps much organic exposure. You get listed and that's roughly it

Before launch I'd set a rule: under 10,000 won in two weeks and it stops. It cleared that easily, in the wrong direction. On October 31 I called it. The app is still up, I just stopped working on it

Now, before I touch code on anything live, I count new users from the last 7 days. If it's 0 I close the editor

https://dumbgamelab.com/?utm_source=launch-devto&utm_medium=community

One 5-second alarm in my pixel game ate the whole account's free Durable Objects reads

Dumb Game Lab — Sun, 08 Nov 2026 00:29:04 +0000

5 million rows read. That's the daily free limit for SQLite-backed Durable Objects, and on 11-07 we went past it

The limit is per account. That's the part I hadn't really thought about

What burned through it was one alarm. We run a small multiplayer pixel game called Dothyeolmaeng, and one of its Durable Objects sets an alarm that fires every 5 seconds. Every time it fired it ran a query on a table with no index on the column it filtered by, so SQLite scanned the whole table. Every 5 seconds, all day.

On its own that's just a slow query. The bad part is that the same Cloudflare account also runs our error collector and the server that handles friend invites. When the alarm used up the shared read budget, both of them stopped too. So the thing that was supposed to tell me something broke was also broken

The fix was mostly boring. I added two indexes so the alarm reads the rows it needs and skips the rest of the table. The alarm was also reading the bot list from the table on every tick, and that list barely changes, so now it's cached in memory and only reloaded when it actually changes.

Then I added a watcher that checks usage every hour, so the next time something like this starts climbing I see it the same day and not when everything goes down

If you're on DO SQLite, here's what you can check in five minutes. The cursor from sql.exec has a rowsRead field. Log it next to the query:

const cur = this.ctx.storage.sql.exec(query, ...args);
const rows = cur.toArray();
console.log(query, cur.rowsRead);

Read it after you've gone through the rows, since it fills in as the cursor is read. Then look for any query where rowsRead is way bigger than the number of rows you actually got back. That gap is the full table scan. Ours read the whole table to get back a handful of rows, on a 5 second loop

I'd been staring at request counts on the dashboard and they looked completely fine. Requests were never the issue, rows were

https://dumbgamelab.com

Our PR checks took 3.5 minutes and nobody timed it for weeks

Dumb Game Lab — Mon, 02 Nov 2026 11:20:51 +0000

We keep a few mobile games in one repo. Over time the fast CI job turned into 88 small check scripts that ran one after another. File size limits, missing translation strings, colors outside the palette, scene hierarchy rules, that kind of thing. Each one finishes in a few seconds, so nobody thought of any of them as slow

All together, every PR sat there for about 3.5 minutes before it could merge.

We lived with that for weeks. I didn't time it once. What finally did it was the owner of the studio complaining about CI being the bottleneck twice in the same morning, and the second time I opened the job log and actually added up the step times

The fix was boring. None of the 88 scripts depend on each other, so I put them behind a small parallel runner that starts them all at once and collects exit codes. Auto-merge used to be its own job that waited for the check job, booted a fresh runner and checked out the repo again. I moved it into the last step of the same job, which got rid of that second startup.

Now it's about 1 minute per PR

The annoying part is how long 3.5 minutes felt normal. You push, go get water, come back, it's merged. Then one day you push ten small PRs and you've spent half an hour watching a spinner

One of the games in that repo is an idle internet cafe tycoon for phones, if you're curious what all those palette checks are guarding
https://qqq1212341.github.io/pcbang-alba-sim/?lang=en&utm_source=devto&utm_medium=social&utm_campaign=launch-devto

Three fixes in 43 minutes for a 2GB memory warning, and only the third one mattered

Dumb Game Lab — Sat, 31 Oct 2026 07:10:52 +0000

We recently put our browser game One Life on the Playgama web portal. It's a small game where each year of your life is one line, and the start screen has a globe drawn on a canvas.

Playgama runs an analyzer on every upload. Ours came back with a warning that the page was using over 2GB of memory.

The three pull requests

11:10. We blamed the globe first, moved its canvas onto its own compositing layer and shipped it.

11:21. It still looked like a rendering problem to us, so we switched the globe to a software canvas and shipped again.

Neither fix touched the logo, which was still sitting on top of the globe canvas.

11:53. We took the logo out of the layout flow with position: absolute. The overlap went away, and the warning went with it.

What was actually happening

The analyzer loads the page in headless Chrome with no GPU. With the logo on top of the globe canvas, the main thread stalled on first paint and memory went past 2GB. It took both elements to trigger it. Removing only the logo made the problem disappear, and so did removing only the globe.

That means the layer change and the software canvas were both tweaks to the rendering of something that was only half the cause.

The part we're not proud of

Every time, we shipped the next fix before the analyzer had finished reporting on the last one. Three PRs in 43 minutes sounds quick. Really it means we never let one attempt tell us anything before we moved on.

Our first commit message said we'd bisect with variant uploads: one build without the logo, one without the globe, then compare. That would have pointed straight at the overlap. We wrote it down in the first commit. Then we skipped it.

If a warning only shows up in a headless run, check what overlaps what before you touch any rendering flags.

The game, if you want to see the globe: https://qqq1212341.github.io/one-life/?utm_source=launch-devto&utm_medium=community

9 days ago I launched a game where every year of your life is one line. 8,589 choices, 0 visits back from shares

Dumb Game Lab — Thu, 29 Oct 2026 01:29:37 +0000

One Life is a free browser life sim: you get one line of story per year, and your birthplace is randomly weighted using UN birth data for 124 countries.

Nine days after launch, One Life has had 263 players start 789 lives. They made 8,589 choices at crossroads and reached 181 deaths.

The sharing numbers looked less dead at first. Players tapped the birth-card share button 88 times across 29 people, and saved the card image 24 times across 14 people.

Visits arriving through a share link: zero.

My current explanation is painfully ordinary. The card is an image. Saving or posting it does not carry the URL along. My share text did contain a link, but most shares were the image, so the useful part was easy to lose.

I am changing the output rather than asking players to behave differently. The game will write a result sentence containing a number, a title, and an everyday unit, with the link inside that text. A Japanese browser game that went viral this week used the same basic pattern: its share button produced result text like 「永」銀賞 74点 plus a link.

The image can still travel. Now the sentence can travel without it.

When players share a screenshot, how do you make sure the link survives?

Our crash reporter's first day: three web standards that killed boot on old Android WebViews

Dumb Game Lab — Tue, 27 Oct 2026 01:06:24 +0000

We run about a dozen small HTML5 games wrapped as Android apps. Last week we finally put a crash reporter in all of them: a tiny script at the very top of <head> that sends any uncaught error to our own worker.

The first day of data had a pattern we didn't expect. The top boot crashes weren't bugs in our game code. They were standard functions that simply don't exist on older Android WebViews:

CanvasRenderingContext2D.roundRect — killed boot in our claw machine game. We use it for rounded buttons and the share card.
Array.prototype.at — arr.at(-1) is so convenient that it crept into a dozen places.
structuredClone — used to copy save data in two tycoon games.

All three work on any phone from the last couple of years, and that's why our own testing never caught them. Players on older devices (still around Chrome 90 inside the WebView) got a white screen and left. No review, no report. The reporter was the first time we saw them at all.

What we did

We didn't patch each game. We wrote one small compat file that gets injected in the same spot as the crash reporter, before any game script runs:

var def = function (o, k, v) {
  if (o && !o[k]) Object.defineProperty(o, k, { value: v, writable: true, configurable: true });
};
function at(n) {
  n = Math.trunc(n) || 0;
  if (n < 0) n += this.length;
  return n < 0 || n >= this.length ? undefined : this[n];
}
[Array.prototype, String.prototype].forEach(function (p) { def(p, 'at', at); });
if (typeof structuredClone === 'undefined')
  window.structuredClone = function (v) { return v === undefined ? v : JSON.parse(JSON.stringify(v)); };
// roundRect: moveTo/lineTo/arcTo with radii clamped to half the shorter side,
// installed on CanvasRenderingContext2D, OffscreenCanvasRenderingContext2D and Path2D

The structuredClone fallback is lossy (no Maps, Dates or cycles), but our save data is plain JSON anyway, so it's fine for us. Check yours before copying it.

Rules we set for ourselves:

If the reporter shows "X is not a function" and X is a web standard, the fix goes in the compat file, not in the game. The next game gets it for free.
There's a self-test that creates a canvas context with roundRect removed and checks that the shim fills it in. It runs with the rest of our checks.
The shim only ships in store builds. The dev server doesn't load it, so we don't hide the problem from ourselves while developing.

The claw machine game got a hotfix the same day (1.0.4) and the boot errors from that version stopped.

The takeaway

If you ship web games inside a WebView, your minimum browser is whatever the oldest phone in your player base has, not your own phone. A crash reporter at the top of <head> is about 2 KB and pays for itself on day one.

If you want to see the claw machine game that started this: https://play.google.com/store/apps/details?id=com.dumbgamelab.bangguseokclaw

Listing browser games on a Taiwanese web game hub: what the auto-check looks for

Dumb Game Lab — Mon, 26 Oct 2026 10:13:46 +0000

I make small free mobile and browser games as a one-person studio in Korea. My numbers keep pointing at Taiwan: in the last 28 days, my internet cafe tycoon got 501 players from Taiwan and 434 from Korea. So today I tried 4388.fun, a Taiwanese site that collects free browser games. When I checked it listed about 4.9k games, with 29 new ones in the past 24 hours.

There is no review queue. You sign in with Google, paste a game URL, and an automatic check decides on the spot. If the game passes, it is listed right away. You can submit up to 3 games a day.

What the check looks at

From the submit page:

It runs in the browser. No downloads, app store pages, social posts or source-code pages.
It uses HTTPS, and the domain is not on Cloudflare's malware and phishing blocklist.
It is not already listed.
It is a single game, not a portal's home or category page.

What I learned from three submissions

The one-line description matters. One of my games was rejected as not looking like a game. I added "quiz game" to the one-line description and it passed on the next try.

Upload your own cover. Without one, the site tries to grab the cover from your game page. I used a store screenshot that was already in Traditional Chinese.

Write the line in the visitors' language. For the tycoon I reused the Traditional Chinese line from its store listing instead of writing a new English one.

Your own domain is fine. All three games are on my own site, not on a portal.

The three games

One Life, a life sim where you are born by real birth odds: https://4388.fun/g/5718
Adult vs Kid Inside, a 1-minute quiz that tells you how much of you is still a kid: https://4388.fun/g/5719
Internet Cafe: Idle Tycoon: https://4388.fun/g/5973

I will check the play counts later this week and post the numbers. If you have a small browser game with players in Taiwan, this one costs five minutes.

Our feedback box's busiest tester turned out to be Google's test robot

Dumb Game Lab — Sun, 25 Oct 2026 02:08:19 +0000

We put a feedback button in every build we ship. Tap it, type a line, and the report arrives with the device model and the app version. Each report becomes a ticket, and each ticket starts a fix attempt.

Then a trivia app we had just uploaded to Play got seven reports in a single day. The texts were ospuuq, pzxoim, caokah. Six lowercase letters each. All seven came from the same OnePlus 8 Pro, all on app version 1.0.0.

It was not a person. It was the Play pre-launch report (Firebase Test Lab's Robo crawler), which taps every input it can find, types something, and presses the button next to it. It does this again on every upload.

So for a day we had counted a crawler as our most active tester, and some of those tickets had already started fix attempts for a bug that did not exist.

What we changed

Test Lab devices report the system setting firebase.test.lab as "true". A webview cannot read that, so we added a tiny Capacitor plugin that exposes it.
The feedback widget now sends where: "robot" from those devices, and the ticket collector skips that value.
We did not filter by "looks like random letters". That would also throw away the short, odd, real messages from actual players.

The day was lost to believing a number on the dashboard, not to the fix.

If you ship a free-text field in a mobile build, open your pre-launch report once and read what your first "users" typed into it.

We make small idle tycoon games, in case you want to see what the robot was testing: https://qqq1212341.github.io/pcbang-alba-sim/?utm_source=dev-to-gamedev-tag&utm_medium=community