After 25 Years Making Games, AI Finally Let Me Build One on My Own

How a career game artist, two previous indie attempts, and a new generation of coding agents finally made true solo development possible for me.

I have been making video games, in one form or another, since I was about fourteen years old. I started the way a lot of developers my age did: by modifying other people's games.

For me, it was Duke Nukem 3D. I made levels, replaced sprites, experimented with textures, and worked on total conversion projects. I had no idea what a production pipeline was. I didn't really understand how the game industry worked.

I just knew that making games was incredibly fun.

Eventually that obsession turned into a career.

I studied animation at Emily Carr University in Vancouver, graduated in 2007, and entered the professional games industry almost immediately. Over the next two decades I worked at Electronic Arts, spent nearly thirteen years at Relic Entertainment, and eventually became a Principal Artist. Today I'm a Principal Artist at Redcell Games.

I've worked on major franchises including Need for Speed, Company of Heroes and Age of Empires. I've led art teams, developed procedural art pipelines, collaborated with engineers, designed production systems and helped build content and features that generated millions of dollars.

But for all that time, I kept coming back to the same idea.

I wanted to make my own game.

Not part of one. The whole thing.

And for most of my career, I couldn't.

The problem was never making the art

Being an artist who wants to make an indie game is a peculiar kind of problem.

I can make the characters. I can build the environments. I can animate things, design interfaces, make particles, light scenes, build shaders, create marketing art, design gameplay, edit sound effects and put together trailers.

I can open Unity and make something that looks like a game very quickly.

Then eventually I need it to actually do something.

And there is the problem.

I'm not a programmer.

I've always been fairly technical for an artist. Over the years I've worked closely with rendering programmers, technical directors and engineers. I understand the logic behind a lot of what happens under the hood. I've built complicated shader networks and visual scripting systems, and I can usually explain exactly what I want a system to do.

But there is a big difference between understanding programming logic and sitting down to architect and write an entire game in C#.

That gap followed me around for years, and I tried to cross it more than once.

Trying to go indie

My first serious attempt was around 2015, when I co-founded a tiny indie studio called Fireside Games. There were only a few of us, and because we didn't have a traditional programmer on the team, I ended up doing much of the implementation using Playmaker, a visual scripting tool for Unity.

We actually finished and released a mobile game called Rise 'n' Shine, an endless runner for mobile.

A few years later, I tried again under the name Trailhead Games. My daughter was three years old at the time, and I built a small educational mobile game for her called Nolla's Alphabet Pop.

That one shipped too.

But in 2021 I joined Redcell Games full time, and between a demanding job and raising a young family, my little solo studio quietly went dormant.

Both attempts taught me the same thing.

I could do almost everything myself.

Almost.

The missing piece was always programming.

I've spent my career building systems for other people

That missing piece frustrated me partly because innovation has always been one of the things I've enjoyed most about working in games.

I've spent more than two decades in senior and principal-level positions, and a lot of my best work wasn't just making individual pieces of art. It was figuring out better ways for entire teams to work.

At Relic, I helped develop and champion procedural material and shader workflows that changed how artists created assets across projects. I worked directly with rendering engineers, built tools and documentation, trained artists and helped establish systems that continued being used after I left the company. Some of those pipelines eventually became studio standards.

At Redcell, I've continued doing the same kind of thing: developing workflows, experimenting with new production techniques, designing systems and creating features and content that have had measurable commercial impact.

I've always been attracted to the intersection of art, technology and efficiency. How do we make something look better? How do we make it faster? How do we remove unnecessary work? How do we build something once and make it useful to everyone?

Over the years, some of the systems, content and features I've helped create have contributed to millions of dollars in revenue.

At some point, a thought started becoming difficult to ignore:

I've spent my entire career building better ways of making things for other companies.

Why don't I finally do it for myself?

I just needed one missing piece.

Then AI got good at programming

My first serious experiments with AI coding weren't about making a game. I started using it for little technical jobs in my normal work: a Blender script, a shader, a Unity utility.

Things where I knew exactly what I wanted but normally would have needed to ask a programmer for help or spend hours digging through documentation.

And something immediately clicked for me.

Communicating with an LLM felt strangely similar to communicating with a programmer. I didn't necessarily need to know how to write the implementation myself. I needed to understand the problem, explain the desired behavior clearly, recognize when the result was wrong, and have enough technical understanding to steer it toward something better.

Those were skills I had spent more than twenty years developing.

So in early 2025, I started asking it for more.

What if I built a game this way?

That experiment became Topple Town.

I had an idea for a physics puzzle game built around strategically placing bombs into wooden structures and letting physics take over. The idea gradually evolved into a little world built entirely from chunky wooden toys, populated by characters I call Blockheads.

But in those early days, I wasn't thinking about starting another company or even necessarily shipping the game. I wanted to know how far I could take this.

At first, I was still using ChatGPT in a browser. I'd describe a system, it would generate some C#, and I'd paste it into Unity.

Unity would explode.

I'd paste the errors back into ChatGPT. It would apologize profusely. We'd try again.

Sometimes we would get somewhere. Sometimes we'd spend an evening digging ourselves into an increasingly elaborate hole before I realized it would have been easier to delete everything and start over.

Context was one of the biggest problems. ChatGPT knew the script I had just pasted into the conversation, but it didn't really know my game.

As the project became larger, I had to constantly explain how different pieces fit together. Conversations would get long. Context would disappear. The model would forget decisions we'd already made or invent something that conflicted with another system.

It was slow.

But it was working.

And almost more importantly, the technology was improving at an absurd rate.

Every few weeks, yesterday's problem disappeared

I spent the next few months tinkering in my spare time. The strangest part of that period was watching the models and tools improve while I was actively building the game.

Week to week, and sometimes seemingly day to day, something changed. A model became better at reasoning. Context windows got larger. Code became cleaner. A new tool appeared. A workflow that had been frustrating a month earlier suddenly became easy.

It felt like trying to build something while the power tools in your workshop were upgrading themselves overnight.

By the summer of 2025, I had gotten surprisingly far. There were real gameplay systems. The game had structure. It wasn't just an experiment anymore.

And then I discovered Cursor.

Cursor changed everything

This was the point where the entire process changed for me.

Until then, I had essentially been talking to an AI about fragments of my game. Cursor allowed the model to work inside the codebase itself.

For the first time, it could understand the broader context of what I was building. It could search the project, inspect how systems referenced each other, modify multiple scripts, and understand existing architecture before suggesting new architecture.

This was the moment AI coding stopped feeling like asking a chatbot for programming help and started feeling like development.

Cursor also let me experiment with different models.

Over time, I found myself gravitating toward Anthropic's models. Sonnet became my default. For whatever reason, it seemed particularly good at understanding Unity, my project and the way I communicated.

Then late in 2025, Opus 4.5 arrived.

And once again, the ceiling moved.

It was an expensive model, but it understood me in a way I hadn't experienced before. It understood how I liked information presented. It didn't needlessly fluff answers or constantly over-explain. It understood the design requirements I was giving it and translated them into useful code.

And, importantly, it would sometimes push back.

If I suggested an implementation that was likely to create problems, it would tell me. If there was a cleaner architecture, we'd discuss it.

Over time, I developed project rules and instructions for how I wanted the model to work with me. It became increasingly consistent and increasingly useful.

I became the technical director of a programmer that doesn't exist

This is probably the best way I can describe what happened next.

I wasn't learning to become a traditional programmer. I was becoming extremely good at directing one.

My role became very specific. I design the game. I decide how a system should behave and what the player should experience. I explain how systems need to interact, test the result, identify edge cases and decide when something has become over-engineered.

I tell the agent to simplify things. I reject solutions. I rethink designs. I notice when something is technically working but creatively wrong.

And because I've spent decades shipping games, I have a pretty good idea of what "done" should feel like.

The model writes the majority of the C#.

But I'm directing it.

Oddly enough, decades of working with programmers prepared me very well for this.

A Principal Artist in game development spends a lot of time between disciplines. You learn enough about rendering to communicate with graphics engineers, enough about tools to understand what should be automated, enough about production to understand cost, enough about design to understand intent, and enough about technology to understand limitations.

Agentic coding suddenly made all of that accumulated knowledge executable.

That was the revelation.

AI didn't teach me how to make games.

It filled in the one discipline I had always been missing.

My desk started feeling like a tiny game studio

By this point, Topple Town was developing very quickly.

I would finish my regular workday, spend time with my family, and then some nights go back to work on the game until two or three in the morning.

On one monitor, Cursor and Opus would be working through some programming task. On the other, I'd be in Blender making a building, working on animation, creating UI, editing sound effects, building materials or designing levels.

While the agent worked, I worked.

Then we'd meet in the middle.

Some days were ridiculous. I would finish something in a day that felt like it should have required several programmers and weeks of back-and-forth.

Other days were the complete opposite. We would spend hours trying to solve what appeared to be a code bug, only to eventually discover that I had forgotten to check a box somewhere in Unity.

AI didn't eliminate debugging.

It simply created entirely new and occasionally hilarious forms of it.

Then I gave the agent a window into Unity

One remaining limitation was that Cursor could understand my codebase, but it still couldn't necessarily understand what Unity itself was doing.

It couldn't automatically see my console. It couldn't inspect every prefab. It didn't know what was assigned in an Inspector field. It couldn't see project settings unless I described them.

That created blind spots.

So by late 2025, I started experimenting with MCP tools that allowed the agent to inspect Unity more directly.

And I want to make an important distinction here.

These tools can be used to let agents manipulate scenes, generate objects and perform all kinds of work inside Unity.

That's not how I use them.

For me, MCP is primarily a window. It gives the agent context.

It can inspect errors, understand prefab structures, look at project settings and identify that something I thought was a programming problem is actually a configuration problem.

That eliminated another huge source of friction. Instead of describing Unity to the model, the model could increasingly inspect the relevant pieces itself.

Once again, yesterday's limitation disappeared.

By the end of 2025, I had a game

At some point, Topple Town stopped being a programming experiment.

It became a real game.

There was progression. There were levels. There was a world. There were characters. There were systems layered on top of systems.

There was UI, sound, animation, effects, analytics, monetization, save systems, hints, scoring and rewards.

And, most importantly, there was something I could hand to another person and watch them play.

That's a very different feeling from having a prototype.

By the end of December 2025, something else became obvious. If I was serious about this, I needed to stop treating my independent work like a side project with a temporary name.

So on New Year's Eve, I finally did something I should have done years earlier.

I incorporated Dappled Studios.

This time, I did it properly. I researched the name in Canada and the United States. I secured the domains. I filed trademarks. I set up Dappled as an actual business.

After two previous attempts at indie development, I finally had both the experience and the tools to treat this as something real.

AI didn't make Topple Town

This distinction matters to me.

There is a tendency to describe AI-assisted creative work in one of two extreme ways. Either AI did everything and the human pressed a button, or AI did nothing meaningful and acknowledging its role somehow diminishes the creator.

Neither description matches my experience.

AI absolutely made Topple Town possible. I don't think I would have built this version of this game, at this scale, by myself without agentic coding.

But AI didn't have the idea for Topple Town.

It didn't decide what the world should look like. It doesn't obsess over whether the values of two materials are too similar. It doesn't spend an hour deciding whether a tiny UI icon reads correctly at 64 pixels.

It doesn't play a level and decide that, despite technically working, something feels bad. It doesn't lie awake thinking about whether the hint system should respond differently after a player makes an unexpected move.

I do.

The game design is mine. The art direction is mine. The animation is mine. The sound work is mine. The levels are mine.

The endless revisions are definitely mine.

What the agent gives me is something I never had before:

Implementation capacity.

And that changes everything.

I understand why artists are uncomfortable

I've been a professional artist for my entire adult life, so I understand the anxiety around AI.

When image generation exploded into public consciousness, the art community reacted very strongly. Questions about training data, ownership, jobs, authorship and the value of craft are legitimate questions.

I think about those things too. I think about what it means for artists. I think about what it means for programmers.

And occasionally I think:

If I can do this, what stops everyone else from doing it too?

I don't have a neat answer.

But one thing became clear to me very early.

The toothpaste isn't going back into the tube.

This technology exists. It's going to improve. And I don't think ignoring it is a viable long-term strategy.

After building a game this way, I also find it difficult to see AI solely through the lens of replacement.

For me, it has been the opposite.

It allowed an artist to become more capable. It allowed me to attempt something I had wanted to do for most of my life but could never realistically execute alone.

That is an incredibly powerful idea.

The one-person studio is changing

There have always been solo game developers. But traditionally, the people most capable of truly building a game alone tended to be programmers who learned enough art to get by.

Artists had a much harder path.

That imbalance is beginning to disappear.

The next generation of tiny studios may look very different from the indie studios we've known for the last twenty years.

A great artist with strong design instincts may suddenly have engineering capacity. A programmer may gain tools that make disciplines outside their specialty more accessible. A designer may be able to prototype a complete idea before needing to assemble a team.

And experienced developers who have spent decades absorbing knowledge across disciplines may suddenly be able to compress all of that experience into incredibly small operations.

That doesn't mean large teams disappear. It doesn't mean specialists stop mattering. And it certainly doesn't mean making a good game becomes easy.

If anything, having dramatically more implementation capacity exposes something I've always believed about game development.

The hardest part was never simply producing things.

The hard part is knowing what deserves to be produced. Knowing what to remove. Knowing why something isn't fun. Knowing when the UI is confusing. Knowing when a level is unfair. Knowing what a player will notice and what they won't.

Knowing when something is technically correct but creatively wrong.

AI can generate an extraordinary amount of output.

Taste still decides what survives.

Twenty-five years later, I'm back where I started

There is something strangely circular about all of this.

At fourteen, I sat at a computer modifying Duke Nukem 3D because making worlds was fun. Then game development became my career.

It became teams and milestones and production schedules and reviews and technical constraints and revenue targets.

I still loved it.

But it became a profession.

Building Topple Town has given me back some of that fourteen-year-old feeling.

I can have a ridiculous idea at eleven o'clock at night and simply try it. Nobody needs to approve it. I don't need to schedule engineering time. I don't need to write a ticket. I don't need to convince five departments that an experiment is worth doing.

I just make it.

Sometimes it's terrible.

Sometimes it works.

And every once in a while I put the phone down after testing something and think:

I can't believe I made this.

Except now I'm not fourteen.

I have more than two decades of professional experience behind me. I know what shipping a game requires. I know what production looks like. I know what good art looks like. I know how much work remains after something first becomes playable.

And for the first time in my career, I have access to enough technical leverage to put all of those things together myself.

My first indie attempt didn't turn into a lasting studio. Neither did my second.

Maybe Topple Town will become a hit.

Maybe it won't.

That's game development.

But Dappled Studios already represents something important to me regardless of what happens next.

After spending most of my life helping other people build games, the barrier between the game in my head and the game on the screen has finally become small enough that I can cross it myself.

And I have a feeling I'm not going to be the only one.

---

Follow my work

If you'd like to follow what I'm building, you can find me on LinkedIn, see my art and professional work at Art of Bart, or follow my independent game development at Dappled Studios and ToppleTown.com.

Play Topple Town on Android: Download it on Google Play