Flint’s origin story

2026-08-04

I first got into game development back in 2014, the first project I worked on was a mobile game made in Cocos2D with a friend. After launching the game on iOS we were disappointed to find that the promised Android support was not happening at the time. Unity was starting to get widely adopted so I took the opportunity to learn it by re-implementing our game in Unity. I was sold on the concept of democratizing game development and it felt like they actually cared about indie developers.

The port went well so I decided to stick with Unity for our next project. We decided to skip mobile and went bigger on our next project, targeting consoles and PCs primarily. Making games is a very time consuming endeavor, just how much there was to learn wasn’t clear at the start. The project initially grew at a steady pace as we slowly learned the various aspects of this multifaceted discipline. Somewhere about halfway the size of the game and the complexity of the code reached a level which slowed us down.

A beacon of hope in the darkness

Unity has it’s strengths, but the editor is not one of them, it is buggy and most operations are very manual and time consuming. A couple of years into the project I came across Odin Inspector and was very excited by the ability to extend the Unity editor with interfaces specific to my needs. With it I was able to automate time consuming and error prone tasks. It’s even more clear to me today how important that is and the few hours I have spent on internal tools have paid off many times over in saved time and avoided bugs. This made it clear to me that an all purpose editor like the one provided by Unity isn’t the right way, each game has its own specific needs.

Rug pull

Like many others I lost all faith in the company when the runtime fee debacle happened. At the time I was already frustrated by an earlier, lesser known rug pull that they carried out against us developers making games for consoles using the Personal plan. I started looking for alternatives, Godot was the obvious one and I spent some time playing with it in my spare time. This was around the time the big Godot 4 upgrade was gearing up to release, neither 3 or 4 felt particularly ready for prime time. Ultimately I found similar frustrations with Godot that I did with Unity except for it being open source. I tried to contribute, but was held back by slow pace of development and my own lack of knowledge of C++. I think Godot is a great option and it is probably in a much better place today, but it also still aims to provide a one size fits all type of experience and I’m not convinced that is the right way.

After spending many years working in Unity I found myself fed up with it’s buggy, ineffective, and idiosyncratic nature. Even the smallest changes took a lot of work and were risky. Progress had slowed to a crawl, it felt like treading water. This was a tough period and I did what I could to improve the quality of our code, working through as many bugs as possible, and building custom editor UIs to help me make faster progress. Ultimately things got better, but the only way I made it through that period was by continuing to search for a better path than Unity, that way I was able to give myself some hope.

Looking for a new path

During winter break of 2023 I read through the “The Rust Programming Language” book and found myself excited by the opportunities Rust provided as a modern language. Unfortunately it didn’t take long until I had a simple game project using Bevy and I learned about the Rust compile times. I almost instantly started to look further afield and found Odin and Zig as two other options. I was already aware of JAI, but the fact that it wasn’t openly available disqualified it regardless of how strong of a candidate it probably is otherwise. After comparing Odin and Zig I landed on Zig. I was mostly drawn to how explicit the language was, and I was fascinated by the opportunities comptime could provide. I liked the whole ethos of Zig more so that’s what I tried next and it has been my go-to language for side projects since.

Throughout all this time I had been collecting knowledge about how other game developers went about their craft, what tools did they create for themselves, which workflows did they use. I had been following Jonathan Blow’s work for many years, and I was blown away by the Tomorrow Corp tech demo. I scoured the internet for anything I could find about AAA debug menus and engines.

An obvious gold mine of this type of information was the Handmade Hero series by Casey Muratori. When it had originally aired I was only vaguely aware of it and never had the time to watch any of it seriously. So armed with my new axe, Zig, I decided to follow along from the start and see if I could accelerate my learning of Zig by implementing everything Casey implemented in C using Zig. It was slow going at first, I had a lot of low level concepts to learn or re-learn after so many years in higher level languages. But it was clear that I was learning a lot, both about Zig and about game engine architecture. Over time I became more and more confident in Zig and I am still working my way through the series.

The handmade approach resonated with me, I have first hand experience of how much work it is to maintain large projects with large amounts of dependencies. At some point just keeping all dependencies up to date and migrating code to work with new versions can become a considerable amount of the work of maintaining the project. Casey’s approach of understanding each thing he needed for the project deeply enough to implement it himself was a breath of fresh air.

Current state

Flint is my attempt to take everything I have learned from personal experience and from researching what others are doing. This project is what gives me hope for the future of my game development career. If I don’t have a viable alternative to Unity when we’re done with our current project, it may be my last. But my hope is that using open source technologies and all the lessons I have learned over the last 10 years I can put together something that I will feel comfortable starting another project on.

I realize that the technology can’t solve all the problems, scope creep and complexity are separate issues but the tech can at least get out of our way and allow us to experiment enough to find the best game possible and make it to the finish line faster. Unity feels like a constant uphill battle where just getting a single approach working is a big undertaking, forget about experimenting with lots of different approaches in search of the most fun way.

Although progress is slow I’m really enjoying it. I’m currently in a phase of using Flint myself for a different learning side project and I’m learning a lot, both about new game development subjects but also about what Flint needs to be as useful as possible.