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?
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:
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.
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 )