Why MEGA4 is going all-in on Zig
When MEGA4 started in 2025, the plan was straightforward: build a Unity-inspired game engine and editor using C#.
At the time, that choice made perfect sense. C# is an excellent language, and there are already outstanding engines built around it. Unity, Flax, and even Godot's C# support provide mature ecosystems with years of development behind them.
So why switch?
The honest answer is much simpler than any technical justification:
I wanted to learn Zig.
How this started
The migration wasn't planned.
It began as small experiments exploring Zig's language features and ecosystem. Those experiments gradually expanded until I found myself rebuilding pieces of Turian in Zig. At some point, what was originally a side exploration became serious enough that I decided to rebuild Turian entirely.
Ironically, Turian's original C# implementation was doing well and was approaching what could reasonably be called a v1 release. This wasn't a reaction to major problems with C# or dissatisfaction with the existing architecture.
It was curiosity.
One thing that made this transition much easier was DVUI, an existing Zig GUI library. Instead of spending months building an editor UI framework from scratch, I could immediately start working on editor features and workflows from day one.
Why Zig?
For all the experimentation, a few aspects of Zig convinced me to stay.
Performance and predictability
C# performance continues to improve with every release, and modern .NET is remarkably fast.
Still, Zig's native compilation and lack of runtime overhead provide a level of predictability that is valuable when building engine code. There is no garbage collector to tune and no runtime making decisions behind the scenes. What the code does is generally what the program does.
For a game engine, that simplicity is attractive.
Excellent C interoperability
One of Zig's strongest features is how naturally it integrates with C libraries.
The game development ecosystem is built on decades of existing C and C++ software: graphics APIs, physics engines, asset importers, audio systems, compression libraries, and countless utilities.
Being able to consume C libraries directly dramatically lowers the barrier to integrating proven solutions today, while still leaving the option to replace or rewrite parts of the stack later if needed.
An opportunity to explore
The C# ecosystem already offers several mature engine options.
Zig, on the other hand, is still early in its journey. There are promising projects and initiatives, but nothing yet with the maturity or ecosystem depth of established engines.
That makes building in Zig both riskier and more exciting. There is still a lot of unexplored territory.
What Zig changes
Moving from Unity or Godot to Zig requires a shift in mindset.
The biggest difference isn't performance or memory management. It's how you structure software.
Zig has no classes, inheritance, interfaces, attributes, or runtime reflection in the way C# developers are accustomed to. Instead, it emphasizes composition, explicitness, and compile-time programming.
Fortunately, Zig provides alternatives for all of these concepts.
Comptime instead of runtime reflection
Turian's component system uses Zig's compile-time facilities to inspect component definitions and generate editor integrations automatically.
pub const Player = struct {
pub const is_component = true;
speed: f32 = 5.0,
jump_height: f32 = 2.0,
grounded: bool = false,
};
That component can be discovered by the editor, exposed in inspectors, and serialized into scene files without external registration systems or generated code.
The capability is there, but the approach is fundamentally different from the attribute-driven workflows common in Unity.
Explicit memory management
Zig requires explicit allocation decisions.
Different systems can use different allocation strategies depending on their needs: temporary frame allocators, persistent scene allocators, asset-loading arenas, and so on.
This level of control can improve predictability, although it also means developers need to think more carefully about ownership and lifetimes.
It's a trade-off rather than a universal improvement.
The honest trade-off
Choosing Zig means accepting that many familiar conveniences simply don't exist yet.
Developers coming from Unity or Godot often need to rethink established patterns. Features typically implemented with inheritance, interfaces, attributes, and runtime reflection require different approaches built around composition and compile-time programming.
There is also the reality that Zig itself is still evolving. The language is young, tooling continues to improve, and best practices are still emerging.
And, frankly, I'm learning too.
Building Turian in Zig means learning alongside the community, discovering what works, changing course when necessary, and occasionally rebuilding systems that seemed finished only months earlier.
That uncertainty is part of the project.
Where things stand now
At the moment, Turian is the only active MEGA4 project running on Zig.
The broader MEGA4 ecosystem remains largely aspirational:
- Guinevere is planned as a fork of DVUI, but development has not started.
- Gaya, originally envisioned as a standalone editor, no longer exists as a separate project and will likely emerge from Turian Studio itself.
- Mystery, a community game intended to showcase Turian, is still being defined.
Meanwhile, Turian continues to evolve rapidly.
Today, Turian can import 3D assets and materials, provides an integrated editor experience, and can build standalone executables for games created with the engine.
The next major milestone is Playable Game, focused on providing the infrastructure necessary to actually build complete games on top of the engine.
MEGA4 started as an attempt to build a game engine.
Somewhere along the way, it also became a way to learn a new language, experiment with different architectural ideas, and contribute to a growing ecosystem.
We'll figure out the rest as we go.