不惜一切代價也要發佈：AI 導師如何助我推出首款遊戲

For two years I tested games at a large studio. Then, while looking for my next job, I spent a month making and releasing my own pet project, Taveronen: The Beginning, a small, cozy idle game about a tavern, built in Godot. I made it together with an AI that became my mentor along the way.

In this post I'll explain why I believe finishing a game of your own is the best school for anyone who works in game development or is planning to get into it. For a beginner it lays a foundation, and for an experienced professional it offers a view of the project as a whole. I'll also share the pitfalls I ran into and explain why even a tiny solo release hurts in the same places as a big studio launch.

A Shelf of Unfinished Games

It all started at a local game dev meetup at the end of this summer. I'd been to meetups like that before, but that evening something else caught my attention: how many of the developers around me had never released a single game of their own.

I talked to people who had been working on their own projects for five years or more without ever finishing them, so their games stayed on the shelf for good. The reason was almost always the same. A new idea comes along that seems brighter at the time than the one already in progress, everything starts over, then the next idea arrives, and the cycle repeats. Of course, even an unfinished project brings experience and knowledge, but without a release a lot of that work seems to vanish into thin air.

A few months before the meetup, a friend and colleague of mine told me he had made a game on the principle of "release at any cost": not for anything material, but simply for the sake of releasing it. I didn't think much of it at the time, because I had no idea how many games never make it to release. After the meetup I saw it with my own eyes, and I got fired up about it myself.

Yes, "releasing for the sake of releasing" isn't the noblest goal. From the outside it can look like an urge to add one more throwaway game to an already huge stream of forgettable content. But I wanted to break through that wall of never shipping and find out first-hand where the real difficulties hide. There turned out to be plenty of them, and they're what the rest of this post is about.

Seeing a Game vs. Making One

As a tester, I worked on both large and small projects. QA experience really does teach you to see a game as a whole: how its systems connect, where they break, and what the player will feel when they do. But seeing a game and making one are completely different things.

I had tried to start my own game many times, and every attempt ended the same way: the engine was downloaded, installed, opened... and closed. I think a lot of people know that feeling.

This time I decided to approach it from a different angle and brought in an AI, Claude, as a partner. Not as a magic "make me a game" button, but as a mentor and a teammate who supplied content. It explained things and gave me code, while I put everything together in the engine myself: every scene, every script, every setting. The result was a tiny studio where I was the game designer and the AI handled the execution.

I picked a simple engine, Godot. It's lightweight, and several of my friends had already worked with it, so there was always someone to ask for advice. Next I'd like to try my hand at Unity or Unreal, whether for a sequel to Taveronen or a completely new game.

Taveronen: An Idea I Could Actually Finish

For my first project I deliberately chose the simplest idea possible and decided not to stray from it until release. That came easily to me, although I know how hard this kind of discipline is for others. My lack of experience became my safety net: I knew perfectly well that I couldn't handle complex systems yet, so I was never tempted to wander off into them.

Taveronen is a game about an abandoned tavern that you bring back to life. You start in an empty, cold hall where you earn one gold coin every second, and you spend that money at the shop on furnishings: first a fireplace, then a wall torch, chairs, a table, and so on.

Each purchase appears in the hall with a small animation, and every new item makes the tavern a little warmer. From time to time, purchased items start to pulse, and if you click them, you get a couple of extra coins. Once you've bought everything, you've beaten the game.

You can't lose, and there's no rush. The game runs at its own pace, so you can keep it open on a second monitor while you work, watch videos or play something else.

That's exactly what I love about the idle genre. Someone who rarely plays games, or stopped playing long ago, can still play one and feel part of the gaming community, and I think that's very valuable.

One special feature of Taveronen is its music. Instead of a short two-minute loop, the tavern plays a single calm track about half an hour long. It does loop, of course, but a full playthrough takes about that long, so the melody never has time to repeat and get on your nerves.

In the end, the game has seven items, three languages (English, Russian and Spanish) and two versions: one for the browser and one for Windows.

Under the Hood

Technically, Taveronen is simple, but in a single month I had to touch almost every part of development, so here's a quick tour of all of them.

Architecture. The entire game state (gold, purchased items and bonus timers) lives in one global singleton script, and the scenes simply ask it what to display. Thanks to this, the menu, the tavern and the victory screen barely depend on one another. The code is written in GDScript with static typing.

The tavern and its furniture. Every item has its own spot marked out in the hall in advance, and its sprite stays hidden until it's purchased. When the player buys something, it appears in that spot with a small animation: it pops up a little and fades in.

Graphics and atmosphere. The fire in the fireplace and the torch, as well as the blinking dragon, are frame-by-frame animations, with the warm glow painted right into the frames. The starry sky in the main menu is brought to life by one shader, with no extra images at all, and a particle system makes dust swirl in the beams of light coming through the tavern windows.

UI and fonts. The whole game uses one pixel font, and finding it turned out to be surprisingly hard, because many pixel fonts simply don't support Cyrillic. To keep long Russian and Spanish strings from overflowing the buttons, I had to add automatic text resizing.

Sound. Music and sound effects are routed to two separate audio buses, so their volume can be adjusted independently in the settings.

Localization. From the very start, I never wrote UI text directly. Instead, the game uses keys such as MENU_TITLE or MENU_NEW_GAME, which you can see in the screenshot above, and the translations for all three languages live in a single table.

Saves. Progress is saved automatically to a JSON file every 10 seconds and after every purchase, so you can close the game at any moment without losing anything.

Builds. The game ships in two versions, for the browser and for Windows, and each has its own quirks. For example, I had to hide the Quit button in the browser version, because the game can't close the browser tab by itself.

What My Own Game Taught Me

Every day of development, I wrote down in a dev diary what I'd done, what had broken and what decisions I'd made. Reading it now, I can see things I had long known in theory but only truly understood in practice.

A game is everything at once. Graphics, music, sound, gameplay, game feel, narrative and localization, followed by marketing, PR and talking to players. I don't have many players yet, and all my PR fit into a couple of posts on LinkedIn and Telegram, but even that turned out to be a job of its own. In a studio you see your own area, but when you work solo, every area is yours, and only then do you realize how many there really are.

Any change can blow up the project. Now I find it even harder to understand commenters who write things like "Come on, it's a five-second balance tweak." My balance changed three times. At first, a playthrough was designed to last three hours, then I sent friends a one-hour demo, and based on their feedback the final game shrank to 30 minutes. Each of these changes sets off a whole chain reaction: shop prices, the pace of purchases and a complete retest of everything. Changes are normal, but every one of them carries risk, and now I've seen that for myself.

The hardest part is knowing when to stop. New ideas come every day, and holding back is very hard, but if you keep adding features forever, there will be no release. That's exactly how you end up with the kind of projects people work on for five years and never ship, so it's important to be honest about what you can handle and to keep your goal in sight at all times.

You need a tester, whatever anyone says. This discovery surprised even me, and there's some irony in it, since I'm a tester by profession. But when you add a feature yourself, you really don't want to spend long testing it: you make sure it works and rush on to the next thing. That's why a separate person who will calmly and thoroughly check everything isn't a luxury but a necessity.

Release: Small, but with the Same Pains

The most interesting part began on release day. The project was tiny, but everything went just like at a big studio: bugs popped up at the last minute, and compatibility problems appeared after launch. For example, gold kept ticking up right in the main menu, and one player with older hardware saw a mess of colored dots instead of the game, because their graphics card didn't get along with the renderer I'd chosen. The scale is different, but the feelings are the same, and that's exactly why a small solo project is such good preparation for working in a big team.

The release itself is a separate job, too. The itch.io page needs a cover, screenshots, a description and a trailer. I put the trailer together with Claude: I recorded gameplay, described what I wanted to see, and it edited a 32-second video.

"Not perfect, but good enough" is actually a pretty good motto for this kind of development. And after release, like it or not, you start watching the stats and picking up new details. For example, a game from a new itch.io account doesn't show up in search right away, and in my case it took five days. Real experience is made of small things like that.

And there was something I didn't expect at all: on release day, a strange silence set in. For a whole month my life had revolved around the game, and then you press "Publish" and an almost eerie calm settles over you. A strange feeling, but an interesting one in its own way.

Being Honest About AI

The graphics and the basis for the music were generated by AI. I turned the generated MIDI files into finished WAV tracks, and I assembled and set up everything else in the engine myself.

At the same time, I feel rather negative about AI-generated content, because, to me, it lacks soul. A contradiction? Partly. But for me this was a learning project: the goal was to go all the way from idea to release, not to learn pixel art. Maybe my opinion will change over time, but for now that's how I feel, and my conscience is somewhat eased by the fact that the assets turned out exactly the way I'd imagined them: simple and cozy.

There's also an unexpected side effect: an experience like this makes you want to draw on your own. Once you understand what a pixel sprite is made of, you want to open Aseprite and make one yourself.

AI has greatly lowered the barrier to entry into game development, and I'm living proof of that. There will be even more throwaway games; that's inevitable. But solo developers get more time for what matters most, the creative work itself, which means there's a better chance that something truly beautiful will emerge from that stream.

Of course, on its own, a game like this is a small thing that brings nothing new to the industry. But my point is a different one: AI can and should support creativity, not replace it.

The Takeaway: Make Your Own Game

I do have one concern. I'm encouraging everyone in game dev to make their own game, but I'd really hate for this to become yet another line in job requirements, which are long enough already. Your own game is a tool for growth, not a box to tick on your resume.

For me, Taveronen didn't end with the release either. I'm now starting to write automated tests for it with GUT (Godot Unit Test) to level up my test automation skills. A game you know down to the last line of code is the easiest one to test, so I couldn't ask for a better training ground.

Still, let me repeat the main point: making your own game may be the best thing you can do to grow and to see game development as it really is. Not through articles and YouTube videos, but when it's just you, the engine and your only teammate, an AI.

It won't be easy. Things will break at the worst possible moment, and the project will eat up a huge amount of time, energy and nerves. But today anyone can give it a try, and perhaps, thanks to new tools, we'll see games that would otherwise have been left to rot on their authors' hard drives. After all, in creative work, what matters in the end is the idea and the taste, not the tools it was made with.

If you'd like to see what I ended up with, you can play Taveronen for free right in your browser. It takes about half an hour.

Acknowledgments

Thanks to Roman Urazovskiy, the very friend who released a game "at any cost" and helped me with advice on visual effects, and to Andrey Dolgarev, who supported me in word and deed throughout the whole project.

And of course, thanks to my family: my wife Maria, who found the compatibility bug on older hardware, and my daughter Kira, my young tester, who gave me the sweetest feedback in the world.

• Game: Taveronen: The Beginning on itch.io
• Trailer: YouTube
• LinkedIn: denis-kurchikov
• Telegram: Voljulan

Originally published in Russian on DTF.