Let's talk about game engines

Larithea has a custom engine, built by me — and it is not an engine in the traditional sense.

Let's back up a bit. I had several versions of Larithea. The one before last I was working on while at Immutable. But early in 2026 I got stuck with the latest React Native build. I was using AI more and more, and I could not get the results I wanted — it felt like fighting the AI every step of the way. I checked every line of code, tried to understand why I was getting slop, and overall felt very unproductive.

So I made a "Jesus take the wheel" commitment.

I restarted the build, defined the technology, the architecture and the stack — and each time I wanted to write code, I wrote a skill instead. It was unbelievably painful. It felt like I had no control over anything. I only looked at code when it was in a PR, and I only made PRs when dev was ready for staging.

But I think it was a mindset correction I needed. Instead of caring deeply about HOW I get to the end (feature, functionality, test), I focused on WHAT GOOD LOOKS LIKE. Instead of crying about AI slop, I had to ask myself: "What made the AI write this slop? What information does it need so it doesn't?" Each time we finished a new piece of work, there was a step: "now let's turn this into a skill." Not a smooth ride. But a very interesting experience for me. Very new!

The number of times I had to sit on my hands and change the skill instead of editing the code… what an exercise of will that was.

Slowly and painfully, we got to the point of Claude producing reliable code that does what it is supposed to do.

Here are some of the skills we developed over time. They are the current base of the engine:

Translation skill + automation set: uses two languages to create the third, with automation that won't let a single unapproved string into the game. Deserves a separate post. It is very cool!

Add base trigger: add a new tappable trigger (panel, friend dialogue, examine hotspot, enemy fight, exit) to a walking location: every file to change, in order, plus the gotchas.

Add character sprite: build and register sprite-sheet animations for a new character (hero, NPC, or enemy) from the master sprite sheet.

Add fight field sprite: add a hero's in-battle sprite sheets and size-align them across poses and against the other heroes.

Add quest: plan and wire up a side quest end to end: design decisions and approvals first, then a fixed implementation order (giver → entry trigger → scenes → aspects → dialogues → tail items).

Add scene: insert a battle or story scene into a chapter (wiring, sigil shuffling, economy rebalance, follow-up checks).

Design system skill: also needs a separate post, because I live in a world of luxury now: I can have a design system, thanks to AI.

Hero voices: a voice reference for the five Chapter 1 heroes, with cited example lines and "avoid" notes, used whenever any hero speech is written or reviewed.

Those are the non-technical skills. There is an array of technical ones too, like e2e tests, Windows testing on a Vagon cloud machine, querying game data, and so on.

I consider this my engine. It is a level of abstraction on top of the typical engine actions, one that lets Claude perform them stably and in alignment with the architecture. And unlike a traditional game engine, I don't have to work around someone else's idea of what a game engine should do.

Of course, I can get away with this mostly because of the stack. React Native + Node.js + Postgres gives me the full power of the AI. And no physics plus 2D graphics means I can mostly reuse display tools that already exist.

To be clear, this is not a "look at my AI harness" post. It is about the different way of thinking I had to force on myself so the AI could do a better job. And yes, I still scream at it - especially when we do translations. (I can comfortably scream at it in two languages now, which is very helpful!)