How I made my Zig gameplay code hot reloadable
Posted by unvestigate@reddit | programming | View on Reddit | 6 comments
A couple of months ago I made the zig parts of my game’s codebase hot reloadable. A few people have asked me about challenges and issues with doing that, so I wrote a blog post about it.
Not a how-to tutorial, but rather “this is what I did”. Hoping it will be useful to someone trying to do the same thing :)
Satish_1679@reddit
Honestly the biggest productivity unlock lately is compounding iteration speed across the whole workflow. Claude for debugging/reasoning, Runable for specs and presentation docs, hot reload for gameplay iteration, and suddenly solo developers can move at speeds that used to require actual teams.
want_to_want@reddit
Very cool! I looked through the rest of your blog too, your game looks great, especially the vehicle models.
However, isn't 8 years in development much too long? I understand the urge to build things the right way. Recently I released a simple app that took a while to build, because I tried to engineer it as cleanly as possible. It got very few users, and the experience burned me a bit.
At the very least, it seems to me, after 8 years you should be in "production mode" - making the levels and content for the actual campaign. If you're spending time on deep infra stuff at this point, like hot code reloading, it feels the project might be a bit off track. Sorry if impertinent.
unvestigate@reddit (OP)
Hah, yeah. The blog has been going on for some time, but I actually started this game in 2023. There was an earlier incarnation of the project called "Slide" which I originally started working on in 2018 or so. They both run on the same engine and they are both vehicular games, but their design is pretty different. Slide was supposed to be a combat game with light physics-based puzzling.
Traction Point, the current game, is a puzzle-exploration game at its heart. It is written in Zig and I am building the campaign as we speak. It also has a free-form sandbox mode and you can even mod it already: https://github.com/MadrigalGames/TractionPointModding Join the discord to get access to a prerelease version.
As for why it is taking so long, well I am doing almost everything myself. Writing the code (including the tech), modeling and texturing everything (genuine programmer art), doing level design, writing dialogue etc. I wish it was faster but I am using the very limited funds I have for things I truly cannot do myself (like voice actor direction, music etc.). I am basically going as fast as I can, and you can follow along with the live streams on YT if you want.
want_to_want@reddit
Yeah. Again, sorry about the critiques, I'm not actually that qualified to make them. I've only ever released one game and it was much smaller than yours, took about a month to make.
Curious if you've thought about starting with a simpler artstyle? When I saw your game, I thought it could work really well with the graphics of Ravenfield (which went to early access within a year of development) or Off-Road Velociraptor Safari (which was probably made in like three months). The main mechanic, vehicles picking up cargo and other vehicles, can be fun even if the graphics aren't super detailed. And the details are a big multiplier on development time.
Awesan@reddit
This is very cool, thanks for sharing.
In practice was the design obvious from the start or did you go through several iterations?
Off topic, but I'm also quite curious how many cpp "patterns" the zig code has inherited and how that feels. For example I wouldn't naturally reach to interfaces with a vtable in an all-zig codebase I fully control, rather I'd use an enum with a switch.
unvestigate@reddit (OP)
Thanks!
I had been sitting on the idea for a while, but the actual work took only a week and a half (+ the occasional bugfix since then). Almost all of the stuff I mentioned in the blog post went in "on the first try", but I needed to do some acrobatics on the general purpose allocator used throughout the game code, as well as the "Std.Io" interface passed around, to patch them up after the reload. I think I rewrote that code 3-4 times before I landed on something I like (or at the very least can live with). It's not a lot of code though, maybe 150 lines.
You are quite correct in pointing out that a lot of the Zig code shown here isn't necessarily "idiomatic". A lot of it comes from wrapping the interfaces of a C++ game engine and some of it comes from old habits. Eg. the AI actions can't be blamed on the C++ codebase because the AI fully written in Zig. Many people in the zig-gamedev sphere reach for a more POD-style architecture combined with ECS, and I probably would as well if I started from scratch today. Pretty sure it would work great with hot reloading too.