DEV Community: Marvin Tang

I Rewrote One AI Prompt 15 Times to Kill the "AI Smell" in Product Reviews

Marvin Tang — Fri, 05 Jun 2026 03:43:36 +0000

You can smell an AI-written product review from the first sentence. "In today's fast-paced world, finding the right product can be a game-changer." Nobody talks like that. Nobody who has actually used a slow-feeder bowl for three months opens with a thesis statement.

I run a pet-gear review site, and I wanted to use AI to speed up drafting without producing that. What I found is that the prompt is the entire job. I ended up rewriting one review-drafting prompt around fifteen times, and the interesting part wasn't getting the AI to write more — it was getting it to write less like an AI. Here's what actually moved the needle, and the hard ceiling I kept hitting.

Why the first prompt failed

The naive version is the one everyone starts with:

Write a review of [product]. Make it sound natural and helpful.

What comes back is fluent and completely hollow. It has the shape of a review with none of the substance: sweeping adjectives, zero specifics, a conclusion that could apply to any product in the category. "Make it sound natural" does nothing, because the model's default register already is what it thinks natural sounds like — and its idea of natural is a marketing brochure.

The problem isn't fluency. The model has plenty. The problem is that generic prose is its lowest-energy output, and a vague prompt lets it sit there.

What actually worked

The fixes were all about removing the model's room to be generic.

A banned-phrase list. I keep an explicit blocklist in the prompt — "game-changer," "in today's world," "look no further," "when it comes to," "elevate your," "whether you're a... or a..." Naming the clichés is far more effective than asking for "no clichés," because the model can't reliably detect its own tells; it can follow a literal list.

Forced structure with required slots. Instead of "write a review," the prompt demands specific components: the use case it's actually for, who it's not for, and at least one concrete drawback. The single biggest jump in believability came from forcing a real negative. Reviews with no downside read as ads; humans instinctively distrust them. A required "here's what annoyed me" slot breaks the brochure tone instantly.

Specificity over judgment. I forbid bare evaluations. The model can't write "it works great" — it has to write under what conditions it behaves how. "Great for a strong puller" is a claim; "it works great" is filler. Forcing the conditional drags the text toward something testable.

Constrained voice and density. First person, restrained, no encyclopedia tone, no summarizing the entire product category before getting to the point. I cap how much throat-clearing it's allowed before the first concrete observation.

Each of these is a small rule. Stacked together, they pull the output out of brochure-land and into something that at least reads like a person wrote it.

(For the mechanical drafting I leaned on Claude — it's good at following a strict, rule-heavy prompt like this. The prompt design was the work; the generation was the easy part.)

The ceiling no prompt gets past

Here's where I have to be honest, because it's the whole point.

Every technique above improves how the review reads. None of them improves whether it's true. You can make AI text sound like a person who used the product for three months. You cannot make it into a person who used the product for three months.

The things that make a review actually worth reading — how it held up after real use, the specific way it failed that the product page never mentions, the exact measurement, the photo of the thing dirty and dented on your kitchen floor — the model doesn't have any of that. If you let it fill those gaps, it invents them, and now you're not writing a thin review, you're writing a confidently false one. That's worse.

So the line I settled on: AI drafts and structures; a human supplies the experience. The prompt produces a clean, specific, human-sounding skeleton. Then someone who has actually handled the product fills in the parts only use can produce — and cuts anything the draft asserted that isn't true. On a pet site especially, where people make decisions that affect an animal's health, getting that division wrong isn't a style problem.

This also happens to line up with where search is going. Google's "helpful content" push is explicitly hunting for first-hand experience and demoting content that's generated to rank. A pile of fluent, experience-free reviews is exactly the target. The fluency was never the moat. The experience is.

That's the workflow behind pawpry.com — AI for the draft, a real person for the parts that matter. The prompt engineering got me a better starting line, not a finish line.

The takeaway

If you're using AI to draft content, spend your effort on the prompt, not on editing the output into shape afterward — a good prompt prevents the AI smell, late editing only masks it. But know exactly what the prompt can and can't buy you. It buys readability. It does not buy experience, and the moment you ask it to fake experience, you've built the thing everyone — readers and search engines alike — is learning to filter out.

Solo indie dev, writing these up as I go. If you've found prompt tricks that kill the AI tone, I'll take them — and I'm curious where everyone else draws the human-in-the-loop line.

From ASP.NET + MSSQL to PHP + MySQL: Migrating a Names Site Without Mangling the Accents

Marvin Tang — Sat, 30 May 2026 13:05:41 +0000

My baby-name site started life on ASP.NET with a MSSQL backend. It worked. The reason I rewrote the whole thing in PHP + MySQL had nothing to do with the code being bad — it was everything around the code.

This is the migration writeup: why I left a stack that was technically fine, the MSSQL → MySQL gotchas that actually cost me time (the worst one was thematically perfect for a names site), and what the new stack let me build that the old one was quietly blocking.

The real reason: hosting, not code

ASP.NET is a perfectly good framework. The problem is its habitat. For a solo dev shipping small sites:

Windows hosting is scarce and pricier. The cheap, plentiful end of the hosting market is overwhelmingly Linux/LAMP. Windows + IIS plans are fewer, cost more, and the budget ones I could find were the least stable.
The servers were worse. More downtime, slower support, fewer knobs I was allowed to touch.
Changes were awkward. Deploying and tweaking a .NET app on shared Windows hosting was consistently more friction than scp + a PHP file on a LAMP box.

PHP + MySQL inverts all three: hosting is everywhere, it's cheap, the quality bar at the same price is higher, and extending the site later is far less ceremony. For a content/data site I plan to keep adding to, "easy to extend on cheap, stable hosting" beats "technically elegant on expensive, fragile hosting" every time.

So the port was a means to an end. The end was the database.

The schema migration: MSSQL → MySQL

A names site is mostly database. The dictionary is ~19,862 names; the popularity layer is 63,890 US Social Security Administration records spanning 1880–2024; the geographic layer is ~6.5M state-level rows. Porting that is where the work lived.

The type and syntax mapping that mattered:

MSSQL                      ->  MySQL
-------------------------------------------------------
INT IDENTITY(1,1)          ->  INT AUTO_INCREMENT
NVARCHAR(n)                ->  VARCHAR(n)        (utf8mb4)
NVARCHAR(MAX)              ->  TEXT / LONGTEXT
BIT                        ->  TINYINT(1)
DATETIME2                  ->  DATETIME
GETDATE()                  ->  NOW()
ISNULL(x, y)               ->  IFNULL(x, y) / COALESCE
LEN()                      ->  CHAR_LENGTH()
[bracketed].[columns]      ->  `backticked`.`columns`
SELECT TOP 10 ...          ->  SELECT ... LIMIT 10
... OFFSET n FETCH m       ->  ... LIMIT m OFFSET n
a + b   (string concat)    ->  CONCAT(a, b)

None of these is hard individually. The cost is that they're scattered through every query and stored procedure, so a "find and replace" mindset misses things — especially string concatenation with +, which silently becomes numeric addition in MySQL instead of erroring.

The collation trap (where the accents died)

Here's the one that bit me, and it's almost funny that it happened on a names site of all things.

Names are full of non-ASCII characters: José, Zoë, Renée, François, Søren. The original MSSQL database stored these fine under its own collation. When I did the first bulk import into MySQL, a chunk of names came back as Jos?, Ren?e, or worse — mojibake like JosÃ©.

Two separate things were wrong:

The column character set. Defaulting to utf8 in MySQL is a trap — historical MySQL utf8 is only 3 bytes and can't store the full Unicode range. The correct choice is utf8mb4 with a utf8mb4_unicode_ci (or 0900_ai_ci) collation, end to end: table, connection, and client.
The import encoding. Exporting from MSSQL and loading into MySQL without pinning the encoding on both sides re-interpreted the bytes. The fix was exporting as UTF-8 explicitly and telling LOAD DATA INFILE the same with CHARACTER SET utf8mb4.

The lesson I'd tattoo on past-me: set utf8mb4 on the database, the table, and the connection (SET NAMES utf8mb4 / PDO charset=utf8mb4) before importing a single row. Fixing encoding after the data's already mangled means re-importing from source, because you can't always tell a correctly-stored é from a double-encoded one after the fact.

Moving 6.5M rows

For the bulk data — especially the state-level records — row-by-row inserts were a non-starter. The path that worked:

Export each MSSQL table to UTF-8 CSV.
LOAD DATA INFILE into MySQL with the charset pinned, indexes added after the load (building indexes during a multi-million-row insert is dramatically slower).
Spot-check a sample of accented names against the source before trusting the whole load.

The app layer

The PHP rewrite itself was the least surprising part. Data access went from ADO.NET to PDO with prepared statements (parameterized everywhere — a data site is a giant SQL-injection surface if you're lazy). Paging went from OFFSET/FETCH to LIMIT ... OFFSET. The routing and templating got rebuilt but conceptually mapped one-to-one.

I'll be honest that I leaned on Claude to accelerate the mechanical parts of the port — translating stored-procedure logic and grinding through the query rewrites. It's good at the tedious 1:1 translation; the judgment calls (the collation decision, the index-after-load ordering) were still mine to get wrong first.

What the new stack unlocked

Here's the payoff, and the reason the migration was worth it. On the old stack, every new feature was a fight with the hosting. On PHP + MySQL, adding to the site got cheap enough that I could turn a static name dictionary into something closer to a data product:

Query-driven tools straight off the SSA tables — popularity by birth year, year-over-year trending movers, a name → US-state lookup over those 6.5M rows, side-by-side comparison of two names across 145 years.
Research reports generated from the same dataset — decade-by-decade breakdowns, per-state rankings, long-arc analyses like which mid-century names have effectively gone extinct.

None of that was impossible on the old stack. It was just expensive and annoying enough that I never did it. That's the quiet cost of a high-friction stack: not the features you can't build, but the ones you don't bother to.

You can see where it landed at 9babynames.com. The migration is invisible to visitors — which is exactly the point.

Solo indie dev, writing these up as I go. If you've done a MSSQL → MySQL move, I'm curious whether the collation/charset step bit you too, or whether I just walked into it.

I Cloned My Dog-Name Site to Build a Cat-Name Site. The Routing Layer Bit Back.

Marvin Tang — Wed, 27 May 2026 07:36:06 +0000

I run a dog-name site. A few weeks ago a reader emailed asking the obvious question: "Do you have one for cats?"

I didn't. But I had a fully built PHP content site sitting right there — browse names by breed, by origin, by color, by size; a name-detail page for every entry; clean URLs all the way down. Cats are just dogs with a different attitude and a smaller breed list, right? I figured I'd clone the whole thing in an afternoon.

It did not take an afternoon. And the part that ate the time wasn't the data or the templates — it was the routing layer. This is the story of what doesn't copy over when you "just clone" a content site, written down so the next person (or future me) doesn't repeat it.

The shape of the thing

Both sites are plain PHP — no framework. Every page is a file under pages/, and a clean URL gets rewritten to it with a query string. So /breeds/letter/a/page/2 becomes pages/breeds.php?letter=a&page=2. Nice URLs for users and search engines, ordinary PHP underneath.

The catch is that the rewrite has to happen in two completely different places, because the site runs in two completely different environments.

In production it's Apache, so the rules live in .htaccess:

# /breeds, /breeds/letter/{a}, /breeds/page/{n}
RewriteRule ^breeds(?:/letter/([a-z]))?(?:/page/(\d+))?/?$ pages/breeds.php?letter=$1&page=$2 [L,QSA,NC]

Locally I develop with PHP's built-in server (php -S localhost:8080 router.php), which knows nothing about .htaccess. So the same route has to exist again, as a preg_match in router.php:

if (preg_match('#^/breeds(?:/letter/([a-z]))?(?:/page/(\d+))?/?$#i', $uri, $m)) {
    $_GET['letter'] = $m[1] ?? '';
    $_GET['page']   = $m[2] ?? '';
    require __DIR__ . '/pages/breeds.php';
    return true;
}

One logical route, two physical definitions. On a single site that's already a low-grade tax: every time I add a route I edit two files and keep two regexes in sync. It works, I'd made my peace with it.

Cloning doubled the tax into something worse

Here's the thing I didn't think through before I copied the folder. The site has dozens of routes — name detail, categories, the dictionary, search, comparison pages, a pile of 301s for legacy URLs. Each one already lived in two places. Clone the site, and now every route lives in four places, across two repos.

The first time I added a cat-specific route, I added it to the cat site's .htaccess, tested it on production, and it worked. Then a week later I went to test something locally and got a 404 — because I'd never mirrored that rule into the cat site's router.php. The local and production routing had silently drifted apart. On the dog site I'd trained myself to edit both. On the fresh clone, I hadn't built that muscle yet, and the duplication just quietly rotted.

That's the trap with cloning: you copy the code, but you don't copy the discipline the code silently depends on.

What actually didn't transfer

Beyond routing, a few assumptions I'd hardcoded for dogs leaked through:

Breed counts. The dog site assumes a long breed list with its own pagination thresholds. Cats have far fewer recognized breeds, so pages that were comfortably full on one site looked empty on the other. The layout "worked" but felt broken.
Category vocabulary. "Working dogs," "herding," "guardian" — none of that maps to cats. The category system was generic enough to run with cat data, but the seed categories were dog-shaped, so half of them were nonsense until I redid them.
Copy and microcopy. Every "your new puppy" string. Cloning finds these the hard way, one user-facing typo at a time.

None of these were hard. They were just invisible until real data hit them — which is exactly the kind of thing a clone hides from you, because the code compiles and the page renders. It's the content that's wrong, and content doesn't throw exceptions.

What I'd do instead (and am slowly refactoring toward)

The honest takeaway: I shouldn't have cloned a site. I should have built one engine and two instances.

Concretely, the routing table should be defined once, as data, not twice as code:

// routes.php — single source of truth
return [
    ['pattern' => '#^/breeds(?:/letter/([a-z]))?(?:/page/(\d+))?/?$#i',
     'page'    => 'breeds.php',
     'params'  => ['letter', 'page']],
    // ...
];

router.php loops over that array for local dev. And a small build script can generate the .htaccess rewrite block from the same table for production. One definition, two consumers — instead of four hand-maintained copies. The entity ("dog" vs "cat") becomes a config value: breed list, categories, and copy strings get injected, while the engine stays identical.

I'm not all the way there yet — the cat site shipped on the cloned codebase because shipping beat refactoring. But every route I touch now, I move into the shared table instead of duplicating it. The fork is slowly converging back into an engine.

If you want to see the two instances side by side, the cat site is live at icatnames.com and the original dog site it grew out of is idognames.com — same bones, different animal, and (now) a slowly shrinking amount of duplicated routing.

The lesson in one line

Cloning copies your code but not the invisible discipline it relies on. If a site has any duplicated-but-must-stay-in-sync layer, a clone doesn't double your maintenance — it squares it.

How do the rest of you handle dev-vs-prod routing parity without a framework? I'd genuinely like to hear if there's a cleaner pattern than "generate one from the other."

Cocos Creator 2D Physics on iOS: Notes on Fixed Timestep, ProMotion, and CCD

Marvin Tang — Sun, 17 May 2026 09:56:26 +0000

Cocos Creator's 2D physics looks solid in editor preview. Bouncing balls behave. Collisions trigger. Frame rate sits at 60. Then you ship to iOS, install on an actual device, and small things start to feel off — a ball that occasionally tunnels through a thin wall, gameplay that feels subtly faster on newer iPhones, a stuck collision after the user backgrounds the app and reopens it.

None of these are obvious bugs. They're the result of how the engine's physics interacts with iOS-specific runtime behavior that doesn't show up in desktop testing.

After shipping a 2D physics-based ricochet game built on Cocos Creator 3.x to the App Store, here's the short list of things I'd configure differently if I were starting over.

1. ProMotion silently changes your simulation

iPhone 13 Pro was the first iPhone with ProMotion, and every Pro model since has it. ProMotion means the display refreshes at up to 120Hz. WebViews and native runtime loops driven by CADisplayLink follow that refresh rate, which means requestAnimationFrame — and the Cocos Creator game loop bound to it — can fire up to 120 times per second on these devices.

If your physics integration uses the per-frame delta time directly — velocity += accel * dt; position += velocity * dt — your simulation now runs at a different effective resolution on a 120Hz device than on a 60Hz device. Same starting state, same input, slightly different physical outcome. Players on newer iPhones experience a subtly different game.

The fix is to lock physics to a fixed timestep, decoupled from rendering. In Project Settings → Physics 2D, set the Fixed Time Step explicitly (1/60s is the standard choice):

import { PhysicsSystem2D } from 'cc';

PhysicsSystem2D.instance.fixedTimeStep = 1 / 60;

Rendering still happens at whatever rate the device offers. Physics ticks at 60Hz regardless. Behavior becomes consistent across devices.

2. Don't integrate with variable dt

Even on a constant 60Hz display, the actual frame interval can vary — a thermal-throttled iPhone can drop to 45fps mid-game, or hit 30fps if other apps are competing for CPU. The classic accumulator pattern handles this without breaking the simulation:

const FIXED_DT = 1 / 60;
let accumulator = 0;

update(deltaTime: number) {
  accumulator += deltaTime;
  while (accumulator >= FIXED_DT) {
    this.stepPhysics(FIXED_DT);
    accumulator -= FIXED_DT;
  }
  // Optional: interpolate render position using accumulator / FIXED_DT
}

Cocos Creator's built-in physics system does this internally once you configure a fixed time step. But if you're running any of your own integration — custom forces, custom motion on non-rigidbody entities, gameplay logic that touches positions — apply the same pattern there. The moment any part of your simulation uses raw deltaTime, you've reintroduced the inconsistency you just fixed.

3. CCD is not on by default, and you usually want it

A ball moving at 1000 px/s in a 60Hz simulation moves about 16.7 px per frame. If your wall collider is 10 px thick — or your ball is small and your wall is at an angle — there's a real chance the ball is in front of the wall on frame N and behind it on frame N+1, with no collision detected in between.

Discrete collision detection misses these. The fix is continuous collision detection, which in box2d terms means setting the bullet flag on the rigid body:

const rb = this.getComponent(RigidBody2D);
rb.bullet = true;

Two things to know:

CCD has a real CPU cost. Apply it only to bodies that actually move fast — typically the player projectile, not every dynamic body in the scene.
It only protects against passing through static and kinematic bodies. Two CCD-enabled dynamic bodies can still miss each other under box2d's defaults.

If you have geometry that's both fast-moving and dynamic-on-dynamic, supplement with manual raycasts between frames. Sample the start and end positions, fire a raycast along that segment, snap to the first hit.

4. Touch input lands later than you think

A user taps the screen. The native touch event arrives at the WebView. WebView forwards it to JavaScript. Your input handler runs. Cocos Creator's event system dispatches it on the next tick. Your physics responds on the tick after that.

That's two to three frames of latency between the finger landing and the ball reacting. At 60Hz that's 33-50ms — noticeable in a precision physics game where the player is reading visual feedback to aim.

You can't eliminate the WebView → JS hop, but you can avoid adding more delay:

Don't queue input into a buffer that's drained on the next physics tick. Handle it in the same tick if the input affects current-frame simulation.
For aiming-style mechanics, render a preview of the trajectory the moment the touch starts, and only commit to a physics force on release. The visual responsiveness masks the input lag — by the time the player releases, they've already been seeing what would happen.

5. Background/foreground destroys your physics state

When the user switches to another app and comes back, the JS event loop has been suspended for an arbitrary duration — seconds, minutes, hours. The next update() call receives a delta time that reflects that entire pause.

If you pass that delta unfiltered into your physics step, the accumulator from section 2 runs hundreds or thousands of fixed steps in a single tick. The game freezes for a moment, then resumes with the ball teleported across the level — through walls, past triggers, anywhere.

Two complementary fixes:

// Clamp delta to prevent runaway accumulation
update(deltaTime: number) {
  const safeDt = Math.min(deltaTime, 0.1);
  // ... use safeDt for physics
}

// Pause physics on visibility change
document.addEventListener('visibilitychange', () => {
  PhysicsSystem2D.instance.enable = !document.hidden;
});

The clamp protects you from runaway dt. The visibilitychange handler is cleaner — physics genuinely shouldn't tick when the user can't see the game. Use both.

6. Determinism is fragile, and you probably don't need it

If you ever want replay validation, network sync, or "the same level always plays out the same given the same input," you need deterministic physics. Floating-point math across iOS device generations — and especially across iOS vs Android — is not guaranteed to produce bit-identical results, even with a fixed timestep.

This is solvable: fixed-point math, integer-only simulation, or running physics on a server. Each path is heavyweight.

For most single-player physics games, the right answer is to not need determinism. Save state snapshots instead of replays. Validate completion server-side based on outcomes (level cleared, score reached) rather than exact motion paths. Build replay sharing as a video, not a deterministic simulation.

Pre-ship checklist

Before submitting a Cocos Creator 2D physics game to App Review, I'd now check:

Physics fixed timestep is set explicitly, not left to default
Fast-moving rigid bodies have bullet = true
Input handlers process within the same tick as the affected physics step
deltaTime is clamped, and physics pauses on visibilitychange
Tested on at least one ProMotion device (iPhone 13 Pro or later) and one older device

None of this is obscure. It's just easy to miss when desktop preview looks perfect.

The game these notes come from is Juicy Ricochet — playable in the browser at phyfun.com or as a native iOS build on the App Store. Most of what's above is the result of behavior I didn't see until I was running on a real iPhone in real hands.

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.

DEV Community: Marvin Tang

I Rewrote One AI Prompt 15 Times to Kill the "AI Smell" in Product Reviews

Why the first prompt failed

What actually worked

The ceiling no prompt gets past

The takeaway

From ASP.NET + MSSQL to PHP + MySQL: Migrating a Names Site Without Mangling the Accents

The real reason: hosting, not code

The schema migration: MSSQL → MySQL

The collation trap (where the accents died)

Moving 6.5M rows

The app layer

What the new stack unlocked

I Cloned My Dog-Name Site to Build a Cat-Name Site. The Routing Layer Bit Back.

The shape of the thing

Cloning doubled the tax into something worse

What actually didn't transfer

What I'd do instead (and am slowly refactoring toward)

The lesson in one line

Cocos Creator 2D Physics on iOS: Notes on Fixed Timestep, ProMotion, and CCD

1. ProMotion silently changes your simulation

2. Don't integrate with variable dt

3. CCD is not on by default, and you usually want it

4. Touch input lands later than you think

5. Background/foreground destroys your physics state

6. Determinism is fragile, and you probably don't need it

Pre-ship checklist

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

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

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

4. `preventDefault` aggressively (but not indiscriminately)