I would assume, that when developing a game alone, you would depend a lot on libraries other have written. Is the Zig ecosystem rich enough in this respect, at this point?
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:
> 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.
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 )
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.
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.
