DEV Community: Marvin Tang

Mapping TikTok's 46 Hidden Emoji Codes: A Reverse Engineering Story

Marvin Tang — Fri, 08 May 2026 09:04:05 +0000

A while back I noticed something in a TikTok comment thread that didn't make sense to me. People were typing what looked like emojis I'd never seen in any standard keyboard. A shaking face. A specific cartoon thumbs-up that didn't match the iOS or Android version. A speechless head-tilt.

At first I assumed they were stickers, or some creator-only feature. But the more I scrolled, the more I noticed regular accounts using them in plain text comments. They were typing something. The platform was rendering it as a custom emoji.

What I found over the next two weeks turned into TTEmos — a reference site for TikTok's 46 undocumented hidden emoji codes. This is the technical version of how that worked.

The first lead

The first thing I did was right-click "Inspect" on a comment that contained one of these mystery emojis. The DOM showed an <img> tag pointing to an asset on TikTok's CDN. Nothing unusual there, except that the user had clearly typed plain text into the comment box — the input field had no emoji picker open, and there was no sticker UI involved.

That meant somewhere between the user typing and the comment rendering, TikTok was doing a text replacement.

I went to the DevTools Network tab, posted a test comment with the text [smile], and watched. Two things happened:

The submit request sent the literal string [smile] to the API, with no client-side replacement.
When the comment came back from the server and rendered, the text was gone and an image was in its place.

So the replacement was happening on render, against a known list of codes the platform recognized.

Finding the list

The next step was figuring out where this known list lived. The likely candidates were:

A JS bundle on the web client that did the replacement after fetch
Server-rendered HTML that arrived with the image already in place
A separate config endpoint the client fetched on load

I spent about an hour going through bundled JS files in the Sources tab, looking for anything that mapped a square-bracket-wrapped string to an image filename. After narrowing it down, I found a chunk of code with the structure I was looking for. Roughly (paraphrased — not the literal source):

const EMOJI_MAP = {
  "[smile]":     "/emoji/smile.png",
  "[happy]":     "/emoji/happy.png",
  "[shock]":     "/emoji/shock.png",
  // ...
};

function renderCommentText(text) {
  return text.replace(/\[\w+\]/g, (match) => {
    const asset = EMOJI_MAP[match];
    return asset ? `<img src="${asset}">` : match;
  });
}

Once I had the map, I had the codes. There were 46 of them.

Validation

Having a list extracted from a JS file is a hypothesis, not a confirmed reference. The list could include codes that no longer worked. It could exclude codes that lived in a different code path. I needed to validate every entry on the live platform.

So I made a test account and started typing each code into comments, one at a time. For each code I checked:

Does the code render as an emoji at all?
Is the rendered emoji visually distinct from the others?
Does it render the same way in different contexts (comment, caption, reply)?
Does it survive the Edit flow without breaking?

Most codes passed cleanly. A few were interesting:

Three codes were effectively deprecated — they were in the JS map but rendered as literal text on the live platform.
Two codes had visually identical outputs (they pointed to the same asset).
Some codes had region-specific rendering — they worked normally in some locales but not others.

I documented each of these on the reference site as separate metadata fields.

The reference site itself

Once I had the validated list, the question became how to make it useful.

The temptation with this kind of niche knowledge is to write a long blog post listing everything. That's how most fragments of this list had been published before — buried in Reddit threads, halfway through YouTube tutorials, scattered across screenshots in TikTok comments themselves. The problem is that a blog post is something you read once. People who actually wanted to use these codes needed something they'd come back to dozens of times.

So I built a static site. No backend. No database. One page with all 46 emojis, a search/filter, and a one-click copy button on each one.

The architecture was deliberately boring:

ttemos.com/
├── index.html        # main reference page
├── emojis.json       # the validated 46 entries
└── assets/
    └── *.png         # locally hosted emoji images

A small bit of JavaScript handles search, filter, and copy-to-clipboard:

async function copyCode(code, button) {
  try {
    await navigator.clipboard.writeText(code);
    button.classList.add('copied');
    setTimeout(() => button.classList.remove('copied'), 1500);
  } catch (err) {
    // fall back to a hidden textarea + execCommand for older browsers
    fallbackCopy(code);
  }
}

That's the whole product. The user opens the site, finds the emoji they want, clicks copy, pastes into a TikTok comment. Three seconds.

I hosted my own copies of the emoji-style icons rather than hot-linking to TikTok's CDN. Hot-linking would have been faster to set up but fragile — TikTok could change their CDN paths at any time and the reference site would break overnight without me even noticing.

A note on undocumented features

There's an ethics question hovering over this kind of project worth addressing directly.

Documenting an undocumented but publicly visible feature isn't reverse-engineering an API in the harmful sense. The codes are publicly visible in the product. Users are typing them in plain text. The codes don't bypass any security boundary, don't expose private data, and don't unlock anything that wasn't already accessible.

What I tried to avoid was anything that would cross a line:

I didn't rehost TikTok's actual emoji image assets at scale. The reference site uses my own icons in a similar style.
I didn't build automation that posts to TikTok programmatically.
I didn't document anything else that came up while looking for the emoji map — internal API endpoints, auth flows, anything in that category stayed in DevTools and out of the article.

The goal was a reference. Nothing more.

What I'd do differently

Two things, looking back:

Build the validation harness first. I validated codes one by one manually, which took hours. If I were starting again, I'd write a small test script that takes a list of candidate codes, posts each one to a throwaway test account, and reports back which render and which don't. The platform makes that easy because the rendered output is in the DOM after submission.

Track the source of each code. Some codes came from the original JS map, some came from community Reddit threads I cross-referenced, and a few I discovered by trying patterns that weren't in either source. I didn't track which was which. When the platform updated their map a few months later and three codes broke, I had no record of which sources had been most reliable historically.

What's there now

TTEmos currently has all 46 validated codes with metadata about regional differences and deprecation status. The full reference is at ttemos.com.

It's a small static site. It will probably never grow into anything bigger. But every time someone wants to type a hidden TikTok emoji, the site is there.

The broader point — for anyone building something similar — is that platforms quietly accumulate undocumented features, and there's real value in being the person who writes them down. Not for the SEO. Not for affiliate clicks. Just because the documentation should exist and nobody else is making it.

What undocumented features have you mapped? Drop a comment.

Building 24 Random Tools in One App: An Architecture Story

Marvin Tang — Fri, 08 May 2026 08:53:12 +0000

When I started RandTap, I had a list of about eight tools I wanted to build. A dice roller. A coin flip. A password generator. A random number generator. A few others. Each one was a single-purpose utility I'd looked for separately on the web and never found a clean version of.

Eight became twelve. Twelve became eighteen. By the time I shipped, the app had 24 tools, with more queued. And along the way, the architecture question stopped being "how do I build a dice roller" and started being "how do I build a system that can hold 24 unrelated tools without collapsing into spaghetti."

This post is about what I learned. If you're building any kind of multi-tool app — a calculator collection, a converter suite, a generator hub — the patterns here might save you some time.

Why one app, not 24

The first decision was strategic, not technical. I could have shipped 24 separate single-purpose web pages. SEO-wise, that's probably better — each page can target its own keywords without competing.

But each tool was tiny. A dice roller is maybe 200 lines of code. A coin flip is 50. Building 24 separate sites would have meant 24 separate deployments, 24 sets of analytics, 24 navigation experiences for the user, and 24 places I'd need to update if I changed something cross-cutting like the theme or the sound system.

Bundling won. The trade-off was accepting that no single tool gets to optimize its URL structure perfectly. The win was a coherent product that compounds — every tool I add benefits from the shared shell.

The shell vs the tool

The first architectural decision that actually mattered was separating the shell from the tools.

The shell is everything that's the same regardless of which tool you're using:

Navigation (sidebar, header, tool picker)
Theme (dark/light mode, accent color)
Settings (sound on/off, haptic feedback, history retention)
Layout grid (tool content area, action buttons, result display)
Cross-cutting features (copy result, share, history)

The tools are the thing-specific logic:

A dice roller knows about face counts and rolls
A password generator knows about character classes and length
An animal facts tool knows about a database of facts

Once I was clear on this division, the architecture got dramatically simpler. Each tool became a self-contained module that exposed a small interface to the shell:

interface Tool {
  id: string;            // 'dice-roller'
  name: string;          // 'Dice Roller'
  category: ToolCategory;
  icon: IconName;

  // The tool's main UI, rendered inside the shell
  render: () => Component;

  // The 'generate' action when the user taps the main button
  generate: (state: ToolState) => Result;

  // Format a result as text for clipboard / share / history
  formatResult: (result: Result) => string;
}

That's it. Every tool implements that interface. The shell handles everything else.

Local state vs global state

The second pattern that mattered was being strict about state ownership.

A tool like the dice roller has its own state — what dice are selected, what the last roll was, the visual animation status. None of that needs to be visible outside the tool. Treating it as global state would have created cross-tool dependencies that don't actually exist in the user's mental model.

So tool state is local. Each tool manages its own state with whatever pattern makes sense for that tool — useState for simple ones, useReducer for complex ones, a small state machine for animation-heavy ones.

But there's a small slice of state that belongs to the shell and is visible everywhere:

Active tool ID (which tool is currently displayed)
Theme (dark/light, accent color)
Settings (sound, haptics, history toggle)
Recent results (the cross-tool history)

That's global. Tools can read it, but they can't write to most of it directly. They emit events ("a result was generated"), and the shell decides what to do with them.

This split kept the codebase navigable as it grew. When I added the 18th tool, I didn't have to think about what global state might conflict. I just wrote a self-contained module that conformed to the Tool interface and registered it.

Routing and lazy loading

With 24 tools, bundling everything into a single JavaScript file would have made the initial page load slow. Most users open RandTap to use one or two tools — they don't need the code for the other 22.

The fix was lazy loading. Each tool lives in its own module, and the shell loads them on demand:

const TOOL_REGISTRY: Record<string, () => Promise<{ default: Tool }>> = {
  'dice-roller':  () => import('./tools/dice-roller'),
  'coin-flip':    () => import('./tools/coin-flip'),
  'password-gen': () => import('./tools/password-gen'),
  // ... 21 more
};

async function loadTool(id: string): Promise<Tool> {
  const loader = TOOL_REGISTRY[id];
  if (!loader) throw new Error(`Unknown tool: ${id}`);
  const module = await loader();
  return module.default;
}

The first time a user opens a tool, there's a small loading state while the chunk downloads. After that, it's cached for the session.

For SEO, each tool also has a server-rendered shell with the tool's name and description in static HTML. Search engines see real content even before the JS runs. This was a cheap win that significantly improved indexing.

The web-to-iOS port

About six months in, I started thinking about an iOS version. The web app was working, but App Store distribution opens up a different audience and a different monetization model.

The naive plan was to wrap the web app in a WebView and ship it. This works, technically. But it doesn't feel like an iOS app. Tap latency is wrong. Animations don't feel native. Haptics don't trigger correctly. Users can tell.

The harder plan — and the one I went with — was to rewrite the UI shell natively, while keeping the tool logic largely shared.

The key insight was that the shell-vs-tool division I'd already made paid off here. Each tool's logic was already isolated and platform-independent. The shell — navigation, theme, settings — was the only part that had to be rewritten for iOS.

That's roughly 30% of the codebase, not 100%. A meaningful saving.

In practice, the iOS version uses a native shell and bridges into the tool logic through a thin adapter layer. The dice roller's "given current state, return the next roll" logic is functionally the same on both platforms.

Some adaptations were unavoidable:

Animations are native on iOS (UIKit / CoreAnimation), not the same web CSS animations. They take similar parameters but produce different results.
Haptics are a real iOS feature — iPhones have a Taptic Engine that's much richer than the limited browser vibration API. The iOS version uses much more nuanced haptic feedback than the web version can.
Persistence uses UserDefaults on iOS, localStorage on web. The interface I exposed to tools is the same; the implementation differs underneath.
Offline behavior is different. The iOS version is fully offline by default; the web version assumes connectivity for some features (like sharing).

What I'd do differently

A few things, looking back:

Define the Tool interface earlier. I wrote the first six tools without a shared interface, then refactored them when the seventh tool revealed the pattern. The refactor was painful. If I'd seen the pattern from tool one, the codebase would be cleaner today.

Build the history feature later. I added cross-tool history early, before I knew what users actually wanted to do with it. Most of that code went unused. If I were starting now, I'd ship without history and add it only when users asked.

Treat the shell as a product. The shell is at least as important as any individual tool. It's what makes the whole experience coherent. I underinvested in it for the first version and paid for it later when I had to retrofit settings, theme, and accessibility properly.

Pick the tool boundaries by user intent, not technical convenience. Some of my early tools were split because they were technically separate modules in my head, even though users would have wanted them combined. (Example: I shipped a "random number" tool and a "random number range" tool as two tools. They should always have been one tool with a range toggle.)

What's there now

RandTap currently has 24+ tools across categories: dice, decisions, generators, randomizers, and a small "fun" category for things like animal facts. It's free to use on the web with no account, and the iOS version is on the App Store with full offline support.

You can play with the web version at randtap.com.

The architecture I described isn't anything novel. It's just the same separation-of-concerns pattern applied to a niche category that doesn't usually get architectural treatment. If you're building any kind of tool collection, the shell-vs-tool split, strict state boundaries, and lazy loading are probably worth applying from day one.

What multi-tool patterns have you found helpful? Drop a comment.

The Infinite HTTPS Redirect Loop That Hit Me at 2am (and How X-Forwarded-Proto Saved My Site)

Marvin Tang — Thu, 30 Apr 2026 08:28:17 +0000

Earlier this year I migrated phyfun.com from www to non-www. On paper it's a five-minute job. In practice it took the site down for several hours, generated thousands of Search Console errors, and taught me more about SiteGround's hosting stack than I ever wanted to know.

This is the war story. If you're on SiteGround, or any Nginx-in-front-of-Apache hybrid setup, and you've ever wondered why your .htaccess HTTPS redirect rules don't behave the way the docs say they should — this post is for you.

The plan

phyfun.com is a browser physics-games site that's been online for years. The domain was historically configured with www.phyfun.com as canonical, with the bare domain redirecting to www. I wanted to flip that — make the bare domain canonical, redirect www to bare.

The reasoning was simple. I'd been moving toward shorter, cleaner URLs across all my sites, and Search Console was showing weird canonical conflicts on a few pages. Cleaning up the canonical was on my "do this when I have an evening" list for a while.

So one evening I sat down to do it. The plan was:

Add canonical tags pointing to non-www on all pages.
Update sitemap to use non-www URLs.
Add 301 redirects in .htaccess from www to non-www, and from HTTP to HTTPS.
Update Search Console with the non-www property as canonical.
Wait, watch, sleep.

Steps 1 and 2 were trivial. Step 3 is where everything went wrong.

The naive redirect rule

Here's the .htaccess I started with — the kind of rule you'll find in approximately every Stack Overflow answer about Apache HTTPS redirects:

RewriteEngine On

# Force HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Force non-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [L,R=301]

This is correct on a vanilla Apache setup. It is not correct on SiteGround. I deployed it. The site went down.

What I saw in the browser: ERR_TOO_MANY_REDIRECTS. What I saw in the Apache logs (after I figured out where SiteGround keeps them): every single request was being 301'd back to itself, in an infinite loop.

I rolled back. The site came up. I went to make coffee.

Why this fails on SiteGround

It took me an embarrassing amount of digging to understand what was happening. The short version:

SiteGround runs Nginx in front of Apache. Nginx terminates TLS. By the time the request reaches Apache, it's already been decrypted, and Apache sees a plain HTTP request — even when the user is browsing over HTTPS.

So when my .htaccess rule says:

RewriteCond %{HTTPS} off

Apache evaluates %{HTTPS} as off for every single request, including HTTPS ones, because that's what Apache sees. The rule then 301-redirects the request to HTTPS. The browser follows the redirect, hits Nginx, which terminates TLS again, hands the now-HTTP request to Apache, which sees %{HTTPS} = off, redirects again, and the cycle continues until the browser gives up.

This is a really common gotcha on hosts that use this kind of hybrid setup — SiteGround, certain WP Engine configurations, some Cloudways stacks, anywhere there's a TLS-terminating reverse proxy in front of Apache. If you've never run into it, count yourself lucky.

The fix: X-Forwarded-Proto

The fix is to stop trusting Apache's view of the protocol and instead read the header that Nginx adds when forwarding the request. That header is X-Forwarded-Proto, and it contains the actual protocol the client used (http or https).

Here's the corrected rule:

RewriteEngine On

# Force HTTPS — using X-Forwarded-Proto for Nginx-in-front-of-Apache hosts
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Force non-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [L,R=301]

The key change is RewriteCond %{HTTP:X-Forwarded-Proto} !https instead of RewriteCond %{HTTPS} off. Apache's %{HTTPS} is wrong on this kind of host. The header is right.

A few things worth knowing about this syntax:

%{HTTP:HeaderName} is how you access an arbitrary HTTP header in mod_rewrite. The HTTP: prefix tells Apache to look in the request headers, not its built-in environment variables.
The ! negates the match. So !https means "if X-Forwarded-Proto is anything other than https, redirect."
This works because Nginx faithfully sets X-Forwarded-Proto when forwarding. If you ever set this rule on a host where Nginx isn't doing that, the rule will silently misbehave. Confirm your host actually sets the header before relying on it. You can check with curl -I or by dumping headers in a tiny PHP file.

After deploying this, the site came back up. The redirect loop was gone. I made more coffee.

The bonus problem: .aspx zombie URLs

While I was already in .htaccess, I decided to deal with another issue I'd been ignoring.

phyfun.com had been on a different platform years ago, and that platform used .aspx URLs. When I rebuilt the site on a different stack, those URLs went away — but the wider web had no way to know that. Old links to .aspx pages were still being requested, by humans and bots, years later.

For a long time those requests had been hitting my generic 404 page, which returned a 200 OK status with "page not found" content. This is what's called a soft 404 — the response body says "not found" but the HTTP status code says "OK". Google really doesn't like this. Search Console had been flagging hundreds of these for ages, which I'd been politely ignoring.

The right answer for URLs that are gone and never coming back is HTTP 410 Gone, not 404. The semantic difference matters:

404 Not Found means "the resource isn't here right now, maybe try later."
410 Gone means "this resource is permanently gone, stop asking, deindex it."

Google treats them very differently. 410s drop out of the index much faster than 404s.

The .htaccess rule:

# Permanently mark old .aspx URLs as gone
RewriteRule \.aspx$ - [G,L]

The [G] flag returns 410 Gone. The - means "don't substitute the URL." The [L] stops further rewrite processing for these URLs.

Within a few weeks of deploying this, Search Console's "Soft 404" report stopped growing. Within about two months, the old .aspx URLs were essentially fully removed from Google's index. The Search Console error counts dropped from "hundreds, occasionally rising" to "zero."

If you have a site with a long history of URL changes, run a "soft 404" audit. Anything that's permanently gone should return 410, not 404, and definitely not 200.

The full corrected .htaccess

For reference, here's roughly what I ended up with:

RewriteEngine On

# 1. Force HTTPS (Nginx-in-front-of-Apache aware)
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# 2. Force non-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [L,R=301]

# 3. Permanently mark old .aspx URLs as Gone
RewriteRule \.aspx$ - [G,L]

# 4. Standard rewrite rules for the rest of the site below…

That's the migration in three blocks. The first one is the trap I fell into. The second is straightforward. The third is the tidying-up that should have happened years earlier.

Lessons learned

Trust your host's actual stack, not the generic Apache docs. "Nginx-in-front-of-Apache" is a different deployment from "vanilla Apache," and a lot of standard .htaccess snippets are subtly wrong on it. Always check what your host actually runs before pasting Stack Overflow rules.

X-Forwarded-Proto is the canonical way to detect protocol behind a reverse proxy. Not just for Apache — Express, Flask, Django, every web framework has equivalent helpers (req.protocol with trust proxy, request.is_secure, request.scheme with SECURE_PROXY_SSL_HEADER). If you've ever wondered why your framework "thinks" HTTPS is HTTP, this is usually the answer.

Soft 404s are not the same as 404s. Google treats them differently. If a page is permanently gone, return 410. If a page is broken right now but might come back, return 503. If you're just genuinely unsure, 404. The status code matters.

Test redirect rules on a staging copy first. I didn't, because the rule was "obvious." It wasn't. Twenty minutes of staging would have saved me three hours of production hot-fixing. I keep saying I've learned this lesson and I keep proving I haven't.

Search Console mostly fixes itself if you fix the underlying signals. The soft 404 cleanup showed me that GSC reports are largely a function of what your server actually sends. Once the server stops sending bad signals, the reports clear, often without further intervention.

Wrapping up

If you're hosting on SiteGround or any similar Nginx-in-front-of-Apache stack and you've ever had a redirect rule that "just doesn't work," X-Forwarded-Proto is probably what you need.

If you have an old site with URLs that no longer exist, switching them from soft 404 to 410 Gone is one of the lowest-effort, highest-leverage hygiene moves available — especially if Google's been quietly downranking those URLs for years.

And if you've ever taken down your own site at 2am, welcome. The club has many members.

The Hidden Complexity of Two-Player Browser Games — A Practical Guide to Keyboard Input

Marvin Tang — Thu, 30 Apr 2026 07:35:09 +0000

I run 2playerfun.com, a site dedicated entirely to two-player browser games where both players share one keyboard. It's a niche that turned out to have more technical depth than I expected.

When I started, I assumed local multiplayer was the easy case. No netcode. No latency. No matchmaking. Just two players, one keyboard, browser-side state. What could go wrong?

What could go wrong, it turns out, is that two people pressing keys on a single keyboard at the same time is a surprisingly hostile environment.

This post is about what I've learned. If you're building a local-multiplayer browser game, or you've just always wondered why every two-player web game uses WASD and arrows specifically, read on.

Keyboard hardware actually matters

The thing nobody tells you when you start: keyboards have a property called N-key rollover (NKRO), and most keyboards don't have very good NKRO.

In practice this means: a cheap membrane keyboard might only register two or three simultaneous key presses correctly. If Player 1 is holding W and A to move diagonally, and Player 2 presses an arrow key at the same time, the keyboard might just not send the third event. Or worse, it might send a "ghost" event for a key that wasn't actually pressed.

This is hardware. There's nothing you can do about it from the browser. But there are things you can do that make the problem less common.

Why every 2P game uses WASD + Arrows

If you've played any local multiplayer browser game, you've seen this layout:

Player 1: WASD (movement) + nearby action keys (Q, E, F, Space)
Player 2: Arrow keys (movement) + nearby action keys (Enter, comma, period, M, /)

This isn't an accident. WASD and arrow keys live on opposite sides of the keyboard, on different rows of the underlying key matrix. On most keyboards, this means they're far less likely to ghost into each other than, say, WASD and TFGH would be.

You can almost always press WASD + arrows + 2–3 nearby action keys simultaneously without issues, even on a cheap keyboard. That's why the convention exists. It's a hardware-aware layout choice that the genre converged on through trial and error.

Lesson: if you're inventing your own scheme, don't put both players' keys in the same physical region of the keyboard. Use the WASD/arrow split unless you have a strong reason not to.

Browser event handling — the things that bit me

Once you've got your key layout, you have to actually capture the inputs in the browser. Here's where I learned a few things the hard way.

1. Use `keydown` and `keyup`, not `keypress`

The keypress event is deprecated and doesn't fire for non-character keys like arrows or modifiers. Use keydown for "key went down" and keyup for "key was released":

window.addEventListener('keydown', (e) => {
  // Handle press
});

window.addEventListener('keyup', (e) => {
  // Handle release
});

2. Use `event.code`, not `event.key` or `event.keyCode`

event.keyCode is deprecated.
event.key returns the character ("a", "A", "ArrowLeft"), which changes with keyboard layout (AZERTY vs QWERTY) and shift state.
event.code returns the physical key location ("KeyA", "ArrowLeft"), which is consistent across layouts.

For game input, you almost always want the physical key, not the character. Use event.code:

window.addEventListener('keydown', (e) => {
  switch (e.code) {
    case 'KeyW':    player1.up = true; break;
    case 'ArrowUp': player2.up = true; break;
  }
});

3. Handle key repeat correctly

When a key is held, the browser fires keydown repeatedly. For movement keys this is fine — your game loop reads the state every frame. For action keys (jump, shoot), you want to fire the action only on initial press, not on every repeat.

Two common patterns:

// Pattern A: skip repeats with event.repeat
window.addEventListener('keydown', (e) => {
  if (e.repeat) return;
  if (e.code === 'Space') player1.jump();
});

// Pattern B: track held keys, fire action on transition
const heldKeys = new Set();

window.addEventListener('keydown', (e) => {
  if (heldKeys.has(e.code)) return;
  heldKeys.add(e.code);
  if (e.code === 'Space') player1.jump();
});

window.addEventListener('keyup', (e) => {
  heldKeys.delete(e.code);
});

I prefer Pattern B because it gives you a clean "what's currently held" state for movement, plus reliable transition detection for actions, from the same data structure.

4. `preventDefault` aggressively (but not indiscriminately)

Browsers have default behavior for many keys:

Space scrolls the page.
Arrow keys scroll the page.
Tab moves focus.
/ may open browser search.
F1–F12 do various OS/browser things.

If your game uses any of these for input, call event.preventDefault() or the browser hijacks the key:

const gameKeys = new Set([
  'Space',
  'ArrowUp', 'ArrowDown', 'ArrowLeft', 'ArrowRight',
  'KeyW', 'KeyA', 'KeyS', 'KeyD',
  'Enter',
]);

window.addEventListener('keydown', (e) => {
  if (gameKeys.has(e.code)) {
    e.preventDefault();
  }
  // ... handle game input
});

Whitelist your game keys. Don't blanket-preventDefault everything — users still need Ctrl+R, Ctrl+Tab, and so on for browser functions. I've seen games that swallow Tab and break focus navigation site-wide. Don't be that game.

5. Focus matters

Your game needs focus to receive keyboard events. If you're rendering into a <canvas>, the canvas itself doesn't receive keyboard events by default. Two options:

Listen on window — simplest, but globally captures keys.
Make the canvas focusable with tabindex="0" and listen on the canvas — better for embeddable games.

For a dedicated 2P game page, window is fine. For games embedded inside a larger page, scope to the canvas.

The input architecture I actually use

Here's the pattern I use across 2playerfun games:

const players = {
  p1: { up: false, down: false, left: false, right: false, action: false },
  p2: { up: false, down: false, left: false, right: false, action: false },
};

const keyMap = {
  KeyW:       ['p1', 'up'],
  KeyS:       ['p1', 'down'],
  KeyA:       ['p1', 'left'],
  KeyD:       ['p1', 'right'],
  Space:      ['p1', 'action'],

  ArrowUp:    ['p2', 'up'],
  ArrowDown:  ['p2', 'down'],
  ArrowLeft:  ['p2', 'left'],
  ArrowRight: ['p2', 'right'],
  Enter:      ['p2', 'action'],
};

window.addEventListener('keydown', (e) => {
  const mapping = keyMap[e.code];
  if (!mapping) return;
  e.preventDefault();
  const [who, what] = mapping;
  players[who][what] = true;
});

window.addEventListener('keyup', (e) => {
  const mapping = keyMap[e.code];
  if (!mapping) return;
  const [who, what] = mapping;
  players[who][what] = false;
});

// In game loop:
function update(dt) {
  if (players.p1.up)    p1Sprite.y -= speed * dt;
  if (players.p1.down)  p1Sprite.y += speed * dt;
  if (players.p1.left)  p1Sprite.x -= speed * dt;
  if (players.p1.right) p1Sprite.x += speed * dt;
  // ... same for p2
}

The key idea: keep input state in a structured object that the game loop reads, instead of mutating game state directly in event handlers. This decouples input from game logic and makes a few things much easier:

Customizable key bindings — just rebuild keyMap.
Replay systems — serialize the players state per frame.
AI opponents — let the AI write to the state object the same way the keyboard does.
Networked multiplayer later — the state object is what you'd send over the wire.

This pattern looks trivial in isolation, but the savings compound over a dozen games.

The mobile/touch reality

Honest answer: local multiplayer on mobile is mostly broken.

In theory you can put two touch zones on screen — one player on the left, one on the right. In practice this works for very simple games (tap-to-jump, swipe-to-move) but breaks down for anything needing simultaneous directional + action input. The device is also held by one person, which adds awkward physical dynamics.

For 2playerfun, my pragmatic answer is: most games are desktop-only, and mobile users see a polite "this game works best on a desktop with two players sharing a keyboard" message. Trying to force mobile two-player support has been more trouble than it's worth, and the audience that wants couch co-op is mostly on laptops anyway.

What I wish I'd known earlier

Test on a cheap keyboard. Your nice mechanical board with full NKRO will tell you nothing about what 90% of your users experience. Buy a $15 USB membrane keyboard and test 2P games on it. You will find ghosting issues you didn't know existed.

Use event.code from day one. Switching from event.key or event.keyCode later means rewriting input across every game. Save yourself the rework.

Don't blanket-preventDefault. Be specific about which keys your game uses, and let the rest behave normally.

Build the input layer once, reuse it. The keyMap → state object → game-loop-reads-state pattern works for almost every local 2P game I've built. Once it's working, copy it forward.

Wrapping up

Local multiplayer browser games feel like a niche from 2008, but the genre is having a quiet renaissance. People want to play games together in person again. Sharing a couch and a laptop is a perfectly valid form of multiplayer, and the browser is an extremely accessible platform for it — no installs, no accounts, no friend codes, no matchmaking.

If you're building one, I hope some of this saves you a few hours.

If you're just looking to play one, 2playerfun.com has a couple hundred of them, all using roughly the input architecture above.

Building a Gacha Tower Defense in Cocos Creator: Wave System, Merge Logic, and 28 Enemy Types

Marvin Tang — Fri, 24 Apr 2026 10:41:35 +0000

I wrote recently about migrating from LayaAir to Cocos Creator. This post is the follow-up: what I actually built with Cocos after the migration settled.

The game is Cosmic Summon, a gacha merge tower defense. Players summon heroes randomly, place them on a grid, and combine duplicates to evolve them through seven rarity tiers. Enemies spawn in 50 waves themed around real constellations. Bosses appear every five waves.

This post walks through the technical decisions behind three of the core systems: the merge mechanic, the wave progression, and the enemy variety system.

The Merge Mechanic

The merge mechanic is the heart of the gameplay loop. When a player places two heroes of the same type on adjacent grid cells, they combine into a higher-tier version of that hero.

Implementing this cleanly in Cocos Creator came down to three decisions.

First, the grid is a logical structure, not a visual one. Heroes are rendered at pixel-perfect positions but their merge eligibility is determined by grid coordinates stored on the hero component itself:

@ccclass('HeroUnit')
export class HeroUnit extends Component {
  @property
  heroType: string = '';

  @property
  tier: number = 1;

  @property
  gridX: number = 0;

  @property
  gridY: number = 0;

  canMergeWith(other: HeroUnit): boolean {
    if (this.heroType !== other.heroType) return false;
    if (this.tier !== other.tier) return false;
    if (this.tier >= 7) return false;
    return this.isAdjacent(other);
  }

  isAdjacent(other: HeroUnit): boolean {
    const dx = Math.abs(this.gridX - other.gridX);
    const dy = Math.abs(this.gridY - other.gridY);
    return (dx + dy) === 1;
  }
}

Second, the merge animation is handled by the Cocos Animation component, not by manually tweening properties. The animation plays on a temporary placeholder node while the old heroes are destroyed and the new hero is instantiated underneath. This lets the visual feel smooth even when the game logic is doing three things at once.

Third, the merge trigger is evaluated on placement, not continuously. The old approach ran merge checks every frame, which was fine for small boards but slowed down on mobile with 20+ units on screen. Evaluating only on placement cut the CPU overhead substantially.

The Wave Progression System

50 waves is enough that designing them manually would be tedious and error-prone. I built a wave configuration system based on JSON data, evaluated at runtime:

interface WaveConfig {
  waveNumber: number;
  constellation: string;
  spawns: EnemySpawn[];
  isBossWave: boolean;
  durationSeconds: number;
}

interface EnemySpawn {
  enemyType: string;
  count: number;
  delayMs: number;
  spawnPattern: 'single' | 'cluster' | 'stream';
}

The wave data lives in a JSON file shipped with the game. At runtime, the wave manager reads the config for the current wave, schedules enemy spawns through Cocos's scheduler, and triggers the wave completion event when all enemies are defeated or reach the base.

This separation of wave configuration from wave logic made iteration vastly faster. When playtesting revealed that wave 23 was too easy, I adjusted the JSON file, not the code.

One useful pattern: rather than spawning enemies instantly, each spawn is scheduled with a delay. This gives waves a sense of rhythm rather than a wall of enemies arriving simultaneously. For the 5-wave boss cadence, the boss spawn is preceded by a 2-second pause and a visual warning effect.

The Enemy Variety System

28 enemy types sounds like a lot, but the complexity comes from how they interact with each other and with the player's hero composition, not from the types being mechanically unique.

Each enemy is a composition of behaviors rather than a monolithic class:

@ccclass('Enemy')
export class Enemy extends Component {
  @property([Component])
  behaviors: Component[] = [];

  @property
  hp: number = 100;

  @property
  speed: number = 50;

  takeDamage(amount: number) {
    const reflect = this.getBehavior(ReflectBehavior);
    if (reflect && reflect.shouldReflect()) {
      reflect.reflectDamage(amount);
      return;
    }
    this.hp -= amount;
    if (this.hp <= 0) this.onDeath();
  }

  onDeath() {
    const split = this.getBehavior(SplitBehavior);
    if (split) split.spawnSplitUnits();
    this.node.destroy();
  }

  getBehavior<T extends Component>(type: new () => T): T | null {
    return this.behaviors.find(b => b instanceof type) as T || null;
  }
}

Behaviors are reusable: StealthBehavior vanishes for N seconds, SplitBehavior spawns smaller enemies on death, ReflectBehavior bounces damage, SummonBehavior spawns minions during lifetime, ShieldBehavior absorbs a fixed amount before taking hit damage.

A Reflector Splitter enemy is simply an enemy with both ReflectBehavior and SplitBehavior attached. This compositional approach made adding new enemy types trivial, usually just a new config entry referencing existing behaviors.

Performance Considerations

With up to 40 active enemies plus 15 heroes plus projectiles plus UI, the scene can hit several hundred nodes during peak combat. A few patterns that helped.

Object pooling for projectiles and hit effects. These are spawned frequently and destroyed frequently. Pooling eliminates the allocation cost:

const pool = new NodePool('Projectile', 50);
const projectile = pool.get() ?? instantiate(projectilePrefab);
pool.put(projectile);

Avoid per-frame array allocations in update loops. Reusing a single array reference across frames rather than creating new arrays each update saved measurable frame time on lower-end phones.

Batching sprite draws. Cocos Creator supports auto-batching for sprites in the same atlas. Grouping projectile sprites and enemy sprites into their respective atlases meant the whole scene rendered in a handful of draw calls rather than dozens.

What I'd Do Differently Next Time

Two things.

First, I'd design the merge system's edge cases earlier. The current implementation handles the common cases well but had weird behavior when players rapidly placed and removed units in the same frame. Fixing it required refactoring the placement event queue late in development.

Second, I'd build a dev-mode wave editor from the start. I eventually built one to accelerate balance testing, but the first 30 waves were designed with manual JSON editing, which was slow and error-prone. An in-editor tool would have paid for itself many times over.

Playable

Cosmic Summon runs in any modern browser at phyfun.com with no download or account required. The iOS version is currently in App Store review.

If you're building anything in Cocos Creator and want to see a working example of these patterns, the game is a decent reference for gacha systems, merge mechanics, and wave-based progression in a single project.

This article was written with AI assistance.

From LayaAir to Cocos Creator: A Solo Dev's Engine Migration After iOS Builds Kept Crashing

Marvin Tang — Mon, 20 Apr 2026 02:13:31 +0000

The debug build that wouldn't stop crashing

It was 2 AM. I had just spent five days trying to fix the same bug.

My game ran perfectly in the browser — 60 FPS, smooth animations, clean input handling. Then I'd run the iOS debug build and watch it crash within 30 seconds of launch. Sometimes on scene load. Sometimes mid-gameplay. Sometimes on a simple button tap.

No consistent stack trace. No clear reproduction path. Just crashes.

That week, I decided to migrate the entire project from LayaAir to Cocos Creator.

This post is about why I made that call, what the migration actually looked like as a solo developer, and what I'd tell anyone considering either engine today.

Why I chose LayaAir in the first place

When I started building browser-first games, LayaAir was an obvious pick:

Strong WebGL performance — genuinely fast in the browser, often beating Cocos and Phaser in my side-by-side tests
TypeScript-first — clean workflow, great autocomplete, sane codebase
Good for 2D casual games — which is exactly what I build
Active in the Chinese dev community — a lot of reference material if you can read it

For about 8 months, this was the right choice. My physics games and puzzle games shipped to the browser, loaded fast, and ran well on desktop and mobile browsers alike.

Where LayaAir shines: Web builds

Let me be fair to LayaAir. For web-only targets, it's still a solid engine:

Small runtime size
Fast startup
Good rendering performance on WebGL
Reasonable TypeScript DX

If I were building a game that would only ever run in a browser, I'd still consider it.

The problems started when I tried to go native.

Where it broke: iOS native builds

My goal was to ship the same game to iOS. LayaAir advertises native export to iOS via its build pipeline — in theory, you get an Xcode project from your web codebase.

In practice, the iOS output was unstable in ways I couldn't engineer around:

Debug builds crashed unpredictably. Same code that ran flawlessly in the browser would segfault on device, often with stack traces pointing into the engine's native layer, not my code.
Memory-related crashes during scene transitions, even in a simple project with minimal assets.
Inconsistent behavior between simulator and real device — a bug that reproduced on iPhone 14 might not show on the simulator, and vice versa.
Very limited English-language debugging resources. Most issue discussions were in Chinese, and even there, many reported bugs had no resolution.

I spent five full days trying to:

Strip the project down to a minimal reproduction
Experiment with different build configurations
Try every combination of engine version and Xcode version I could find
Post on forums and wait for responses that never came

The issue wasn't in my code. It was in the engine's native bridge. And as a solo developer, I don't have the budget — in time or money — to debug someone else's native runtime.

The switch decision

Here's the framing that helped me decide:

"How many more days am I willing to spend on a problem I can't see the bottom of?"

If the engine's iOS layer was buggy enough that a minimal project crashed, what would happen when I added monetization SDKs, more assets, more scenes?

I gave myself a budget: two more days. If I didn't have a stable build by then, I'd switch engines.

I didn't make it to day two.

Migrating to Cocos Creator

Cocos Creator was the natural alternative:

Also TypeScript-based
Similar scene/node/component architecture to LayaAir
61% of top 100 WeChat mini games ship on Cocos — which tells me the native export pipeline is battle-tested
MIT-licensed and actively maintained
Broader international documentation

The migration took about 10 days of focused work for a medium-sized project (a merge-gacha tower defense with around 40 scenes).

Here's what actually transferred well and what didn't:

What was easy

Game logic and data structures — pure TypeScript business logic ported with minimal changes
Scene structure concepts — both engines use a tree of nodes with components attached. The mental model is nearly identical.
Asset pipeline — sprites, atlases, and audio imported cleanly

What needed rewriting

Scene transitions and lifecycle hooks — API names and timing differ enough that I rewrote all the transition code
Input handling — the event system is different; I consolidated my input layer into a single adapter module
UI layout — LayaAir and Cocos have different layout primitives. I redid most of my UI by hand.
Animation system — different timeline formats; I reimplemented the important ones

What surprised me

Cocos's editor is heavier but more stable. LayaAir IDE is lighter, but I hit editor crashes regularly. Cocos Creator's editor has held up through multi-hour sessions without issue.
The iOS export just worked. The first time I tried to build for iOS with Cocos Creator, it compiled, ran on device, and didn't crash. After five days of LayaAir debugging, this felt absurd.
Web performance is still good. I was worried I'd lose the web performance edge. In practice, for my 2D casual games, the difference is imperceptible.

Results after the switch

Cosmic Summon (my gacha merge tower defense) now runs on both browser and iOS from the same Cocos Creator project
Juicy Ricochet shipped to the App Store as an all-Cocos build
Zero engine-layer crashes since the migration
My development velocity actually increased once I was past the migration hump — the editor stability alone was worth it

What I'd tell someone in the same situation

A few things I learned the hard way:

1. Set a debugging budget before you start.
"I'll fix this bug eventually" is how you lose two weeks. Decide in advance how many days the problem is worth.

2. Engine problems in the native layer are usually not solvable as a user.
If the crash comes from inside the engine's C++ or Objective-C code and isn't fixed upstream, you're not going to fix it. Move on.

3. Web performance isn't the only metric.
I chose LayaAir partly because its benchmarks were great. But "faster in a controlled web benchmark" didn't matter when the iOS build didn't work at all.

4. Pick the engine that ships the platforms you need — not the one that ships the benchmark you like.
Cocos Creator wasn't the "fastest" engine on paper for my use case. But it shipped everywhere I needed to ship, and that turned out to be the only metric that mattered.

5. Don't mistake language comfort for engine fit.
Both engines use TypeScript. I liked LayaAir's API aesthetically. But aesthetic preference shouldn't outrank "my game crashes on the target platform."

Is LayaAir bad? No.

I want to be clear: LayaAir isn't a bad engine. For web-only projects it's still a reasonable choice, and I know developers shipping successful games on it.

My specific experience was with the iOS native export, which didn't work reliably for my project. Your mileage may vary, especially if you're targeting different platforms or a newer engine version.

But if you're a solo developer, and stability across platforms matters more to you than peak web benchmark performance — Cocos Creator is, in 2026, the safer bet.

Currently building: Cosmic Summon, a gacha merge tower defense live on browser and iOS.

More of my games: phyfun.com

What engine are you using for your indie game? Have you migrated between engines before? I'd love to hear how it went — drop a comment.

How I Used Keyword Research to Build a Niche Naming Site

Marvin Tang — Thu, 16 Apr 2026 08:33:53 +0000

I'm an indie developer based in China. Most of my projects are browser games — physics puzzles, sorting games, two-player titles. But one of the most interesting things I've built has nothing to do with games at all.

It's a dog names site.

iDogNames.com now has over 11,000 dog names searchable by breed, origin, coat color, and meaning. It gets consistent organic traffic. And it started entirely from keyword research, not from any personal passion for dog names.

Here's how the thinking went.

The Problem with Competitive Niches

When I was looking for new content site opportunities, I kept running into the same wall: anything with obvious commercial value was already dominated by large publishers with enormous content budgets. "Best dog food", "puppy training tips", "dog breeds" — these are all real search categories, but ranking for them as a solo developer with no content team is not realistic.

What keyword research actually reveals, if you look carefully enough, is not just where the traffic is — it's where the traffic is relative to the competition. High traffic with low competition is the obvious target. But that combination is rare.

The more interesting question is: where is there consistent, specific demand that large publishers haven't bothered to serve well?

The Long Tail of Naming Queries

Dog name queries turned out to be a surprisingly good answer to that question.

The obvious terms — "dog names", "puppy names", "cute dog names" — are competitive. Large pet content sites rank for these and they're not worth targeting directly.

But dog name queries have an unusually long tail. People don't just search for "dog names". They search for:

"Romanian dog names"
"dog names that mean shadow"
"names for black mouth cur dogs"
"Amish dog names"
"dog names inspired by Broadway musicals"

Each of these is a small query. But there are hundreds of them. And most of them are served poorly — generic name lists with no real depth, or large sites that mention the topic once in a listicle and move on.

The pattern I was looking for: specific intent, real search volume, weak existing results. Dog name queries fit this pattern well across hundreds of variations.

What "Weak Existing Results" Actually Means

This is worth being specific about, because "low competition" means different things depending on what you're building.

For a content site targeting informational queries, weak existing results means:

The top results are generic pages that don't specifically address the query
Large domain authority sites are ranking but with thin, unspecific content
No dedicated resource exists for this specific combination of topic and modifier

"Romanian dog names" is a good example. When I looked at this query, the top results were generic dog name lists that happened to mention Romanian names in passing, or articles about Romanian dog breeds with a name section appended. There was no page built specifically around Romanian dog names with real depth — cultural context, name meanings, male and female options.

That's the gap. Not "nobody is ranking" — there are always results — but "nobody has built the right page for this specific query."

Building for the Long Tail at Scale

The insight that made iDogNames work as a project rather than a single article is that the long tail of naming queries is consistent in structure.

Almost every naming query follows a pattern: [modifier] + dog names. The modifier can be a breed, an origin country, a color, a meaning, a theme, a holiday, a cultural reference. If you can build a system that generates good pages for each modifier, you can cover the long tail systematically rather than one article at a time.

This changes the economics of the project. Instead of writing 500 individual articles, you build a database and a page template that serves queries well across all the variations. The content work shifts from writing to data curation — which, as a developer, is a much more tractable problem.

What the Traffic Data Actually Shows

The queries that perform best on iDogNames are consistently the specific ones, not the broad ones.

Pages targeting breed-specific queries ("Black Mouth Cur dog names", "Presa Canario dog names") perform well because the intent is very specific — someone just got this breed of dog and wants names that fit. Generic name lists don't serve them as well as a dedicated page.

Cultural and origin queries ("Amish dog names", "Serbian dog names", "Swahili dog names") perform well for the same reason — the searcher has a specific context in mind and wants names that fit that context.

Meaning-based queries ("dog names that mean shadow", "dog names that mean light") perform well because the searcher is approaching the problem from a values or aesthetics perspective and existing results rarely address this directly.

The broad queries — "dog names", "cute dog names" — drive less of the traffic than you might expect. The long tail collectively outperforms the head terms, which is exactly what keyword research predicted.

The Transferable Lesson

The specific niche doesn't matter much. What matters is the pattern:

Find a category with consistent, specific demand across many query variations
Look for gaps where specific intent is being served by generic content
Build a system that covers the long tail at scale rather than targeting individual terms
Let the data tell you which variations are worth prioritizing

I've applied the same thinking to iCatNames.com and 9BabyNames.com since building iDogNames. The pattern holds — naming queries in general have a long tail that rewards systematic coverage over individual article targeting.

For solo developers looking for content site opportunities, naming niches are worth considering specifically because the query structure is so consistent. The work is in the data curation and the page quality, not in finding angles — the search data tells you exactly what people are looking for.

I build browser games and niche content sites. The games are at PhyFun.com. If you have questions about the keyword research process or the technical side of building iDogNames, happy to discuss in the comments.

Why the Best Educational Games Teach Better Than Textbooks

Marvin Tang — Sun, 12 Apr 2026 12:19:27 +0000

I've been building browser games for a while. Physics puzzlers,
sorting games, two-player games — the usual indie developer
portfolio.

But when I built LumiGameLab, I had
to think seriously about a question I'd never considered before:
what actually makes a game educational?

The Wrong Answer

The wrong answer is: a game is educational if it covers an
academic subject.

This definition fails immediately when you play the games. A
game can involve math and teach nothing. A game can look like
pure entertainment and quietly build genuine skills. Subject
matter and educational value are not the same thing.

The Right Answer

The right answer, I think, is this: a game is educational when
the learning is embedded in the mechanic — not bolted on top of
it as a reward for playing.

In a bad educational game, learning is the tax you pay to access
the fun part. Answer this question correctly and you get to play
the game. The educational content and the gameplay are separate
layers that don't reinforce each other.

In a good educational game, learning is the gameplay. You solve
equations because the game requires it. You learn country
locations by placing them on a map under time pressure. You
develop intuitions about gravity and momentum because those
principles determine whether you win or lose.

The difference between these two approaches is the difference
between a game that feels like homework and a game you'd play
even if it weren't educational.

Why This Matters for Game Developers

If you're building educational games, this distinction has real
design implications.

Design the mechanic around the learning objective, not the
other way around. If you're building a math game, the math
should be the core loop — not a mini-game attached to an
unrelated action game. Every design decision should ask: does
this reinforce what I want players to learn?

Difficulty and curriculum should scale together. The best
educational games are hard in the right way. Early levels build
understanding. Later levels test mastery. The progression should
mirror how people actually learn, not just how games usually
ramp up challenge.

Feedback should be informative, not just corrective. Telling
a player they got something wrong isn't enough. The feedback loop
should help them understand why — which is harder to design than
it sounds.

Engagement is a feature, not a compromise. Some people treat
engagement and educational rigor as opposing forces — like making
a game fun necessarily dilutes its educational value. I think
this is backwards. Engagement is the precondition for learning.
A game that bores players teaches nothing, regardless of how
educationally rigorous its content is.

What I Found Building LumiGameLab

When I started curating games for LumiGameLab, I played a lot
of games that claimed to be educational. Most of them failed the
basic test: you could skip the educational element and still play
the game. The learning was optional.

The games that passed were the ones where the learning was
unavoidable — where you couldn't progress without actually
understanding the concept the game was built around.

Those games also tended to be the most fun. Not despite being
educational, but because of it. When the challenge is genuine and
the feedback is immediate, the satisfaction of getting it right
is real.

That's what I try to capture with LumiGameLab. Not games that
are educational in spite of being games, but games that are
better games because of their educational design.

If you're building in this space, I'd love to hear what design
patterns you've found that make educational mechanics work. Drop
a comment below.

LumiGameLab is a free educational browser game platform. No
account, no download, no paywalls. Find it at
lumigamelab.com.

How I Built a Free Educational Games Website from Scratch

Marvin Tang — Fri, 10 Apr 2026 08:46:25 +0000

I've been building free browser game sites for a while now. Physics games, sorting games, two-player games — each one started with a specific idea and a gap I noticed in the market.

LumiGameLab was different. This one started with a question I kept coming back to: why is it so hard to find a good free educational games site?

The Problem I Kept Running Into

There are thousands of free browser game sites on the internet. Most of them follow the same formula — action games, casual games, multiplayer games. Fun, addictive, designed to keep players coming back.

But educational games? The ones that actually teach something — physics simulations, math challenges, logic puzzles, geography games — were scattered everywhere. Buried under ads. Hard to trust. No single destination where a parent, a teacher, or a curious kid could go and say: everything here is worth playing, and everything here will teach you something.

That gap is what LumiGameLab is trying to fill.

Why Educational Games Are Underserved

I think the reason educational game sites are rare comes down to a few things.

First, educational games are harder to curate. You can't just collect any fun game — you need games with genuine learning value. That's a higher bar, and most aggregator sites don't want to deal with it.

Second, the audience is different. Parents and teachers have much higher standards for what they'll recommend to kids than casual gamers have for what they'll play themselves. A site full of ads and questionable content is a non-starter. Trust matters.

Third, the best educational games don't always look educational. A physics puzzle game doesn't announce itself as a lesson in Newton's laws. A geography challenge doesn't feel like homework. The educational value is embedded in the gameplay — and curating for that requires actually playing the games, not just listing them.

What I Built

LumiGameLab is a free educational game platform covering ten subject areas: Math, Puzzle and Logic, Language Arts, Science and Space, Geography, Physics, Memory, Trivia and Quiz, Art and Creativity, and Simulation.

Math is the largest category with 28 games — not drill exercises, but games where math is the actual mechanic. You solve equations to survive, use multiplication to advance, and apply logic to win.

The physics games are some of my personal favorites. There's something uniquely satisfying about a game that lets you experiment with real physical principles — momentum, balance, gravity — and see the consequences in real time. It's the kind of intuitive understanding that sticks.

Geography games bring the world to life in ways static maps never could. Flag quizzes, country placement challenges, capital city games — they turn geography from memorization into exploration.

The puzzle and logic section is for anyone who wants to feel genuinely challenged. These are the games you think about when you're not playing.

Technical Decisions

The site is built with PHP, which I've used across most of my web projects. Nothing exotic — clean URLs, fast page loads, mobile-friendly layout, minimal JavaScript.

The main technical challenge was the curation and tagging system. Every game on LumiGameLab is tagged by subject category, topic, age range, and learning focus. Building a flexible tagging system that could handle multiple overlapping categories without becoming a mess took some iteration.

Search and filtering were also important. A parent looking for math games for a 7-year-old has very different needs from a teacher looking for geography games for a high school class. The filtering system needed to handle that range without becoming complicated to use.

The Design Philosophy

Two principles guided every decision:

Everything is free. No subscriptions, no paywalls, no premium tiers. Educational resources should be accessible. Not every family can afford an app subscription. Not every school has a licensed software budget. Free isn't a business model compromise — it's the whole point.

Quality over quantity. I'd rather have 100 games that are genuinely good than 1,000 games that happen to mention a subject somewhere in the description. Every game on the site has been reviewed for actual educational value, not just tagged and listed.

What I've Learned So Far

Building a niche site with a clear educational focus attracts a different kind of visitor than a general game aggregator. The bounce rate is lower. Session time is longer. People are coming with a purpose — a parent looking for something specific for their child, a teacher hunting for a classroom resource, a student who actually wants to learn something.

That's a more valuable audience to build for, even if it's a smaller one.

The other thing I've learned: trust takes time to build, but it compounds. A site that consistently delivers quality recommendations builds a reputation that general aggregators can't easily replicate.

What's Next

LumiGameLab is live now at lumigamelab.com. The current version has games across ten subjects, with new games added regularly.

Upcoming work includes better age-range filtering, teacher resource guides alongside game listings, and expanding the Science and Space category which currently has the fewest games.

If you're building something in the educational space — games, tools, resources — I'd love to hear what you're working on. Drop a comment below.

I build and maintain a small network of free browser-based sites. If you're interested in niche site building, indie game development, or browser-based gaming, follow along.

Why I Built a Separate Website Just for Sorting Games

Marvin Tang — Tue, 31 Mar 2026 13:39:40 +0000

When I added the first water color sorting game to my main game portal, I did what most developers do: I tagged it, categorized it, and moved on.

Six months later I had a dozen sorting games on the site, a noticeable chunk of traffic coming specifically from sorting-related search queries, and a growing suspicion that I was underserving that audience by burying their content inside a general portal.

That suspicion became SortFun.

The SEO case for topical authority

Google's approach to ranking content has shifted significantly toward what SEOs call topical authority — the idea that a site which covers a specific subject comprehensively will outrank a site that covers the same subject shallowly, even if the larger site has more overall domain authority.

For a general game portal, this creates a structural problem. A site that covers action games, puzzle games, racing games, sports games, and sorting games is authoritative about none of them. It's a generalist competing against specialists for every query it targets.
The math on this became clear when I looked at my search console data. My sorting game pages were getting impressions for queries like "water color sort game" and "ball sort puzzle online," but the click-through rates were lower than I expected. The pages were showing up, but something was making users choose a competitor's result instead.
Part of that was positioning. A page on a general portal that happens to have sorting games is a less convincing answer to "I want to play sorting games" than a site called SortFun where every single page is a sorting game.

Taxonomy as product decision

The more interesting engineering decision was how to categorize the games on the new site.

Traditional game portals organize by genre: puzzle, action, strategy, casual. These categories map onto how games are made, not how players think about what they want to play. A player who wants to sort colored balls into tubes doesn't think "I want a puzzle game." They think "I want that satisfying sorting thing."

SortFun organizes by mechanic instead of genre. Water sorting. Ball sorting. Tile sliding. Color matching with a sorting constraint. Each category describes what you actually do, not what shelf it belongs on in a game store.

This distinction matters for SEO because search queries reflect player intent, and player intent is usually mechanic-based. "Water sort puzzle" gets searched. "Casual puzzle game" gets searched less specifically. Building the taxonomy around mechanics means the category pages naturally align with how players actually search.
The single codebase across multiple sites problem
Running multiple specialized sites from a solo developer position creates a maintenance question that's worth thinking through before you commit to the architecture.

My games are built in Cocos Creator. The web builds are static file bundles — HTML, JavaScript, assets — that I deploy to subdirectories on each site. There's no shared runtime dependency between sites, which means a change to the SortFun deployment doesn't affect PhyFun or 2 Player Fun.

The tradeoff is that site-level infrastructure changes — navigation updates, footer changes, sitemap regeneration — have to be applied to each site independently. For two or three sites this is manageable. At ten sites it would become a maintenance burden that outweighs the SEO benefits of separation.

My current threshold: a separate site is justified when the target keyword cluster is large enough to support 50+ unique pages, the mechanic focus is distinct enough that a general portal visitor would feel lost, and the domain name can match the primary keyword naturally. SortFun clears all three. A hypothetical site just for brick-breaker games probably doesn't.

What the data showed after launch

The topical authority hypothesis held up. Within a few months of launching SortFun as a standalone domain, the sorting game pages that had previously been buried on a general portal were ranking higher for their target queries than the equivalent pages on the main site, despite the main site having significantly more overall backlinks.
The click-through rate improved as well. A result from SortFun.com for a sorting game query is immediately legible — the domain name tells you exactly what you're going to get. A result from a general portal requires the user to evaluate whether that portal's version of the game is worth clicking over the other results. Specificity removes that friction.

The tradeoff you're actually making

Splitting content across multiple specialized sites is a bet that topical authority compounds faster than domain authority. For broad, competitive queries, that bet is probably wrong — you want all your link equity concentrated in one domain. For narrow, underserved query clusters, it can be right.

Sorting games is a narrow, underserved cluster. The queries are specific, the competition is thinner than in broader puzzle game categories, and players who want sorting games want a lot of sorting games — they're not one-and-done visitors.

The site is at sortfun.com if you want to see how the taxonomy ended up in practice.

How Keyword Research Led Me to Build a Niche Game Portal

Marvin Tang — Tue, 31 Mar 2026 13:32:49 +0000

Most people treat keyword research as an SEO task. I've come to think of it as a business model discovery tool.

The site that convinced me of this was 2playerfun.com. The keyword came first. The business followed.

What I was actually looking for

Ten years ago I was thinking about browser game portals as a category. The major players — Miniclip, Addicting Games, Newgrounds — were all pursuing the same strategy: maximum breadth, every genre, something for everyone. Their homepages were catalogues. Their category pages were catalogues of catalogues.

The SEO implication of that strategy is that you compete for everything and dominate nothing. A site that covers every genre will always rank below the threshold for any specific genre query, because specificity is exactly what it's trading away in exchange for breadth.

I started pulling keyword data for game-related search queries, looking for volume that wasn't being captured by a dedicated destination.

The keyword that stood out

"Two player games" had consistent monthly search volume. More importantly, when I looked at what was ranking for it, the results were generic portal pages — category tabs on large sites, not dedicated destinations built around that specific query.

The keyword had clear intent behind it: someone sitting with another person, looking for something to play together. That's a specific situation with a specific need. A site built entirely around that need would be more useful to that searcher than page 12 of a general portal's two-player category.

I looked at adjacent keywords to understand the full shape of the opportunity:
"games for two players" — similar volume, same intent
"2 player games unblocked" — significant volume, school audience
"two player games on one keyboard" — lower volume, high specificity
"games to play with friends on computer" — broader intent, overlapping audience

The cluster confirmed what the primary keyword suggested. There was a real, recurring search demand for exactly this kind of content, and no site was serving it as a primary focus.

What made the niche viable beyond search volume

Search volume tells you that demand exists. It doesn't tell you whether the demand is sustainable or whether you can actually serve it well.

Two-player local games had a property that made me confident the niche was worth building around: the use case is social. When someone searches for "two player games," they're almost always doing it with another person present. That social context creates return behavior. Players don't just bookmark a game — they bookmark a destination to come back to with whoever they play with. The retention mechanic is built into the situation.

The competitive landscape also mattered. At the time, no one had built a destination site specifically for this query cluster. The keyword had volume, clear intent, an underserved audience, and no direct competitor. That combination doesn't appear often.

How the keyword shaped the site architecture
Once I committed to the niche, the keyword research informed decisions that went well beyond SEO.

The site name came directly from the primary keyword: 2playerfun.com. Exact match domains have diminished in SEO value since the early days, but for a niche portal, having the keyword in the domain still serves as a clear signal to both users and search engines about what the site is.

The category structure followed the keyword cluster. Instead of organizing by genre — action, puzzle, sports — I organized around play patterns: games for two on one keyboard, games for two on one screen, competitive games, cooperative games. The taxonomy reflected how the audience was actually thinking about their need.

Every page title, meta description, and H1 was written with the primary and secondary keywords in mind. Not keyword stuffing — the content had to actually serve the user — but deliberate alignment between what people were searching for and what the pages delivered.

The broader lesson

The standard advice for niche sites is "find your niche." What that advice usually means in practice is: look at what you're interested in and find a corner of it that isn't overcrowded.

That's backwards. Start with the keyword data. Find queries with real volume and weak competition. Then ask whether you can build something genuinely useful for the person behind that search.

The niche doesn't come from your interests. It comes from the gap between what people are searching for and what currently exists to serve them.

Two player games was that gap. The keyword research found it. The site filled it.

2playerfun.com is live now if you want to see where that keyword research ended up.

Why I Renamed My Game from Star Guardian to Cosmic Summon

Marvin Tang — Tue, 31 Mar 2026 13:20:58 +0000

Naming a game is harder than building it. I learned this the expensive way.

Where Star Guardian came from

When I started designing the gacha tower defense game that would eventually become Cosmic Summon, I had a working title almost immediately: Star Guardian. It felt right. The game is set against a backdrop of real constellations, the heroes are cosmic-themed, and the enemies arrive in waves named after star patterns. Guardian captured the defensive nature of tower defense. Star captured the visual identity.

I built the entire game under that name. The internal project files are still called Star Guardian. The early design documents reference Star Guardian throughout. For months, that was the game.

The problem

When I went to submit to the App Store, I searched the name.
Star Guardian was taken. Not just taken — it was occupied by an established title with a significant player base. Apple's App Store has strict policies around names that are identical or confusingly similar to existing apps. Submitting under Star Guardian wasn't just a branding risk; it was a rejection waiting to happen.

This is a mistake I should have caught earlier. Checking name availability across the App Store, Google Play, and major trademark databases should be one of the first steps in any game project, not something you verify at submission time. I knew this. I skipped it anyway because the name felt so obviously mine that I didn't think to check.

Finding a new name

Renaming a game late in development is disorienting. The name you've been using becomes load-bearing — it's in your mental model of the project, in your marketing copy, in the visual identity you've been building. Changing it feels like changing something fundamental about what the game is.

The criteria I worked from: the new name had to reference the cosmic setting, had to be available across all major platforms, and had to be distinct enough that a player searching for it would find exactly one result.

I went through a long list. Cosmic Defender was taken. Star Sentinel was too generic. Constellation Wars felt like a different genre entirely.

Cosmic Summon worked. Cosmic kept the setting. Summon captured the gacha mechanic that sits at the center of the game loop — you summon heroes, you place them, you merge duplicates to evolve them into higher rarity tiers. The name describes what you do, not just where you do it. And it was available.

What the rename cost

The practical cost was less than I expected. The game's visual identity — constellation backdrops, cosmic hero designs, the color palette — didn't need to change. The marketing copy needed rewriting. The App Store listing, the game's landing page, the description on phyfun.com — all of it needed updating before submission.

The psychological cost was higher. There's a version of this game called Star Guardian that exists only in my project files, and it takes a conscious effort not to revert to that name when describing the game to people who knew the earlier name.

What the game actually is

Cosmic Summon is a gacha merge tower defense game. Players summon heroes using a gacha system, place them on the battlefield, and merge identical units to evolve them through 7 rarity tiers — from Spark up to the legendary Genesis rank. The game features 12 distinct heroes, 28 enemy types with unique abilities, and 50 waves set against real constellation backdrops from Aries to the Southern Cross.

The browser version is live now at phyfun.com. The iOS version is currently in App Store review.

The lesson

Check name availability before you fall in love with a name. Search the App Store, Google Play, the USPTO trademark database, and do a basic web search. Do this on day one of the project, not day one hundred.

The rename worked out. Cosmic Summon is a better descriptive name than Star Guardian was — it tells you more about the mechanics in two words. But I got lucky that the change was mostly cosmetic. If the name had been embedded in the game's UI, in level dialogue, in audio files, the cost would have been significantly higher.

Name your game last. Or at least hold it loosely until you've shipped.

DEV Community: Marvin Tang

Mapping TikTok's 46 Hidden Emoji Codes: A Reverse Engineering Story

The first lead

Finding the list

Validation

The reference site itself

A note on undocumented features

What I'd do differently

What's there now

Building 24 Random Tools in One App: An Architecture Story

Why one app, not 24

The shell vs the tool

Local state vs global state

Routing and lazy loading

The web-to-iOS port

What I'd do differently

What's there now

The Infinite HTTPS Redirect Loop That Hit Me at 2am (and How X-Forwarded-Proto Saved My Site)

The plan

The naive redirect rule

Why this fails on SiteGround

The fix: X-Forwarded-Proto

The bonus problem: .aspx zombie URLs

The full corrected .htaccess

Lessons learned

Wrapping up

The Hidden Complexity of Two-Player Browser Games — A Practical Guide to Keyboard Input

Keyboard hardware actually matters

Why every 2P game uses WASD + Arrows

Browser event handling — the things that bit me

1. Use keydown and keyup, not keypress

2. Use event.code, not event.key or event.keyCode

3. Handle key repeat correctly

4. preventDefault aggressively (but not indiscriminately)

5. Focus matters

The input architecture I actually use

The mobile/touch reality

What I wish I'd known earlier

Wrapping up

Building a Gacha Tower Defense in Cocos Creator: Wave System, Merge Logic, and 28 Enemy Types

The Merge Mechanic

The Wave Progression System

The Enemy Variety System

Performance Considerations

What I'd Do Differently Next Time

Playable

From LayaAir to Cocos Creator: A Solo Dev's Engine Migration After iOS Builds Kept Crashing

The debug build that wouldn't stop crashing

Why I chose LayaAir in the first place

Where LayaAir shines: Web builds

Where it broke: iOS native builds

The switch decision

Migrating to Cocos Creator

What was easy

What needed rewriting

What surprised me

Results after the switch

What I'd tell someone in the same situation

Is LayaAir bad? No.

How I Used Keyword Research to Build a Niche Naming Site

The Problem with Competitive Niches

The Long Tail of Naming Queries

What "Weak Existing Results" Actually Means

Building for the Long Tail at Scale

What the Traffic Data Actually Shows

The Transferable Lesson

Why the Best Educational Games Teach Better Than Textbooks

The Wrong Answer

The Right Answer

Why This Matters for Game Developers

What I Found Building LumiGameLab

How I Built a Free Educational Games Website from Scratch

The Problem I Kept Running Into

Why Educational Games Are Underserved

What I Built

Technical Decisions

The Design Philosophy

What I've Learned So Far

What's Next

Why I Built a Separate Website Just for Sorting Games

1. Use `keydown` and `keyup`, not `keypress`

2. Use `event.code`, not `event.key` or `event.keyCode`

4. `preventDefault` aggressively (but not indiscriminately)