DEV Community: glebr2d2

Unity, Godot, or my own engine? Why my card games are plain TypeScript" published: false tags: gamedev, reactnative, typescript, showdev

glebr2d2 — Mon, 05 Oct 2026 09:13:32 +0000

For a couple of weeks I couldn't decide how to build my card game app: pick a ready-made engine, or write my own code.

On one side were real game engines: Unity, Godot, the usual suspects. On the other was the slightly crazy option of writing it myself in TypeScript on top of React Native. This post is about why I ended up with the crazy option, what it gave me, and what it cost.

The app is called Decks. It's on iOS now with fourteen games: nine solitaires (Klondike, Yukon, Spider, FreeCell, Pyramid, TriPeaks, Golf, Black Hole, Spanish Solitaire) and five puzzles (Codebreak, Triples, Memo, Tower of Hanoi and a two-tower variant).

The idea came from Board Game Arena
I play on Board Game Arena myself, and that's where the inspiration came from. Not any single game on it, but the idea that one platform carries hundreds of them. I wanted the same kind of platform for card games: one engine, many games.

That goal decided almost everything. If the plan is "many games", then the worst thing I can do is write each game as code. Fifteen games written as fifteen implementations is faster for the first two and slower for every one after that.

So in Decks a game is a JSON document, and the engine is an interpreter for it. The engine doesn't know the name of any game it plays.

Why I didn't pick an engine
I didn't decide on paper. I built a prototype in Godot first, and two things didn't work for me: the app came out heavy and slow to launch, and the game rules were hard to test separately from the rendering.

When I looked at what my games actually are, the picture was simple. Cards are flat rectangles. A flip is a scale along one axis with the face swapped at zero. A fan is a rotation around a point outside the card. When I wrote the rendering decision down, I literally noted that WebGPU and 3D engines were considered and rejected: the problem is flat, and the pseudo-3D comes from matrices for free.

What a card game does need is everything around the table: menus, settings, rules pages, text that grows with the system font size, native purchases. An app framework gives you those.

And the heart of the project isn't rendering at all. It's the rules. I wanted rules I could run a thousand times in a test, from a seed, with no screen attached. That pushed me toward a stack where the rules are just code in a plain language with nothing underneath.

I should admit that before Decks I had almost no React Native experience. I learned it along the way.

What I picked
The repo has three packages:

game-core: the rules engine. Pure TypeScript.
tokens: design tokens, just numbers and hex colors.
mobile: the app, built with Expo, React Native, React Native Skia and Reanimated.
Dependencies point inward only. mobile knows about game-core; the reverse is forbidden, and the linter checks it.

Advantage 1: a core with zero dependencies
This is the package.json of the engine, trimmed to the relevant fields:

{
"name": "@deck/game-core",
"description": "Pure core: state, moves, rules interpreter, AI. Zero runtime dependencies, zero DOM, zero React.",
"dependencies": {},
"devDependencies": { "vitest": "^3.2.4", "@types/node": "^22.0.0" }
}
(My docs are actually in Russian; I translated the description for this post.)

ESLint forbids the core from touching React, the DOM, the platform, Math.random and Date.now. Randomness and time come in as parameters.

That one rule pays off over and over:

The same core runs in Node and on the phone. Tests don't mock a game engine, because there is none. The last test runs in the 1.0.3 cycle were about 1,650 core tests and about 5,000 app tests.
Any bug becomes a seed. My project rules say every bug is reproduced as "seed + sequence of moves", and that pair becomes a test in the same commit. There's a tests/repro/ folder with files like 012-espanol-suit-run.test.ts. Card bugs otherwise live forever as "sometimes it happens".
Shuffles mid-game are reproducible too. The generator is mulberry32, and its state grows additively, so jumping to the n-th draw of a seed is O(1):

// packages/game-core/src/model/rng.ts (trimmed)
const STEP = 0x6d2b79f5
export function countingRng(seed: number, skip: number): CountingRng {
let n = skip >>> 0
const base = seed >>> 0
return {
next: () => {
n = (n + 1) >>> 0
let t = (base + Math.imul(n, STEP)) >>> 0
t = Math.imul(t ^ (t >>> 15), t | 1)
t ^= t + Math.imul(t ^ (t >>> 7), t | 61)
return ((t ^ (t >>> 14)) >>> 0) / 4_294_967_296
},
drawn: () => n,
}
}
The engine supports reshuffling in the middle of a game (say, a discard pile turned back into a stock), and that has to replay exactly too. Because of the O(1) jump, a save only needs the seed and the number of draws so far.

Advantage 2: rules are data
Here is Golf's only move rule: a card from the tableau goes to the waste if it is one rank above or below the waste's top card.

"legal": { "op": "or", "args": [
{ "op": "eq", "args": [{ "op": "sub", "args": [
{ "op": "ord", "args": [{ "ref": "sel" }, "rank"] },
{ "op": "ord", "args": [{ "op": "at", "args": [{ "op": "zone", "args": ["waste"] }, "top"] }, "rank"] }
]}, 1] },
{ "...": "the same, the other way round" }
]}
TriPeaks has the same idea, but computed mod 13, so a king and an ace are neighbours there. In Golf they aren't. That difference is a different arithmetic expression in a data file. Neither game has a code path of its own.

There's no eval and no new Function (ESLint fails the build on both). That isn't about security first. You can't ask arbitrary code "what moves are possible right now?", and hints, the "no moves left" check and the test bots all depend on listing moves.

The best proof came late. Yukon, the fourteenth game, shipped in 1.0.3. The commit says it plainly: Yukon is Klondike minus two lines (runOf, alternates), with a different deal, and "the engine and the language were not touched". It arrived with undo, hints, saving and rules text already working.

Advantage 3: one language everywhere
The app, the engine, the tests and the build-time tools are all TypeScript. The scripts/ folders are full of small solvers and measuring tools that import the very same engine. For example, the animated tables in onboarding are real games played by the engine at build time and recorded to a file. The app just plays the recording back.

Even the website is tied to the app: a script generates a manifest from the app's code (which games ship, which links the paywall uses), and the site checks its text against it.

Advantage 4: native UI where it matters
Only the table is a Skia canvas. Everything around it (menus, settings, sheets, rules) is ordinary React Native views. So VoiceOver can read them, and they grow with the system text size for free. For the 1.0.3 release I ran an automated walk at the largest accessibility text size (AX5) in five languages: 855 scenes, zero violations.

System settings like Reduce Motion, Reduce Transparency and Bold Text are read from the phone in exactly one place, and the app follows them. When I needed something React Native doesn't offer, I wrote a small Swift Expo module. There are two: StoreKit 2 for purchases, and a one-function module that reports the phone's thermal state.

Card faces aren't image files either. They're drawn once from design tokens into a Skia atlas, so fourteen games don't drag fourteen sets of card art along. The whole app is about 59 MB on the App Store.

The cost: you are the game engine now
Here's the honest part. Choosing "no engine" means you write the engine bits yourself.

Hit testing is mine. Which card is under your finger is a pure function I wrote. It once returned the first card at equal depth. In Pyramid all cards share one depth and the rows overlap by more than half, so taps went to the card behind, which had no move. My own bug report was "I tap a card and it doesn't flip the first time". The rule is now "the last one drawn wins", the same order Skia paints in.

The 60 fps budget is mine. Work is split by how often it runs. The frame (60 times a second, in a Reanimated worklet on the UI thread) only does numbers: which card, which drop zone, springs. Legal moves are computed once per touch and turned into rectangles. The rules engine is never called on a frame, and the linter enforces it:

// eslint.config.js (trimmed)
{
files: [
'packages/mobile/src/gesture//*.{ts,tsx}',
'packages/mobile/src/frame//.{ts,tsx}',
],
rules: {
'no-restricted-imports': ['error', { patterns: [{
group: ['@deck/game-core', '@deck/game-core/', '/game-core/'],
message: "Frame and gesture don't call the rules. …", // translated from Russian
}] }],
},
}
The hit-test file even duplicates a three-line CardId type instead of importing it. Not even a type import is allowed.

I learned this the hard way. My first drag wrapped each card in a conditional transform. On 52 cards that meant about 3,120 checks per second on the UI thread, and the app crashed on any touch. The fix was a single drag layer with one derived transform.

Later, Codebreak's frame rate sagged over a game (my notes say 118 → 41). It turned out to be nine layers of one problem: work that kept running after its result stopped changing. The deal animated 174 cards when 13 were visible. A font was created three times per card per frame. Now a test across all games checks that an idle table holds zero live subscriptions.

The table is invisible to VoiceOver. To the system, a Skia canvas is one big picture. I wrote it down as a real cost the player pays, not me. Spoken table play is still an open decision.

Native dependencies bite. On Expo SDK 57 the app built fine and crashed on launch with Symbol not found: JavaScriptActor.assumeIsolated. The prebuilt ExpoModulesCore 57.0.11 had been compiled against expo-modules-jsi 57.0.4, while 57.0.8 was being resolved. The fix was to declare expo-modules-core directly (~57.0.15) so the prebuilt pair matches. Prebuilt binaries don't follow semver the way source does.

Generality isn't free. A blackjack rule set I wrote (not shipped) came to 3,581 lines of JSON, because the language can't name a subexpression yet. "Hand value" is repeated 36 times. And I keep one rule ("branch on what a game declares, never on its name") by review for now. The test that would enforce it is written down as debt.

Did I ever regret not using an engine? Sometimes, mostly while I was writing touch and gesture handling myself. In the end, no regrets.

Where this is going
I started with solitaires and puzzles on purpose: they're the best stress test for the table and the language, and a good first product. But the engine was never meant to stop there. From day one the first slice was Durak and Klondike, so the language would grow with hidden hands, turns and an opponent, not only with stacks and cascades. Durak and a couple of other two-player games live in the repo as data files and just aren't on the shelf yet.

Next up are two-player games, starting with Durak, and more solitaires.

Was it worth it?
For me, yes. A new game costs a description, not a second engine, and the newest one proved it. The price is that I'm also the person who owns hit testing, frame budgets and native build quirks.

If you're a solo developer facing the same choice, my advice is simple: choose your stack for the task, not for the hype. A flat card game doesn't need a 3D engine.

If you want to see the result, the app is Decks (App Store). Happy to answer questions about the engine, Skia in the comments and for any feedback
This article was written with AI assistance, but not AI written

# How I Built a Client-Side HEIC Converter — No Server Required

glebr2d2 — Fri, 03 Apr 2026 21:32:21 +0000

Every time someone asked me to "just send the photo as JPG," I died a little inside. iPhones have been saving photos as HEIC since iOS 11, and in 2026, the format mismatch is still a daily pain point for millions of people. Most online converters ask you to upload your personal photos to some random server. I wanted to build something better: a converter that runs entirely in your browser, with zero server involvement.

Here's how I built it, what broke along the way, and what I learned about decoding Apple's image format with WebAssembly.

Why Client-Side Matters

The typical file converter architecture is straightforward: user uploads file, server processes it, server returns the result. It works, but it comes with baggage:

Privacy: Your photos hit someone else's machine. For personal photos, that's a hard sell.
Server costs: Image processing is CPU-intensive. At scale, you're paying real money for compute.
Latency: Upload + process + download vs. just... process. Locally.
Offline capability: A client-side converter works on a plane, in a coffee shop with bad wifi, anywhere.

The tradeoff is complexity. Browsers weren't designed to decode proprietary image formats. But WebAssembly changed that equation.

How HEIC Decoding Works in the Browser

HEIC (High Efficiency Image Container) is built on top of the HEVC video codec — the same tech used for 4K video. Browsers don't support it natively (except Safari, somewhat). So you need a decoder.

The pipeline looks like this:

HEIC file (ArrayBuffer)
    → libheif (compiled to WASM via Emscripten)
    → Raw pixel data (RGBA)
    → Canvas API (draw pixels)
    → canvas.toBlob() → JPG/PNG Blob
    → Download link

I used the heic-to library, which wraps libheif's WASM build into a clean async API. The core conversion is surprisingly compact:

import HeicTo from 'heic-to';

async function convertHeicToJpg(heicFile, quality = 0.9) {
  // heic-to handles WASM loading, decoding, and Canvas rendering
  const jpgBlob = await HeicTo({
    blob: heicFile,       // File or Blob
    to: 'jpeg',           // target format
    quality: quality       // 0.0 - 1.0
  });

  return jpgBlob;  // standard Blob, ready to download
}

Under the hood, heic-to loads a ~1.5MB WASM binary (libheif), decodes the HEIC container, extracts the HEVC-compressed image data, and renders the raw pixels onto an offscreen canvas. The Canvas API then does the format conversion via toBlob().

For batch conversions with multiple files, I zip the results client-side using JSZip:

import JSZip from 'jszip';

async function batchConvert(files, format, quality) {
  const zip = new JSZip();

  for (const file of files) {
    const blob = await HeicTo({ blob: file, to: format, quality });
    const name = file.name.replace(/\.heic$/i, `.${format === 'jpeg' ? 'jpg' : format}`);
    zip.file(name, blob);
  }

  const zipBlob = await zip.generateAsync({ type: 'blob' });
  // trigger download...
}

Everything stays in browser memory. No temporary files on a server, no cleanup jobs, no S3 buckets.

The Challenges Nobody Warns You About

Color Space Mismatch

This was the most insidious bug. iPhones shoot in Display P3 color space — a wider gamut than the sRGB that JPG typically assumes. When you decode HEIC and render to Canvas, the browser may or may not apply color management depending on the platform.

The result: photos that look subtly different after conversion. Slightly desaturated greens, shifted skin tones. Not wrong enough to notice immediately, but wrong enough to bother a photographer.

My solution was an optional sRGB normalization pass. After initial decoding, I re-draw through a Canvas context to force sRGB interpretation:

if (convertToSrgb) {
  const bitmap = await createImageBitmap(blob);
  const canvas = document.createElement('canvas');
  canvas.width = bitmap.width;
  canvas.height = bitmap.height;
  const ctx = canvas.getContext('2d');
  ctx.drawImage(bitmap, 0, 0);
  blob = await new Promise(resolve =>
    canvas.toBlob(resolve, `image/${format}`, quality)
  );
}

It's not perfect color management, but it handles the 90% case. I exposed it as a toggle so users can decide.

Memory Limits on Large Files

A 48MP iPhone photo in HEIC might be 8-12MB compressed. Decoded to raw RGBA pixels, that's 8064 × 6048 × 4 bytes ≈ 195MB in memory. Multiply that by a batch of 20 photos, and you're pushing browsers to their limits.

I process files sequentially rather than in parallel. It's slower, but it avoids the "Aw, Snap!" crash that Chrome shows when you blow through its memory ceiling. For files above ~80MB, I recommend the Chrome extension, which has slightly more generous resource limits.

Browser Compatibility

The WASM-based decoder works in all modern browsers — Chrome, Firefox, Edge, Safari 15+. But I hit edge cases:

Safari on iOS: Intermittent failures with certain HEIC variants that use tiling (multi-image containers). The same files decode fine on macOS Safari.
Firefox: Slightly slower WASM execution compared to Chrome's V8 engine, but functionally identical.
Older browsers: No WASM = no conversion. I show a clear error rather than failing silently.

The Chrome Extension Angle

After building the web version, packaging it as a Chrome extension was a natural next step. The core conversion logic is identical — same heic-to library, same Canvas pipeline. The extension adds convenience: right-click context menu integration, persistent settings, and one fewer tab to keep open.

The extension runs under Manifest V3 with a service worker background script. One quirk: Chrome extensions have stricter CSP (Content Security Policy) than regular web pages, so all WASM loading has to go through 'self' — no CDN loading. I bundle everything locally.

You can try both the web converter and the extension at convert.rocks — the web version is free, no sign-up, and yes, you can disconnect your internet after loading the page to verify nothing gets uploaded.

What I'd Do Differently

Start with WebP output sooner. JPG and PNG were the obvious first targets, but WebP gives you better compression than JPG with better quality. I added it later using webp-converter-browser, but it requires an extra conversion step (HEIC → PNG → WebP) that I'd architect differently from the start.

Use @jsquash for modern format support. The jSquash project provides modular WASM codecs for AVIF, JXL, and WebP with much smaller bundles (~10KB-2MB per codec vs. monolithic builds). For the next phase, I'm adding AVIF encoding and decoding — it's the next "HEIC moment" as Android and web platforms push adoption.

Consider OffscreenCanvas and Web Workers. Currently, conversion blocks the main thread during the Canvas rendering step. For large files, the UI freezes for 1-2 seconds. Moving the Canvas pipeline to a Web Worker with OffscreenCanvas would keep the UI responsive. It's well-supported now but requires restructuring the conversion flow.

Progressive rendering for batch jobs. Right now, all files convert before any results appear. A streaming approach — showing each converted file as it finishes — would feel much faster even if total time is the same.

The Numbers

The entire converter is ~15KB of application JavaScript plus ~1.5MB of WASM (loaded on demand). No framework, no build step for the web version — just vanilla JS, a CDN-loaded library, and the Canvas API. It loads in under 2 seconds on a 3G connection, and conversion takes 1-3 seconds per photo depending on resolution.

For an image format that causes daily frustration for millions of iPhone users sharing photos with Windows and Android users, a 15KB solution that runs in the browser feels like the right level of complexity.

If you're building browser-based file tools and want to compare notes, find me in the comments. I'm currently working on AVIF and JXL converters using the same client-side architecture.