DEV Community: Dhardingsea Developer

I made an idle game where the healer can't attack

Dhardingsea Developer — Mon, 21 Sep 2026 12:56:24 +0000

Mosslight is a free idle game that runs in the browser. You play a healer who cannot attack. The party fights, and your job is to keep them standing. There is no account, no ads, and the game makes no network calls.

Play it on itch.io: https://dhseadev.itch.io/mosslight
Play it on my arcade: https://play.dhseadev.online/games/mosslight/

This post covers what's in the game, and then the part I think other web devs will find useful: running one source tree on two hosts with different security rules, and the save bug my own tests missed.

What is in the game?

Version 0.3.0 has:

3 regions with 24 roads between them, and 12 creatures to meet along the way
4 classes and 6 songs
18 gifts across 5 rarities
9 materials, 7 provisions, and a sanctuary with 6 buildings
8 Insight upgrades, 7 store items, 10 titles, a 21-entry Ledger, and 15 story requests
A Sabbatical (prestige) that opens at level 50
Offline progress for up to 12 hours at half pace

All the art is SVG generated from code, and all the sound is made live with the Web Audio API. There are no image or audio files in the build.

Who can play it comfortably?

I wanted an idle game you can leave open all day without it wearing on you:

Two themes, Heather and Lantern, both checked against WCAG AA contrast
4 text sizes, a high-contrast mode, and reduced motion
Zen mode, which hides everything except the party
Full keyboard play
Ailments are marked by shape as well as color
Autosave, 3 manual save slots, and save export/import

How does one codebase run on itch.io and my own site?

itch.io gets a single self-contained HTML file. My arcade serves plain files from Cloudflare Pages. Two copies of the game would drift apart, so I keep only one.

The source lives as a normal folder: index.html, style.css, and five scripts. The arcade serves that folder as-is. A small build script turns it inside out for itch: it inlines the stylesheet and the five scripts and swaps the page's security policy. Before I changed any game code, that script's output matched the file already on itch.io byte for byte. That match is what shows the folder and the itch file come from one source.

Why didn't the itch.io file just work on my arcade?

Because of Content Security Policy, and because browsers enforce every policy a page has at the same time.

The itch.io build carried its own policy in a meta tag, allowing inline scripts:

<meta http-equiv="Content-Security-Policy" content="script-src 'unsafe-inline'; connect-src 'none'; ...">

The arcade sends one header for every page, allowing only script files from itself:

Content-Security-Policy: script-src 'self'; ...

When a page has both, the browser applies both, so a script runs only if it satisfies both rules. An inline script fails 'self', and an external file fails 'unsafe-inline'. Nothing passes, so copying the itch file over would have loaded an empty page.

The fix: on the arcade, Mosslight loads its scripts as files, and its meta tag now says script-src 'self'. I kept connect-src 'none' in the meta tag on purpose. The arcade header allows a few outside hosts for other games, and the stricter meta rule shuts those out of Mosslight's page. After deploying, I tried a fetch to one of those hosts from the live page. The browser refused it and named Mosslight's connect-src 'none' as the reason.

Combining policies can only tighten, never loosen. That works for you when you want a stricter page, and against you when two rules have nothing in common.

How do saves stay separate when every game shares one website?

Every game on the arcade shares one origin, and so one localStorage. Each game keeps its keys under its own prefix, like mosslight:. The arcade's test suite checks this for every entry, and there is no way to exempt one.

Mosslight was written for the web and saved under plain key names, so it failed those checks. Now it has a small storage adapter: it uses the arcade's namespaced storage when that is there and plain localStorage everywhere else, so itch.io behaves exactly as before. Because the arcade storage is asynchronous, the adapter reads every save key into a cache before the game boots and writes through on every save.

What bug did my tests miss?

Slot 3.

The game offers manual save slots 1, 2 and 3. My first version of the adapter loaded slots 0, 1 and 2 at boot. On the arcade, anything in slot 3 would have looked empty after every reload. My test only saved to slot 1, so everything passed.

A panel of three reviewers found it. Each one read the change against a short spec, without seeing my reasoning. They also found three smaller problems:

a boot error that would have been silently swallowed
a failed read that could have let a new game save over a real one
a slot that showed as full when storage was blocked

All four are fixed. The list of slots to load now comes from the same constant the Settings screen draws its buttons from:

var SLOTS = [1, 2, 3];

The test no longer types slot numbers. It reads them from the page.

How do I know the new test actually works?

I watch it fail first. A test that has never gone red on a broken build proves nothing when it goes green.

Mosslight's save test has 15 checks. Before trusting it, I ran it against three broken versions:

the original itch.io code failed 5 checks
the slots 0-to-2 draft failed exactly 1
a build that crashes on boot failed 7 and named the error

Then the real version passed all 15. After that I still opened the game in both themes and looked at it, because several bugs on my site have passed every automated check and only showed up on screen.

What is not done yet?

Mobile layouts are tested in a browser at phone sizes, not on actual phones.
There is no cloud save. A save lives in the browser you play in, so a save on itch.io doesn't follow you to the arcade. Export and import move it by hand.
Cinder Steps is the last region for now.
Pet swapping, song loadouts and a codex are designed but not built.

I cut my Claude skill registry from 89 skills to 38 without deleting a rule

Dhardingsea Developer — Sat, 19 Sep 2026 22:42:30 +0000

In early August I trimmed my Claude skill registry from 107 skills to 80. By mid-September it had grown back to 95 folders, 89 of them custom skills I wrote. This time I went further: 89 custom skills became 38, and not one rule was deleted.

This post covers how the merge worked, how I checked it, and what it did not fix.

Why did 89 skills become a problem?

A Claude skill is a folder with a SKILL.md file. The body loads only when the skill fires. The description loads every turn, for every skill, whether it fires or not.

With 89 custom skills, those descriptions added up to 70,918 characters in every conversation. That is roughly 17,700 tokens by the usual four-characters-per-token estimate, spent before I typed anything.

Size was not the part that kept biting me, though. The repeat failures were contracts split across two files. One skill wrote a field that another skill read, and the two drifted apart. A gate's check count was quoted in three places with three different numbers. Pairs of skills that had to deploy together got uploaded one half at a time. Every one of those failures lived in the gap between two files.

How do you merge skills without losing what they do?

I stopped treating a skill as the unit and started treating a mode as the unit.

Each merged skill holds the full, unedited body of every skill folded into it, one per # Mode: section. A table at the top lists the modes and says which section to read. Routing names a skill and a mode together, like verify:claim or run-control:loop.

The result:

31 merged skills and 7 that stayed on their own
107 documented modes
80 old skill folders retired

Most merge boundaries follow those split contracts. The state board and the loop that writes to it became one skill, run-control. The pre-ship gate and its extension-specific checks became one skill, preship, so there is only one place a check count can live. Claim verification and "can this measuring tool fail?" became two modes of verify. The instrument check had failed to fire nine times in a row as a separate skill.

How do you rename 80 skills without breaking every reference?

Skills reference each other constantly, so every old name had to point at its new skill:mode token.

The repoint followed four rules:

Rewrite names in live instructions only.
Leave code blocks alone.
Leave changelog history alone, because history should name what it was.
Leave headings alone, because other skills find sections by heading text.

The router also got a legacy table mapping all 80 old names to their new tokens. An old name or slash command still resolves.

The first pass missed something. It only rewrote names nine characters or longer, to avoid false matches on short words. Two short names, run-loop and html-css, survived as plain words in 62 places. A review after install found them, and a patch, not yet installed, fixes them.

How do you prove nothing was lost?

I did not trust my own reading of 89 files. I wrote a gate and made it prove itself before I trusted it.

It checks nine things for every skill:

The frontmatter parses.
The name matches the folder.
The description is under the 1,024-character limit.
The version matches the highest changelog entry.
Code fences are balanced.
No changelog table is broken.
No old skill name remains in live text.
Every heading from every source still exists.
Every source body appears word for word in its merged skill.

Before trusting any check, I broke a copy on purpose and confirmed the check went red. A heading renamed, a line edited, an old name planted, a description padded past the limit. Each check had to catch its own failure first.

That habit paid off twice. The old-name check had a blind spot: its exemption for mode tables spread across table columns, so an old name in any table row could hide. I found it because two nearly identical rows scored differently. Later, a rebuild read my own merged python skill back in as one of its sources, because the stale file copy held two folders with that name. A tripwire now refuses any already-merged file as input.

What did it buy?

Per-turn skill descriptions went from 70,918 characters to 33,962, a 52% cut.
My standing instructions file drops from 6,837 characters to 3,881 in the rewrite, a 43% cut. Rules a skill already enforces now live only in that skill.
Every one of the 38 skills and every mode token has at least one route in the router.
31 platform and vendor skills that had no route get one in the pending patch, each with a boundary against the custom skill it could displace.
The registry is capped at 50. A new capability becomes a mode on an existing skill first.

What did it cost, and what is not done?

Load cost moved from every turn to trigger time. Six merged skills are over 80 KB, and when one fires the whole file loads. The next step is to split those into one reference file per mode, so a trigger loads only the mode it needs.

Install state is not fully confirmed. The file copy my chat sessions read lags the account, so the check that the installed versions match the build still has to run in a fresh session. One updated skill cannot be confirmed from its description at all.

64 section references in prose were already unresolved before the merge and still are. The merge added none, and I have not claimed them fixed.

Would I do it again?

Yes, but for the right reason. Last time I trimmed skills expecting better routing, and found nothing in my failure log that the skill count had caused. This time the goal was different: fewer cross-file contracts, a smaller always-on load, and the same abilities behind a clearer address. On those three measures, it held.

The Underrated Superpower of Games — Why I Built Creature Camp

Dhardingsea Developer — Fri, 18 Sep 2026 21:21:17 +0000

The screenshot on my phone is always the same: a small fox with a flower crown sitting by a stone. Her name is Ember, and she doesn't do anything particularly useful. She just exists in my browser, wandering around a camp with other woodland creatures, occasionally befriending a raccoon or stealing a snack.

Building Creature Camp changed how I think about what games can actually do for us. And I think developers are sleeping on this.

The Problem With "Productivity"

We're all drowning in optimization. Every app wants to make us better, faster, smarter. Every break is monitored. Every minute has to count. And somewhere in that relentless efficiency, we started treating anything that doesn't move us toward a goal like we're wasting time.

Games got caught in the crossfire. They became "time killers" — something you do when you should be doing something else. The language alone makes them sound frivolous.

But that's backwards.

What Creature Camp Taught Me

I built this game because I needed a way to think about something outside my brain for a while. Not a distraction that rewires your dopamine and leaves you needing a reset afterward. Something that actually lets you rest while staying engaged.

The creatures just live. They wander. They interact with each other. There's no timer, no "beat the level," no achievement unlock that feels hollow the moment you earn it. You play because watching them exist is... pleasant. Calming. Your brain gets to be present without having to perform.

But here's where it gets interesting: while your brain is busy being calm, something sneaky happens. You notice patterns in how creatures befriend each other. You start thinking about what the next friend should look like. You find yourself imagining the camp differently tomorrow. Your hands relax, but your mind doesn't stop — it just stops grinding.

That's the real value. Not the distraction. The insight that comes because you're not frantically trying to extract it.

Why This Matters For Developers

We're the worst at this. We game hard — we optimize every mechanic, chase completion, speed-run everything. But somewhere between building systems and perfecting them, we forgot that the best ideas don't come from intensity. They come from that weird space where your attention is lowered but not off.

Games can be that space. Not the ones designed to extract your time, but the ones designed to give it back to you.

Creature Camp isn't a game that competes for your focus. It's one that plays alongside your actual life. You come back because you want to see what Ember's doing today. Not because the algorithm told you to.

Building it taught me something I should have known: the most valuable tool you can create isn't always the one that solves a problem faster. Sometimes it's the one that lets you breathe while you're solving it.

Every creature I drew in code, every small interaction, every choice to make nothing require energy — that was a small argument for your right to rest.

And somehow, building that argument made me better at my actual work.

If you want to wander a woodland camp with some creatures (and maybe pet a fox wearing a flower crown), you can play Creature Camp for free at play.dhseadev.online. It's offline, no accounts, no data leaving your browser. Just you and a camp that's waiting to see what tomorrow brings.

From Python Script to .exe: Building Batch PDF Tools That Users Actually Want to Run

Dhardingsea Developer — Thu, 17 Sep 2026 13:24:42 +0000

I've spent the last few years building internal tools for a legal process serving company. Some of them are Python scripts that only I use. Others are tools that filing staff need to run daily. Those tools taught me something: the easiest Python script is worthless if it requires the user to open a terminal.

This post is about the complete pipeline: writing Python tools for PDF manipulation, packaging them as standalone .exe files, and automating the build process so you can iterate without friction.

Let's build a real tool: a batch PDF page extractor that processes an entire folder of documents when you double-click it.

The Problem: From Manual to Bulk

Early on, we built a tool to extract the first page of PDFs—useful for forms processing. It worked fine as a Python script if you dragged a file onto it. But then the ask came: "Can it process a whole folder at once?"

That simple question exposed the real challenge: batch processing and user experience are inseparable. A tool that works on one file is a toy. A tool that scans a folder, processes everything, and shows results? That's infrastructure.

Part 1: Writing the Tool (PyMuPDF)

Let's start with a simple but practical example: extracting the last page of PDFs. You could use PyPDF2 or pdfplumber, but PyMuPDF (fitz) is faster, lighter, and handles edge cases better.

Here's the core:

import fitz  # PyMuPDF
from pathlib import Path

def extract_last_page(input_pdf: str) -> bool:
    input_path = Path(input_pdf)

    if not input_path.exists():
        print(f"  ✗ Not found: {input_pdf}")
        return False

    try:
        doc = fitz.open(input_pdf)
        page_count = len(doc)

        if page_count == 0:
            print(f"  ✗ No pages in: {input_pdf}")
            doc.close()
            return False

        # Create new PDF with only the last page
        new_doc = fitz.open()
        last_page_num = page_count - 1
        new_doc.insert_pdf(doc, from_page=last_page_num, to_page=last_page_num)

        # Save as <name>_last_page.pdf
        stem = input_path.stem
        output_name = f"{stem}_last_page.pdf"
        output_path = input_path.parent / output_name

        new_doc.save(output_path)
        new_doc.close()
        doc.close()

        print(f"  ✓ {input_path.name} (page {page_count})")
        return True

    except Exception as e:
        print(f"  ✗ {input_pdf}: {e}")
        return False

Why this approach:

fitz.open() is fast and memory-efficient
insert_pdf() copies pages without re-encoding—critical for large PDFs
Return boolean so caller knows if it succeeded
Descriptive output (checkmarks, file names) for user feedback

Part 2: The UX Layer—Folder Scanning

Here's where we separate "works for me" from "works for staff":

from pathlib import Path

def process_folder() -> None:
    """Scan current folder for PDFs and process all."""
    cwd = Path.cwd()
    pdf_files = sorted(cwd.glob("*.pdf"))

    if not pdf_files:
        print(f"\nNo PDF files found in: {cwd}")
        input("Press Enter to exit...")
        return

    print(f"\nFound {len(pdf_files)} PDF file(s)")
    print(f"Processing...\n")

    success = 0
    for pdf_file in pdf_files:
        if extract_last_page(str(pdf_file)):
            success += 1

    print(f"\n✓ Processed: {success}/{len(pdf_files)} files")
    input("Press Enter to exit...")

Key design decisions:

Path.glob("*.pdf") finds all PDFs in the current directory—no config needed
sorted() ensures predictable order (matters when staff review output)
Two usage modes:
- No args: scan folder (double-click scenario)
- Args: process dropped files (drag-drop scenario)
input("Press Enter...") pauses so users see the results—critical on Windows where console windows close instantly

The main script branches based on arguments:

if __name__ == "__main__":
    if len(sys.argv) == 1:
        process_folder()  # Double-click: scan & process all
    else:
        process_arguments(sys.argv[1:])  # Drag-drop: process these

This is invisible complexity. Users see one tool with two behaviors. The code knows which one from context.

Part 3: Building the .exe—PyInstaller

Now the hard part: getting a Python script into the hands of non-technical users.

PyInstaller converts Python + dependencies into a standalone executable. No Python installation needed. One file, double-click, done.

pip install pyinstaller pymupdf
pyinstaller --onefile --console last_page_extractor.py

This creates dist/last_page_extractor.exe—a fully self-contained binary.

Why --onefile:

Users get one file, not a folder of DLLs
No "where do I put this" confusion
Simpler to version and distribute

Why --console:

Shows output (checkmarks, error messages, file count)
Windows habit: console window closes when done, giving users a natural "exit" moment
Staff can screenshot the output for auditing

Part 4: Automating the Build (The Real Lesson)

Here's where most tutorials stop. Here's where the real work begins.

The problem: Every time you fix a bug or add a feature, rebuilding is friction. Create venv, install deps, run PyInstaller, manage output. One extra step and you stop iterating.

The solution: A PowerShell script that does all of it.

$ErrorActionPreference = "Stop"
$scriptDir = $PSScriptRoot

# Find Python (works with py, python, python3)
$py = $null
foreach ($candidate in @("py -3", "python", "python3")) {
    try {
        $ver = & ([scriptblock]::Create("$candidate --version")) 2>&1
        if ($ver -match "Python 3") { $py = $candidate; break }
    } catch {}
}
if (-not $py) {
    Write-Host "ERROR: Python 3 not found" -ForegroundColor Red
    exit 1
}

# Create venv & install
Write-Host "Creating venv..."
& ([scriptblock]::Create("$py -m venv .venv"))
$pip = Join-Path ".venv" "Scripts\pip.exe"
$pyVenv = Join-Path ".venv" "Scripts\python.exe"

Write-Host "Installing dependencies..."
& $pip install pymupdf pyinstaller --quiet

# Build
Write-Host "Building .exe..."
& $pyVenv -m PyInstaller --onefile --console --name last_page_extractor last_page_extractor.py

$exe = Join-Path "dist" "last_page_extractor.exe"
if (Test-Path $exe) {
    Write-Host "SUCCESS: $exe" -ForegroundColor Green
} else {
    Write-Host "ERROR: .exe not found" -ForegroundColor Red
    exit 1
}

Wrap it in a .cmd file for Windows users:

@echo off
powershell -ExecutionPolicy Bypass -File "%~dp0build_exe.ps1"
pause

Users (or you) just double-click BuildExe.cmd and walk away. No terminal knowledge required.

Why this matters:

Removes friction: Bug found? Fix Python file, double-click build script, done. New .exe is ready.
Handles edge cases: The script finds Python (whether installed as py, python, or python3), creates a fresh venv each time, avoids dependency conflicts.
UNC path handling: If you're building from a network share, the script stages to %LOCALAPPDATA% (Windows won't run PyInstaller from UNC paths). Users never see this.
Reproducible: Every build starts fresh. No "works on my machine" surprises.

Part 5: Learnings & Best Practices

1. Two-Mode UX is Invisible Complexity

Your tool shouldn't make users think about how to use it. Detect the context (folder vs. files) and do the right thing. This is the difference between "a tool that works" and "a tool people actually use."

2. Output Matters More Than You Think

Console output is user feedback. Checkmarks (✓) vs. crosses (✗) are scannable. File names in output let users verify what happened. input("Press Enter...") is the pause button—users won't miss the result window closing.

3. PyInstaller is Fast Enough

You'll hear "PyInstaller is slow, use Nuitka." For CLI tools that run occasionally, it doesn't matter. A 2-3 second startup is fine. The complexity of Nuitka isn't worth it unless you're shipping a game or real-time app.

4. Venv Per Build, Not Shared

Some scripts reuse a venv. Don't. Create fresh each time. It adds 5 seconds, guarantees clean builds, and avoids "works on mine" errors from stale packages.

5. Build Script Ownership is Underrated

Teams ship code. Great teams ship with build infrastructure. A 50-line PowerShell script that removes friction for future you is worth more than a perfect Python module. Invest in it.

6. Console vs. GUI is a UX Choice, Not a Technical One

We use --console because staff can see results and know when to close the window. For a GUI tool, use --windowed. But don't add GUI complexity unless users need it. A good console tool beats a mediocre GUI every time.

7. Name Your Outputs Consistently

<basename>_last_page.pdf is predictable. Staff can tell at a glance what happened. Avoid generic names like output.pdf or temp_1.pdf. Your naming scheme is part of the UX.

Part 6: Scaling This Approach

This pattern scales to dozens of tools:

First tool: Do it right. Spend time on the build script.
Second tool: Copy the build script, change the filename. You've already paid the setup cost.
Tenth tool: You have a repeatable template. New tools are hours, not days.

We've built:

Batch PDF splitters (first page, last page, even pages, ranges)
Court filing fee lookups (CSV processing)
Case metadata extraction (PDF + web scraping)
File renaming utilities

All built on the same foundation: Python + PyMuPDF or similar, PyInstaller, and PowerShell build automation.

The Complete Example

Here's what you need:

last_page_extractor.py — The tool (100 lines of clear Python)
build_exe.ps1 — The build script (50 lines, copy-paste for new projects)
BuildExe.cmd — The launcher (2 lines, so non-technical users can build)

Put all three in a folder. Double-click BuildExe.cmd. Get last_page_extractor.exe in dist/.

Staff double-clicks the .exe in a folder of PDFs. All last pages extract automatically. They see results. Done.

Conclusion

The gap between "works locally" and "users can run it" is bigger than most tutorials suggest. It's not about language features or libraries. It's about:

Context-aware UX (fold vs. files—do the right thing)
Clear output (so users know what happened)
Friction-free building (so you iterate without pain)
Reproducible packaging (so it works everywhere)

A Python script plus PyInstaller plus a good build script is a complete tool. Not a prototype—a shipped product.

The legal tech space taught me that. But it applies everywhere: finance, HR, ops, QA—any role with repeatable file tasks where someone would otherwise do it manually.

Write the tool. Automate the build. Watch staff use it daily.

That's the real shipping.

What build automation patterns do you use? Comment below—I'd love to hear how others handle this.

Building Creature Camp: A Chrome Extension That Breaks the Pet Game Mold

Dhardingsea Developer — Thu, 17 Sep 2026 04:02:04 +0000

I just started working on a Chrome extension called Creature Camp — a free, offline-first pet collection game with no ads, no accounts, and no dark patterns. After shipping it, I want to talk about the technical and design decisions that made it possible.

The Premise

You click a Chrome icon and get a cozy woodland playground. A starter creature (Ember, a shy fox) greets you. As you play, you collect 24 more creatures — each with authored personality, distinct voice, and body language that responds to their mood. They interact with each other, you see what they did while you were gone, and there's a live activity feed of their conversations.

The key constraint: nothing is random about who joins your camp. Every creature unlock is deterministic.

Why I Built This

I shipped LumenReel (125 randomly-drawn critters) last year and learned that players form genuine attachment to procedural creatures when their personality is authored, not their art. Creature Camp extends that: 25 hand-authored creatures, each with personality tier, voice register, and body-language rig.

But the real driver was negative. I got tired of seeing pet games use:

Dark patterns (anxiety loops, near-miss probability)
Countdown timers designed to create FOMO
Paywalls that hide core features
Manipulative notifications
"Loss as win" framing (you lost, but it feels rewarding)

Finch proved people want pet companions (4.9★, 712K reviews). They don't need the tricks.

The Stack

No build step. No bundler. No remote assets.

manifest.json
├── service worker (background)
│   └── sw.js (game loop, unlocks, interactions)
├── side panel UI
│   ├── sidepanel.html (structural)
│   ├── sidepanel.css (Gravity Falls palette)
│   ├── creatures.css (canvas animation styles)
│   └── app.js (UI orchestration)
├── game engine
│   ├── lib/engine.js (tick, spawn, interactions)
│   ├── lib/state.js (save/load)
│   ├── lib/species.js (creature blueprints)
│   ├── lib/chatter.js (authored dialogue)
│   └── lib/unlocks.js (code redemption)
└── rendering
    ├── art/creature.js (canvas draw)
    ├── art/scene.js (background, lighting)
    └── art/bodies-a.js + bodies-b.js (creature rigs)

Everything is modules (type: "module" in manifest). No eval, no inline scripts, no unsafe CSP. MV3 compliant out of the box.

Core Design Decisions

1. Deterministic Creature Unlocks

The handoff said "no coupon-collector tail" — don't let players get stuck chasing one last creature forever.

// Creatures unlock in waves via:
// - Base roster: 20 creatures, no randomness
// - Code pack 1: 5 legendary creatures (MOSSGATHERER, LUNA, etc.)
// - Time-locked: Day 3, Day 7 reveals
// - Interaction-triggered: Thistle appears at 20 interactions

// Every unlock path is deterministic and finite.
// The collection finishes. That is the design.

I simulated 1000 playthroughs to verify: median completion is 3–4 hours of casual play. Nobody hits a brick wall.

2. Species as Immutable Data Rows

Each creature is authored once, never reordered. Every field is a design decision.

const S = (id, key, name, kind, plan, rarity, voice, rest, pack, sig, lore) =>
  Object.freeze({ id, key, name, kind, plan, rarity, voice, rest, pack, sig, lore });

export const SPECIES = Object.freeze([
  S(0, 'ember', 'Ember', 'fox kit', 'chibi', 'common', 'shy', 'shy', 'base', 'ears',
    'A small fox who watched the campfire begin, and never quite stopped watching it.'),
  S(1, 'pip', 'Pip', 'chipmunk', 'chibi', 'common', 'cheerful', 'happy', 'base', 'cheeks',
    'Keeps a seed for everyone. Has never once remembered where.'),
  // ... 23 more, each one authored.
]);

The voice field picks a personality register. The plan field routes to the right body-language rig. The sig field is the expressive channel (ears for foxes, glow for fireflies, etc.). Adding a new creature is just a new row.

3. Canvas Rendering Without Assets

Creatures are drawn in code, not loaded from sprite sheets. Each creature has a rig:

// Creature rigs define: base shape, body parts, animation channels
// Example: Ember (shy fox)
// - body: chibi quadruped
// - ears: main expression channel
// - face: mood-responsive
// - tail: gesture

// Each body part is a canvas path or composite shape
// Animation states (idle, happy, curious, sleeping) change which parts move

This keeps the extension under 2MB total. No network requests. Works offline immediately.

4. The Chatter System (Authored, Not AI)

Every interaction line is hand-written. The chatter engine has zero dark-pattern vocabulary:

// No: "You almost had it!", "One more spin!", "Come back soon!"
// Yes:
export const MEETINGS = {
  shy: [
    '{a} left a pinecone next to {b} and pretended not to have.',
    '{a} sat almost next to {b}. That counts.',
    '{a} and {b} watched the same cloud for a while.',
  ],
  cheerful: [
    '{a} taught {b} a song with no words and too many verses.',
    '{a} and {b} raced to the big rock. They both say they won.',
  ],
  // ... 8 voice registers, 50+ unique lines
};

I wrote a test that scans every string in the game for countdown language, near-miss framing, and loss-as-win phrasing. The test blocks the build if it finds any.

5. Chrome Storage Only

No cloud, no accounts, no data collection.

// All state lives in chrome.storage.local
// - Creatures (25 instances max, ~50KB)
// - Activity feed (last 50 events, ~10KB)
// - Player preferences (a few KB)

// Total: ~2MB with buffer. Well under Chrome's 10MB limit.

// Game works with browser closed. Creatures "live" offline.
// Install extension → first launch → starter creature spawns → play forever.

6. Accessibility as Baseline

Not an afterthought:

Full WCAG AA compliance (color contrast, font sizes)
Keyboard navigation: Tab through all UI, Enter/Space to activate
Screen reader: All interactive elements labeled, live regions for updates
Reduce motion: prefers-reduced-motion media query → creatures hold still
16px base font size, no font smaller than 14px
Skip link to main content

I ran through test-env-web before submission. Zero accessibility violations.

Building Without Dark Patterns

The hardest part wasn't the code. It was deciding what NOT to build.

What I didn't ship:

Hunger timers (creatures never suffer for neglect)
Login requirements (no accounts, no friction)
Randomized loot boxes (you always know what you're getting)
Paywalls hiding features (every creature is free)
Notifications pushing you back (only app-initiated, never pushed)
Daily login streaks (play when you want)
Creature "death" or permanent loss

What I did ship:

Persistent world (creatures exist when you're gone)
Visible consequences of play (creatures change mood based on care)
Discovery (unlocking creatures via codes and milestones)
Social presence (creatures interact with each other)
Cozy aesthetic (Gravity Falls woodland vibe, warm palette)

The result: people don't have to play. They want to.

Technical Wins

Storage optimization: Species data is immutable; only instances are stored. Saves ~80% of what a naive approach would use.

Deterministic RNG: Used Mulberry32 seeded with save ID + tick number. Same creatures always spawn in the same order for the same player. No "lucky" vs. "unlucky" streaks.

Animation perf: 20 creatures animating at 60 FPS without dropping frames. Profiled with Chrome DevTools; each creature takes ~3ms to render and animate.

Code size: No build step means no tree-shaking overhead. The whole extension is ~40KB of JavaScript, gzipped ~12KB.

Chrome Web Store Launch

Submitted 1.0.0 to the Chrome Web Store with:

Privacy policy (offline-only, no data collection)
Screenshots (gameplay, bestiary, creature interactions)
Icons at every size (128px down to 16px, all hand-drawn in a vector tool)
Description: "Raise woodland creatures who meet, play and chat in a cozy side-panel camp. No ads, no accounts, nothing leaves your browser."

Approval: 2 hours.

What I'd Do Differently

Font rendering: SVG text rendering is noisy on some systems. Next version will use canvas text or prerendered glyphs.
Save format: Should have versioned the save JSON from day one. Now I'm stuck with forward compatibility forever. (Don't do this.)
Code redemption UI: The modal could feel more magical. A simple sprite effect when a code is redeemed would delight players.
Creature count: 25 is perfect for v1. Next packs (via codes) should come out slowly, spaced weeks apart. Scarcity keeps discovery feeling special.

The Numbers

25 creatures: Each with unique personality, voice, lore, and body-language rig
50+ authored interaction lines: Two creatures meet every 5–10 minutes
8 voice registers: Shy, cheerful, smug, curious, sleepy, gruff, dreamy, mysterious
6 body plans: Chibi, winged, serpent, quadruped, colossus, wisp
4 rarity tiers: Common, uncommon, rare, legendary
0 dark patterns: Tested and verified

Reflection

Building Creature Camp taught me that constraints breed creativity. By refusing to add:

Timers
Notifications
Paywalls
Random loot

I had to make the core experience compelling. The creatures needed authored personality, not gacha randomness. Interactions needed to be surprising, not punishing. The aesthetic needed to be beautiful and inviting.

The result is a game where playing feels like visiting friends, not completing tasks.

Creature Camp is free on the Chrome Web Store. Install it, get a starter creature, and see what happens. The code is authored, the creatures are deterministic, and your save lives on your device forever.

If you're building a pet game or any game with progression, ask yourself: What would this look like without dark patterns? The answer might surprise you.

Tech stack recap:

Chrome MV3 extension
No bundler, no build step
Canvas rendering from code (no assets)
Deterministic economy simulation
WCAG AA accessibility
Zero external dependencies
Offline-first storage

Ship soulful software.

I Finally Got a Mac. Here's What It Taught Me About Only Building for One OS.

Dhardingsea Developer — Wed, 16 Sep 2026 01:58:20 +0000

I picked up a Mac recently. Nothing dramatic — no grand migration story, no "Windows finally broke me" moment. I just ended up with one, and it made me realize something a little embarrassing: as someone who's shipped a genuinely large number of Chrome extensions, a few desktop tools, and a browser arcade under the DHSeaDev name, I had put almost zero thought into the Apple ecosystem. Not out of dislike. It just never came up. My tools worked, my users were on what they were on, and I kept building.

So this is the post where I admit that, and talk about why "what operating system does this run on" deserves more of a developer's attention than it usually gets — even when, like me, you get lucky.

The lucky part first

Most of what I build lives in the browser. Chrome MV3 extensions are basically OS-agnostic by design — they run wherever Chrome runs, and Chrome runs everywhere that matters. So the honest first finding here is: nothing broke. I installed Chrome on the Mac, logged into my dev account, and every extension I've shipped just worked, sync and all. Same for the browser-based games and tools I've built for the DHSeaDev arcade — they're just web pages. A browser doesn't care what OS is under it, and that's a genuinely nice property to have accidentally built toward.

That's not nothing. A lot of developers find out the hard way that "cross-platform" was actually "cross-platform as long as everyone uses Windows." I got that for free because I picked a browser-first architecture years before I had a reason to care about portability. Worth remembering next time you're picking a stack for something new: the platform-independence payoff might not show up for a long time, and then one day you buy a laptop and it's already paid for itself.

Where it's not free: native desktop tools

The story changes the moment you leave the browser. I've got a handful of internal PySide6 desktop tools — things like an internal document utility suite and an analytics dashboard for my day job at a legal process-serving firm. PySide6 (Qt) is cross-platform in theory, and mostly in practice, but "runs on macOS" and "feels native on macOS" are two very different bars. Native window chrome, dark mode behavior, file dialogs, keyboard shortcuts that macOS users expect (Cmd instead of Ctrl being the least of it), and packaging are all places where a Windows-built Qt app can feel like a guest wearing someone else's coat on a Mac.

And packaging is its own adventure. On Windows I'm used to a PyInstaller build and maybe an Inno Setup installer, and I'm done. macOS wants a signed, notarized .app or .dmg if you want it to run without the user fighting Gatekeeper — that means an Apple Developer Program membership (still $99/year as of this writing), codesigning, and submitting the build to Apple's notarization service before it'll launch cleanly on someone else's machine. It's not hard, but it's a real extra step that doesn't exist in the Windows world, and skipping it means every user has to right-click-and-open their way past a scary warning dialog. That's a bad first impression for a tool that's supposed to make someone's day easier.

None of this is a complaint. It's the kind of gap you don't see until you're standing in it.

The upside: a whole platform I hadn't been building for

Here's the part I'm actually excited about. Having a Mac in hand isn't just "now I have to test on it" — it's a green light to start building for it on purpose. macOS has its own conventions, its own distribution paths (direct download and notarization, or the Mac App Store if a tool fits those rules), and its own audience that's historically underserved by a lot of indie/internal tooling that defaults to Windows-only. A menu bar utility, a proper native companion app, something built with SwiftUI instead of ported in from Qt — that's a new lane, not just a compatibility checkbox.

It also reframes how I think about my existing native tools. The PySide6 apps I've built were written Windows-first, which means "port to Mac" is really "go back and find every place I assumed Windows," and fix it properly instead of papering over it. That's worth doing even if I never ship a Mac build to anyone outside myself, because it's the kind of assumption-hunting that also quietly improves the Windows build.

The actual takeaway

If you build software and you've only ever developed on and for one operating system, it's worth asking yourself why — and whether the answer is "a deliberate architectural choice" or "I just never had a reason to check." Those are very different positions to be in. Mine turned out to be the second one, and I got lucky that my main body of work (browser-based tools and extensions) didn't care. My native desktop tools weren't so lucky, and now I know exactly where the assumptions are hiding.

Consider this your nudge, the same way mine came in a shipping box: if there's a whole ecosystem you've been building software for millions of people on without ever touching, go touch it. You'll either confirm your architecture was more portable than you gave it credit for, or you'll find the gaps while they're still cheap to fix.

Joy in the Build: What the Positivity Wall Taught Me About Making Anything

Dhardingsea Developer — Tue, 15 Sep 2026 03:54:07 +0000

I build a lot of things. Chrome extensions, games, internal tools for the day job, weird little browser experiments nobody asked for. Most of it is technical: state management, manifest permissions, load times, edge cases. But every so often a project reminds me that the point of building something isn't the stack you used — it's what it does for the person on the other end of the screen.

That's what happened with the Positivity Wall.

The idea behind it

The Positivity Wall (https://dhseadev.online/positivity-wall/) is a small, quiet corner of my site. No accounts, no typing, no names attached to anything. You show up, and your browser generates a procedural "stamp" — a little visual mark that's yours and yours alone, tied to nine shared panels: Small Wins, Someone Who Helped, Creatures, Made Me Laugh, Outside, On Repeat, Kindness Received, Still Learning, Showed Up. Come back tomorrow and your stamp is still there, identical, still yours. Nothing is uploaded, nothing is recorded beyond a shared count of how many people have marked something good.

It's a tiny piece of software. There's no monetization angle, no growth loop, no funnel. It exists because I wanted to build something that let people acknowledge a good moment without having to perform it for anyone.

The project leans on a philosophy I didn't invent: Amanda Gore's Joy Project. Gore is a Hall of Fame keynote speaker (CPAE, CSP) who's spent about 35 years and reached over 2 million people across 20+ countries with a simple, research-backed argument — feelings drive results. Her Joy Intelligence framework isn't fluff; the numbers she cites are things like a 37% boost in sales, a 51% reduction in turnover, and a 31% increase in productivity when people actually feel connected and joyful at work, instead of just "fine." Her core diagnosis is that most workplaces (and honestly, most people) suffer from emotional disconnection despite being constantly around each other. Belonging is supposed to be simple. We've made it complicated.

One line from her work anchors the Positivity Wall for me: "You are NOT your story, but your story rules your life." That's the whole reason the wall exists in nine small categories instead of one big blank text box. Give someone "Someone Who Helped" or "Made Me Laugh" as a prompt, and suddenly a good moment they'd have let evaporate becomes something they can point to. You're not asked to journal your trauma. You're asked to notice you laughed today, and that's allowed to be enough.

The candle, for the heavier days

Not everything is a small win, though. Some days call for something quieter. That's what the candle page is for (https://dhseadev.online/candle/?preview=true&frame-nonce=f833df8a41). One button: "Light the Candle." No typing, no sign-in, nothing recorded. You take a moment for someone or something that matters, the candle burns for as long as you're on the page, and then it's gone when you close the tab — like the moment itself. The only shared data point is a live count of how many candles are currently lit, so you know, in some small anonymous way, you're not the only one carrying something right now.

It pairs with Vigil, a Chrome extension I built that does something similar but persistent — candles that can be relit across days instead of disappearing the moment you look away. Same instinct, different shape: sometimes you need a moment, sometimes you need a place to keep coming back to.

There's a Futurama quote I keep coming back to that fits both of these projects better than anything I could write myself: "When you do things right, people won't be sure you have done anything at all." A tool that helps someone quietly feel better for thirty seconds isn't going to trend. It's not supposed to. It's supposed to just work, then get out of the way.

Why this matters for how you build anything

Here's the part that applies whether you're writing a Chrome extension, standing up a FastAPI service, or just doing your day job in a spreadsheet: joy and care aren't separate from craftsmanship — they're a design constraint like any other.

When Gore talks about emotional disconnection driving down performance, she's really talking about attention and trust. A team that feels safe and genuinely good communicates better and catches more problems before they ship. A user who feels respected — not tracked, not farmed for data, not nagged — trusts your product more and actually uses it. That's not a soft metric. It shows up in retention, in support load, in whether people recommend the thing at all.

I think about it at the code level too. A "no-friction, no-account, nothing-recorded" architecture isn't just a privacy stance — it's an act of care. It says: I don't need anything from you to let you have this moment. That constraint shaped every decision on both of these pages, the same way a performance budget or an accessibility requirement shapes a build. Joy, kindness, and consideration for the person on the other end aren't the opposite of rigor. Done right, they are rigor.

So whether you're serving legal documents, shipping a browser extension, or building a nine-panel wall of good moments nobody has to explain to anyone — leave room for the version of the work that makes someone feel a little more human when they're done with it. It costs you almost nothing as a builder. It can mean everything to the person using what you made.

Try the Positivity Wall: https://dhseadev.online/positivity-wall/
Light a candle: https://dhseadev.online/candle/

— DHSeaDev (dhseadev.online)

Sources:

Amanda Gore / The Joy Project: https://amandagore.com/
Amanda Gore speaker bio: https://premierespeakers.com/speakers/amanda-gore/posts/the-science-of-joyful-leadership-with-amanda-gore-insights-from-a-leading-motivational-speaker

CoderLegion - A good, yet different space

Dhardingsea Developer — Mon, 14 Sep 2026 13:45:25 +0000

I got interviewed on CoderLegion about my work and spent some time on the platform. Honestly, it's pretty solid.

It's smaller than DEV.to or LinkedIn, but that actually matters. You're getting real developers talking about real projects instead of engagement bait and recruiter spam.

The gamification stuff they do actually works because it pushes you toward connecting with people doing interesting things, not grinding points.

I came for exposure and got it. Found people worth talking to. I'm happy there, and that's rare.

If you care about actual developer community, it's worth checking out.

https://coderlegion.com/27044/from-html-legal-automation-dhardingsea-developers-journey-building-software-that-solves

Stress Test? Pen Test? Yes Tests!

Dhardingsea Developer — Sat, 12 Sep 2026 22:01:38 +0000

Why Your Game's Security Tests Need to Be Adversarial—Not Just Automated

Published on DHSeaDev. A hard-won lesson from shipping a browser-based TCG.

When we stress-tested Prismwar, our original gate suite reported everything was fine. Then we ran a mutation campaign, and 31 out of 70 carefully crafted bugs survived without raising a flag. Here's what went wrong—and how we fixed it.

The Test That Tested Itself

The first blind spot was the most embarrassing: our test harness shared defects with the code it was supposed to verify.

We had a replay system that recorded matches as a seed, both decks, and the player's actions. The Rival's moves are derived at playback time by running the same AI code. When we tested replay fidelity, we recorded and played back ten matches—and all ten matched perfectly.

Sounds good, right? Wrong.

The issue: our harness omitted the AI's defence step in the replay player, and our scripted human player omitted it in the recorder. So the test round-tripped through the same bug and agreed with itself. A round trip cannot test its own driver. Neither can it test its engine. We rebuilt the test to drive the AI's defence window directly and assert the match phase advances—that found it immediately.

The lesson applies everywhere: when testing a system that has two paths (encode/decode, server/client, record/replay), don't let both paths share the same code on the test side. Property assertions work. Round trips don't.

44% of Bugs Stayed Silent

The mutation campaign replaced 70 isolated lines of code with deliberate defects. 39 made the game unplayable. But 31 made the game fail silently:

Dropped guards: validateDeck checks deck legality before a match starts. We deleted the lower-bound check. The gate passed. Invalid 4-card decks loaded fine and then threw an uncaught error in checkWin as soon as someone attacked. The error boundary swallowed it into a "Something went wrong" message, and the assertion "no console errors" stayed green.
Discarded state: An attacker declared blockers but the code forgot to store which ones. The match proceeded as if nothing was blocked. Replays still worked and reproduced correctly (for the wrong reason—the entire engine had the same bug).
Unsigned profiles: The integrity check exempted unsigned saves to allow mid-session work before signing. An attacker simply wrote a JSON with no sig field, granting 720 cards and a million wins. It imported as integrity:'ok'.

Every one of these would have made it into production without sabotage-driven proof.

What Actually Worked

We stopped relying on "no crash" and "match outcomes are deterministic" as evidence. Instead:

Entry guards at the choke point. The game's state machine enters through newGame(). We made that the single place that refuses invalid inputs: non-array decks, decks under 10 cards, missing players. Everything downstream assumes the precondition is true. One sabotage per boundary, and each one must actually throw (not silently default). We verified that the guard itself catches that attack—not just that the game doesn't crash.

Property assertions instead of outcome comparison. Instead of "does the game end in 50 turns or fewer," we assert that the stall detector measures progress—and if you remove that measurement, the test fails. The property is "this mechanism exists and is consulted," not "bad state doesn't happen."

Pinned baselines for non-observable code paths. The AI engine has zero randomness once seeded. We computed a SHA-256 fingerprint over the outcomes of a 512-game corpus. Any change to the rules, the AI decision weights, or the game logic moves that hash. We assert it doesn't move. If it does, we decide to bump it—or revert. But "no change" is measured, not assumed.

Instrument-proved test instrumentality. Before we ran our 70 mutations, we proved the harness could see a break by installing an attacker key and verifying that it unlocked a legendary card it shouldn't. When we replaced the stall detector with a board-count check, we proved the harness caught it by deliberately deleting the right code and watching the test fail.

The Adversarial Mindset

Security tests are not about passing. They're about finding specific ways the code could fail and then proving you catch every one:

Write a defect (a mutation, a forgery, a code path omission).
Run the test to prove it catches the defect. If it doesn't, the defect is a gap.
Verify that removing the defence that catches it makes the test fail. If removing the defence doesn't move the needle, you have a false positive.
Keep the defect as a proof that the test was actually running.

This is inverse from "does my happy path work." You're asking: "What specifically am I refusing?"

For Prismwar:

ECDSA: we proved the harness detects payload tampering, signature forgery, and algorithm confusion. Nine attacks. All caught.
XSS: 350 real-UI trials on a stripped CSP, zero escapes (our HTML builder uses textContent, not string concatenation).
Determinism: identical results across three runs when entropy is disabled.
Persistence: crossing two concurrent save cycles doesn't lose data (a known limitation, documented as unreachable in the shipped UI).
State legality: illegal actions are refused with a clean Error, not a crash or silent skip.

What We Shipped

Final count: 122 assertions, 99 sabotages, 0 escapes, control green. The gates ran against a real build packaged for the Chrome Web Store. Not a best-case scenario. The actual game.

Three automated checks broke themselves in the process:

A brace-balance one-liner couldn't see regex literals or comments. Fixed with a real lexer.
An AWK scan counted lines across multiple files and reported false positives. Replaced with scoped iteration.
A "no console errors" assertion didn't discriminate real errors from false red runs. Now it routes the specific assertion to the relevant scope.

Ship It Adversarially

When you're shipping something that handles user data—saves, settings, payment—or something competitive where cheating matters, your test suite needs to be adversarial:

Can you add security properties that would break if someone removed the defense? If not, you don't have evidence the defense is real.
Do your round-trip tests share machinery with the code they're testing? If so, rebuild one path to go a different way.
Is your baseline pinned? A green build on "determinism" without a fingerprint is a hope, not a fact.
Did you prove your test is actually running? Before you trust a suite, break something on purpose and watch it fail.

Prismwar ships with a ledger wall where users post their best cards. That wall is read-only. The game's state is signed, and the signature is verified on load. Every one of these decisions is backed by a sabotage that proves what fails if you remove it.

That's not perfection. It's shipping with evidence.

Prismwar is live at play.dhseadev.online./ The gate suite is in the DHSeaDev arcade build at scripts/verify-prismwar.mjs and sabotage-prismwar.mjs on GitHub.

Developer? Engineer? Vibin'? What are we now?

Dhardingsea Developer — Fri, 11 Sep 2026 18:44:44 +0000

The Vibe Coder's Advantage: Why AI Just Made "Professional Developer" Meaningless

The term "software developer" used to mean something clear. You went to school, learned computer science, memorized algorithms, practiced for years, and eventually got hired. You had the credentials. You had the training. You were legitimate.

I'm not a software developer. I'm a vibe coder.

I didn't go to school for this. I learned by building things—usually because I needed them to exist and nobody was going to make them for me. I built Chrome extensions because I had ideas. I built internal tools at HSPS because my colleagues needed them. I built my own way into competency through intuition, experimentation, and a willingness to look stupid in front of my code.

And honestly? That approach just became way more viable for everyone.

What's a Vibe Coder?

A vibe coder learns through construction, not curriculum. You feel your way through problems. You don't need to understand the platonic ideal of an algorithm—you need to know what works right now. You ship first, optimize later. You fail forward. You're driven by curiosity and immediacy rather than foundational theory.

Traditional software developers learn the opposite way. Theory first, application second. Algorithms, data structures, design patterns, architecture—you build a mental model of how systems should work, and then you implement against that model. It's rigorous. It's principled. It's often slower.

Neither is wrong. They're just different operating systems for the same skill.

But here's what's changed: AI just collapsed the activation energy for becoming a vibe coder.

The Democratization Moment

Two years ago, if you wanted to build a Chrome extension and didn't know how, the friction was brutal:

You'd learn JavaScript from scratch
You'd learn the Chrome API surface
You'd hit weird bugs and spend hours debugging documentation
You'd rewrite things three times because you didn't understand the patterns

Today? You describe what you want to Claude or ChatGPT, iterate in real-time, and the system generates the code. You learn by reading what the AI wrote, not by struggling through a tutorial. You're still vibe coding—you're still learning by building—but the friction of "not knowing how" is gone.

This is huge. And I don't think the industry has internalized what this actually means.

It means anyone with curiosity and an idea can now be a developer. Not "kind of" or "technically." Actually. You can ship real, functional tools without a CS degree. Without years of practice. Without memorizing JavaScript event loops.

That's not hyperbole. That's where we are.

What This Means for "Professional" Developers

Here's the uncomfortable question: if AI can generate code, and vibe coders can now ship production tools, what exactly is a "professional developer" providing?

The answer is judgment.

A professional developer (whether they're a vibe coder or classically trained) brings:

Taste: knowing what solutions are over-engineered vs. undercooked
Tradeoffs: understanding the cost of every architectural decision
Sustainability: building systems that don't collapse under maintenance
Security: catching the vulnerabilities AI missed
Empathy: writing code that other humans can understand

None of these things require a degree. None of them require formal training. But they do require experience—which is just a fancy word for accumulated failure.

The AI doesn't fail. It just generates. A human who's shipped a dozen projects and watched three of them break in production has something the AI doesn't: scars.

The Future Isn't "No Developers"

I've heard the fears: "AI will replace developers. In five years, nobody will need to code."

I think this misunderstands how tools work.

When the printing press arrived, people didn't stop writing. Writers became more valuable because the distribution layer solved itself. The bottleneck moved upstream. Same with spreadsheets—Excel didn't kill financial analysis, it killed the human calculator and elevated the analyst.

AI won't kill developers. It'll kill tedious code. It'll eliminate the friction between "I have an idea" and "this tool exists."

What it means for the future:

More tools will exist. Not because we have more developers, but because the activation energy disappeared. Anyone with a problem can become a developer.
Quality will matter more. When everyone can generate code, the projects that survive will be the ones built with actual judgment and care.
Vibe coding becomes the default. You'll be able to build without understanding formal computer science, which is democratizing and scary at the same time.
"Developer" becomes a meaningless title. It'll matter less what you're called and more what you've shipped and whether it breaks.

The Uncomfortable Truth

Here's what actually keeps me up: will the industry adapt to this? Or will it double down on credentials and gatekeeping?

Right now, there's a lot of resistance. "Real developers know algorithms." "You can't ship production code without understanding systems design." "AI-generated code is garbage."

Some of this is true. Some of it is just people protecting the value of the credential they paid for.

The vibe coders are about to have a decade. People who can feel their way through problems, who learn by shipping, who don't need permission to build—those people are about to be unstoppable. Because the thing holding them back (the friction of not knowing how) just evaporated.

The professionally trained developers will adapt or won't. The ones who lean into judgment, mentorship, and architecture thinking will become more valuable. The ones who relied on their credential and their ability to memorize syntax will find themselves competing with a free AI that doesn't forget.

What I Actually Am

I don't have a CS degree. I learn by building. I've failed at more projects than I've shipped. I think in problems, not algorithms. I'm inefficient in ways that a classically trained developer would notice.

But I can ship things. I know what feels right. I can look at code and know whether it'll break in six months. And I can do all of that now faster because I have an AI thinking partner.

That doesn't make me a "real developer" in the old sense. But increasingly, I think the old sense was always wrong.

Maybe the future isn't about becoming a developer. Maybe it's about becoming someone who can think clearly about problems, and then having the judgment to know when to use which tool—including the AI—to solve them.

That was always what development was about anyway.

Check us out at Dhseadev.online

What do you think? Are you a vibe coder or a systems thinker? Have you seen this shift play out in your own work? Drop a comment—I'm curious how other people are adapting to this moment.

I set an 18-hour playtime target for my idle game. A simulation says it has 3.7

Dhardingsea Developer — Fri, 11 Sep 2026 14:10:04 +0000

Ashline is an idle army-vs-army battler I'm building for my browser arcade (not public yet). You get five unit roles, enemy waves that hit back, offline progress, a champion with skill trees and a collection of officers you recruit.

Before putting it in front of people, I wanted a number instead of a feeling. How long does a realistic player take to run out of new things to unlock? My target was 18 hours.

Simulating a player instead of guessing

I already had a headless engine and a reference player for balance testing, so playtime.js puts the two together. The simulated player plays 20 active minutes a day, closes the tab and comes back tomorrow. It records the moment each of the game's 20 achievements first unlocks.

Offline time isn't a multiplier. It runs the actual combat loop at reduced efficiency, so being away advances waves. That's capped at 8 hours.

// the shape of it (simplified)
while (unlocked.size < ACHIEVEMENTS.length && day < MAX_DAYS) {
  for (let t = 0; t < 20 * MIN; t += TICK) {
    referencePlayer(S);            // buy, rally, recruit, prestige
    tick(S, TICK);
    activeTime += TICK;
    for (const a of ACHIEVEMENTS)
      if (!unlocked.has(a.id) && a.test(S)) unlocked.set(a.id, activeTime);
  }
  settleOffline(S, DAY - 20 * MIN); // real combat, reduced efficiency, capped
  day++;
}

The first version hung. The bug wasn't in the game. My reference player had unbounded while loops for recruiting and spending points. They're capped at 200 iterations now.

The result

9 of 20 achievements unlock in the first 40 minutes.
All 12 officers are collected by 1.3 hours.
The last unlock lands at 3.7 active hours.

That's about five times short of the target.

The obvious fix is the wrong one

The quickest way to hit 18 hours is to multiply every threshold. Same unlocks, just further apart.

That adds grind, not playtime. The simulation measures when you run out of new things, and stretching the thresholds doesn't create any. The gap is content.

So I added content, and the number got worse

The biggest addition was Onslaught, a separate mode for the champion:

12 named waves, then Endless
one life, and no full heal between waves
after every cleared wave, pick one of three boons drawn from a pool of 24
boons last only for that run
marks (the champion's progression currency) are banked when you die

I tuned it so a fresh champion dies around wave 2 in about 30 seconds, and an invested one reaches 20+.

Then I re-ran the playtime simulation: 3.1 hours, down from 3.7.

Onslaught banks marks, and marks buy the champion progression that unlocks achievements. So the new mode wasn't a new ladder. It was an accelerator bolted onto the old one. The achievements are still tied to the army's wave counter. A new mode needs goals of its own, like run depth and build variety, or it only shortens the path to the same finish line.

Why "no full heal"

In the main mode, when your army hits 0 HP it routs: it falls back two waves, heals fully and keeps going. An idle game shouldn't dead-end while you're away.

The balance suite exposed a side effect. I had written a test claiming "the champion alone cannot progress." That claim is false by construction. With a full heal after every rout, anything with regeneration can grind forever. I replaced it with a comparative test (the army must out-progress a lone champion by a margin) and built Onslaught so that death actually ends something.

Splitting the modes quietly broke two tests

Taking the champion out of army combat left two balance bands meaningless, and one of them still looked great:

"No dominant skill tree" reported 90 / 90 / 90 / 90. Perfect balance, apparently. In fact, the four trees no longer touched army combat, so every build was identical.
The spell band read 0 / 0, because spells no longer buffed the army.

I retired both rather than leave them green. Eight Onslaught-specific bands replaced them: the stakes are real, investment helps monotonically, the ladder is beatable, no boon dominates, no boon is dead, death is final, marks scale with depth, and a draft follows every clear.

Two more things measuring caught

Correlated randomness. Recruiting rolls a rarity, then an officer within that rarity. Both rolls used the same index into the seeded generator, so they were correlated: 7 out of 7 rares came out as the same officer. Deriving a separate index fixed it, and I checked the fix over 10,000 pulls. Pulls stay deterministic on (seed, pull number), so reloading a save can't reroll a result.

An optimization I didn't make. Officer effects get recomputed several times per tick, and I had flagged it for memoization. Profiling put it at 5.69µs per tick, 0.034% of a 16.7ms frame. Shipping that "fix" would have been claiming a win that didn't exist, so I cut it.

What's next

Achievements tied to Onslaught depth and build variety, so the new mode extends the ladder instead of shortening it.
Real attack classes. The five army roles currently fight identically. Only their HP, armor, regen and splash differ, while the names and the 2.5D ranks suggest melee, ranged and magic. That's the biggest gap between how the game looks and how it plays, and it's an engine change that invalidates every balance band, so it gets its own tuning pass.
Then re-run playtime.js.

The number I didn't want was the most useful thing the simulation produced. 3.7 hours doesn't say the game is bad. It says where the game ends, and that adding a mode isn't the same as adding somewhere to go.

Three of my test gates had never heard of the game I was shipping

Dhardingsea Developer — Fri, 11 Sep 2026 03:47:52 +0000

My browser arcade at play.dhseadev.online deploys when I push to main. Nothing ships unless verify-all.sh prints ALL GATES PASS. This week I was adding a ninth entry, a card game called Prismwar (not live yet). I built it, the index listed it, dist/ contained it.

Three of the gates in that suite had no idea it existed.

The list that didn't grow

The arcade is driven by one table, ENTRIES. The build reads it, and so do the index, the sitemap and llms.txt. Three test scripts didn't: the boot/paint/save gate, the stress battery and the SEO-heading gate. Each one had its own hardcoded list of pages, written back when the arcade was smaller.

So the new row got built, emitted and linked, and none of those three scripts ever loaded it. They reported on everything they knew about, and all of it passed. Nothing in the output was false. It just described a smaller arcade than the one I was shipping.

// what the gates had (simplified)
const PAGES = ['prism-cascade', 'lumenreel', 'veilfall' /* ...frozen in time */];

// what they should have
import { ENTRIES } from '../build.mjs';
const PAGES = ENTRIES.map(e => e.id);

For today I added the missing rows by hand. After that the full run included Prismwar and passed. The real fix is deriving every gate's list from ENTRIES, so a new entry can't be built without also being tested.

This wasn't a one-off. The same week, an idle game I'm building for the arcade gave me five more green results that weren't telling the truth.

A sabotage that everything catches proves nothing

Ashline, an idle auto-battler, has an "instrument proof": break the engine in specific ways on purpose, then confirm the balance suite goes red for each one.

The first run caught four sabotages out of four, and every one reported the same thing: the army stalled at wave 1.

That's what gave it away. Four different breakages shouldn't produce one identical symptom. The unbroken game was also stuck at wave 1, because of a cold-start bug where the starting army did zero damage. The suite wasn't detecting my sabotage. It was detecting a softlock that was already there, four times over.

The fix was a control. Run the unbroken build first and require it to pass. A sabotage only counts as caught if the baseline was green and the broken build fails a check that fits the breakage. After that, each sabotage tripped its own band.

Buttons that exist vs. buttons you can press

Ashline's DOM smoke test was 13 for 13: boot, five buy buttons, accessible names, HUD updates, save writes, offline settle, graceful storage failure.

I opened the game and saw a line across the screen with nothing to click.

On load, the game called buyLoop(). That's the automated player the simulation uses in place of a human. It spent the opening currency before first paint, so every buy button rendered disabled. The test checked that the buttons existed and had names. It never checked whether anyone could press one.

I added four assertions:

an action is available at load
a purchase is affordable at load
the starting grant hasn't been spent
clicking alone clears wave 1 within 12 seconds

Then I put buyLoop() back into load() on purpose. The suite dropped to 15/17, failing on exactly the two grant checks. That's when I started trusting it.

Three asserts that couldn't fail

The quieter version of the problem is an assertion that can't go red at all:

A gravity check for particles that returned true no matter what. It never read velocity before and after a step. Now it does, and it measures +90 vy per 0.1s at G=900.
check('champion drawn larger', true). A literal. I wrote it, and it would pass on a blank canvas forever.
A reduced-motion check that passed for the wrong reason. The attack has a 250ms cooldown, so the second call was refused, and "motion on" and "motion off" looked identical. Once I fixed that, the test failed on the good build. The harness pins Date.now() to 0, so the cooldown never cleared. That's two harness bugs and zero game bugs.

The literal became a spy that records what the renderer actually received:

// passes forever
check('champion drawn larger', true);

// passes only if the renderer actually did it (simplified)
const heights = [];
const draw = Champion.draw;
Champion.draw = (ctx, x, y, h, ...rest) => { heights.push(h); return draw(ctx, x, y, h, ...rest); };
renderLine(); renderArena();
check('champion drawn larger in arena', heights[1] > heights[0]);

The real numbers are 52px on the battle line and 86px in the arena.

The copy that was a version behind

Ashline also has a delivery-path check. It runs the balance bands against the engine extracted from the built HTML, not the source module, because the HTML is what players get.

Good idea, bad execution. My extracted copy of the sim was stale. It predated the army-combat rewrite, so it reported 7 bands under an old label when the real suite had 10. Now both derived files are regenerated from the build on every run, and a copy is never reused.

What I check before I believe a green run

Does the gate's inventory match the product's? Compare what it tested with what shipped.
Was the control green, and did each break fail differently? If every break fails the same way, you're looking at one bug that was already there.
Does the assertion test use, or just existence? "The button exists" and "the button can be pressed" are different tests.
Can I make it fail? Break the thing on purpose. If the test stays green, the test is the bug.
Is the artifact current? Regenerate anything derived. A stale copy tests yesterday's build.

Then open the thing. A gate caught every problem above except the unplayable build. I found that one by clicking on it.

A passing gate is making a claim. The only way I've found to check that claim is to watch the gate fail first.