I spent about 6 months making this game in Zig (with Raylib), and recently released it for download on itch:
You play as a Wizard who fights their way through a series of dungeon rooms, adding new spells to your deck along the way.
This project tested both my game design and programming skills - it is by far my most complex project to date and I’m really proud of it!
I had to build (or hack together) many systems along the way, including:
Game code hot reload
Asset loading and lookup (with hot reload of assets)
Frame-by-frame rewind for debugging the game state
Custom icons and formatting encoded and decoded into unicode
Polyphonic sound playback system built on top of Raylib’s sound API
Entities and their complex interactions - hit/hurtboxes, physics, animation, creature AI, spells, abilities…
You can check out the code on github:
Some reflections on my programming style and Zig-specific things:
I use BoundedBuffer almost everywhere I need an array, including any strings I need to store in the game state.
The whole game state can be copied by value (well, almost) and that’s how I implemented debug rewind, just copy the state each frame into a circular buffer.
Lots of unions. Anytime I wanted something ‘polymorphic’ like different spells, AI behaviors, projectiles, entity renderers, etc, it’s just a union.
comptime is very useful. In most cases I just use it to save typing, like generating an enum and a union from an array of types.
The UI code is basically all ad-hoc garbage and was painful to iterate on. Hot code reload made this more bearable.
It’s a common observation, but the standard library is very educational and easy to read - I didn’t shy away from using it like I do with C++ because I can just look and see exactly how everything works.
Overall I really enjoy Zig. It’s been over a year since I began using it for personal projects. For me, it hits a nice sweet spot between simplicity and expressiveness.
Feel free to ask questions if you’re curious about anything.
Sick! I’ve tried it on M1 for a couple runs, it played pretty well, didn’t get past 4th room, though, a bit difficult to move and aim with touchpad. Btw, are you building a universal bundle for MacOS (aarch64), or just x86_64? M1 was getting somewhat hot as if it was using Rosetta.
Hey, thanks for playing! I definitely recommend playing with a mouse if you can. It might also help to make liberal use of ‘pause’ feature (spacebar), since you can aim your spells while paused.
The Mac version is built for aarch64 only.
I never noticed it heating up my M1 machine, but checking the CPU usage just now it does seem high… and looking at the code I just realized that I turned off sleeping in the main loop last time I worked on the frame timing code! So that doesn’t seem good…hmmm
<1 hour later>
Okay I released an update. CPU usage should be greatly reduced now - Let me know if it helped, and thanks for the feedback!
I tried building for Linux and had to fix a case sensitive issue with a @import("data.zig"); instead of @import("Data.zig");
Now I am stuck on the following error in src/raylib.zig
src/raylib.zig:126:56: error: parameter of type ‘[1]cimport.struct___va_list_tag_1’ not allowed in function with calling convention ‘x86_64_sysv’
fn raylibTraceLog(msg_type: c_int, text: [*c]const u8, args: stdio.va_list) callconv(.c) void {
^~~~~~~~~~~~~~~~~~~
src/raylib.zig:126:56: note: arrays are not allowed as a parameter type
I don’t know if this is a translate-c issue or just something I could override by typing. I tried using an anyopaque pointer but couldn’t get it to work.
Wonderful! I went ahead and pushed a couple of commits which achieve the same thing as your fork, so I suppose main should build for Linux now (can’t actually test it myself).
On X11, I was able to compile and run after adding .linux_display_backend = .X11, to raylib_dep in the build script (and install the necessary dependencies). Really nice!
Is there a reason you chose to use git submodule instead of the zig build system to fetch raylib for you?
Mainly ignorance I think … It is nice to have all the code dependencies right there in the repo instead of fetched and cached somewhere which is harder to find and edit if needed.
At several points in development I hacked around issues with raylib’s build.rs after upgrading my zig version, not sure I could have done that so easily otherwise.
Is there a zig build option to make it work with Wayland?
install
└─ install raylib
└─ zig build-lib raylib Debug native failure
error: unable to find dynamic system library 'GLX' using strategy 'paths_first'
error: unable to find dynamic system library 'X11' using strategy 'paths_first'
error: unable to find dynamic system library 'Xcursor' using strategy 'paths_first'
error: unable to find dynamic system library 'Xext' using strategy 'paths_first'
error: unable to find dynamic system library 'Xfixes' using strategy 'paths_first'
error: unable to find dynamic system library 'Xi' using strategy 'paths_first'
error: unable to find dynamic system library 'Xinerama' using strategy 'paths_first'
error: unable to find dynamic system library 'Xrandr' using strategy 'paths_first'
error: unable to find dynamic system library 'Xrender' using strategy 'paths_first'
error: unable to find dynamic system library 'EGL' using strategy 'paths_first'
error: unable to find dynamic system library 'xkbcommon' using strategy 'paths_first'
I got the version from itch and spent a good half hour playing, weirdly captivating! I’m sorta new to zig (sorta…completely). Creating a release build from source with zig build --release=fast gives me a .exe to play (I’m on windows) but that version for me runs REALLY slow, at unplayable FPS. Unsure if I’m missing some parameters to building (zig build for a debug build did the same). Any tips you can give me here? I’m looking forward to playing around with the source.
I recommend running zig build -h and looking in the “Project-Specific Options” section. It seems like there is a -Ddo-release option that you can set to “build all targets for release”. So maybe try running zig build -Ddo-release instead of zig build --release=fast. I also looked into the build.zig a bit and it seems like the normal release parameter should be passed through most parts as well, but the do-release parameter has some more usages than just setting build target optimize mode.
… It is nice to have all the code dependencies right there in the repo instead of fetched and cached somewhere which is harder to find and edit if needed.