Even a simple game used to take a long time
Before The Gate, I had already worked on several side projects. Around 2024, some encouraging results with AI Doodle Design made me wonder whether I could take on something more complex. That brought me back to an idea I had kept putting off: making a game.
After more than 30 years of playing games, I knew what I liked. I wondered what would happen if I combined that taste with my experience as a product designer. I wanted to decide for myself what players could choose, what rewards they would get, and what would make them want to keep going.
In 2024, I started developing with the Godot game engine and Grok. Once I got into it, I found that what I could actually do with AI was still quite limited. Even getting a very simple game running took an enormous amount of time. It nearly ended there, as something I had tried once.
The following year, Figma Make gave me a reason to try again. This time, I could make a fairly convincing mini-game. It was clearly a step forward, but a game with my own world and enough depth to stay fun over a longer play session still felt out of reach.
The first prototype with Fable felt different
In 2026, seeing what people were making with Claude's Fable made me feel it was time for another attempt. With a detailed enough design, perhaps I could make the game properly this time. I worked through a design document in conversation with Claude and built the first prototype.
Playing it for the first time was genuinely exciting. I could attack, dodge, and parry an enemy's attack. The boss I had asked for appeared, and defeating it led to a reward. The graphics were rough, but I was already playing through the combat I had imagined.
From there, I gradually shaped it into the game I wanted. By then, I was also using AI extensively at work and contributing to real code. Having already learned a little about how to explain what I wanted and what to check made a difference here, too.
The game begins in modern cities much like the ones we live in. Mysterious gates appear around the world, and monsters emerge from them. The protagonist helps people and defeats regional bosses, gradually discovering why the gates appeared.
I wanted players to fight as cute pixel characters, with a story that revealed things they would not notice on their first run. Ideally, the combat would get them started, and curiosity about the world would make them stay.
Getting from that first prototype to the game as it is now meant running into quite a few problems I had not anticipated.
My friends found very different difficulty levels in the same game
The thing I did most was play. I played it myself, asked friends to try it, and watched where they got stuck. Their reactions to the same game were surprisingly different.
One friend who was unfamiliar with this kind of game kept dying before beating the first map's boss. Another, who was used to roguelikes and demanding controls, regularly topped the leaderboard. They brought different gaming experience and different levels of skill with the controls.
I realized that what felt like the right difficulty to me could not be the standard for everyone. Someone struggling with combat might want to see more of the story but be unable to get there. A skilled player needed a reason to keep fighting once the combat became familiar.
In Novice mode, I increased the protection and benefits players received after taking a hit. I also adjusted HP and attack power in their favor. I wanted to make clearing the game less demanding so they could concentrate on the story.
For experienced players, I adjusted enemy attack power, attack speed, movement speed, and projectile frequency at higher difficulties. Attacks became harder to avoid than in Standard mode, and I removed the brief invulnerability period after being hit. The highest scores would also require playing at the hardest difficulty.
Changing numbers alone could make the difficulty feel very different. But setting them once was not enough. I needed to keep playing, watching other people, and adjusting.
So I built a separate admin interface for balancing the game. I could change frequently adjusted values such as HP, attack power, attack speed, and movement speed, then deploy them myself without asking an agent for every edit. I wanted to fix what I had just felt during a run and try it again straight away.
What would make someone play again after clearing it?
Alongside difficulty, I kept thinking about the reason to start another run. A short combat clip can make a game look quite convincing. But when someone actually plays, something has to follow the boss fight. I had to decide what to reward them with, where to send them next, and how to make that next step clear.
Collecting the story across different cities
In The Gate, each run takes players through three of the eight maps. Defeating a regional boss gives them a fragment of the truth. The fragments from those three regions open a path to a dimensional gate, where a fight with its guardian ends the run.
That still leaves cities they have not visited. Unlocking other maps introduces new monsters, different boss attack patterns, and more pieces of the story. Clearing all eight maps brings players closer to the deeper reason behind the gates.
Hades was a big inspiration for this structure. I liked how players could have different experiences through their choices while repeated runs gradually led toward a shared truth. In The Gate, I wanted people to notice clues they had previously missed and connect what they had learned to reach the story for themselves.
Trying the attacks before choosing a class
Not everyone will return for the story alone. I wanted the combat itself to feel good even for someone who only played once or twice. That meant paying attention to the impact of attacks and how players chose their fighting style.
Players start as the Hero, the basic class. A light attack hits enemies up close, while a heavy attack fires a projectile. The heavy attack can be tapped or charged. Rather than picking a class from a description before playing, they get to try both kinds of attack first.
Collecting a currency called Dimensional Stones lets them change class. Someone who enjoys fighting up close can become a Warrior, with stronger melee attacks. Someone who prefers projectiles can become a Mage. I wanted weapon and class choices to help people approach the same fight with different strategies.
Some might return to learn more of the story, others to try another class, and others to improve their leaderboard record. Even if the graphics change a lot, the feel of combat and this class system are things I want to keep.
The graphics started to fall apart when they moved
As I kept playing, the original code-generated graphics bothered me more. They were enough to check whether the game worked, but what I wanted was cute, appealing pixel characters. Seeing those characters move and fight would help bring me into the world I had imagined.
This was a side project, and making it look like something I actually liked was not something I wanted to give up. After the first Fable prototype, I turned to PixelLab to generate pixel-art game assets.
The characters looked much better than the early graphics. But turning them in another direction could change their appearance, and adding movement sometimes distorted their hands or bodies. A character that looked fine standing in one direction still had to look like the same character when walking and attacking in another.
Assets that looked fine on their own felt much less consistent when animated in sequence. Producing one image I liked was not enough.
Working on code and images together in Codex
Around this time, the release of Sol in Codex became another important turning point for me. With the more capable model, I felt I could make meaningful progress on development with an agent entirely within Codex. Being able to generate images natively in that same environment made it especially appealing.
I moved the work to Codex when I wanted to develop the characters, maps, world, and story in more detail. Since then, I have used Sol, Luna Max, and more recently Astra. I wanted to develop the code and graphics together without losing the style and design I had established.
First, I set detailed visual guidelines for the characters, maps, story, and game as a whole. I created reference images, then prepared views of the same character from different directions. Those became the basis for sprite sheets containing the frames of walking and attacking animations.
To repeat this work, I put together skills and production workflows, and ran an Asset Lab and a Map Lab. I needed somewhere to keep making and checking the assets that would actually go into the game. This process also helped me improve the cutscenes and storytelling considerably compared with the early version.
Even then, a missing pixel or two or an awkward frame in a particular movement could remain. I wanted to be able to spot those problems and fix them myself.
So I built a Figma plugin and a pixel-editing setup for my own use. I could bring sprite sheets onto the canvas and fix individual details, much like working in a pixel editor. I could already judge what looked wrong as a designer; I wanted to fix it in a familiar tool. Building a small tool of my own had become much less of a burden, too.
Seokchon Lake made me change my approach to maps
Maps had a similar problem. I made assets in various sizes while trying to keep their pixel scale and shapes consistent. They could look fine individually, then lose that consistency when placed together in the game.
My first approach was to prepare modular assets and ask AI to combine them into a complete map. The most baffling result was Seokchon Lake.
I asked it to build the lake using the assets we had made together. It put a shape inside the lake that looked like a raised middle finger. The map itself was rough, but I could not understand why it had produced that particular shape.
When I asked, the AI claimed it could not depict Lotte World for copyright reasons and had represented only the site. It said the finger-like extension was the bridge leading to Lotte World. But a bridge should connect all the way to the shore, shouldn't it? This one stopped halfway. The explanation did not make it any more convincing.
I thought the modular approach could improve with more time. At that point, though, I was more interested in releasing the game and finding out whether it was fun. Rather than keep trying to perfect map production, I needed a way to finish the maps I could use now.
So I reversed the process. I would generate an entire map as a high-resolution image first, then place the information the game needed over it using vector shapes.
I defined collision areas so characters could not walk through walls, along with enemy spawn points, places that needed to open or close, and treasure chest locations. Looking at the picture, I worked out what could move where.
The downside was that changing the map graphics meant editing the information placed over them again. It created more manual work than assembling modular assets. Still, I decided that completing the ten map images I had prepared this way would let me release the game.
I spent the time lining them up one by one, and this is still how the game works today. Eventually, I want individual map assets to carry information such as collision areas so they can be assembled as modules. But even without solving that perfectly, I wanted to put out a game people could play.
As the game grew, I had to change how I worked
Fixing combat, changing graphics, and adding features meant the requests I made of agents kept growing. I try to explain the situation, what is not working, and how I would like it to improve in as much detail as I can.
But I had one repository and several kinds of work happening at once. There were small fixes, large features, and times when I wanted to analyze a problem or ask for advice. One session could not comfortably handle all of it.
I created separate sessions for small issues, larger features, and analysis and discussion with me. I assigned roles to different models, too. To work that way, I also had to understand how software development worked and how much responsibility to give each session.
Then requests from earlier conversations started getting lost. Asking for several things at once could result in some being skipped. Sometimes an agent said it had finished something that had not actually been applied. As requests grew from dozens into thousands, my own memory became a limitation as well.
I could not remember every problem, when I had found it, or where I had reported it. I also needed a place to keep images and explanations so I could return to an issue later. Even if I did not fix it immediately, I needed to understand what had been wrong when I came back.
So I created a GitHub project and issue board, just as I would when working with people. Each request became an issue with its situation and specifications written down. Having a record I could revisit after a conversation meant I no longer had to rely only on my memory and an agent's reply.
Making the work more explicit helped me keep deploying and running the live game more reliably.
The leaderboard looked fine until a developer friend checked it
UX, graphics, and the fun I felt while playing were relatively easy for me to judge. I could see what felt wrong, explain what I wanted, and check the result.
Security, CDNs, server and resource costs, and development stability were different. These were areas I had not worked with deeply as a designer. Sometimes I did not even know what needed improving. Advice from developer friends was especially valuable here.
The first leaderboard recorded a score from the browser after a player cleared the game. They could enter a nickname and compare their rank with other players. As far as I could see, it did what it needed to do.
Then a developer friend pointed out that scores and nicknames could be changed arbitrarily through another route. I used that feedback to fix the problem with AI. If I had built and checked it entirely on my own, I probably would not have noticed.
I had made the leaderboard to give people the fun of improving their record, but I also had to make sure those records could be trusted. Releasing and running a game meant checking things I was not naturally equipped to see.
There is still a lot to improve, but I can keep building
If I had to score the graphics today, I would give them about six out of ten. Consistency across directions and movements still needs work, and I want to improve map production. I expect better models and a better workflow to help, but I have not fully solved these problems yet.
Even so, making the game has been genuinely exciting and enjoyable. I could get surprisingly close to something that had only existed in my head, then play it myself. When I found something I wanted to change, I could go back and change it.
Just a year earlier, getting a new design into a real product meant plenty of discussion, technical review, and coordination between stakeholders. It inevitably took time before I could see the result, judge it, and improve it.
With The Gate, I could try what I wanted and work through what I did not yet understand by asking questions with AI. The process itself was so enjoyable that I kept working on the game during my days off. I had made just one GitHub contribution in 2025, but found myself making over 3,000 in the first half of this year alone.
What began as a side project to make a game that suited my own taste grew into something much larger. I was designing how players understood their next action, why they would try again, what a dedicated player might discover, the characters and maps, and deployment and operations. I was making and improving a substantial digital product on my own terms.
