Introducing Turian: a 3D game engine in pure Zig

Game engines tend to make you choose. You can have the productivity of a visual editor — scene hierarchy, inspector, drag-and-drop assets — or the control and predictability of a systems language. Pick one.

Turian refuses the trade. It's a component-based 3D game engine entirely in Zig, and today we're putting up its first public home on the web.

How this started

When the MEGA4 initiative began, the plan was straightforward: build a Unity-inspired game engine and editor. At the time, the engine was written in C# and was approaching what could reasonably be called a v1 release.

So why Zig?

The honest answer is simpler than any technical justification: I wanted to learn it.

What started as small experiments exploring Zig's language features grew as I found myself rebuilding pieces of the engine. At some point, the side exploration became serious enough that I decided to rebuild Turian entirely.

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 start working on editor features from day one.

What's here today

Turian has reached its first usable shape, on the road to the v0.1 · Hello Game milestone (roughly Godot 3 parity):

• A real editor. Turian Studio gives you a scene hierarchy, an inspector, an asset browser, and a live 3D viewport powered by SDL3 GPU (Vulkan / Metal / D3D12) — all in one window.
• Components are just structs. Add pub const is_component = true; to any Zig struct and it shows up in Add Component with its public fields exposed in the inspector. The editor parses real Zig source, not a regex, so comments and conditional compilation never trip it up.
• Live script discovery. Drop a .zig file into your project's assets/, hit Refresh, and your component is available immediately.
• Headless builds. turian-cli build cooks your assets and emits a single self-contained executable — the exact same artifact the editor produces, perfect for CI.

Why Zig?

One language, top to bottom: the engine, the editor, your game logic, and the build tooling are all Zig. No scripting bridge, no FFI tax, no garbage collector. What you write is what the machine does — and your game ships as a single native binary you can hand to a friend who installs nothing.

Zig's C interoperability deserves special mention. The game development ecosystem is built on decades of C and C++ software: graphics APIs, physics engines, asset importers, audio systems. Being able to consume C libraries directly lowers the barrier to integrating proven solutions, while leaving the option to replace or rewrite parts later.

What Zig changes

Moving from a more established engine to Zig requires a shift in mindset. Zig has no classes, no inheritance, no interfaces, no attributes, no runtime reflection in the way you might be used to. Instead, it emphasizes composition, explicitness, and compile-time programming.

Comptime instead of runtime reflection. Turian's component system uses Zig's compile-time facilities to inspect component definitions and generate editor integrations automatically. The editor discovers pub const is_component = true; by parsing real Zig source — comments, conditional compilation, and formatting all Just Work.

Explicit memory management. Different systems use different allocation strategies depending on their needs: temporary frame allocators, persistent scene allocators, asset-loading arenas, and so on. This requires thinking more carefully about ownership, but the control is valuable in engine code.

The honest trade-off

There's a catch worth being honest about: Zig has no stable ABI, so the engine can't ship as a precompiled library. Your game is compiled together with the engine source. The SDK ships that source; you supply the Zig compiler. In exchange, there are no version-mismatch surprises at runtime.

Choosing Zig also means accepting that many familiar conveniences don't exist yet. Features typically implemented with inheritance, interfaces, and reflection require different approaches built around composition and compile-time programming. 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 months earlier. That uncertainty is part of the project.

Where it fits in MEGA4

Turian is the first MEGA4 project running on Zig. Its editor is planned to eventually become a plugin for Gaya, with Guinevere as the GUI layer underneath — the same architecture that powers the rest of the initiative. The first real game built with it will be Mystery.

Where it's going

Turian ships in milestones, each a usable leap:

• v0.2 · Real 3D — glTF mesh & material import, textures with mips and KTX2, multi-light shadows, proper color management.
• v0.3 · Playable Game — input, audio, and physics.
• v0.4 · AAA Workflows — Play Mode, gizmos, tabbed UI, drag-and-drop, undo/redo everywhere.
• v0.5 · Rich Content — animation, prefabs, particles, LOD.
• v1.0 · Production Ready — a credible alternative for professional studios.

Follow the live roadmap on GitLab, and if you want to try it now, start with the Getting Started tutorial.

It's free software under GPLv3 — no seats, no revenue share, no per-title fees. See you in the editor.