Reflecting on a Year of Gamedev in Zig

I previously worked at a fintech and they, understandably so given the domain, blocked Discord. Think for a second what wonders that does for participating in open source (which the same employer had no problem with).

Discord is not a suitable platform for developers. I think Matrix is pretty good but, fuck it, I'll take IRC over Discord - it's still perfectly functional.

> Am I the only one who feels this is a step back from platforms such as Stack Overflow?

I have a long-held belief that the single best community information database format is Stack Overflow. (As opposed to wiki, chats, user groups/mailing lists, flat/threaded forums.) An editable top-level question, answered by several editable top level answers with different weighting on different things. (And then chat or small comments, there should be a place for some busywork that should carry no relevant information ideally.) Not necessary the website, but the format.

The second is blogosphere, allow users to write articles and engage in comments. For some reason basically no communities have these. They tend to have discord, and maybe a wiki.

I always found SO really slow. Often I would get stuck on something, ask a question and then have to wait an hour for a response (which would often become a back and forth of comments with large periods of time between them). Even on discords for less popular languages/libraries you generally get an answer in minutes.

I think this is likely due to the incentives SO creates. I have never actually answered a SO question because it feels like you need to answer perfectly or get torn apart. I will often contribute to a discord question even if I don't full know the answer just because I think I can add something useful.

    > I have never actually answered a SO question because it feels like you need to answer perfectly or get torn apart. 

I agree, Discord is a terrible user experience for me. The UI is confusing and any piece of information older than a few hours disappears forever into the void.

Discord sucks. Slack is so much better, IMO.

Discord is really bad if you want more than 1-on-1 real-time communication with other humans. This is also its primary advantage.

I agree i rather see all this discussion etc take place on dedicated forums or other text based options so search engines can index the stuff..

You can still ask your Zig question on Stack Overflow, or they have a semi-official Discourse forum Ziggit (which I find preferable to Discord) where I got answers quickly...

Zig Discord is also just semi-official... there is also Slack, there is also mailing list, libera IRC, Telegram, QQ, Zulip...

https://github.com/ziglang/zig/wiki/Community

SO is a very beginner-unfriendly platform. Every time I used it, I either did not get any replies or had my question altered, deleted, removed, closed etc. I have no clue why anyone still uses it.

Discord is just one of many places where you can get help from other Zig community members.

Over time I've seen plenty of comments like this one about platform A vs platform B and I find them all absolutely uninteresting. Having an active Discord server doesn't stop you from having active communities elsewhere.

Some people prefer Discord and they made a comfortable home for themselves. If you prefer a different platform (which could be a matter of personal preference or an objective advantage, it really doesn't matter which it is), then go make yourself a comfortable home there and start offering help to others on it.

If you're a newcomer and can't really offer much help, then you're asking for people who do have that knowledge to help you on a platform of your choice. That's certainly something you can wish for, but you can't demand it, regardless of how much objectively better your platform might be.

In the context of Zig, Ziggit has been pretty nice also. I use that instead.

Agreed - humans like participating in chats better (when you have a problem, you want live humans ready to answer you now), but the SO style archive is better for long term archiving & retrievability.

A LLM product that turns Discord transcripts into a browsable Q&A archive would be neat.

I don’t really think chat is a step back (discord may be a step back vs irc or I am just graying). Learning newish tech in chat has always been way more engaging for me than wiki or forum style communication.

IME chat attracts people who devote a lot of energy to the topic, including top contributors and power users. If you have questions about the latest features or obscure use cases there isn’t a better place to go.

Forum and wiki are great formats too, with different strengths. But if you are frustrated because you can’t seem to find help in those formats, head for the chat.

Some communities archive their chat. This seems like a great source of data to bootstrap a wiki or faq.

I agree, but I think that you could get a useful middle ground by continuously publishing the contents of your Q&A Discord channel to the internet (in a way where it gets indexed by search engines).

Yes, Stack Overflow collated these questions and answers better but then at least you could google for something and get the answer, rather than asking again.

Ziggit is a Zig Discourse that is pretty good: https://ziggit.dev/

It's almost as fast as the Discord and much friendlier to searching and context.

I make a point of avoiding the Discord simply because I want my questions and answers to be searchable by people who come afterward.

Totally agree

But once we opened a Discord for our product we had so many more questions and users coming in. I do not like that it is locked up on a proprietary platform organised as a chat interface, but damn is it popular and often-used. Having users communicate with us more regularly is very motivating, and we've had so much more quality feedback by having it available

It is, unfortunately, where a lot of the people are and it makes your user base feel very "alive"

In a world where every surface of the web is infested with bots, trolls, spammers and AI slop, persistent static and public information is a hazard. Moving knowledge to ephemeral communities is an immune response to what the web has become. I'm usually not a fan of gatekeeping but doing so to filter for human beings seems like a necessary evil.

There's also `std.fmt.allocPrint()` which functions similarly to `format!()`. Although I'd argue its rather poorly named, like many of the functions in the stdlib...

For wanting to avoid fiddling with multiple repeated alloc/defer-free, it's often convenient to use the arena allocators that allow you to release everything with a single `defer arena.deinit()`

My game has a bunch of strings, and my string code currently looks very different to this! For example, copying two lines from source:

  var buffer : [64] u8 = undefined;
  const level_name_cstring : stringnt = std.fmt.bufPrintZ(&buffer, "{}. {s}", .{icon_index + 1, level_name}) catch unreachable;

(Make the string "10. Fortress" from the int 10 and "Fortress")

The reason is, most of the strings in my game are bounded, and actually, known ahead of time. None of the levels have names that approach anything as long as 64 bytes, so I can actually do a fair bit of string manipulation on the stack before needing to use / save it to an allocator. (At least for now before localization XD)

So it depends on the use case. Sure, string manipulation in general can be tiresome in Zig, but in many cases it's also simple.

You're welcome! My experience with the breaking changes in Zig has not been bad at all. For brevity in the blog I didn't get into what I had to do to get things working again, but the process itself was straightforwards. Sometimes the names of some standard library functions had changed, sometimes it was some extra fields in the build system. Whatever the case, the changes were almost always documented in the release notes anyway, so after reading the release notes I basically knew the (small) amount of work I had ahead of me.

All posts not fellating Rust are eventually flagged here. It’s not really a neutral venue for more academic conversations about PLT.

pretty much no language do this by default. however, most languages target the -v1 instruction set in 'release' or optimized mode. (e.g. Rust does this, and AFAIK GCC and clang both do this for C/C++)

"Joy" is always highest for new languages, because there are only green fields and enthusiasts. "Joy" is also increased by languages that let you just do what you want, like dynamic typing, or other language features that delay seeing that first error.

I’ve been dabbling in OS development. I started with rust and it was… ok. Lots of what you’d expect: unsafe all over the place, weird borrow checker work arounds. It felt like I was bending the languages arm.

I recently started to re implement the (admittedly very basic) kernel in Zig and it’s been a breath of fresh air. The language seems much better suited for the level of abstraction that Osdev lives at. Major bonus is that all the existing C code is directly useable in a zig project without any wrapper nonsense or it can be easily translated.

I think I’ll stick with dig for a bit.

> Rust is still popular but it turns out the developer joy is pretty low.

Rust is one of the language I enjoy to use. The problem is you need to overcome its steep learning curve in order to enjoy it, which people tend to give up because it is too hard.

For my (relatively simple) use cases, I've had a significantly better time using comptime than templates; the syntax and the quality of the error messages are a lot simpler in Zig. While I've never attempted to do anything super fancy with templates in C/C++, my gut feeling is that comptime can provide most, if not all, of functionality that templates provide. (But C/C++ template experts please chime in if this is not the case.)

I would go even further: showing the generated cmake file is like showing the disassembly from the zig snippet shown.

I still think the point stands though: zig's build system is nicer. Still bad IMHO as I despise build systems where you describe the build in the same language. Most of the time, it's much better to have a declarative rather than imperative build system. All in all, Ninja/Meson/Cargo/etc are much better in this regard.

(and yes, I think build.rs was a mistake, a necessary evil. Definitely not a feature)

If you don't use zig, you might have missed why that error indicates a stdlib bug. The error in the article is down to a quirk of the type system where literals (like the literal float) have their own unique type (comptime_float) that can coerce to related types (f32, f64) but in this particular case, when atan switches on the type, it doesn't explicitly include comptime_float and fails. Seems like an oversight in the stdlib to me.

The issue is that atan wasn't implemented for a comptime float.

A "comptime f32" is different from an "f32"

1. I agree

2. I guess this is a matter of perspective. I don't have strong opinions on build systems but as someone who only occasionally dabbles in systems programming, I know that Zig's build system is infinitely more approachable and coherent than the monstrosities of CMake and any other build system I've ever come across in various C and C++ projects.

3. That's true, but Zig isn't 1.0 yet so that's to be expected.

> Zig main source of QnA is a black box (Discord)?

The Discord is quite okay-ish for getting a quick answer for things you're blocked on. For proper discussions and deeper questions, Ziggit is a better choice (which is also a 'proper' forum):

https://ziggit.dev/latest

> Zig uses Gradle style approach to Maven.

Zig's build system is conceptionally further away from both Gradle and Maven than Gradle is different from Maven (having to wrestle with both from time to time, my personal opinion is: both are a huge pile of excrement, unfit for real-world usage - even cmake is better than what the Java world accepts as build systems, and that's some achievement ;)

At least the Zig build system looks promising in the way that simple things are simple and complex things are possible, even though the API still sometimes doesn't quite know if it wants to be imperative or declarative. But the basic idea is that the Zig build system and package manager are "just" part of the regular stdlib and that your build process is a regular Zig program that gets compiled and then executed to perform the build.

> Zig changes in big exciting ways, sounds like euphemism for breaking changes

...which is completely expected of a pre-1.0 status. OTH, the last couple of versions were not worse than fixing new warnings after a minor C/C++ compiler update.

Ultimately, this will be determined by the scope of the project, and depends on whether you count using an existing C library as part of the Zig ecosystem.

If you want Zig libraries that don't call any C/C++ code whatsoever, then you're going to have a hard time (as of 2025). There's not, e.g, something as mature and tested as glfw in pure Zig. There is work being done to make pure Zig libraries for gamedev however, see for example Mach: https://machengine.org/

If you're happy to use C libraries though (as I am), then things are generally fine. Many of the most popular gamedev C/C++ libraries have already had their build systems converted into Zig (e.g. Raylib) and so can easily be added to a project without having to do any work in the build system.

For C libraries that aren't already packaged, or if you want to maintain full control of the build yourself, packaging libraries with the Zig build system isn't too bad, but it's still a lot of work. (E.g. Ghostty maintains its own build files for its packages; as a result there is a lot of Ghostty build system code: https://github.com/ghostty-org/ghostty/tree/main/pkg )

> I would assume, that when developing a game alone, you would depend a lot on libraries other have written.

The guts of a game engine don't require any libraries at all. Using licensed offerings like havok for physics, etc., I don't think the language-specific part you might write (bindings, etc.) is a meaningful part of integrating the offering, and since they're licensed it's not as if you could just add them willy nilly in C++. You could argue that you'd want a language-specific library for some Steam SDK stuff, but AFAIK both Odin and Zig do have bindings for at least some important parts of these, and even if they didn't I don't think FFI is really that big of a problem in either language.

If you use Odin everything you need in order to create a game engine is shipped with it via the standard library (`math:linalg`, etc.) and vendor libraries (`vendor:{OpenGL,directx/direct3d11,directx/direct3d12,wgpu}`, etc.). If you really do want to use libraries `raylib` is also included, as well as SDL.

The Zig compiler can compile C, C++ and ObjC, directly import C headers, directly call into C APIs and the Zig type system is very "C ABI friendly". So if something isn't available in pure Zig it's quite trivial to directly integrate dependencies that are written in C, C++ or ObjC (much easier than any other language I used so far).

There's also a centralized effort to wrap C/C++ libraries into Zig packages so that they can be easily consumed in the Zig build system:

https://github.com/allyourcodebase

C interoperability is the name of the game with Zig, however there is a chance of reading article like "Moving away from Zig" in the future like we're seeing with Rust. At one point in time you have to decide whether you want to write a game or tinker with tech and engines. Both is absolutely fine, of course and most of us "get it", but it also depends on personal skills and pain and time threshold.

You can easily integrate any C library, so pretty much all the important stuff is available. You also have Zig-gamedev repo where you have community written zig wrappers for those c libraries.