I've been keeping a journal on and off for 25 years, from handwritten notebooks at the start, to cloud notes synced between my phone and my computer, to md files now. The tools changed along with the times. On and off, because without a fixed mechanism forcing output, running on enthusiasm alone, it's easy to run hot and then go cold. When I was building this website at the end of July, I decided to try something else: throw each day's thoughts and progress into a materials inbox, let Claude go through it every week or two to see what's worth distilling or expanding, and then write the final version myself. Once a scheduled AI is chasing me every day about that day's progress, "remembering to write it down" gets solved by the system. What's left is the recording itself, and digging the useful parts out of my head. This post is the first batch that came out of it.
Crypto Adventure
Crypto Adventure is the web AVG I'm mainly experimenting with right now. Thanks to AI, I can finally start turning ideas I've carried for years into something real. The details are in another post you can click through to. Two things happened these two weeks: I fixed the save system, and I replaced the way the narrative is presented.
Saves: from seven days in the browser to auto-save on both local and cloud
Local saves and cloud saves used to run on two separate sets of logic, and they fought each other. Now there are slots for starting a new game, and local and cloud auto-save at the same time. The cloud side runs on Neon via Vercel.
Early in development I stored progress the simplest way possible, which was to keep it in the browser's localStorage. I was the only one working on the game, no multiple devices were involved, and it made testing easy. Then one thing changed my mind: Safari's localStorage has a seven day rule. If a player doesn't open your site for seven days straight, WebKit wipes the whole local storage. A player puts the game down for a week, comes back, and the save is gone. That's not a good thing for a game, so the idea of saving to the cloud came up. Going by my experience with nonograms (a picture logic puzzle I pull out whenever I want to relax my brain, 1000+ hours in by now), the simplest approach seemed to be giving each player an account, binding progress to the account, and uploading to the cloud in real time.
Sounds easy. It's just syncing, right? In practice, the more I built, the more questions turned up. What if devices A and B log into the same account at the same time but take different routes, so the files conflict? What if I keep playing on device A while it's offline, and device B hasn't progressed but is online, so device B carries the newer cloud timestamp even though A is actually further along? The moment A reconnects there's a sync problem, so how do you handle it? If a player chooses to start over, do you just overwrite the old save, and what happens to the entries they already collected? And if starting over means a second playthrough after finishing the first, is the logic even the same?
The more I thought about it, the more I ran out of room in my head. "Cloud sync" was never one phrase that could cover it. In the end it took GPT and Claude interrogating each other, revising the plan and fixing problems, before I could close the case for now.
Narrative: from visual novel back to traditional AVG
The narrative exposed another problem I created by jumping into implementation before thinking it through.
I wrote the story the way you write a novel. Straight narration blends everything together: what the scene looks like, which character does what, who says what. A traditional AVG is driven by dialogue and is closer to writing a script, where the different kinds of content have to be pulled apart. By the time I noticed, I had already implemented one story route, presented as passages that show up when you click, like reading a novel.
So I had AI research it: keep the current approach, or switch to a traditional AVG? The answer came back that plenty of popular games are narration style AVGs, players are used to the form, and keeping it would be fine. I didn't ask any follow-up questions or think hard about the real difference between narration driven and dialogue driven. I just took the conclusion.
Then I finished writing and connecting all the stories and gave it to Sama to try. He said there was so much text that it was tiring to read, and if there's character dialogue, why can't he see what the characters look like? It doesn't feel immersive. Also, the choices popping up from the bottom feel like an exam.
That's when I realized the quiet unease I'd been sitting on was justified. Narration style needs other game mechanics to hold it up, and minimal narration games that actually work are rare. Dialogue style has character art and background art, which pulls players into the story more easily. What I want to make is a game about character relationships driven by choices, and that fits the second kind.
So I changed it.
What I learned
- Practice does teach you things, but discussing and playing it out before implementing, until the plan is complete enough that there are no obvious holes and nothing left I'm unsure about, saves a lot of rework.
- Don't mix different features into one branch, let alone one commit. Rolling a single feature back cleanly gets very hard.
- After the switch from narration to dialogue, the biggest weakness of AI writing came out. It can write narration, but it's really bad at dialogue. Maybe it's because it comes out of English translated into Chinese; there's a flavor to it. I was always going to rewrite it myself and only wanted the structure and the story paths set down first, but right now it reads badly.
- I thought through how saves evolved in other games, from manual saves on a single machine, to multiple slots with both manual and auto, to cloud auto-save across devices. It's all trade-offs in how you allocate resources. I also finally understand why, when you get disconnected mid-game and log back in, your character sits a little behind where you left off.
AI Collaboration
April and now: three months apart, and a level apart
While reorganizing this website I noticed the last update was in April. Back then I was using the Codex plugin in VSCode and Gemini inside Antigravity, going sentence by sentence: describe, confirm, adjust. I described a lot and gave reference images, but whatever it couldn't do, it couldn't do. How many layers the "mountains" should have, which one sits on top of which, how to tune the colors: describing it out loud never got me what I wanted. Three months later, the current version of Claude produces a complete improvement plan on its own. It thinks about the whole picture, mocks up a few different versions, and shows you the results as images. The difference is big.
For fine tuning a design, Claude Design fits better. It controls each component through code instead of rendering a whole image in one shot the way GPT or Gemini do, so trying things out costs much less. You can put your designer through revision after revision :D.
Have a look at the covers I did for the presidential handover publication of the IMC (International Management Council) chapter:
My current global Instructions
Having a few principles pressing on me while I draft a plan keeps things from drifting and cuts down rework a lot. These are my current global Instructions:
- When settling on a plan, discuss and confirm it with me point by point if needed
- When building features, use Occam's razor: do not multiply entities beyond necessity
- When doing acceptance testing, use Murphy's law: anything that can go wrong will go wrong
- When solving problems, fixing bugs, or designing architecture or plans, start from first principles
- After finishing a relatively complex task, you may spin up secondary agents for adversarial review
- When handing tasks to sub-agents, run them through the Coase theorem first
- When generating presentations, no thinking process and no commentary, conclusions only. Every block must have clear boundaries, and the same content must not appear in two places
What I learned
- Planning, implementing, debugging: for anything even slightly complex, making a plan first beats jumping straight in.
- When making the plan, put first principles, Murphy's law, Occam's razor and adversarial review to work, which is what the Instructions above are there for.
- Running two different companies' models against each other matters too. I pass feedback between GPT and Claude with "my colleague said...", and they'll answer with something like "that's solid feedback, I checked it, and they're basically right", then give me a better plan.
- Plan, implement, find problems, fix them, fold the improvements into the docs, implement again. A few rounds of that and a workflow is more or less in shape.
- When I gave Sama the game to test, I started out explaining it to him in English, then just handed him the GitHub repo. He read the code himself, asked AI about it and came back with feedback, and he got the details of the game better than he would have from talking to me. These days sharing the repo is a lot faster than explaining out loud.