Português English

Blogs

Launching Turian feature
2026.06.13

Launching Turian

It’s finally time to talk about what I’ve been cooking. After a massive technical pivot and a lot of “mad scientist” hours in the lab, I am super excited to announce that Turian is officially live.

Turian is a 3D game engine built entirely in Zig. But to understand why it exists, we have to look back at where I was just a few months ago.

The Road Through C#

If you’ve followed my work, you know I’m incredibly proud of Guinevere, the C# GUI library I designed. I love that project. But as I tried to use it to build a full-blown engine studio, things got… complicated. I even tried a hybrid approach using Avalonia—which is a rock-solid piece of tech—but it just didn’t feel right for what I wanted to achieve. Plus, let’s be honest, the C# game engine scene is pretty crowded already.

When I started my “side quest” into Zig, something clicked. Programming in Zig was just fun. I found an existing Zig IMGUI library that let me start building the Turian Studio from day one. It’s not as powerful as I want it to be yet—I’ll probably end up forking it or investing heavily in enhancing it—but it got the ball rolling.

Some Technical Magic

One of the biggest hurdles in Zig (compared to C#) is the lack of reflection. I needed the editor to be able to “see” and manipulate the code. I’m happy to say I’ve mostly solved this! Now, the editor can inspect your structs and give you a proper UI to tweak them.

But the feature I’m most proud of? The In-Editor Play Mode. I managed to implement this by compiling the user’s game code into a library and loading it at runtime. It feels just like working in Unity or Godot—you hit play, and you’re in the game instantly. When you’re ready to ship, the final game is still compiled as a single, lean, native executable.

Right now, you can create a project from scratch, drop in your 3D models, add scripts, and “cook” the final game with just a few clicks.

The Roadmap

We are moving fast. The engine is evolving every day. Here’s the general plan for the near future:

  • Refining the 3D World: We’re currently deep into improving materials, lighting, and shadows.
  • Studio Power: Making the editor more robust, user-friendly, and powerful.
  • The Big Three: Soon, we’ll be investing heavily in Audio, Physics, and a proper In-Game GUI system.

The goal is to give you everything you need to build a complete, functional game without leaving the ecosystem.

A New MEGA4

This release marks a reset for the MEGA4 initiative. Like the original plan, we’re embracing the “One Language” philosophy, and, this time, Turian is our starting point. Instead of starting from the GUI and building upwards, we’re are jumping some steps and then go down to the bottom of the stack.

I’m definitively not an expert in Zig, and building a game engine is most definitely not an easy task, so there is not lack of excitement.

It’s totally open-source (GPLv3). I’m having a fun time coding this project. Check it out at turian.mass4.org!

A Zig-Zag Adventure feature
2026.06.10

A Zig-Zag Adventure

I’m a huge fan of C#. I’ve spent years mastering it, and honestly, quite good at it. And C# is better than ever: with every release, gets faster and more robust—at this point, rivaling C++ and Rust in many benchmarks with barely any difference. I still love it, and many of my projects are (and will continue to be) built with it. It’s my “home base.”

But lately, I felt like I needed a new challenge—something more “raw”. That’s when I started playing with Zig as a hobby/educational project. And well, things escalated.

Why Zig? (And why not Rust?)

I did try Rust, but honestly? It’s just not fun for me. It’s way too strict. Instead of focusing on the code logic or the “big picture”, I’d spend hours fighting the grammar and the borrow checker. And don’t even get me started on the syntax—it’s full of abbreviated commands and esoteric punctuation that makes my eyes hurt.

Zig, on the other hand, is simple, direct, and what you see is what you get. No hidden runtime, no heavy-handed rules. It respects your intelligence.

It’s Not All Sunshine and Rainbows

Let’s be real: moving to Zig has been a massive uphill battle in some ways. Coming from the luxury of C#, I really miss things like Attributes and Reflection. Yes, reflection is slower, but man, it is incredibly powerful for building tools. Zig’s comptime is amazing and covers a lot of ground, but it’s a different beast entirely.

Then there’s the ecosystem. Zig is still young, and the documentation is… let’s say “sparse.” Even LLMs, which are usually my go-to for quick answers, constantly struggle to give the right solutions because there just aren’t enough examples out there yet.

It’s ABI is not stable. Some things that would be trivial in C, are not possible in Zig.

And don’t get me started on the IDE support. I’ve moved most of my coding to the Zed editor lately. I love how fast it is, but it’s definitely not Rider. When you’re used to the deep, “knows-everything” intelligence of JetBrains tools for C#, coding in Zig feels a bit like flying a plane with half the instruments missing.

The Perfect Side Project

So why do it? Because it is an adventure. I feel exploring a brand new world, sharing my findings with the community, and pushing the boundaries. It is like planing a day-one-released game without any walkthrough - you’re just trying to figure things out on your own.

What started as a “let’s see how this works” weekend project has turned into something much bigger. It’s been an incredible learning experience that has forced me to sharpen my skills. And that hobby project? It actually turned into a full-blown engine. But I’ll save the details of that “accidental” release for the next post.

Expedition To A Dream feature
2026.05.07

Expedition To A Dream

Rarely does a debut title from a new studio land with such thunderous impact as Sandfall Interactive’s Clair Obscur: Expedition 33. It is a game that feels both nostalgic and fiercely modern, blending the deliberate pacing of classic JRPGs with a visual fidelity that pushes current-gen hardware to its absolute limits. Set in a world inspired by Belle Époque France, it tells a haunting story of a Paintress who wipes away ages with a stroke of her brush.

World map

Blueprints and Whispers

From a technical standpoint, this is a showcase for Unreal Engine 5. The implementation of Nanite and Lumen is among the best I’ve seen, allowing for environments that are densely packed with ornate architectural details without sacrificing performance. What is particularly impressive is that the team achieved this level of complexity almost entirely using Unreal’s visual scripting Blueprints, with very little C++ code—a significant feat for a project of this scale and visual fidelity.

The “Paintress” aesthetic is more than just a lore point; it informs the entire rendering pipeline, with certain effects and transitions looking like brushstrokes coming to life. However, while the levels are visually breathtaking, their layout can be deceptively labyrinthine. I often found myself inadvertently looping back to the start, lost in the sheer density of the ornate French-inspired architecture.

One stylistic choice that deserves special mention is the voice acting. Eschewing the typical high-octane shouting of action games, the cast often speaks in low, almost whispering tones—even in moments of despair or intense action. It gives the game a unique, somber atmosphere that feels distinctly deliberate and “stylish.”

Combat

The Combat Conundrum

The most significant design decision is the “Active Turn-Based” combat. Unlike traditional JRPGs where you might select a command and watch it play out, Expedition 33 requires constant player engagement. Every enemy attack can be dodged or parried in real-time, and your own attacks benefit from timed button presses.

A crucial piece of advice for any newcomer: test if you truly enjoy this combat loop early on. Because the game is a massive RPG, you will be engaging in these mechanics hundreds, if not thousands, of times throughout the journey. If the rhythm of parrying and dodging doesn’t click for you, the sheer frequency of combat might eventually feel like a hurdle rather than a highlight. For me, it added a layer of tension but I was exausted by the end.

Narrative and Character Depth

The story is a melancholic trek through a dying world, and for the most part, the writing is superb. It tackles heavy themes of grief, death, and the core of human existence with genuine maturity. The chemistry between the members of the expedition feels earned, and their individual motivations are slowly unpeeled like an onion.

However, by the third act, the narrative starts to lose its subtle touch. Themes that were previously explored through atmosphere and subtext begin to be discussed quite plainly and repetitively, making the existential weight feel a bit more forced than it was in the game’s earlier hours.

Cutscene

Rinse and Repeat

While the “active” nature of the combat is its soul, it can also lead to fatigue. Some late-game bosses have massive health pools, and maintaining perfect parry timing for 20+ minutes can be mentally draining. A bit more variety in encounter pacing—perhaps some “puzzles” within the combat system that don’t rely solely on reflexes—would have been a welcome addition.

Clair Obscur: Expedition 33 is a triumph of art and ambition. It proves that the turn-based genre still has plenty of room for innovation. Despite some third-act heavy-handedness and occasionally confusing level design, it is an essential experience for anyone who appreciates bold art direction and deep, challenging systems.

My Rating: 7★★★★★★★
Metacritic: 92
The NUKE Uncertainty: When a Maestro Steps Away feature
2026.04.27

The NUKE Uncertainty: When a Maestro Steps Away

Other day iI woke to some unsettling news in the .NET ecosystem. Rumors are swirling—and some blog posts are starting to corroborate—that NUKE, the build system I’ve come to rely on for almost all my C# projects, is being effectively abandoned.

The word on the street is that the primary developer, Matthias Koch, has reached a breaking point. After years of pouring heart and soul into the project, the lack of financial incentive and the sheer weight of maintaining such a critical piece of infrastructure has taken its toll. What’s even more concerning is the talk that any future development might happen in a fork that could be closed-source or move to a paid model.

This hits home. Hard. I just wrote about how much I love Nuke, and now the foundation feels like it’s shifting under my feet.

The Search for a Substitute

When a tool you depend on enters “maintenance mode” or changes its licensing terms, the first instinct is to look for a lifeboat.

Interestingly, Cake 6.0 was recently released, and it seems the team there has been paying attention. They’ve introduced the Cake.Sdk, which feels very much like an answer to NUKE’s “code-first” philosophy. It moves away from the old .cake scripts and toward standard .cs files with a project-based approach. It’s got that IDE integration and strongly-typed feel that made me switch to NUKE in the first place.

Is it enough to make me jump ship? Not yet. For the time being, I’m sticking with NUKE. The existing code is MIT licensed, and even if the official repo is archived, the current version still works. But the long-term viability is definitely a question mark.

The Cost of “Free”

This situation shines a harsh spotlight on the open-source ecosystem. We—developers and businesses alike—have become incredibly comfortable building empires on the back of free labor. We depend on these “tiny” projects maintained by one or two people, and we often forget that there’s a human on the other side of that GitHub handle.

If we care about these tools, we have to support them. Whether it’s through GitHub Sponsors, Open Collective, or enterprise licenses, “free” always has a cost. If the maintainers can’t pay their bills or find a reason to keep going beyond “community spirit,” the project eventually collapses.

I’m at a crossroads here. Are you already testing the waters with Cake 6 or maybe something else like Modular Pipelines? For now, I’ll keep my Nuke scripts running, but I’ll be keeping a very close eye on the horizon.

Oscar Awards 2026 feature
2026.03.14

Oscar Awards 2026

The USA’s Academy of Motion Picture Arts and Sciences is about to host the annual Oscar Awards. These are the movies that I watched and can comment on.

  1. The Secret Agent (8★★★★★★★★): Longer than needed, yet with a thrilling ending.
  2. Weapons (7★★★★★★★): Uneven by design.
  3. Sinners (7★★★★★★★): Ryan Coogler + Michael B. Jordan movie that blends blues, horror, and history.
  4. One Battle After Another (7★★★★★★★): may be one of this year’s Oscar favorites, but despite the acclaim it left me oddly unmoved, with strong craft overshadowed by a story that never fully resonated.
  5. The Devil Is Busy (7★★★★★★★): The routine of a abortion clinic.
  6. Frankenstein (6★★★★★★): Reverent to the source but rarely surprising. Good performances carry a production that plays it too safe.

Documentaries

  1. The Devil Is Busy (7★★★★★★★): A short documentary about a abortion clinic.

Animations

  1. The Girl Who Cried Pearls (8★★★★★★★★): This short film is a mastery in stop motion animation; very touching.
  2. KPop Demon Hunters (8★★★★★★★★): Gleefully maximalist. Combines idol culture and demon-slaying with more wit and heart than it has any right to.
Bruno MASSA