Yes, we use AI to build our mods

Plain version first. A lot of what Rioku Labs makes is built with an AI coding assistant, mostly Claude Code. That covers the mod scripts, the test suites, the tools we use to build and package mods, and this website. The block models are generated by code in Blender, and a lot of that code gets written the same way.

I'm saying it because modding communities care about this, and they're right to. People have strong feelings about AI in games, and a lot of those feelings were earned. I'd rather you hear it from me in a post than work it out yourself and wonder what else I left out.

Where I'm coming from

My day job is in software development, so I've watched AI coding tools arrive from pretty close up. I've seen the bad side first hand. Code that looks finished and isn't. Pull requests nobody can explain, because nobody really wrote them. Tests that pass because they don't actually test anything. Confident answers that are just wrong. When people call it slop, I know exactly what they mean, and I've had to clean some of it up.

I've also seen the other side. Developers who stopped losing their afternoons to boilerplate and glue code and got to spend them on the hard problems instead. People getting productive in a new language or framework in a week instead of a month. Small teams shipping things that used to need big ones. Same tools, very different results.

The difference, every time I've seen it, is the person using it. AI is a tool. Used responsibly, it does what it's told, and really that's all it can do. If you don't know what you're asking for, or you don't check what comes back, you get slop. If you do, you get a lot more done than you ever could on your own.

What I can't do

I'm not going to lie: I don't know the first thing about 3D modelling. I've never been good at frontend work either. I've always been a backend and infrastructure guy, and before my current job I spent eight years working in data centers. That's where my strengths are, and none of them have much to do with making things look good.

So without help, Data Center would have stayed an idea. I knew exactly what I wanted and had no way to build it. Modelling, materials, UVs, animation, the game's block definitions, and a website that doesn't look like it's from 2004 are each things people spend years getting good at.

What I can do

What eight years on a data center floor does give you is a very clear picture of what one should look like. That's where the mod came from, and it's why there's so much focus on getting the details right.

Racks come in standard heights, so ours are 42U and 24U. Hot and cold aisles get closed off with doors and roof panels so the air goes where it's supposed to. Perforated floor tiles go where the cold air needs to come up, not wherever they fit. Rack power strips run off two separate feeds so one failure doesn't take a rack down, and our A and B strips sit in opposite rear corners because that's how you'd actually wire it. Cable trays hang above the racks and drop into the cable managers, not into the middle of the rack. And a KVM drawer slides all the way out and stops before the screen lifts, because that's how they work.

None of that is taste in the artistic sense. It's knowing what's right. That turns out to be exactly what a tool that does what it's told needs from whoever is telling it. It can write a generator for a perforated floor tile without breaking a sweat. It has no idea where that tile belongs until somebody tells it.

How we actually use it

In practice the assistant writes the code and I decide what the code should make. Every block starts as a description of the real thing: what it is, what each part does, how it should behave in the game. The assistant turns that into models, definitions and scripts, and then I look at the renders.

That last part is most of the job. Nothing gets accepted because a test went green. Models get rendered from several angles, moving parts get rendered as video, and a lot of what I send back is some version of "no, that's not how that works."

When I catch the same kind of mistake twice, it becomes a written rule the assistant has to follow from then on. Every visible part on a block needs a real job. Parts have to physically touch whatever they're attached to. A broken block shows a solid inside with torn wiring, never an empty box. Those rules live next to the code, and where they can be checked by a test they are, so each new block starts from everything the last one taught us.

There are lines it doesn't cross, either. We don't copy other people's mods or code, whoever or whatever is doing the typing, and we only reuse code where its licence allows it. Data Center's source is public under the GPL, so you can read all of it and judge it for yourself.

Where it still gets it wrong

Left alone, the assistant will happily make something that passes every test and still looks wrong. Our first KVM motion was technically fine and looked like a glitch. The first go at broken interiors modelled pipes, pumps and control boards, used up nearly the whole triangle budget, and still looked hollow. An early model had clamps floating off their mounts and pins that weren't in their holes.

Every one of those got caught by a person looking at a render and going, no, that's not right. I don't really count that as the tool failing. It did what it was told. What it was told just wasn't specific enough yet, and fixing that is my job.

Why there's a dev log at all

Posts like this one start as AI drafts too, and I'll be honest about why: I'm not good at writing like this. Explaining what I built and why, in a way that's actually enjoyable to read, is its own skill, and it's one I want to get better at. So I tell the assistant what I want to say, it writes a draft, and then I rewrite it until it sounds like me. Every round of that teaches me a bit more about saying what I mean. If a draft says something that isn't true, it doesn't go up.

Why bother writing at all, then? Because what matters most to me is pretty simple. I want people to have cool stuff to play with in the games we love. That's the whole point of Rioku Labs, and the mods are only half of it.

I love reading dev logs. Keen Software House's dev blogs have been a big one for me over the years. The sneak peeks of what's coming, the technical details of how something actually works under the hood, the problems they ran into on the way there. I'd read those and come away wanting to build something myself, and eventually I did. They're a big part of why these mods exist.

So this dev log is me trying to keep that chain going. I want to share what I'm learning as I learn it, including the parts that went wrong. I want to show you what we're working on before it's finished, rough edges and all. And if I'm lucky, a post here gives the next person the push to stop sitting on their idea and start building it, the same way those blogs did for me.

If any of this changes how you feel about our mods, that's fair, and I'd rather you made that call with the full picture. But I'll say this much. Without these tools there would be no Data Center. There'd just be a guy who used to work in data centers, with a lot of opinions about cable trays and no way to build any of them.

PS: If my old boss is reading this, I spent so much time trying to make the cable management look right (including using velcro, not zip ties!) only in the off chance you ever install this mod you could feel proud ;)

o7
- DM