DEV Community: Renderscribe

I Built an Idle Game With an AI Pair Programmer. Here's What Actually Got Hard.

Renderscribe — Wed, 30 Sep 2026 09:55:34 +0000

I've spent the last few months building Galactic Idle, a space-empire incremental game, using Vue 3, TypeScript, Capacitor (for Android), and an AI pair programmer. This isn't a "AI will replace us" or "AI is overhyped" post. It's a field report on where the time actually went.

Short version: the AI collapsed the cost of writing code. The hard parts moved somewhere else.

The stack

Vue 3 + TypeScript + Vite for the game and UI
Capacitor to ship the same code as an Android app
Vitest + Playwright for unit and e2e tests
PostHog for opt-in, consent-gated analytics
Nine locales, with a coverage check so missing translation keys fail loudly

All game state lives in one big composable, useGameStore.ts. That is not a recommendation. It's a confession, and it's why I'll come back to cleanup in a minute.

What the AI made cheap

Things that used to cost me days and now cost me an afternoon:

Wiring a consent-gated analytics layer that forwards from a central logEvent function
i18n across nine languages
A trailer capture rig: a Playwright script that plays the game with an injected cursor ghost and a virtual clock, then renders both 16:9 and 9:16 gameplay trailers. I'll probably write that one up separately.
Refactors that touch dozens of call sites, like replacing scattered toast() calls with a structured logEvent/grantResources spine and result cards

If your bottleneck was "I know what I want, I just have to type it," you'll feel this immediately.

What it did not make cheap

1. Balance is a data problem, not a code problem

Idle games are economies. Early on, tapping was too strong, so I capped clickPower (5000 → 900) and sqrt-dampened the upgrade stack. Then conquest rewards were too generous, so I cut the ×3/×5 global reward upgrades. The AI implemented each change in minutes. Knowing which change to make required numbers.

So I gave myself a way to get them. The store exposes a hook that only exists when the URL contains ?__sim:

// Balance-sim hook — only active when the URL contains ?__sim
// Lets an offline harness fast-forward the real economy and read/drive it.
// VITE_SIM_HOOK=1 opts a production build in (scripts/capture-trailer.mjs builds that
// into dist-capture/ so the shipped bundle never carries the hook).
if ((import.meta.env.DEV || import.meta.env.VITE_SIM_HOOK === '1')
    && typeof window !== 'undefined'
    && /(\?|&)__sim\b/.test(window.location?.search ?? '')) {
  ;(window as unknown as { __SIM: unknown }).__SIM = {
    store: useGameStore(),
    tick, recalc, cleanup, fireRandomEvent,
    setDtCap: (v: number) => { _tickDtCap = v },
  }
}

A Node script drives a headless browser, calls tick with a raised dt cap, and reads the real store, not a re-implementation of the economy that can drift from the real one. That's the bit I'd recommend stealing: simulate the real code, not a model of it.

What it found: after the nerfs, content lasts roughly 8 to 20 hours, and there's a credits-negative trough somewhere around hours 3 to 8 that I never would have noticed by playing. I only found it because I could fast-forward.

2. The data told me I was fixing the wrong problem

I shipped opt-in PostHog analytics and looked at the first real numbers:

~40% of players left before completing their first goal
Median playtime: 5 minutes
The funnel cliffs were building → research → ship

I'd been agonizing over a 2-hour progression wall. The real problem was the first five minutes. No pair programmer, human or otherwise, was going to tell me that. Only data does.

One practical gotcha for anyone doing the same: my session_end event turned out to be effectively a heartbeat, so raw counts were inflated until I deduped. Check what your events actually mean before you trust a funnel.

3. Fast code generation grows dead code

When implementation is cheap, it's very easy to end up with a parallel, half-abandoned copy of your own app. I did. A "product cohesion" audit deleted a whole dead parallel app stack, merged two drifting friction models into one upkeep system, and merged two overlapping conquest features into one.

Rule I now follow: every time the AI adds something, I ask what it replaced. If the answer is "nothing," that's a smell.

4. Offline earnings are a design decision hiding in a number

Offline income is capped to up to 30 seconds of live production, with plasma excluded. That one line has generated more back-and-forth than most features, because it's balance, monetization (there's a rewarded-ad hook to boost it), and retention all at once. The code is trivial. The decision isn't.

What I'd tell another dev

Give the AI a clear goal and a way to verify. It's fast when it can check its own work (tests, a sim, a build) and confidently wrong when it can't.
Build measurement early. Analytics and a simulator will teach you more than any amount of playtesting on yourself.
Treat deletion as a feature. Budget time for cleanup, because generation makes mess cheaper too.
Never let a secret touch tool output. I learned that the hard way with a token. Pipe or assign directly, always.
Expect your job to shift from "person who writes the code" to "person who decides what the code should do and checks that it did."

What's next

The next post in this series digs into the capture rig and how the virtual clock keeps trailers deterministic. If you've built an idle game or any economy-driven app, I'd love to hear how you approach balancing, and especially how you handle the first-five-minutes problem.

Galactic Idle is live on itch.io and in progress for Google Play. I'd genuinely love to hear where the first five minutes lose you.

Systemic Interactions & Emergence: The Depth We Didn't Design

Renderscribe — Wed, 16 Sep 2026 10:50:24 +0000

Notes from building Galactic Idle, a browser/mobile idle empire builder

Every idle game starts as a spreadsheet: resource in, resource out, multiply
by upgrade, repeat. The genre's real trick isn't the spreadsheet — it's what
happens when you stack five or six spreadsheets on top of each other and let
them read from the same state. That's where the interesting behavior lives,
and almost none of it is behavior you designed. It's behavior you
discovered.

Here's what that's actually looked like for us, with the real code behind
each example.

The setup: independent systems, shared state

Galactic Idle runs on five resources (energy, minerals, credits, research,
plasma), a building economy, a research tree, a conquest layer, a diplomacy
layer, and — the piece that turned out to matter most — an Upkeep
system: ongoing drain across four facets (Power, Fleet, Research, Colony)
that scales as a capped percentage of gross production, growing with empire
size.

None of these were designed together as one mechanic. Upkeep was bolted on
specifically to solve a problem: once a player had enough buildings,
production compounded without resistance and the back half of the game
turned into watching numbers go up with no decisions left to make. Upkeep
was the fix — friction that scales with success.

What we didn't fully predict was what Upkeep would do once it started
talking to the other systems.

Emergent tension #1: conquest now competes with itself

Conquering planets is supposed to feel unambiguously good — more territory,
more resources, more empire. But Upkeep's Colony facet reads how many
planets you've conquered as one of its inputs:

let flatColony = 0
for (const p of state.planets) if (p.conquered) flatColony += p.strain
flatColony *= fx.colonyStrainMult
// Admin load grows with colony structures, not just planet count, so
// stacking them to maxCount is self-limiting on the minerals side.
const colonyAxis = conqueredCount.value + totalColonyBuildings.value * 0.35

And the generic upkeep function that consumes it doesn't know or care that
colonyAxis came from Conquest — it just sees a number that scales drain:

function applyUpkeep(
  facet: UpkeepFacetId,
  gross: number, flat: number, axis: number, reductionMult: number,
  skimSurplus = false,
) {
  const t = UPKEEP_DRAG[facet]
  const dragPct = Math.min(t.cap, Math.max(0, axis) * t.perUnit) * reductionMult
  const base = skimSurplus ? Math.max(0, gross - flat) : Math.max(0, gross)
  const f = upkeep[facet]
  f.flat = flat
  f.dragPct = dragPct
  f.drain = flat + base * dragPct
  return f.drain
}

dragPct is a percentage of gross production — not just the new
planet's production, all of it. So every planet you take doesn't just add
resources; it adds to the denominator that skims off the top of your
entire empire.

That means aggressive early conquest — which looks correct from a "bigger
number is better" instinct — can actively work against a player who hasn't
built up the production base to absorb the extra drain. Nobody wrote a rule
that says "don't over-expand." It fell out of two systems (Conquest,
Upkeep) that were never designed to talk to each other, connected only by
reusing the same empire-size variable.

We only found this by running it, not by reading the code. Once
conquest-heavy playtests started stalling out, we traced it back to
colonyAxis reading conqueredCount as an input it was never explicitly
balanced against. That's the emergent-depth story working in our favor: a
genuine strategic trade-off (expand fast vs. expand sustainably) we get
credit for without having designed it directly.

Emergent tension #2: the fix and the disease share a cause

Command Points — earned from conquest and mid-tier goals — fund a Doctrine
tree gated by planets conquered. On paper, this is a completely separate
progression track: spend a currency, pick a branch, get a bonus.

In practice, Doctrines became the system that makes emergent tension #1
survivable. A player who over-expands and gets hit by rising Upkeep has, by
virtue of having conquered those same planets, also unlocked Doctrine tiers
that can offset the drain (de.colonyStrainMult, de.fleetUpkeepMult,
etc., feeding straight back into applyUpkeep's reductionMult argument
above). The two systems weren't built as a matched pair, but because they
both key off the same underlying variable — planets conquered — they ended
up in a feedback loop: the thing that causes the pain and the thing that
funds the cure grow at the same rate.

That's not something a design doc predicted. It's something that fell out
of reusing one game-state variable as an input to two unrelated systems —
which is, in miniature, the entire argument for why emergence tends to come
from shared state, not from any single system's internal complexity.

Emergent tension #3: the one that was a bug, not a feature

Not every emergent interaction is a gift. A player on itch.io reported that
building costs "don't go up until they're actually completed, so you can
queue up a ton of them at a really low cost." Here's why:

function getCost(b: Building): Partial<Resource> {
  const out: Partial<Resource> = {}
  for (const [r, v] of Object.entries(b.baseCost)) {
    if (v !== undefined) {
      out[r as keyof Resource] = Math.ceil(v * Math.pow(b.mult, b.count))
    }
  }
  return out
}

getCost scales off b.count — units actually completed. Compare that to
buyBuilding, which queues a purchase:

function buyBuilding(b: Building) {
  const cost = getCost(b)
  if (!spend(cost)) return
  // ...
  if (buildQueues[b.id]) {
    buildQueues[b.id]!.count++   // <- a SEPARATE counter from b.count
  } else {
    buildQueues[b.id] = { progress: 0, timeLeft: t, totalTime: t, count: 1 }
  }
}

buildQueues[b.id].count and b.count are two different numbers, and
getCost only ever reads the second one. Queue ten of the same building
and every one of them prices at the first unit's cost, because none of
them have "completed" yet as far as the cost function is concerned. Neither
function is wrong in isolation — the interaction between them is wrong.

The interesting part: we'd already solved this exact shape of problem
somewhere else in the codebase. buyColonyBuilding (a different building
category, with hard caps) already accounts for owned plus queued:

function buyColonyBuilding(cb: ColonyBuilding) {
  // Built + already-queued must never exceed the cap — otherwise queuing
  // a batch up front keeps constructing past maxCount as each one finishes.
  if (cb.count + (buildQueues[cb.id]?.count ?? 0) >= cb.maxCount) return
  // ...
}

The fix pattern existed in the codebase before the bug was even reported —
it just hadn't been applied everywhere the same category of interaction
could occur. The practical lesson: once you know two of your systems share
state in a way you didn't fully map, go looking for every other place the
same shape of interaction could be silently happening. It usually is.

How we actually find this stuff

We don't rely on hunches. The game exposes a debug hook that lets an
external harness drive the real simulation loop, not a separate model of
it:

// Balance-sim hook — only active when the URL contains ?__sim.
// Lets an offline harness fast-forward the real economy and read/drive it.
if (typeof window !== 'undefined' && /(\?|&)__sim\b/.test(window.location?.search ?? '')) {
  ;(window as unknown as { __SIM: unknown }).__SIM = {
    store: useGameStore(),
    tick, recalc, cleanup, fireRandomEvent,
    setDtCap: (v: number) => { _tickDtCap = v },
  }
}

A headless script loads the page with ?__sim, waits for window.__SIM,
and then calls tick() in a tight loop with an inflated dt cap — the
exact same tick/recalc functions a real browser session calls once a
frame, just run thousands of times a second with no rendering in between.
When we tune one system, we re-run the harness across the entire game
arc, not just the system we touched, specifically because the interesting
failures show up two or three systems away from the one we edited.

The most recent finding from that harness: a tuning pass on research costs
eliminated a "front-loading" exploit where the early game moved faster than
intended — but in fixing it, produced a new credits-negative trough three
to eight hours in, a dip that existed in neither the pre-nerf nor the
intended post-nerf design. Nobody wrote that trough into a spec. It emerged
from two changes that were each individually correct.

The actual takeaway

"Emergence" gets talked about like a feature you add. It isn't. It's a
cost you pay for having systems that share state at all, and the only
lever you have is how fast you notice it — through simulation, through
player reports, through deliberately stress-testing the seams between
systems instead of just the systems themselves.

If your game has more than two or three systems reading the same
underlying numbers, you don't get to choose whether emergent behavior
happens. You only get to choose whether you find it before your players do.

Turning game telemetry into better onboarding decisions

Renderscribe — Wed, 09 Sep 2026 08:57:49 +0000

The most useful analytics result is not always a surprising number. Sometimes it is the moment when the data shows you where your assumptions end.

That happened with Galactic Idle.

The first five minutes told us more than the late game

We shipped opt-in, anonymous analytics and looked at the first 15 real players. This is a tiny sample, so it is not a retention study or a claim about our audience. It is a directional signal: enough to tell us where the onboarding deserves attention.

The early funnel looked like this:

Milestone	Players	Share
Opened the game	15	100%
Reached the first goal	8	53%
Reached Industrial Revolution	6	40%
Played past seven minutes	3	20%
Reached the endgame	1	7%

The median observed playtime was five minutes. Six people never produced a game event at all.

That immediately changed the question we were asking. We had been thinking about mid-game balance: research costs, content density, and the economy after the first hour. But most new players were not getting anywhere near that part of the game.

The onboarding problem was earlier.

A funnel is useful, but only if the events are meaningful

Our first implementation was goal-heavy. We recorded milestone goals, so the data gave us a clear view of progression after a player started playing.

It also created a blind spot.

There was an app_open event, then eventually a first goal. Between those two points, we recorded almost nothing. When someone opened the game and left before the first goal, we could see the drop-off but not the cause.

That gap might mean:

the game was slow to become interactive;
the title screen did not make the next action obvious;
the first screen was confusing;
the player simply decided the game was not for them.

Those are four different product decisions. A single “player left” number cannot distinguish them.

The lesson was simple: instrument the questions you want to answer, not only the achievements you are proud of.

What we added to the first 90 seconds

The next build adds a small set of events around the opening:

app_ready records when the game becomes interactive and includes the load time.

first_interaction records the first meaningful tap or building action.

tutorial_step records progress through the opening sequence.

session_end records the session duration, furthest milestone, tap count, and a resource snapshot.

app_resume separates a return to an existing page from a genuinely new open. This matters because fullscreen toggles and iframe reloads can otherwise make one sitting look like several sessions.

None of these events needs a name, email address, session recording, or a replay of what a player did. They answer product questions while keeping the collection deliberately narrow.

Turning observations into onboarding decisions

Telemetry is not the fix. It is the instrument panel that helps you choose the fix.

For example:

Observation	Likely next decision
Long delay between `app_open` and `app_ready`	Reduce startup work, improve loading feedback, or show a clearer ready state
`app_ready` is fast but `first_interaction` is missing	Improve the title screen, affordances, and first-call-to-action
Players interact but fail to reach the first goal	Rework the opening objective or explain the feedback loop
Players reach several goals, then disappear in a burst	Reduce the early goal firehose and add breathing room
Sessions end before the first system unlock	Move a meaningful glimpse of the wider game earlier

This is the difference between “our onboarding has a 53% conversion rate” and “we need to learn whether the first minute is slow, unclear, or simply unappealing.” The second statement leads to a testable change.

The activity log was a clue, not a conclusion

One screenshot from a fresh save showed a wall of notifications: Solar Pioneer, First Spark, Mineral Extraction, Open for Business, Solar Farm, Industrial Revolution, and several unlocks in quick succession.

The log looked exciting. It also explained why the opening might feel noisy.

Goals were intended to provide pacing. In practice, several of them fired within the first few minutes, then the game became quieter while the player was still learning what mattered. The data did not prove that the activity log caused people to leave, but it gave us a concrete hypothesis to test.

That is a healthy role for analytics: narrow the search space, then let design and player feedback do the rest.

What the data still cannot tell us

Fifteen players are enough to find a suspicious cliff, not enough to declare a universal truth. We still need to measure:

whether the same pattern holds across more traffic;
whether players return on another day;
whether the first conquest becomes a stronger onboarding milestone;
whether changes to the title screen and early goals improve the funnel;
whether the English-only interface affects players in non-English locales.

We also need to be careful with our definitions. app_open is not automatically a session, and a missing event is not automatically a negative experience. Better instrumentation reduces those ambiguities, but it never removes the need for judgment.

The practical takeaway

Start with the smallest set of events that can answer the next onboarding question.

For a new game, that might be:

When is the game ready?
When does the player first interact?
What is the first meaningful outcome?
When does the session end?
What was the furthest useful milestone?

Then connect each event to a decision you are willing to make. If you would not change the game based on the result, the event probably does not belong in the first version of the dashboard.

The best outcome of our first analytics pass was not discovering that the endgame was too hard. It was realizing that we had been trying to optimize a part of the game most new players never saw.

Before tuning the galaxy, we need to make sure players can find it.

Galactic Idle analytics are opt-in and anonymous. We do not collect names, email addresses, IP addresses, or session recordings. Players can disable analytics in Settings.

Building Galactic Idle: Our First Public Balancing Pass

Renderscribe — Mon, 07 Sep 2026 17:22:28 +0000

We recently released the first public build of Galactic Idle, a browser-based sci-fi strategy game about resource management, research, fleets, and planetary conquest.

Play it here:

Galactic Idle

The game is built around a simple loop:

Generate resources.
Invest in buildings and research.
Grow your fleet.
Expand across the galaxy.
Return later and decide what comes next.

The challenge has been making that loop feel rewarding without allowing progress to become meaningless.

The balancing problem

Idle games have a difficult balance to find.

If resources accumulate too slowly, players feel blocked. If they accumulate too quickly, the player can return after a short absence and immediately unlock half the game.

We have been tuning:

Offline resource accumulation
Building and research costs
Production rates
Fleet growth
Planet conquest requirements
Ten-minute conquest timers
Mission rewards
Research progression
Resource caps and economy pacing

Our current goal is for progress to feel generous early on, but increasingly deliberate as the player expands.

What we are trying to learn

We would especially value feedback from developers and players who have worked on idle, incremental, strategy, or management games.

A few questions we are investigating:

How long should a player be away before offline rewards feel meaningful?
What percentage of normal production is reasonable for offline progress?
When does a resource cap become helpful structure rather than frustration?
Should conquest timers be shortened by research, fleet upgrades, or special bonuses?
How many meaningful decisions should a player make during a typical ten-minute session?
How do you communicate that a slow upgrade is building toward a larger strategic payoff?
How do you prevent late-game numbers from making early systems irrelevant?

We are also interested in how players interpret the economy. A resource can be mathematically balanced and still feel wrong if its purpose is unclear or its feedback is too subtle.

What we have learned so far

One lesson is that visible feedback matters as much as the underlying numbers.

Players need to understand:

What they can afford
What they are working toward
Why a resource matters
What they will receive for completing a goal
How long a timed action will take
What changed while they were away

We have added requirement tooltips, mission reward reminders, planet information panels, conquest timers, and next-goal notifications to make those relationships clearer.

The numbers still need testing, but clearer information makes balancing feedback much more useful. A player can tell us that a conquest feels too slow only if they understand how long it is supposed to take.

We would love your feedback

If you try Galactic Idle, please tell us:

How far you progressed
How long you played
Which system felt most satisfying
Where progression felt too fast or too slow
Whether the offline rewards felt fair
Whether the conquest timer created anticipation or friction
What you would change first

Specific examples are especially helpful. “Research is too expensive after the second tier” gives us something actionable to investigate.

Give us feedback here:

Post Feedback

We are sharing the game early because balancing is better when it happens in conversation with real players. If you are also working on an idle or strategy game, feel free to share what balancing problem you are currently wrestling with.

Background music by DavidKBD, used under the applicable license: https://davidkbd.itch.io/

gamedev #indiedev #webdev #gamebalance #indiegames