I think Zig is great and I'm following it with interest. But I think people should be aware that it is not really stable yet, at least in my experience from trying it earlier this year.
I ran into a compiler crash: https://github.com/ziglang/zig/issues/7865. I attempted to fix the compiler crash myself (https://github.com/ziglang/zig/pull/8372), and I found a fix that worked, but apparently it was not the right fix, and I was told the correct fix would be "quite hard" and "To fix some of the bugs you would need to rewrite quite a bit of code."
It sounds like a big milestone will be when Zig's stage1 compiler is self-hosting, written in Zig instead of in C++. I got the sense that the C++ code I was modifying is somewhat crufty, and the Zig version of it will be better designed in many ways (ie. https://github.com/ziglang/zig/issues/89#issuecomment-382110...), which will make fixing bugs like the one I encountered will be more tractable. I personally will be interested to revisit Zig when this migration occurs.
I also found that the language was changing from release to release in ways that made me update the code.
This is all totally reasonable for a language in development, and I mean no disrespect to the Zig devs -- it's an extremely interesting language. I only say this because stories I saw on HN gave me an impression that Zig was farther along than it is, at least in my experience.
As a counterpoint, we've written several thousand lines of code in Zig for a new financial accounting database called TigerBeetle [1], and all we've seen were two compiler bugs. The first was already fixed a few hours before we reported it, and the second was not a showstopper and something we could easily work around.
On the other hand, because Zig has incredible velocity, we're also seeing that std lib contributions or fixes we make (e.g. io_uring) are landed quickly, and that the community has some of the most talented programmers we've seen, who are also well aware of where the language is at (and like you, also looking forward to self-hosted).
As for TigerBeetle, when we made the decision to go with Zig, the only alternative for us was C since we needed a safe way to handle memory allocation failure and also wanted a simple language with high orthogonality and power, and C interop. However, C's toolchain even then was still not as "ready" as Zig's and Zig also presented a unique approach to safety (e.g. the compiler can check that all syscall errors are handled at compile time, and integer arithmetic and overflow is checked by default) plus comptime, which is a force multiplier.
To be fair, the days of debugging we save through Zig's safety compared to C's undefined behavior, we could easily spend a few hours contributing small fixes back to the language. And breaking changes between releases have also been fairly tame, and the changes welcome. We appreciate the velocity here.
The final insight for us was realizing that it would also take us some time to get our project to production, and that our roadmap would probably intersect with Zig's stability. We go into this decision some more in the Q&A at the end of our Zig SHOWTIME talk [2].
We could have skated to where the puck was at, or where we believed it would be, and we picked the latter. Technological waves can be incredible if you can spot the value ahead of the curve. In hindsight, this decision has paid off again and again. We would never go back to C. For new projects, there are a good many reasons to pick Zig, and for projects that may have a long half-life, this decision may be all the more important.
I tried, and enjoyed, Zig. My enjoyment rapidly fell off a cliff when I started getting deeper into the stdlib. It feels like (this may not be true) that people contributed random stuff into it, a bit like C++ prior to Boost. The inconsistency hampered my enjoyment, and I headed back to Rust.
I'm building relatively small game, I don't really need full game engine.
I try to write simple code that does only what I really need.
I want to push Zig forward, I want to promote it.
I was working with UE5 and Unity at AMD - those engines are really huge, bloated and they are changing very fast. I want to keep control over my code. Again, I don't need 90% of their features.
I like low-level stuff and I want to master my skill.
> Why zig-gamedev project?
I want to help others learning Zig. I want to create demos, audio-visual experiments and even some art stuff. I'm interested in intersection of art and science.
I want to prototype and experiment with ideas that potentially will be used in game (tech, algorithms, etc.).
> Why Windows and DX12?
DX12 is really well supported by Microsoft. They have great tools. They have interop with Direct2D and DirectWrite. They have DirectML (built on top of DX12). Windows itself has builtin decoders for most video formats (I will need this and I don't want to include entire ffmpeg).
I'm most familiar with DX12. DX12 is a bit less verbose than Vulkan.
I don't have a bandwidth to care about other platforms. Focusing only on Windows lets me write simpler and often more optimized code.
Also, drivers are really mature and stable.
> Why to take risk?
I was working for big corporations for ~12 years now. Money is good but you don't really realize your ideas there. You don't own what you build. Now, I want to create my own stuff, my way, using my ideas. Money will come later.
I'm using Zig language full-time to create an indie game. Also, I've created zig-gamedev project to build game development ecosystem for this language. Using DirectX 12 for rendering, Bullet for physics. I'm ex-AAA game developer and graphics programmer.
This is really looking great! You say you left your job... do you have income yet, or is that an item on the todo list? Any clues about the game you're working on?
Zig is a really interesting language for game dev.
I was thinking about using Zig with raylib for my next project. The show stopper was that C ABI compatibility is not yet complete: https://github.com/ziglang/zig/issues/1481
I could have probably worked around it but decided to go the C and Lua for scripting route for now which works great but I can totally see Zig as a decent C replacement.
I am not interested in Windows but I am wishing you best of luck with your project. Seems quite interesting.
One of the nicer things about Zig is that the unoptimized debug binaries are still pretty fast, often only 2 or 3 times slower than the optimized ones rather than 10+ times slower. Presumably because Rust and C++ have a lot of abstractions that have to be sent through the optimizer to be truly "zero-cost".
That, combined with generally really fast compiles (again relative to C++ and Rust) is a nice combination for game devs.
I don't really get the "I Left My Job to write $FOO in $BAR language" reason.
I can understand if someone left their job to write $FOO - you see an opportunity and you take a risk on it. What does the language have to do with it?
To me, taking such a risk, and then adding further risk (using a language you weren't using daily) seems to be a recipe for disaster.
If I were taking a risk (by leaving my job) on a new product, I would do my best to reduce all the other risks (use a familiar and popular tech stack, for one).
As someone who did something similar in my youth my argument was that the new language presented unparalleled productivity opportunities vs the “old”
The real reason was of course that I wanted to play with the new thing.
You are right, Market fit and the idea matter most (when assessing a new company)
But not all ideas should be weighed purely on profit. If op is in a healthy financial state and can shoulder the risk for a year, it’s hard to weigh the opportunity risk for him as a person. It might reinvigorate a love for programming or lead to a job in this new language. And ofc it may also just work ;)
You're not factoring in the fairly huge opportunity cost of missing out on a major technological wave, not being one of the early domain experts, not to mention all the benefits that come with riding the wave.
Zig is perfect for game developers, and being one of the first in the space is going to be an advantage.
Also, the product here is actually defined as "Building gamedev ecosystem for @ziglang!" — Zig itself is part of the strategy here.
> I can understand if someone left their job to write $FOO - you see an opportunity and you take a risk on it. What does the language have to do with it?
There are no business opportunities in independent games - they are passion projects, with little chance of payoff. So, if someone is passionate about his game idea and also passionate about Zig, it makes sense to combine both motivations in one project. He might not have enough passion to do the game in C++ or some other language he already knows and hates :)
I think it's interesting, because product/market fit is really important, and you have one camp of guys saying that programming language is almost irrelevant. But then it isn't always the case, because choosing the right language constructs can make or break your software depending on the domain, and have a quicker time to market. I think the problem lies in a lack of scientific literature, and a collision of culture between result oriented business people, and geeky explorative tech people. I would love to find a way to bridge the gap of understanding, but to even approach this problem in a correct way seems difficult.
Agree. If you want to create games for a living then you need to think game design/business first and tools second. The hardest part of doing games is coming up with compelling game designS that people actually want to pay $ for. Tech is very low on the list of what’s important.
Sometimes you just need to do something different then working for a boss. We are in a privileged position that some can work 1 month and use it to live 2 comfortable months off it. Why not take some risks in life.
Is anyone using Zig on embedded micros yet? M0/M3 or so? I do a bit if C code on st micros and Atmel chips, I’d love to have a modernized C in this world.
I do a bit of game dev, and whilst I've been really interested in getting into a framework rather than using an engine, so far I haven't been able to budge from Godot.
So my question is, why is Zig so good for game dev specifically (thats by far the most common use I've seen for the language so far, in my limited dealings with it)?
How is zig compared to nim, where you can also disable safety(even disabling the gc)? To me nim seems more "ergonomic", but they both try to hit the same problem space.
Asking since I want to build a ray tracer and voxel engine in nim as a side project at some point. But I really like the approach of high level safety and optional low level performance from both languages. I was considering Rust, but I don't like having to deal with the borrow checker all the time.
I think most people in that situation would have saved up a lot of money so that they can support themselves properly during that period of time between jobs or between sources of income.
If anyone thought this was an oddly specific remark (as I did), I looked it up. The 1989 Namco/Toaplan side-scrolling arcade shooter "Zero Wing" [1] is has two notable facts that make it a fun reference here:
1. It's the game from which the "all your base" meme comes.
2. The fighter craft that the player controls is called "the ZIG".
As a former game developer, I don't get why the people start from scratch by developing their own rendering engines or even game engines. Using Unity, Unreal or even Godot is helping you to launch your game 100x faster.
I know it might be fun to develop your own engine but it will take a lot of time and it still won't be as usable as an engine developed by 100x more engineers.
That's it right there. You can spent years pretending to write a game while optimizing your from-scratch engine for features that probably no-one will ever use [1]. But I think it depends on what your goal is.
If it's a small hobby project, and you enjoy the process of writing your own engine (which, granted, can also be a great learning experience), then why not? You're probably in for the fun anyway.
I know some indie devs who learned the hard way that if your goal is in fact to eventually release a game, doing it without using an existing engine can reaaally drag things out.
I think it's tempting: you can get started on a new "engine" pretty easily, and get something up and running in a day or two. But then comes the long tail of adding all the other stuff, which often isn't so much fun.
A lot of the game development process isn't actually programming, so by writing everything from scratch, a programmer can artificially shift the focus into the direction they're more comfortable with.
It depends, writing a very targeted engine for your game isn’t necessarily that much slower than using a general purpose engine off the shelf.
The problems usually start when people are more interested in writing the engine than making a game. Then they gravitate towards all sorts of fun technical problems that would be useful in a general purpose engine but not really for their specific set of problems. I’ve also seen this tinkering trap with general purpose engines but quite technical projects.
I do game development consulting now and then (speedrun mode, leaderboards, randomizers, supporting infrastructure, etc.) and it's really nice to see Godot mentioned here. I don't often make projects from scratch but it is genuinely a pleasure to use.
In regards to developing your own engine - it's almost never more efficient to do so nowadays, but it is almost always significantly more fun. If the author has enough wealth accumulated to quit their job and work on a passion project full time, I imagine they can afford to do something just for fun as the baseline.
For me personally, as a hobbyist game dev, Unity and the like feel like I'm having to relearn how to do something I already know how to do if I just write code instead of relying on someone else's gigantic abstraction. And I also very much like the idea that I can make my small games super small and port them to literally anything without having to hope some third party adds support for it.
There are some great titles where the whole game was built around a unique feature provided by a custom engine. It probably wouldn't have been possible to do "Teardown" in Unity, for example; not without making some serious compromises, at least.
This really depends on the game and your personal goals. Engines like Unity, Unreal or Godot must cover the entire game development landscape, but the 'engine feature slice' needed for one specific game may be so small that such generalist engines don't provide much help or are even actively harmful because they force you into building the game in a certain way. The most useful engine-part in such cases might be the tiny platform abstraction layer to work around driver- and OS-API bugs - but usually this platform abstraction layer can't be used alone, and alternatives like SDL also have accumulated lots of such fixes and workarounds over the decades.
As with everything it would depend on the type of thing you’re making and whether you rather deal with problems of an existing solution or the ones you imposed yourself.
Even ignoring that. I think there is a more fundamental question here as well. What type of maker do you want to be?
100% agree. I don’t know why you were downvoted. I assume that some people hate it when you dare to talk reality. I have run my own successful game biz for 5+ years and have written more than one commercial game engine that was used to release commercial games on consoles and PC. And I 100% agree with you. Unity (for example) will make you at least 10 times more productive than writing a 3D engine from scratch.
[+] [-] haberman|4 years ago|reply
I ran into a compiler crash: https://github.com/ziglang/zig/issues/7865. I attempted to fix the compiler crash myself (https://github.com/ziglang/zig/pull/8372), and I found a fix that worked, but apparently it was not the right fix, and I was told the correct fix would be "quite hard" and "To fix some of the bugs you would need to rewrite quite a bit of code."
It sounds like a big milestone will be when Zig's stage1 compiler is self-hosting, written in Zig instead of in C++. I got the sense that the C++ code I was modifying is somewhat crufty, and the Zig version of it will be better designed in many ways (ie. https://github.com/ziglang/zig/issues/89#issuecomment-382110...), which will make fixing bugs like the one I encountered will be more tractable. I personally will be interested to revisit Zig when this migration occurs.
I also found that the language was changing from release to release in ways that made me update the code.
This is all totally reasonable for a language in development, and I mean no disrespect to the Zig devs -- it's an extremely interesting language. I only say this because stories I saw on HN gave me an impression that Zig was farther along than it is, at least in my experience.
[+] [-] _vvhw|4 years ago|reply
On the other hand, because Zig has incredible velocity, we're also seeing that std lib contributions or fixes we make (e.g. io_uring) are landed quickly, and that the community has some of the most talented programmers we've seen, who are also well aware of where the language is at (and like you, also looking forward to self-hosted).
As for TigerBeetle, when we made the decision to go with Zig, the only alternative for us was C since we needed a safe way to handle memory allocation failure and also wanted a simple language with high orthogonality and power, and C interop. However, C's toolchain even then was still not as "ready" as Zig's and Zig also presented a unique approach to safety (e.g. the compiler can check that all syscall errors are handled at compile time, and integer arithmetic and overflow is checked by default) plus comptime, which is a force multiplier.
To be fair, the days of debugging we save through Zig's safety compared to C's undefined behavior, we could easily spend a few hours contributing small fixes back to the language. And breaking changes between releases have also been fairly tame, and the changes welcome. We appreciate the velocity here.
The final insight for us was realizing that it would also take us some time to get our project to production, and that our roadmap would probably intersect with Zig's stability. We go into this decision some more in the Q&A at the end of our Zig SHOWTIME talk [2].
We could have skated to where the puck was at, or where we believed it would be, and we picked the latter. Technological waves can be incredible if you can spot the value ahead of the curve. In hindsight, this decision has paid off again and again. We would never go back to C. For new projects, there are a good many reasons to pick Zig, and for projects that may have a long half-life, this decision may be all the more important.
[1] https://www.tigerbeetle.com
[2] https://www.youtube.com/watch?v=BH2jvJ74npM (TigerBeetle — A Million Financial Transactions Per Second In Zig)
[+] [-] zamalek|4 years ago|reply
[+] [-] bagels|4 years ago|reply
[+] [-] michal-z|4 years ago|reply
> Why not Unity or UE5? Why Zig?
I'm building relatively small game, I don't really need full game engine. I try to write simple code that does only what I really need. I want to push Zig forward, I want to promote it. I was working with UE5 and Unity at AMD - those engines are really huge, bloated and they are changing very fast. I want to keep control over my code. Again, I don't need 90% of their features. I like low-level stuff and I want to master my skill.
> Why zig-gamedev project?
I want to help others learning Zig. I want to create demos, audio-visual experiments and even some art stuff. I'm interested in intersection of art and science. I want to prototype and experiment with ideas that potentially will be used in game (tech, algorithms, etc.).
> Why Windows and DX12?
DX12 is really well supported by Microsoft. They have great tools. They have interop with Direct2D and DirectWrite. They have DirectML (built on top of DX12). Windows itself has builtin decoders for most video formats (I will need this and I don't want to include entire ffmpeg).
I'm most familiar with DX12. DX12 is a bit less verbose than Vulkan.
I don't have a bandwidth to care about other platforms. Focusing only on Windows lets me write simpler and often more optimized code.
Also, drivers are really mature and stable.
> Why to take risk?
I was working for big corporations for ~12 years now. Money is good but you don't really realize your ideas there. You don't own what you build. Now, I want to create my own stuff, my way, using my ideas. Money will come later.
[+] [-] michal-z|4 years ago|reply
[+] [-] Shadonototra|4 years ago|reply
Full time indie is a fun and scary adventure at the same time, good luck!
One question, why DX 12? i'm kinda sad when i see indie choose proprietary non-portable tech..
Not to say that vulkan is better (i hate it), but i'm curious
[+] [-] losvedir|4 years ago|reply
[+] [-] Rygu|4 years ago|reply
[+] [-] cyber_kinetist|4 years ago|reply
[+] [-] klyrs|4 years ago|reply
[+] [-] SrslyJosh|4 years ago|reply
[+] [-] cardanome|4 years ago|reply
I was thinking about using Zig with raylib for my next project. The show stopper was that C ABI compatibility is not yet complete: https://github.com/ziglang/zig/issues/1481
I could have probably worked around it but decided to go the C and Lua for scripting route for now which works great but I can totally see Zig as a decent C replacement.
I am not interested in Windows but I am wishing you best of luck with your project. Seems quite interesting.
[+] [-] dralley|4 years ago|reply
That, combined with generally really fast compiles (again relative to C++ and Rust) is a nice combination for game devs.
[+] [-] lelanthran|4 years ago|reply
I can understand if someone left their job to write $FOO - you see an opportunity and you take a risk on it. What does the language have to do with it?
To me, taking such a risk, and then adding further risk (using a language you weren't using daily) seems to be a recipe for disaster.
If I were taking a risk (by leaving my job) on a new product, I would do my best to reduce all the other risks (use a familiar and popular tech stack, for one).
[+] [-] ramblerman|4 years ago|reply
The real reason was of course that I wanted to play with the new thing.
You are right, Market fit and the idea matter most (when assessing a new company)
But not all ideas should be weighed purely on profit. If op is in a healthy financial state and can shoulder the risk for a year, it’s hard to weigh the opportunity risk for him as a person. It might reinvigorate a love for programming or lead to a job in this new language. And ofc it may also just work ;)
[+] [-] _vvhw|4 years ago|reply
Zig is perfect for game developers, and being one of the first in the space is going to be an advantage.
Also, the product here is actually defined as "Building gamedev ecosystem for @ziglang!" — Zig itself is part of the strategy here.
[+] [-] killtimeatwork|4 years ago|reply
There are no business opportunities in independent games - they are passion projects, with little chance of payoff. So, if someone is passionate about his game idea and also passionate about Zig, it makes sense to combine both motivations in one project. He might not have enough passion to do the game in C++ or some other language he already knows and hates :)
[+] [-] FieryTransition|4 years ago|reply
[+] [-] mbrodersen|4 years ago|reply
[+] [-] dragonelite|4 years ago|reply
[+] [-] travisgriggs|4 years ago|reply
[+] [-] bodge5000|4 years ago|reply
So my question is, why is Zig so good for game dev specifically (thats by far the most common use I've seen for the language so far, in my limited dealings with it)?
[+] [-] FieryTransition|4 years ago|reply
[+] [-] FieryTransition|4 years ago|reply
[+] [-] fallat|4 years ago|reply
[+] [-] fouc|4 years ago|reply
[+] [-] egypturnash|4 years ago|reply
[+] [-] unwind|4 years ago|reply
1. It's the game from which the "all your base" meme comes.
2. The fighter craft that the player controls is called "the ZIG".
[1]: https://en.wikipedia.org/wiki/Zero_Wing
[+] [-] gavanwilhite|4 years ago|reply
Async stuff is interesting to see
[+] [-] HugoDaniel|4 years ago|reply
[+] [-] mpbeauj|4 years ago|reply
[deleted]
[+] [-] DeathArrow|4 years ago|reply
I know it might be fun to develop your own engine but it will take a lot of time and it still won't be as usable as an engine developed by 100x more engineers.
[+] [-] kleiba|4 years ago|reply
That's it right there. You can spent years pretending to write a game while optimizing your from-scratch engine for features that probably no-one will ever use [1]. But I think it depends on what your goal is.
If it's a small hobby project, and you enjoy the process of writing your own engine (which, granted, can also be a great learning experience), then why not? You're probably in for the fun anyway.
I know some indie devs who learned the hard way that if your goal is in fact to eventually release a game, doing it without using an existing engine can reaaally drag things out.
I think it's tempting: you can get started on a new "engine" pretty easily, and get something up and running in a day or two. But then comes the long tail of adding all the other stuff, which often isn't so much fun.
A lot of the game development process isn't actually programming, so by writing everything from scratch, a programmer can artificially shift the focus into the direction they're more comfortable with.
[1] https://handmadehero.org/
[+] [-] meheleventyone|4 years ago|reply
The problems usually start when people are more interested in writing the engine than making a game. Then they gravitate towards all sorts of fun technical problems that would be useful in a general purpose engine but not really for their specific set of problems. I’ve also seen this tinkering trap with general purpose engines but quite technical projects.
[+] [-] ari__|4 years ago|reply
In regards to developing your own engine - it's almost never more efficient to do so nowadays, but it is almost always significantly more fun. If the author has enough wealth accumulated to quit their job and work on a passion project full time, I imagine they can afford to do something just for fun as the baseline.
[+] [-] AnIdiotOnTheNet|4 years ago|reply
[+] [-] csande17|4 years ago|reply
[+] [-] flohofwoe|4 years ago|reply
[+] [-] dgb23|4 years ago|reply
Even ignoring that. I think there is a more fundamental question here as well. What type of maker do you want to be?
[+] [-] mbrodersen|4 years ago|reply