Awen is now a Qt Quick framework, and Briarthorn is source available

Time for an Awen update, because the project has changed shape since I introduced it in March. The short version: Awen is now a C++23 application framework built around Qt Quick, it’s MIT licensed, and Briarthorn’s full source now lives inside it. There’s also a playable web build of Briarthorn that deploys itself on every push.

---

From game engine to Qt Quick framework

When I kicked off Awen it was a 2D game engine on Raylib. That version did its job. It gave me a skeleton that built on five platforms and a place to explore modern C++ in public.

Then Briarthorn happened. I moved the game from Godot to Qt Quick a couple months ago, and after that I was spending all my time in QML and Qt-flavored C++. Keeping a separate Raylib engine going on the side stopped making sense. The useful pieces I was building for the game (the SDL3 gamepad layer, the per-frame system loop) wanted to live somewhere other apps could reach them.

So Awen pivoted. It’s now a framework for building applications on top of Qt Quick, games included, and Qt Quick is the sole rendering backend. The framework is a set of QML modules under src/:

• awen.entity — the entity value type, plus the System/Systems pair that games derive their per-frame logic from.
• awen.gamepad — the SDL3-backed gamepad layer from the Godot post, now a proper module. On the web build SDL wraps the browser’s Gamepad API, so the same QML bindings work there too.
• awen.shapes — primitives for instrument-style drawing. Briarthorn’s range rings sit on top of it.

There’s also a shared bootstrap, awen::runApp, so an app never writes its own main(). The CMake helper generates one per app.

All of that is MIT licensed now. The source is at funnansoftware/awen.

---

The platforms

Awen builds for Windows, Linux, macOS, Android (arm64-v8a), and the web via WebAssembly. CI covers all of those on every push, plus a SteamOS job that builds Qt through vcpkg against SteamOS’s older glibc. Each platform is one CMake preset, so getting a build is cmake --preset windows and go.

Qt itself is handled for you. If there’s a prebuilt Qt kit on the machine, the build picks it up. If not, vcpkg builds Qt from source on the first configure. That one’s slow… but it’s binary-cached, so you only pay it once.

---

Briarthorn is source available

Briarthorn now lives in the repo at app/briarthorn. The game is written in QML on the framework’s bootstrap, so what’s in that directory is the actual game: the HUD, the systems, the input profiles, the aircraft database.

The licensing is split. The framework is MIT, and the game directory carries the PolyForm Noncommercial license. You can build it and poke around in the code for any noncommercial purpose. Selling it is the only thing off the table.

I like this arrangement because the game is what drives the framework. Every module in src/ exists because Briarthorn needed it, and every push builds the framework against a real app instead of a toy sample. It also means that when I walk through some piece of the game on stream, the code is right there instead of sitting in a private repo.

---

Playable builds at briarthorn.game

The web workflow now deploys the WebAssembly build straight to Cloudflare on every push to main. It’s playable at play.briarthorn.game, linked from the new landing page at briarthorn.game. Whatever’s on main is what’s in your browser.

It’s early. What you’ll see is the tactical picture coming together piece by piece (range rings just landed). But handing someone a URL instead of build instructions is a nice place to be.

---

That’s the update. Next up is building out more of the combat loop and seeing how far the framework modules stretch as the game grows. I stream the work at twitch.tv/funnansoftware if you want to follow along. And if you try the web build and something breaks, tell me.