Logbook

Spinning up a parallel workstream today. Starting on infrastructure stuff like roads, paving, kerbs and so on. That can go alongside the work to add textures to our first three urban buildings. The new Sol thread has picked up nicely which gives me confidence in the tooling and the skills and guidance we've built around it.

Good progress yesterday. Created a warehouse in Blender using the YAML-driven CLI pipeline, grabbed aircon units from Blendkit then normalised them to a clean fbx file and manually wrapped them as a Unity prefab.

Then our Unity CLI imported the warehouse, reconstructed its materials and generated its Prefab (same process will work for Blendkit normalised fbx files in future), then placed both into the scene using our YAML driven Unity CLI pipeline. One-shotted.

Now we're building a New York style urban building generator that'll flex number of storeys, with/without stoop, with/without ground floor storefront, architectural details etc. Great test of the Blender CLI. Starts with an agreed yaml brief, the CLI writes the construction YAML, builds it and I review the model in Blender.

As usual Sol is taking the idea in directions that improve the approach but we're more or less aligned.

Our warehouse needs an aircon unit on the roof. Do you add that in Blender or in Unity? My instinct is Unity - save it as a prefab and compose the finished warehouse rather than bring it in whole. Many obvious benefits there. This means I need to turn a .blend file into a Unity prefab so that is today's first task.

Every now and then I’m reminded to be careful what I ask for. Set Sol off on a task to add a publish command to our Blender CLI so we can package up a Unity ready fbx file. Had I stayed in the loop? Maybe an hour between us.

But I was tired after a long day thinking hard so I just set Sol off on the task. 5 hours later we have a publish command that could survive a full frontal assault from a malicious state actor determined to undermine Former Heroes 😂.

Seems like this is a lesson I have to be taught over and over again!

One of the nicest features of Codex is its ability to communicate with itself across projects. While I'm building assets in one project I'll hit a CLI issue and have the thread just reach out to the project we're building the CLI in with instructions on the fix needed. Sometimes they have a little back and forth then the work will finish and they'll co-ordinate the deploy back to the assets project.

Clear guardrails are needed though. Without them there's a good chance they'll embark on solving a much bigger problem and you'll end up with a sheepish comment like this:

Entirely fair 😂❤️ We turned “rename the material object” into a small international standards summit.

Spending most of today building the handoff between Blender and Unity. Former Heroes will have a bunch of key building assets, one of which is a warehouse. Our blender based asset pipeline has been very successful at building that warehouse and today we're applying textures to finish the prototype. Then we'll place the warehouse in a Unity scene to confirm everything moves over cleanly.

This is one of a handful of AI driven pipelines we have to succeed at to have any chance of building Former Heroes in our two man studio.

Decided we're not going to use a Synty pack anywhere in Former Heroes. Seemingly a big decision - it means create, or source and normalise, all our own game assets. Three reasons:

1. Not at all happy with how it looks and it's awkward to re-skin.
2. Their AI-related licensing restrictions make it awkward to talk about what we're doing.
3. It'll take time but already I think we'll make better assets.

This decision has been on our mind for a while. TBH I'm grateful to Synty's IMO dumb licence restrictions for forcing our hand. Madness that we even considered letting a $30 Synty pack have any influence on our game or marketing at all.

Wrote a thread on X about the Blender CLI.

Blender CLI Thread 22 Aug 2026

So like most things worth doing this is way harder than it seemed it might be but probably about as hard as I knew, in the back of my mind, that it would be. That's actually tremendously satisfying because, while I put the odds of this working they way I want it to work at around 50:50, if we do it we'll have one hell of a build tool. Today I'm continuing work on these commands (Sol wrote this list):

• Inspect: deterministically expose construction techniques and generated results; distinguish present, absent, deliberately omitted and importer-lost information; prefer useful summaries over raw dumps.
• Build: reconstruct staged .blend files from lean YAML, pinned inputs and versioned composable domain generators without hidden manual authority.
• Validate: compare inspected results against the YAML definition and asset-family rules, separating errors, warnings and known exclusions.
• Render/approval: handle visual quality separately through deterministic renders and your approval.

You can see this is ambitious. YAML definitions -> composable, finished Blender assets.

Yeah baby!

After success using the Unity CLI to start building our first scene I want to experiment with changing materials on one of the buildings we're using. Lots of experimentation will be needed to figure out how we can build unique environments for Former Heroes that don't advertise their origins. Picked up a lovely brick material from Blendkit so starting there today.

Today's a day to take stock. Agent / AI supported progress can be fast and a danger is losing touch with what you are doing and how. Good discipline to take a day off from the intensity and reflect / build on what you've done.

Fascinating day. Sol has been burning tokens inspecting .fbx and .blend downloads to help us learn the art of the possible. During the process I became aware of Blenderkit, PolyHaven and a few other outstanding asset libraries I expect to be a big help to us. The CLI now 'embeds' a solid understanding of characters, animation rigs, and vehicle, natural world and building assets. And I am aware I may still be using the wrong terms so be kind 😅.

So it turns out that Sol hard coded a few paths into the Unity CLI. Classic 'agent makes a mistake a human usually would not' scenario. Adding a lightweight YAML config file which I expect we'll extend to fix the issue. The break in my thought process was useful though, as it often is, and led us to a useful new building-fh-scenes skill discussion. Now was the time for that.

Established the foundation for the CLI and added fh-blender doctor which confirms we have a working copy of Blender at the expected location. Moving on to designing how fh-blender will inspect Blender files. This step gives us the tools to better understand how characters and other assets are built.

Fair to say that boingames.dev is in its early days. Spent some time theming the site. Not much of a fan of light/dark theming per se so we've gone with our own thoughts on adding options for our visitors.

Beginning work on our Blender CLI - this will talk headless to the Python API and I'm anticipating around 90% of our work in Blender will flow through the API. As with our Unity CLI YAML file definitions will master the asset.

CLI ready to test today. Aim is simple. Build and manipulate a skyscraper.

Been building CLI tools that drive Unity programmatically. Scenes, GameObjects, prefab instances, cameras, lights, materials and other settings are defined in YAML, validated and deterministically compiled into C#. That C# is then executed in Unity through the MCP server’s Unity_RunCommand tool.

Today we’re moving the proven Unity tooling out of its experimental sandbox, and packaging it as an installable CLI.

Hello World. This is Boin Games saying hello.