Forem: 盛永裕介

I shipped a polished hanafuda card game in 2 days with Claude and Godot

盛永裕介 — Sat, 02 May 2026 13:25:12 +0000

I just released Shin KoiKoi — a free, polished take on the traditional Japanese card game Hanafuda Koi-Koi. Solo dev, 2 days from kickoff to itch.io public page, with full multi-language support and accessibility features.

This post is a release log. I'll walk through the technical choices, what went right, and the three or four things that bit me. No hype — just what actually happened.

Why this game

The market for hanafuda apps is bleak. Most options are ad-laden, freemium-gated, or visually frozen in 2010. I wanted a polished, fully-offline, ad-free version that respects the player. So I built one.

The scope decision that made this feasible: only the Koi-Koi rule set. No Hachi-Hachi, no Hanaawase variants, no Mushi. Single-player only for v0.1.0. Online multiplayer is planned but deferred.

The stack

Area	Choice
Engine	Godot 4.6.2 .NET (mono)
Language	C# (`net9.0` target)
AI pair programming	Anthropic Claude
Visual assets	Gemini nanobanana2 / Midjourney V7
Fonts	Noto Sans CJK + Noto Sans Devanagari (OFL)
Tests	184 unit tests (homemade xUnit-like, all green)
Distribution	itch.io Direct (Mac/Win/Linux simultaneous)

I picked Godot over Unity for three reasons: open source + zero royalties at scale, smaller binary footprint than Unity, and faster cold-edit cycle (the script-error-restart loop is much friendlier than Unity's domain reload).

What "2 days" actually means

I want to be honest about the timeline:

Pre-work: ~3 weeks of design notes, scope decisions, and rule research before I touched the editor
Active dev: 2 focused days of code + asset curation
Polish day: itch.io setup, screenshots, multilingual descriptions, SNS announcements

So "2 days" is the interesting part — actual implementation. The pre-work matters; jumping into Godot without a scope decision would have stretched this into weeks.

The 2 days included Claude writing roughly 70% of the UI scaffolding under my direction. I supplied game logic, iterations, and the "feel" decisions (animation timing, spacing, color theory). The collaboration was much closer to "principal engineer with junior pair" than "AI did it all" — Claude needed direction at every architectural decision, but the typing and boilerplate were near-instant.

Things that bit me

1. macOS export ETC2/ASTC requirement

Universal binary export for macOS fails with a non-obvious error if you don't explicitly enable VRAM compression in project settings:

ETC2 ASTC テクスチャフォーマットが無効になっている場合、
ユニバーサルまたは arm64 用にエクスポートできません

The fix is one line in project.godot:

[rendering]
textures/vram_compression/import_etc2_astc=true
textures/vram_compression/import_s3tc_bptc=true

Cost me 30 minutes searching the wrong way. Documenting it here so the next person Googles directly to the answer.

2. Multi-language font fallback (especially Hindi)

Adding Devanagari (हिन्दी) to a font stack that already covers CJK and Latin requires careful priority ordering:

var sysFont = new SystemFont
{
    FontNames = new[]
    {
        "Noto Sans CJK JP",
        "Hiragino Sans",
        "Yu Gothic",
        "Noto Sans",
        "Noto Sans Devanagari",  // ← critical for Hindi
        "sans-serif",
    },
    AllowSystemFallback = true,
};

If you put Noto Sans Devanagari before Noto Sans CJK JP, CJK characters render with weird stroke widths. Tested all 6 languages (ja/en/de/fr/es/hi) — no missing glyphs ("tofu" boxes) anywhere.

3. AI-generated screenshot automation

Manual screenshots are tedious and inconsistent. I wrote a Node-based state machine in C# that:

Initializes the Main scene
Walks through Title → Game → Yaku list → Stats → Settings
Captures viewport texture as PNG at each stop
Quits cleanly

public partial class ScreenshotTour : Node
{
    public override void _Process(double delta)
    {
        _stepElapsed += (float)delta;
        switch (_step)
        {
            case 0: if (_stepElapsed >= 3.0f) Advance(); break;
            case 1: Capture("01_title.png"); Advance(); break;
            case 2: _main.OpenSettingsForScreenshot(); Advance(); break;
            // ...
        }
    }
}

Triggered via CLI: --screenshots /tmp/output_dir. Now I can re-shoot all marketing screenshots in 15 seconds whenever the UI changes. Worth the 30 minutes to write.

4. Oracle Cloud Always Free region trap

Tried to use Oracle Cloud's Always Free tier for online multiplayer (Phase 2). Hit two roadblocks:

ARM Ampere A1.Flex shape is chronically out of capacity in Tokyo (50+ retry failures)
Subscribing to other regions (Phoenix, Osaka) requires upgrading to Pay-As-You-Go — the home region is the only one available on the strict Always Free tier

Workaround for now: ship offline-only v0.1.0 to itch.io, defer online multiplayer to v0.2 when capacity opens up or I switch hosting strategies. This was the right call — the game is complete as a single-player experience and shipping early matters more than adding multiplayer to an unproven idea.

AI art with zero IP risk

I generated ~45 PNG assets using Gemini nanobanana2 and Midjourney V7. All disclosed openly via itch.io's "AI generation disclosure" toggle (it's a yes/no field; I selected yes).

The risk-mitigation choice that made this clean: no characters, no people. Only:

Family crests (kamon)
Hanafuda card motifs (12 months of seasonal nature imagery — public-domain cultural symbols)
Backgrounds (pine, cherry blossom, moon)
Rank badges (kanji on lacquered medallions)

Every element is either a public-domain cultural symbol or an abstract decoration. No specific character likeness anywhere, so no IP collision risk.

Accessibility from day one

This is non-negotiable for me. v0.1.0 ships with:

Colorblind mode (deutan/protan-aware saturation tweaks)
4 UI scales (0.85x / 1.0x / 1.15x / 1.30x)
Reduced motion mode (shortens cutin animations)
6 languages with proper script support
GDPR/CCPA consent flow on first run

Adding these later costs more than building them in upfront, and "indie casual" isn't an excuse to skip them.

What I'd do differently

Set up automation earlier: I should have written the screenshot tour and SDK install scripts in hour 1, not hour 30
Pre-build the icon set: Apple/Google demand many icon sizes; using sips to batch-resize would have saved 20 minutes
Test on Linux earlier: I built Linux export last and discovered a permissions issue. Should have done a quick smoke test on each platform every few hours

Roadmap

✅ v0.1.0 (2026-05-02): Single-player, all 3 desktop platforms, 6 languages, accessibility
🔜 v0.1.1: Bug fixes from itch.io community feedback
🔜 v0.2: Online multiplayer (Nakama + free server hosting once capacity opens)
🔜 Mobile: Google Play ($25 one-time) and possibly App Store ($99/year if interest justifies)
🔜 Steam: Landscape UI implementation first, then Steamworks Direct ($100 per submission)

Try it

Download Shin KoiKoi (free) — Mac, Windows, Linux. No ads, no IAP, no tracking.

Source isn't public yet, but if any specific subsystem (the AI evaluator, the locale system, the screenshot tour) interests folks I'm happy to write follow-up posts. Reply or DM with what you'd want.

Built solo by hogwartz.inc. Engine: Godot 4.6.2. Pair programming: Anthropic Claude. Made with respect for the traditional game and for the player's time.

Adding 'avoid if' caveats to my AI game recommender — what changed

盛永裕介 — Fri, 01 May 2026 14:02:16 +0000

I added a single sentence to my AI prompt for indie game recommendations: "include one specific 'avoid if' caveat per game that mentions a real limitation." The output went from blandly positive to advice I'd actually trust — the kind of thing a friend who'd played the game would say.

This is a 1,000-word post about why that one-line change matters more than I expected, and where it falls apart.

The marketing-speak problem

Pull up almost any indie game directory site and you'll find the same shape of copy: every game is "breathtaking", "innovative", "unforgettable". The third-party recommendation engines built on top of Steam are particularly bad at this — they default to the marketing voice of the developer's own store page.

I noticed it as soon as I started building Find Games Like, the indie-games half of a three-site experiment I'm running. I was generating recommendations for ~140 indie titles using Claude Haiku 4.5, and the first batch read like the back of a Steam keyword search: lots of adjectives, zero specific information about who shouldn't play.

Generic AI tone matches generic marketing tone, because both are trying to maximize the chance that any given reader thinks the product is for them. That's exactly the wrong objective for a recommendation engine. A good recommendation is most useful when it filters out the wrong audience.

The actual prompt change

Here's what I changed. The original prompt asked Claude to produce three reasons to recommend a game. The new version asks for the same plus one specific caveat:

For each game, write:
- 3 specific reasons someone might love it
- 1 "avoid if" caveat naming a concrete audience trait or game element
  that would make this game frustrating

That's the entire change. Not even a system prompt edit — just two more lines in the user-turn instruction.

The model behavior shift was bigger than the prompt size suggests. The act of having to name who shouldn't play forces Claude to think about the game's actual properties rather than generating flattery. The caveat sentence then anchors the surrounding three positive sentences in something that feels real.

What it produces

Three real outputs from the current pipeline:

Celeste — avoid if you're uncomfortable with themes of anxiety and panic attacks. The game's narrative is explicitly about the protagonist's mental health, and several mechanics tie difficulty spikes to representations of intrusive thoughts.

Hades — avoid if you dislike permadeath roguelikes or need a single linear story you can finish in one sitting. Each run takes 30-50 minutes, and the narrative deliberately rewards repeated failure.

Hollow Knight — avoid if you find punishing platforming and unforgiving boss fights frustrating. The map is intentionally cryptic and progression often requires returning to old areas after acquiring abilities you didn't know existed.

Each one is specific. Each one names an actual game property a hypothetical player could check against their own preferences. None of them say "if you don't like indie games" or "if you don't like Metroidvanias", which is what a lazy version of this prompt would produce.

Why this works

There's a credibility mechanic here that's older than directory sites: admitting weakness signals integrity. A recommender that only ever says good things either has bad taste or is hiding something. A recommender that says "this is great, but it's not for you if X" is making a calibrated claim — which makes the positive part of the claim more believable.

The same instinct shows up in product copy when it's done well. Patagonia's "Don't Buy This Jacket" Black Friday ad is the canonical example. App Store reviews that lead with "I had to stop using this because…" are the most useful ones in the entire reviews section. Restaurant guides that explicitly note service quirks alongside food quality feel more trustworthy than ones that only star-rate.

The "avoid if" pattern is just the directory-listing version of that instinct, applied at the prompt layer instead of relying on individual writers to remember to do it.

Where it breaks down

Not every game has a meaningful caveat. Some titles are genuinely broad-appeal — short narrative games, cozy farming sims, party games for groups. Claude noticed this early in the pipeline and started inventing caveats for games that didn't really need one. The first version of Stardew Valley in my data read "avoid if you don't enjoy slow-paced games", which is approximately useless.

I've been adding a fallback rule to the prompt: "if no honest caveat exists, return null for the avoid_if field rather than fabricating one." Compliance is around 80% — Claude still occasionally invents weak caveats — but it's better than forcing one on every entry.

Two other places this technique fails:

Taste-driven domains where there's no objective basis for caveats. Recommending books for a particular mood, or recommending restaurants for a particular cuisine — the caveat would be tautological ("avoid if you don't like mystery novels"). The technique needs a domain where some audience traits genuinely conflict with the product.
When the underlying knowledge is wrong. Claude once generated a caveat for Outer Wilds about "puzzle complexity" when the game's actual stress point is the time-loop mechanic. Wrong-axis caveats are arguably worse than no caveats — they look authoritative while pointing the reader at a fictional concern. I haven't fully solved this; the best mitigation so far is grounding the prompt with the game's actual Steam tags and a one-paragraph manual summary before asking for the caveat.

Where to apply it beyond games

I think the same pattern applies to almost any directory or recommendation site:

OSS alternatives to SaaS: "Stay on the SaaS if your team has fewer than three engineers and no DevOps capacity."
AI tools directories: "Avoid this model if your workload is latency-sensitive at scale."
Restaurant guides: "Skip on a date — the lighting is industrial and tables are loud."
Book recommendations: "Skip if you've already read X — the thesis overlaps significantly."

What these share is a mental model where the audience has a specific trait, the product has a specific limitation, and a useful directory makes that mapping explicit instead of leaving every reader to discover it post-purchase.

What I'm watching

I don't have data yet on whether "avoid if" caveats actually translate into more reader trust. Find Games Like is eight days old and traffic is essentially zero — I'll publish real engagement numbers (comments, time on page, return visits) at the 30-day mark.

The falsifiable claim is: pages with caveats should outperform pages without them on engagement metrics. If that turns out to be wrong by month two, I'll need to revisit the assumption that honesty-as-trust-signal works in directory contexts the way it works in book reviews.

Until then: every AI-generated recommendation I add to that site has a caveat. The prompt is two extra lines. The output reads like advice from someone who's actually played the game.

Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.

I built 3 programmatic SEO sites for $25/month using Claude Haiku — here's the full architecture

盛永裕介 — Fri, 01 May 2026 11:59:13 +0000

Spent the past week running an experiment: can a programmatic SEO directory site survive Google's 2024 Helpful Content Update if every page is AI-generated?

Rather than pick one niche and bet the farm, I built three parallel sites with the same stack — different content categories, identical architecture, single content generation pipeline. They share a monorepo, deploy independently to Vercel, and refresh nightly via one GitHub Actions cron.

This post is the architecture write-up. I'll publish actual revenue/traffic numbers in a follow-up after 6 months.

The three sites

🤖 Top AI Tools — ~500 open-source models from HuggingFace, with Claude-generated summaries, use cases, and FAQ
🎮 Find Games Like — "games like X" recommendations for indie titles on Steam, with AI-curated similarity reasoning and "avoid if" caveats
🛠 Open Alternative To — open-source replacements for ~80 popular SaaS products, refreshed daily from GitHub stars and last-pushed timestamps

All three are static-generated, all three rebuild nightly, all three share editorial logic from a single TypeScript package.

Why three sites instead of one

Three reasons:

Cheap insurance against niche choice failure. I don't know which niche Google will tolerate in 2026. Three uncorrelated bets > one big one.
Shared ETL infrastructure. The cost of running site #2 and #3 is mostly the marginal Claude API tokens (~$2/site/month). Hosting and code is amortized.
A/B testing categories. AI-tools is the most saturated PSEO niche on Earth. SaaS-alternative goes head-to-head with alternativeto.net (DA80+, 20 years authority). Indie games is the underdog with the cleanest niche fit. After 6 months, the data tells me which thesis was right.

Stack at a glance

Layer	Tool	Why
Site framework	Astro 5 (SSG)	100% static output, no runtime cost
Styling	Tailwind v4	Newer engine, faster builds, smaller CSS
Content gen	Claude Haiku 4.5 via Anthropic SDK	Cheap, fast, sufficient for directory copy
Data store	Turso (libSQL)	ETL state + idempotency tracking
Cron	GitHub Actions matrix job	Free, version-controlled, reliable
Hosting	Vercel Pro	Fast SSG deploys, image optimization
Monorepo	pnpm + Turborepo	Workspace-aware builds, cached output

Total monthly cost

Item	Cost
Vercel Pro	$20
Anthropic API (Haiku 4.5, daily refresh)	~$5
Turso (free tier 500MB)	$0
GitHub Actions (under 2k min/mo free quota)	$0
Domains (Vercel subdomains until validation)	$0
Total	~$25/month

Repo layout

seo-farm/
├── apps/
│   ├── ai-tools/          # topaitools.vercel.app
│   ├── indie-games/       # findgameslike.vercel.app
│   ├── oss-alternatives/  # openalternativeto.vercel.app
│   └── dashboard/         # internal status page
├── packages/
│   ├── shared/            # Anthropic client, DB schema, monetization helpers
│   └── publish/           # the script that posted this article
└── .github/workflows/
    └── refresh-content.yml  # nightly cron

The three sites are intentionally separate Vercel projects (different roots), but share @seo-farm/shared for the Claude client, libSQL helpers, AdSense + Amazon affiliate components, and structured-data builders. Each site has its own ETL — HuggingFace API for ai-tools, Steam Web API + RAWG for indie-games, GitHub repo discovery for oss-alternatives.

Content generation pipeline

The cron runs daily at 02:00 UTC and processes one app at a time (matrix max-parallel: 1 to stay below Anthropic burst limits):

strategy:
  matrix:
    app: [ai-tools, indie-games, oss-alternatives]
  max-parallel: 1
env:
  ETL_LIMIT: "500"
  GENERATE_LIMIT: "300"

Per app, the pipeline is:

ETL stage — fetch source data (HuggingFace models / Steam games / GitHub repos), upsert into Turso
Detect missing content — find rows where generated_at is null or older than 30 days
Generate with Haiku 4.5 — batch ~5 entries per call, one prompt per content type
Cache & dedupe — write back to Turso with new generated_at timestamp
Trigger build — only if content changed, push commit and let Vercel rebuild

The hard part is step 3 prompt design. Generic "summarize this tool" prompts produce slop. What worked:

One prompt per content type (summary / use cases / FAQ / pros-cons), never a single mega-prompt
Strict format constraints ("3-5 bullet points, max 12 words each, no marketing language")
Source-grounded context — only use info from the provided model card; refuse to fabricate benchmarks
An "avoid if" caveat for game recs — most game directories only gush. Find Games Like prompt explicitly asks Claude to be honest about limitations

For Find Games Like, the "avoid if" produces lines like:

Celeste — avoid if you're uncomfortable with themes of anxiety and panic attacks
Hades — avoid if you dislike permadeath roguelikes or need linear story progression

That's one of the few moments AI summaries actually beat human-written game directories, which all default to marketing-speak.

Ranking strategy (or: things Google may kill anyway)

I'm not delusional about this. Google's March 2024 update specifically targeted "scaled content abuse" and de-indexed thousands of programmatic SEO sites. The bet here:

Source-grounded content — every detail page links to canonical authoritative source (HuggingFace model card, Steam store page, GitHub repo). Reader can verify in one click.
Real utility — directory + comparison tables that genuinely save time vs reading 30 docs pages
Honest framing — "AI-generated, here's the source" disclosed in footer, no hiding
Per-page structured data — SoftwareApplication, VideoGame, Product JSON-LD on every detail page
Low quantity, daily freshness — 880 total pages, refreshed daily so star counts and modification dates stay current. Not 100k pages of stale garbage.

I genuinely don't know if any of this is enough. The whole point of the experiment is to find out. If two of three sites get deindexed by month 3, that itself is a useful data point.

What's wired up

AdSense site-wide (currently in review — sites are <2 weeks old)
Amazon Associates with category-relevant search links per page (no fake recs, just amzn.to search-by-keyword links to actual related books/peripherals)
GA4 per site with separate properties
Newsletter via Beehiiv iframe ("Indie Discovery Weekly")
Sitemaps + robots.txt + llms.txt generated at build time

Milestones I'm watching

Month	Question	Threshold
1	Did Google index the pages?	Search Console impressions >1k/day = yes
3	Is organic traffic growing?	>50% organic share of GA4 sessions = healthy
6	Is monetization viable?	AdSense approved, RPM measurable, decision: delete or double down
12	Is it sellable?	3 consecutive months of profit > 0 = list on Empire Flippers / similar

Open questions for readers

I'd genuinely value feedback on:

PSEO survivors of March 2024 — what categories are still ranking?
Schema markup — am I missing anything obvious for directory sites?
AI content disclosure — how transparent is too transparent? Does the footer "AI-generated" disclosure help or hurt?
Niche durability — which of the three do you think survives 12 months? Place your bets.

Repo isn't public yet — I might open source it after the 6-month checkpoint depending on how the experiment goes. Happy to share specific snippets in the comments if anyone's curious about a particular piece (Astro content collection layout, the Claude prompts, the structured-data helper, the Vercel Pro deploy config).

Next update in 30 days with actual numbers, regardless of how ugly they look.