Pocket Forge Games is a mobile game studio building a no-install browser game hub. Players open one link on their phone, pick from a portfolio of original games, and play instantly—no accounts, no downloads, no friction. Right now three games are live (Spark Keeper, Belt & Pinion, Tallytongue) with working leaderboards and a habit-tracking layer. The studio builds one game at a time using a shared platform, so each new game only needs game code plus a tile. You get a live, playable portfolio site, a cross-game nickname leaderboard, device-local progress tracking, and usage measurement all built in.
Mission
Pocket Forge Games — plan
What we're building
A small mobile game studio and the web platform that holds its games. A player opens one link on their phone, picks a game from the hub, and plays instantly in the browser — no install, no account. Downloads and installable builds come later, as a distribution layer on top of a working hub, not before it.
Studio name (ratified 2026-09-29) Pocket Forge Games is the final studio name, ratified by the owner. It is no longer a placeholder. It is already what the hub, the shared link previews and the installable-app metadata say, so nothing needed renaming.
Where we actually are (as of 2026-10-16)
Three games are live and verified on one hub. Game #1 Spark Keeper (arcade), game #2 Belt & Pinion (daily gear puzzle), game #3 (word + number). All three cards render with working art, all three play pages load, and the nickname leaderboard reads and writes real Postgres rows, including the for both daily games.
Tallytongue
today's board
The habit layer is finished and independently verified, and still not live. Streaks, per-day personal bests, badges and a 30-puzzle on-device archive, shared by both daily games, plus a first-ever Tallytongue warm-up that is provably never submitted to the daily board. I verified it myself: harnesses pass, both puzzle generators' fingerprints are byte-identical to their pre-change values, and the warm-up writes practice only. One defect I found in the warm-up end panel (daily copy plus a submittable form on a teaching ledger) is fixed and re-verified in the browser.
Usage measurement is built, proved against the real database, and its readouts work. Plays per game (counted when a game actually starts, restarts included), practice runs in their own counter so they can never inflate the daily figure, and share taps. Aggregate only — no cookies, no identifiers, no stored IPs. The owner has two readouts: an unlisted internal page, which I loaded and verified myself (it labels itself internal, is noindex, is not linked from the hub, and states its own limits in plain words), and a one-line shell command. The numbers are our own QA traffic and nothing else: 5 plays, 6 practice runs, 2 share taps, lifetime, across all three games. Nobody outside the team has played.
The website is published and the public link is stale. Nothing new can go live: publishing is refused because the plan's published-site limit is reached. This blocks every ship — the habit layer, measurement, and every game after them. It is an owner action (upgrade the plan, or archive another business's site); it has been refused on every attempt so far, six of them.
The database auto-pauses when idle and was resumed once already. While paused nothing is recorded: scores and plays stay on the player's device. The readout prints the timestamp of the last counter write, which is the honest signal for whether the data is current. With no traffic this will happen again, and it is worth revisiting once we actually have players.
The cross-game platform is built — a game registry, per-game score plumbing, a shared play shell, a day-scoped board, a shared deterministic PRNG, a shared habit module and a shared measurement helper. A new game is now game code plus a tile, not plumbing.
There is no revenue, no payment path and no products. The Stripe balance is $0 available and $0 pending with no transactions, and the only product on that account belongs to a different business of the owner's. All three games are free, and the owner has decided nothing gets wired for money before we have real usage numbers.
Direction (owner-set, 2026-09-29): we are not a one-thumb-arcade studio
Pocket Forge is a portfolio studio: many small original browser games across different genres, sharing one hub, one nickname-leaderboard pattern and one visual identity. Control scheme is chosen per game by what that game needs — one-thumb, two-thumb, landscape, tap-timing, drag, swipe — rather than by a house rule. A game that needs a landscape two-handed screen is a game we can ship.
Rules that stay true for every game:
Original, written from scratch by us. No clones, no reskins, no licensed IP, no third-party asset packs we don't own.
Instant-play in a phone browser, short sessions, a clear score, instant restart, difficulty that ramps.
One URL a player can text to a friend.
No two games may share both their input scheme and their core skill (added 2026-10-07 with the variety slate). A new game must widen the portfolio, not repeat a lane we already occupy.
No third daily. Two one-puzzle-a-day games already compete for the same returning moment; the next games should alternate between daily-seeded and per-run formats.
One game built and published at a time. Build capacity is a single engineer, so the slate is a pipeline, not a batch.
How this makes money (owner decision 2026-10-06) Not decided yet — deliberately, and nothing is wired. The owner's call is that no payment work happens until we can count plays and share actions per game, at which point the model gets chosen from real numbers rather than from a list of plausible ones. The candidates on the table, with their honest costs, are: a one-off supporter/archive purchase (fits what we've built and works with the current one-time-only Stripe account); a monthly subscription (strongest long-run fit for daily puzzles, but this Stripe account cannot take subscriptions at all — switching to the full experience would redo onboarding and disturb the owner's other business on that account, so it is an explicit decision, not a default); ads (needs tens of thousands of plays a month to beat pocket change, and taxes the instant-load promise); cosmetics (needs accounts or device-local unlocks to mean anything); and two non-product routes stated for completeness — paid contract work, or selling the business. Orefell, with its device-local progress loop, is the most natural first candidate for a supporter purchase or a paid archive, precisely because progress on the device is something a player can value — noted, not decided, and nothing is wired.
The slate (Revision 2 — a working document, not ratified)
The variety slate lives in full at games/slate-2-variety.md: eight candidates organised by lane (rhythm, memory, risk/economy, aim, spatial routing, physics manipulation, lane defense, chain reaction), each with input scheme, session length, scoring and a rough cost. Belt & Pinion and Tallytongue are shipped. Two earlier reflex concepts sit in an appendix as duplicates of Spark Keeper's lane. Names are exact-string searches, not trademark clearance; effort figures are estimates, not measured. The slate is the menu for game #6 onward.
Owner-requested game — space shooter with upgrades and prestige, name Orefell (approved 2026-10-16)
Full brief at games/orefell-brief.md. Destroy falling meteors to earn ore; spend ore on upgrades that last the run; each level of meteors is harder; a prestige button resets ore and run upgrades to bank a permanent bonus computed from how far the player got, so the next run is measurably faster. The economy must be the spine of the game — a shooter alone would repeat Spark Keeper's reflex lane, and by the house rule the skill has to be the upgrade-and-retire decision. It is our first game with progress that survives a session: device-local only, no account, and the same honest limitation as streaks (clearing site data starts again from zero). Per-run format, not a third daily. Owner's three calls, now made: the name Orefell is approved; Quenchhold finishes first and Orefell starts when that build is complete; prestige unlocks at the third level — a short, prestige-often loop rather than a long climb, so the run is short and punchy and the permanent bonus must be felt in the next run's first level. The headless curve simulator therefore tests prestige-at-3 as the primary configuration and reports what a player gets by pushing to 6, 9 and 12 instead — if the numbers show the owner's chosen loop is the weaker one, that gets reported rather than buried.
Current focus — the locked build order (owner-set)
Game #2 — Belt & Pinion — shipped and live.
Game #3 — Tallytongue — shipped and live.
Habit layer for the two daily games — built, verified and defect-free; waiting on the published-site limit to go live.
Measurement — built, proved, readouts verified. Meaningless until something is live and promoted.
Game #4 — Quenchhold. The simple single-session RPG: three classes, a seeded ten-room hold, a boss, a score, instant restart. No accounts and no saved progress — growth lives inside the run and combat is deterministic, so the shared daily hold is a puzzle to solve rather than a roll. Deterministic core in build now; UI and art follow.
Game #5 — Orefell (owner-requested, above): the upgrade-and-prestige space shooter. Starts once Quenchhold is complete.
Roster review — after game #4 (owner-set trigger). Report plainly whether the single build slot is the real bottleneck before adding anyone.
Then stop and measure properly — which games get played and which get shared — before accounts, downloads or payments. Note the honest gap: with nothing published and nothing sending anyone to the site, these numbers will stay at zero however good the games are, so promotion becomes a real task the moment publishing clears.
Deliberately not yet in scope
player accounts, server-side saved progress, installable/PWA builds, app-store builds, payments, ads, and building two games simultaneously. Device-local progress is in scope for Orefell (upgrades and prestige stored on the device only) — deliberate: it is what makes a prestige loop mean anything, and it keeps us clear of accounts.
What we need from the owner (steering)
Resolve the published-site limit — it is still blocking every ship. Publishing was refused again after the owner's clearance; the habit layer, measurement and every game after them are queued behind it. Either the Pro upgrade at $20/month (publishing to a live environment is a Pro feature; Plus at $60 is only needed for a custom domain) or archiving another business's site, which is free. If an upgrade or archive was made, it may not have landed against this business.
Whether the daily-puzzle shape is the habit you want — genuinely testable: two of the three games are one-puzzle-a-day, and you can play both yourself today.
A domain decision, if you want it — pocketforgegames.com is available at $14 for the first year and $47/year after; the short pocketforge.com is taken. Serving the site on our own domain needs the Plus plan ($60/month); buying and parking it does not.
The revenue model — after the numbers, not before. Once plays and shares are counted from real traffic, pick from real data. If subscriptions are seriously considered, the Stripe switch and what it would disturb at the owner's other business need deciding explicitly.
The team
CTO
Team Lead
Team management, task planning, delegation, and monitoring
G
game engineer
Full-stack builder for the Pocket Forge Games site and games: mobile-first HTML/CSS/JS game development (canvas/touch), site hub pages, lightweight backend API routes, database-backed leaderboards, and publishing the site. Also generates original game art and UI assets.
Setup
No MCPs needed. The site is live at the hub URL (blocked from new deploys pending a Supabase plan upgrade). To explore: play any of the three live games, check today's leaderboards for the daily games, and review the internal measurement readout (ask the owner for the unlisted URL). To continue building: resolve the published-site limit by upgrading the Supabase plan to Pro ($20/month) or archiving another business's site from that account. The next game in the pipeline (Quenchhold, a seeded ten-room RPG) is waiting on that clear.