It's Your Town: Building a game together with AI
It's Your Town is a browser game I designed not only for building a city but for spending a little time inside the city you build. Placing buildings, laying out streets and watching the town grow is one part of the experience. The other part is listening to music while you watch that town through the eyes of a cat, a boat, a train or an airship.
My goal was never a big game prepared behind closed doors for years. I wanted to build a small but finishable experience first, then grow it with new buildings, animations and mechanics.
From an idea to a working town
The technical foundation is TypeScript, Three.js and Vite. The 3D world runs in the browser; models made in Blender are exported in a game-ready form and added to that world.
I split development into small steps. First came building placement and camera controls, then the floor system, roads, bridges, moving vehicles and life in the city. Every new feature was tried on top of the existing experience.
That approach shaped design decisions too. Instead of letting buildings scale freely, I chose a system where taller floors unlock as the city grows. It kept the technical complexity in check and let the town rise in a balanced way.
Several models, one shared project memory
In this project I did not use AI as a tool that writes code once, but as development partners I could lean on for different tasks. I worked with models such as Codex, Claude and GLM on coding, bug analysis, optimisation and design. Product direction, priorities and final decisions stayed with me.
The real challenge was not running models at the same time but making sure each could understand what the others had done. Each chat has its own memory; the project is one. So I put the documentation in the project folder, not the conversation history, at the centre of the process.
Markdown documents recorded the architecture, design decisions, task boundaries, test results and open issues. Document indexes showed where each piece of information lived, and short project memory notes let a new session catch up on the current state.
That way one model could review work another had left behind without me retelling the whole conversation. The result was a way of working built not on models constantly talking to each other, but on a shared, traceable record.
Checking matters as much as generating
I never accepted a model saying "done" as enough on its own. Passing changes through another review round, testing them and seeing them in the game became a core part of the process.
Performance work showed why. An optimisation can lower the processing load while breaking selection outlines, moving objects or fallback rendering. So we looked not only at FPS but at whether the behaviour players see stayed intact.
I used my own cities as test data. I reported visual problems with screenshots, videos and saved cities, so reviews happened not only on small, controlled examples but on towns that grew out of real play.
I steer, the contributions come from many places
In this way of working my role was not just writing prompts. Deciding how the game should feel, limiting scope, trying the results and choosing which suggestion to apply were at the centre of the process.
AI models sped development up; documentation helped keep that speed from turning into chaos. Keeping local development, pushing to GitHub and going live as separate stages also let me manage changes with more control.
Closing
For me, It's Your Town is both a game and an experiment in a way of making things: bringing together the contributions of different models around human direction and a shared project memory, to turn a small idea into a living experience.
