Zig gamedev project – left my job to build games in Zig lang

As a counterpoint, we've written several thousand lines of code in Zig for a new financial accounting database called TigerBeetle [1], and all we've seen were two compiler bugs. The first was already fixed a few hours before we reported it, and the second was not a showstopper and something we could easily work around.

On the other hand, because Zig has incredible velocity, we're also seeing that std lib contributions or fixes we make (e.g. io_uring) are landed quickly, and that the community has some of the most talented programmers we've seen, who are also well aware of where the language is at (and like you, also looking forward to self-hosted).

As for TigerBeetle, when we made the decision to go with Zig, the only alternative for us was C since we needed a safe way to handle memory allocation failure and also wanted a simple language with high orthogonality and power, and C interop. However, C's toolchain even then was still not as "ready" as Zig's and Zig also presented a unique approach to safety (e.g. the compiler can check that all syscall errors are handled at compile time, and integer arithmetic and overflow is checked by default) plus comptime, which is a force multiplier.

To be fair, the days of debugging we save through Zig's safety compared to C's undefined behavior, we could easily spend a few hours contributing small fixes back to the language. And breaking changes between releases have also been fairly tame, and the changes welcome. We appreciate the velocity here.

The final insight for us was realizing that it would also take us some time to get our project to production, and that our roadmap would probably intersect with Zig's stability. We go into this decision some more in the Q&A at the end of our Zig SHOWTIME talk [2].

We could have skated to where the puck was at, or where we believed it would be, and we picked the latter. Technological waves can be incredible if you can spot the value ahead of the curve. In hindsight, this decision has paid off again and again. We would never go back to C. For new projects, there are a good many reasons to pick Zig, and for projects that may have a long half-life, this decision may be all the more important.

[1] https://www.tigerbeetle.com

[2] https://www.youtube.com/watch?v=BH2jvJ74npM (TigerBeetle — A Million Financial Transactions Per Second In Zig)

I believe Zig takes a more nuanced and balanced approach to memory safety as a spectrum, rather than the extremes you present of either GC or borrow checker.

For example, Zig offers spatial memory safety, and provides test allocators to catch temporal memory safety issues. That's already an order of magnitude improvement over C.

Memory safety is also just one aspect of safety, whereas sometimes programmers conflate the two. It's important, but things like checked arithmetic should also be right up there, and should be enabled by default in safe build modes. I think Zig's approach here is also spot on, having worked a little in security, where an integer overflow can be almost as dangerous as a buffer overflow. Yet I don't see many other languages taking checked arithmetic as seriously as Zig does.

Hi Guys, OP here.

> Why not Unity or UE5? Why Zig?

I'm building relatively small game, I don't really need full game engine. I try to write simple code that does only what I really need. I want to push Zig forward, I want to promote it. I was working with UE5 and Unity at AMD - those engines are really huge, bloated and they are changing very fast. I want to keep control over my code. Again, I don't need 90% of their features. I like low-level stuff and I want to master my skill.

> Why zig-gamedev project?

I want to help others learning Zig. I want to create demos, audio-visual experiments and even some art stuff. I'm interested in intersection of art and science. I want to prototype and experiment with ideas that potentially will be used in game (tech, algorithms, etc.).

> Why Windows and DX12?

DX12 is really well supported by Microsoft. They have great tools. They have interop with Direct2D and DirectWrite. They have DirectML (built on top of DX12). Windows itself has builtin decoders for most video formats (I will need this and I don't want to include entire ffmpeg).

I'm most familiar with DX12. DX12 is a bit less verbose than Vulkan.

I don't have a bandwidth to care about other platforms. Focusing only on Windows lets me write simpler and often more optimized code.

Also, drivers are really mature and stable.

> Why to take risk?

I was working for big corporations for ~12 years now. Money is good but you don't really realize your ideas there. You don't own what you build. Now, I want to create my own stuff, my way, using my ideas. Money will come later.

Hey, thanks for the question! I'm answering over in our Discord just so I don't hijack the thread. Pretty awesome what Michal is doing for Zig gaming, and I hope you'll also consider sponsoring him on GitHub sponsors: https://github.com/sponsors/michal-z

> I can understand if someone left their job to write $FOO - you see an opportunity and you take a risk on it. What does the language have to do with it?

There are no business opportunities in independent games - they are passion projects, with little chance of payoff. So, if someone is passionate about his game idea and also passionate about Zig, it makes sense to combine both motivations in one project. He might not have enough passion to do the game in C++ or some other language he already knows and hates :)