Excited to have a new Zig forum, figured I’d get us started!
I’ve been working on Mach engine for the last 8 months. The idea is to have a super nice cross-platform game engine, providing all the things you’d expect from a modern engine, but be quite tooling and data oriented.
I’m also blogging about all the work i do on it and occasionally live-streaming on Twitch.
What are you working on in Zig?
Thanks @slimsag for starting the first topic here! and @dude_the_builder for creating this awesome forum!
I’ve been using Zig for the last 7 months or so on a contract to build a closed source trading engine for cryptocurrency markets. Zig is a great fit for building predictable low-latency systems and comptime is a superpower for offline program configuration.
Last month I also starting working on brucelib in my spare time. A game-dev library where I’m applying some lessons learnt from a year of experimenting with Zig for making “handmade” games. I first got interested in Zig and quit my job in the games industry because I was utterly miserable with the status quo. My hope is that Zig will bring back the joy of programming for many more people!
I have been working on a Tree-sitter parser for my toy note taking syntax in Zig. I have the tree-sitter cli building a zig lib and tree-sitter loading it in Neovim. Still not that far into it due to time. But hopefully will get back to it soon. At least I plan to open an upstream tree-sitter issue to allow tree-sitter cli to use zig build.
I am writing a tool to build demoscene 64kb intros on win32. Only just got started with Zig and this project a couple of months ago.
So far my progress is initializing a window with OpenGL and Dear Imgui, and fleshing out a decent node editor. A lot more work to be done.
So far I am very interested in Drelease-small=true, which just leaves out stuff you don’t use. That’s a big change from C/C++ where I manually had to ifdef out all the parts relating to the tooling when producing a 64kb build.
Hey everyone! Happy to be of some help here for the Zig community. I know Discord and Reddit are all the rage these days but some of us just need a good old-fashioned forum to feel warm and fuzzy inside.
I’ve been iterating (and hopefully not in an infinite loop) over a small programming language, somewhat like AWK, but with a lot of features I like from all the programming languages I’ve come across over the years. I’m calling it
zed and I think I’m close to a working release soon. It originally was fully interpreted, but recently I switched to a compiled bytecode interpreting VM model instead. Let’s see what happens.
I have just picked up Zig last week and getting to know my way around by implementing an LZ4 library.
Found a nice language and a great community!
Thank you for blogging about it! I follow the feed and I always enjoy the posts.
I’m working on zf and telescope-zf-native.nvim. zf is a fuzzy finder like fzy, but tuned to exactly how I want a fuzzy finder to work. Specifically, it prioritizes matches on filenames since most filenames are unique in a project. The other project is a neovim plugin that uses zf via luajit ffi to bring my fuzzy finding algorithm into neovim.
Creating my own fuzzy finder has been a goal for a long time now, and I have really enjoyed using Zig for it.
It is great to see that Zig is attracting people interested in lower level performance programming.
My interests are also in game engines and tools but I keep falling through to lower levels. At the moment I am playing with png loading.
I didn’t like the zigimg is making a lot of allocations so I am trying to rewrite it so that is minimized. I then also discovered that zig’s std zlib allocates up to 300Kb of memory while original C zlib only requires up to 45Kb which makes it much more suitable to allocating from fixed buffer on stack instead of from heap so I might delve into optimizing that a some point as well :).
I heard about Zig in a couple podcasts, it sounded interesting and I’ll probably play around with it before starting a real project =)
Yes the blog series are very nice and helpful. Cannot wait to give Mach a go! Looking forward to write games!
Right now I’m working on an http client and server. Eventually a whole REST framework.
My main projects are:
I’m also interested in using zig for webservers, game programming, eBPF stuff and more
I’ve just been around the edges of zig for a few months. Should have time in a few months to dive in properly and start work on something.
Ooooh, I’m super excited about a fuzzy finder written in Zig! And filenames are 99% of my usecase for a fuzzy finder as well. I love tools that are tuned for a specific task.
As for myself, I’ve just started (like, yesterday) an HTTP server and client (waves at @wavemode ). The sole purpose of the server is to finish learning async so I can properly complete Ziglings! The client, however, may be the start of a home-grown Web spider/search engine.
Thanks for the enthusiasm! If you end up giving it a try, please let me know what you think!
I have a rather ambitious project that I’ve been working on for many years, long before Zig came around.
Its the default project that I attempt to do, everytime I come across a new set of tools. Well … its the other way around actually - The project becomes difficult for a number of reasons, which prompts me to seek out better tech, and learn something new.
So now I’m on round 5 of my attempt to make it all work, and its as much about exploring tech than it is about ever getting this idea working. If I get 90% of this working with this stack, that’s a huge win.
The idea is simple enough, and its easy to get the first 80% working. Its just a multi-user control console for turn-based tabletop miniatures games for a variety of different game systems. The rulebooks on these can run out to over 300 pages long, and often include dozens of charts and tables that can take months to master for each game system.
The control console places all this know-how on each user’s screen, with an “easy to use” set of buttons to keep the game running smoothly. Sounds simple.
Some of the challenges involved :
- Tabletop games are physical and social interactions first. The system must not dilute this experience.
- The reality on the physical tabletop must be the single source of truth, not the computer. Positions of miniatures, terrain, etc are always as per the tabletop and tape measure.
- Information must flow from the tabletop reality to the computer via manual interactions that are simple, and cheatproof. This information flow must be asynchronous to the timeframe of the game. (ie - the game flow shall not block waiting on data entry). Missed data entry points can be corrected by overlaying new data at any time. This means that the system shall still be able to function correctly, whilst it temporarily has incorrect state information.
- Total game speed + cognitive overhead must both be a measurable improvement when using the console compared to doing it all manually
- Despite the physical source-of-truth rule, the system should be able to manage hidden movement / surprises / ambushes for elements that are not physically on the table until their location is revealed, in a cheatproof manner
- UI is touch/tap only. Must work 100% without a keyboard, in an environment where grubby fingers, snack food, and spillt drinks are often the norm
- Physical player input to “random” and computed events is critical. So event resolution on the tabletop is always via physical dice rolls, and verbal arguments about whether the die is crooked or not
- Must be able to work without internet access - so cant rely on a central server ‘in the cloud’ to coordinate user consoles
- Needs auto-discovery for other players to find and join the game easily. No-Keyboard rule means no IP address / domainname entry, has to be click-and-go
- There can be multiple games running in the same venue, so discovery needs to handle this.
- Has to run on platforms - Win/Mac/Linux/Android/iOS.
- May run in a browser as a WASM app, if internet is available
- Security. Hacked games ruin the experience for everyone
- Must simultaneously accommodate players who don’t want to use a console, and are happy with pen+paper+dice for this game
- Game specific logic to be loaded from a single bundle that is portable to all console platforms. That bundle must be secure (not a scripting language that can be inspected and modified in transit). Probs WASM modules loaded into each console, or something ? That foxwren repo above looks super interesting, because could use encrypted wasm bundles that the client app knows how to decrypt on the fly.
Tech stack for this attempt : Client
- Write the whole app in Zig, compile for all platforms as a lean native app
- Use a simple Immediate Mode lib for the UI parts (raylib + custom layers)
- Networking may be tricky - because Wasm networking has some limitations last I looked. Needs exploration to see whats possible here without some janky JS polyfills on top of websockets
- Maybe do “the server” part as a separate app that is spun up once per game instance on someone’s machine ? Not sure yet, too many options.
- Per-Game config and setup via simple .zzz format files that the game host is expected to create/edit offline. Creating a game/scenario editor is out of scope.
- Add the option of spinning up hosted servers on the net, where internet access at the game venue is a given
Expecting to cap this pass to 48 months
Work to date - messing around with raylib, and reading as much Zig code as I can. Experimenting with peer to peer network protocols + discovery
I’m working on two things at the moment:
- The new implementation of Autodocs for the self-hosted compiler
- A website + ticketing system for upcoming conferences
This second project is written in Go actually, but I aim to open source it soon in order to make it easier for other people in the community to run a Zig conference.
I’ve recently adopted a classic FPS named Black Shades. It was originally written (by David Rosen of Wolfire) in C++ for a hackathon in 2002, so I’ve been refactoring and porting it to modern libraries. New code is written in Zig, which so far makes up 12% of the codebase. Multiple bindings have been made for the game, including ones for GLFW, OpenAL and libsndfile.