The Quest Begins!

I kick off an ambitious one-month game development project

Fresh out of college, I worked in the video game industry. I had just completed a degree in music (and had failed the only computer science class I'd taken in college). I got a job as a composer and sound designer at a small online game company, where I worked for the next two and a half years, and then bounced around from contract to contract for another 2 years.

Ultimately, I gave up on working in the game industry as my day job, because I had a wife, a kid, a dog, a mortgage and the lack of stability in the game industry was crushing. Eventually, I realized that I needed to learn to code in order to do so many things I wanted to do. So, I enrolled in a coding bootcamp in 2014 (those were so hot back then), where I learned the basics of iOS development, kicking off a software engineering career that I remain in to this day (and will continue to until either I become independently wealthy, or the robots come for mine, yours, and everyone else's jobs).

I always knew that I wanted to come back to video games at some point, and I knew that it probably wouldn't be until I could do it as a hobby instead of as a job. But I kept putting it off. There was always just enough of a barrier to entry to keep me going, "oh well, someday."

"This game engine costs too much."

"That game engine will take too many royalties if I sell a game."

"That programming language is too hard to learn."

"I don't have time."

New Skills, New Tools

For a few years now, I've had an idea for a game. A game I wished I could play. A game I wished existed. Then a couple friends told me about how they'd been using the Godot game engine. Not only was it free to download, but it was also completely open-source, and collected ZERO ROYALTIES from anyone who made money using it.

I figured it was worth a shot. I downloaded it and started tinkering with it, but I honestly didn't know my butt from my elbow.

This last fall, however, I wrote a design document for the game I'd been dreaming of. I detailed its design philosophy, setting, systems, and primary game mechanics, as well as lots of example content, fleshing out those ideas a bit. I dropped the document into ChatGPT and said something along the lines of, "I've been working as a software engineer for 10+ years, but I've never used Godot or written a single line of GDScript. Do you think this project is doable? Could I build this by myself?"

This was at the height of ChatGPT being the most egregious of sycophants, but in this one small case, I'm glad it was, because I decided I was gonna go for it. I dug in and started building the domain layer of my game in GDScript. Man oh man I hated the language. In my day job as an iOS engineer, I live, eat, and breathe Swift. For each system or state machine I built, all I could think was, "Man, oh man, this would be so much easier and more stable in Swift."

Leveraging My Friends' Brains

Because Godot is open-source (and therefore MASSIVELY extensible), I searched around and found that somebody had built a Swift extension for Godot. But man oh man was I lost when I was trying to understand how to use it to build a project with it. Enter my brilliant friend Eric, who stepped in and and built a git repo for me with a makefile that I could use to generate fresh Swift+Godot projects.

Short on the heels of this, I hopped on a Zoom call with him and another old coworker of ours, Tim, who makes extensive use of AI at his company. Up to this point, the extent of my AI work had been typing stuff into the ChatGPT or Grok web portals and reading the results. Coming out of that Zoom call, I had a much better understanding of how to work with AI agents in an organized and intentional way. I downloaded Codex that afternoon and started playing around with it.

This was an inflection point. In short order, I had forked that git repo Eric had built for me, and begun using Codex to overhaul it into a smooth, Swift-Godot project-generating machine.

Next, I used it to create a new Swift-Godot repo, and then gave it the old GDScript repo for context, and had it help me sketch out a plan to port over the existing project. I had it help me decide how much of it to convert to Swift, and where the boundary should be between the Swift code and the Godot editor. I got savvier with context files, and started teaching it to write code the way I like it.

The Rot Creeps Back In

I had decided to use Swift for the domain layer of my game--the rules, calculations, systems, models, and state machines--and use Godot/GDScript for the more game engine-specific layers. But I kept putting off doing any of that part. I kept writing more and more domain layer. More and more systems. And while it was cool to think stuff out, my experience with creative projects over the course of my life, as well as work projects as an engineer, has taught me that premature optimization is a trap. You can plan and plan and plan, but until you start making something, you don't really know what your project needs: Making a thing reveals what the thing needs.

So, a couple Saturdays ago, I hit the brakes and told Codex that we needed to do a total reboot of our project roadmap. We needed to do a DEEP planning session to figure out the fastest route we could take to get to a playable prototype of my game's main gameplay loop. A true minimum viable product. I was heavily influenced by this video, and said so. I told it what I wanted, why I wanted it, and what I was able to sacrifice, and what we could put into the backlog to be done later. I told it to ask me as many questions as it needed. I sat there and planned with it for three solid hours. But I came out of the other side with an INCREDIBLE plan.

Part of that plan was to make our plan into a localhost website that visualizes our development roadmap, so I didn't have to constantly ask it where we are in the plan. I also had it create a hook in our context files so I could give it a two-word phrase in a fresh conversation in Codex, and it would instantly spin up the minimum context it needed to immediately dig in on the next item on the roadmap.

And finally, I wanted it to teach me to use Godot and Blender rather than having it use them on my behalf.

Holy Crap This Is So Fun

The first phase of the roadmap was to hammer out all of the remaining rules, stats, and design choices that we needed in order to make the prototype. It was like doing the funnest homework assignments ever. How powerful should this be? How should this thing work? What should the interaction be between these two systems?

Finally, I have all the information I needed, and I'm learning the ins and outs of 3D game design in Godot, and how to build 3D objects in Blender, like this silly little thing here:

A chamfered beam

And I'm finally starting to build runnable, playable iterations of the prototype I want to build, starting from the smallest building blocks. Yesterday, I got this neat little scene set up:

It has zooming, panning (mouse and WASD), diffuse lighting, key lighting, shadows, and surface materials. And the best part is that I'm not just "vibe coding." I'm learning, asking questions, digging in here and there, to understand the ideas behind things. I ask it to explain lines of code I don't understand, and once I do, I write comments in the code that explain them... then I ask it if my explanation is correct:

comments for learning

So Here's the Goal

I've paid for a month of ChatGPT Pro so I can use Codex (I guess it's all just "ChatGPT" now) seemingly without limits. And with that hefty cost already sunk, I've made it my goal to finish a playable prototype by the end of September. I have an ambitious roadmap, but I really feel like it's possible. And if I fail, I'll still be far closer to my goal than I would have been otherwise.

So here I go. Wish me luck. I'll try to put as many updates here as I can. Here's one more little snippet from what I learned today, using shared texture instances:

Next up: @tool helpers in Godot! See you soon.

← Back to writing