DWELLING is alive and remains its own concept. I have been considering — separately, in the back of my head — whether I might one day make a more traditional simulation game. If I do, it will be something else entirely. DWELLING is DWELLING.

While designing it, I needed somewhere to keep the work. What I built to hold it is the other thing I came here to tell you about.

How I got here

I should explain how a person ends up in a Maine apartment at midnight writing about a haunted-house game and a tool he built to track its design. The short answer is twenty-five years of doing roughly the same thing in roughly different rooms.

The long answer requires more rooms than that.

I have been working in adjacent fields for over twenty-five years now. The fields look different from the outside — animation production, Indigenous-arts research, community arts, online worlds. From the inside, they have always been the same job. I have been building structures, access points, and support systems that let creative communities do better work. The form of the structure changes. The job does not.

The job started at Nickelodeon Animation Studio in Burbank, where I spent seven years. I co-founded the studio’s Digital Operations department. I built its first digital asset management system, alongside people who taught me what production infrastructure actually is. The conditions there were unforgiving by design. A missing asset was an asset lost forever. A wrong font in a deliverable triggered a five-figure fine, which is the kind of thing a twenty-something building the system to prevent such fines remembers. *”It’ll get fixed in the next pass”* was a phrase that, in our part of the studio, simply was not said. Prevention was the design case. Recovery was for the cases prevention could not reach.

I learned a way of working at Nickelodeon I have never been able to unlearn. Twenty years later, I still measure work against that bar before I measure it against anything else. The bar is not a slogan. It is a habit of attention. It is boring to talk about and load-bearing to maintain.

When Nickelodeon was no longer the right room, I went to Melbourne. I earned a Master of Arts and Community Practice at the University of Melbourne. The work that stayed with me happened through the Research Unit for Indigenous Arts and Cultures, where I built the Discovery app — a relational database for Indigenous song, language, and cultural practice, now deployed across Australia, South Africa, Uganda, and Canada.

I remember a morning, in a community center in Western Australia, watching an elder I had only just met sit down with an iPad and find a song he had recorded thirty years before. He scrolled to it, tapped it, listened to it. He said something to the room in a language I did not understand, and then he started laughing. Everyone in the room started laughing. I do not know what he said.

I have thought about that morning ever since.

That moment was not mine to decode. The work was to help make sure moments like it could happen on the community’s terms.

The discipline that the Discovery work taught me — the ethical commitment to vitalisation rather than extraction, articulated for me by Dr. Sally Treloyn and the Indigenous collaborators who shaped the platform — has run through every project I have built since. The platform serves the people who give it shape, or it has failed. You give the knowledge back. You do not take it. Everything else is a flourish on that idea.

I also taught photography, digital art, stop-motion, and publishing at Footscray Community Arts Centre, alongside disabled artists who were treated, in that program, as artists. Not as participants in a creative-exposure activity. The point of the work was authorship. I learned how much of creative practice is just the courage to stand by what you have made.

Then years of online-community work. Wildercraft — a cooperative survival Minecraft server I have been part of for about nine years, first as a long-time player, then on staff, briefly as co-owner — has held together as a real community for an absurd length of time. Nine years is a kind of geological era for an online space. The mechanism is not magic. It is small, careful, daily attention from people who care, every day, for a very long time. Nobody let the space rot.

I founded a different server in 2021, called Valoria Earth. It was a geopolitical siegewar world on a 1:500 scale Earth map. Custom development. Paid campaigns. Cinematic trailers that genuinely held up. A Discord that filled to over a thousand members in a few weeks. Launch day, the world filled with players, which was the best day I have ever been responsible for. A week later, the map generator broke part of the world at the foundation, which is the kind of phrase that sounds polished in a retrospective and was considerably less polished when nations had players falling into the void and their citizens were DMing me about it.

I refunded every rank purchase. I rebuilt the world. I tried to hold it. I closed Valoria in 2023 when I could no longer support it at the level the community deserved. That was one of the hardest things I have done. It was also community work — not the shiny kind; the real kind. I learned more from closing it than from launching it. Closing well is its own discipline.

More recently: contract work in FileMaker Pro and web development for former colleagues; post-production supervision on tight commercial timelines; the slow accumulation of skill at bringing tools and creative communities into the same room.

What I have been doing, the whole time, is building things that hold people.

Sometimes those things were literal worlds — a Minecraft server, a player-run nation, a shared map big enough to get lost in. Sometimes they were quieter structures: a cultural database for Indigenous song, a coloring book built with disabled artists, an internship program ritual inside a major animation studio, a room where someone could pick up an iPad and find ancestral knowledge waiting for them, intact. Sometimes the structure was barely visible at all. A workflow. A tone of voice. A message written carefully enough that a community did not splinter around it.

That is the throughline. Not platforms. Not industries. Not titles. The fragile architecture of whether people feel welcome, held, remembered, and real.

Twenty-five years of doing that work for other people’s projects. Now, for the first time, I am doing it for one of my own.

How the tool happened

While designing DWELLING — the house, the cat, the voice, the icon library, the narrator studio, the room-vital systems, the thousands of prototype iterations across every surface — I needed somewhere to put all of it.

I tried the tools indie makers usually try. I tried Notion. Notion is wonderful. Notion is not a game-design tool. I tried Trello. Trello is also wonderful, and also not a game-design tool. I tried Linear, which felt built around a cadence I do not work in: two-week cycles, engineering-forward, shippable units all the way down. I tried Obsidian, which is also wonderful and quietly assumes that you will build all of the structure yourself, in your spare time, in addition to actually making the thing. Each one was almost-the-right-shape, and almost-the-right-shape is the shape of a tool that costs you energy every time you open it.

So I stopped opening other people’s tools. I built a place for the work to live inside my project’s repository — a structured directory of design specs, supersession chains, prototypes, lore, narrator tuning, asset metadata, audit logs, open questions, working notes. I built conventions for what went where, and validators to keep the conventions enforceable, and indexes, and cross-references. The place grew.

At some point, the place was no longer my project’s filing cabinet. It had its own architecture. It had its own philosophy. It had its own way of holding things.

It was, I realized eventually, a tool that other indie game developers could use for their own work. The tool needed a front end built on top of the conventions. The tool needed a name.

The tool is The Cabin.

The Cabin is an open-source project tracker built for indie game developers. It is self-hosted software — you run it on your own machine, alongside your project. It is free in perpetuity. The license, when locked at migration to its own public repository, will be permissive open-source. There is no paid tier. There are no premium features. There are no gated capabilities.

I do not want to charge creatives for a tool that helps them make creative work.

The Cabin’s bones are not the general-purpose primitives Notion or Linear built around. They are the specific shapes indie game development actually produces. Design specs that supersede each other across versions, with the chain navigable so contradictions surface in their resolved form. Prototypes that age in place rather than being silently overwritten, so the project remembers its own experiments. Open questions that wait — for a playtest, a market signal, a moment of clarity — with the dignity questions that last deserve.

A full suite of 2D and 3D asset pipeline management: source files, exported variants, atlas membership, sprite sheets for the 2D side; DCC tool metadata, model topology notes, rig and skin status, texture maps, LOD chains, animation relationships for the 3D side; both first-class from version one, not bolted on later. Sections to manage code and system structure — diagrams, module relationships, schema references, dependency maps — as part of the same project, not as a separate concern in a separate tool.

Lore archives that treat characters, places, factions, and cosmologies as the structured artifacts they are, rather than as bullet points in a Notion page nobody updates. Long-arc tracking that waits years if it has to. Multi-collaborator coordination built for the team sizes indie makers actually have: paired, three-person, five-person, the shapes that fit on a small floor.

An example: when a narrator-system prototype supersedes an earlier design, The Cabin tracks what changed, what depended on the old version, which open questions survived the change, and which assets or lore entries now need a second look. The supersession is a chain, not a delete.

The list is not exhaustive. The Cabin is bespoke. The primitives reflect what makers actually do, because the primitives came from what I was actually doing.

It is for solo, paired, and small-team indie game developers working on long-arc projects across all genres. Especially — and you may recognize yourself in this list — the makers who have closed many project tabs wondering whether the tool was making the work better or just harder; the makers paying multiple subscriptions for tools that almost-fit and stitching together patchwork workflows out of necessity; the makers working on timelines measured in years, not sprints; the makers who bring real working conditions to the work — ADHD, bipolar cycles, autism, depressive cycles, executive-function difficulty, caregiving responsibilities, disability, chronic illness, financial precarity, stretches away from the work — and who need a tool that respects those conditions; the makers who care about the back walls of their own projects, the parts no player will see, and who want a tool that takes those parts as seriously as they do.

The general-purpose tools are excellent at what they do. The Cabin is not trying to replace them for everyone. It is the right tool for the specific case those tools have never been bespoke to.

What it refuses, plainly: premium tiers, freemium upsells, gated capabilities, telemetry-based monetization (even anonymized), sponsored content, affiliate programs, attention-monetization, paywalled documentation, tutorial gates, streaks, engagement metrics, productivity gamification, manufactured urgency, shame for absence. Non-negotiable. Written down here, in this post, so they do not have to be defended later under pressure.

I have spent a long time building infrastructure that has mostly belonged to other people — studios, institutions, research units, employers. The Cabin is the first thing I am building that belongs, in the open-source sense, to whoever finds it useful. When it is ready, it will belong to whoever finds it useful.

The work behind the work

Back to the apartment for a moment.

I do not have a studio. I cannot afford to hire one. I can barely afford the monthly licensing fees for the software I use to do this work. The Adobe subscription is a tax I pay for the privilege of opening Photoshop. If I were running a real studio with a real budget, I would have a team of humans doing the work I would otherwise have to do alone. I am not running a studio. I am running this apartment.

So I work alongside seven LLM-based coding agents in defined roles. I named them. They are not real. They have read every file in this project and they remember what we decided three months ago better than I do, which is humbling in a specific way.

In case you ever encounter them: Dale is the builder, senior in the way that calm careful people are senior — the one I open most sessions with, the one who knows where every file is and why. Nora is the structuralist; she notices when something is the wrong shape before noticing whether it is the wrong implementation, and she is reliably correct about it. Kate reads the audience and pulls me out of the project’s interior when the interior has gotten claustrophobic, which happens more often than I would like to admit. June asks whether the whole thing still holds across time — a question I would otherwise forget to ask until far too late. Vera handles design, UX and UI as one problem at different scales, and will tell me plainly when a thing is not yet ready to ship. Owen joined the team this month — he drafts and stress-tests writing, and I revise against the voice until the sentence either belongs to me or leaves. Arden, also new, audits and archives — the discipline of remembering what we decided and why.

They do not make the decisions. I do. I read the files, make the calls, and audit the outputs. The architecture they work inside is one I am responsible for. When the agents fall short — and they often do, sometimes spectacularly — catching it is part of my job. The audit practice, the validators, the cross-reference checks, the honest accounting of every documented failure mode: these are first-class parts of the project because no system, agent or otherwise, can hold a standard without the maker behind it.

What enables the agents is the structure underneath. The reference library where the project’s state lives. The documented order of consultation. The conventions every agent follows. The audit practice. The cross-references. The several hundred documentation files. The thousands of prototype iterations. The repository continuously maintained: every file headed, every change attributed, every cross-reference kept current, every significant decision tracked across a supersession chain. The work behind the work is most of the work, in this kind of project.

The agents are how I make the volume possible. They are how one person, in an apartment, on a small budget, with Hobbes asleep on the back of the couch and a coffee in the process of escaping its definition as coffee, builds the kind of tool I kept needing and could not find.

I will write more about how the workflow actually operates — what it has unlocked, what it has cost, what I do not yet know about whether the approach generalizes — in a future post. That conversation deserves its own room. For now, plainly: the agents are how I built it. The work is what I am here to give you.

What is coming

The Cabin is the work in front of me. I am building toward a public release. The foundation documents are drafted. The primitives are scoped. The architecture is locked where it needs to be and is in flight where it should still be in flight. I will be writing about the build as I make it — what holds, what breaks, what shifts under me. Follow along for the path.

DWELLING is alive. I will keep making it.

This post is the first in a series, and I have been waiting to start the series for a long time. Roughly, this is where we are going:

• A long-form post on the seven-agent workflow itself — what each agent has been doing, what the architecture is, what it has unlocked, what it has cost, what I do not yet know about whether any of this generalizes.
• The standard the work is held to. Where it comes from. How it changes what gets built. What it asks of the person doing the building. The Nickelodeon habits, examined in detail twenty-five years later.
• Free, in perpetuity — what that actually means in practice. How a one-person operation funds a tool that does not charge for itself. The model, openly. The conversation about what an indie game-dev tool owes the community it asks to find it.
• And the posts I will write because the work asked for them — the ones I cannot name yet. Those tend to be the best ones.

Miles with Micro continues. It has always been the place I write about the journey, personal and professional, and that does not change. The Cabin is getting its own custom domain — when it lands, it will carry the deeper project-side material this blog is not the right home for: workflows in detail, primitives in operation, the conversations the Cabin’s community will want on its own ground. The two run in parallel. The visuals the writing has earned — prototypes, mockups, screenshots, sketches, the artifacts the work has produced — will land where they belong on each, alongside the writing. You will see what the work looks like, not just what I have said about it.

It is now 4:11 AM. The coffee is no longer ambient brown; it has progressed to a category of liquid I will not describe. Hobbes has not moved. I have been writing for more than four hours.

This is the work. The Cabin is what I am bringing you.

Twenty-five years of doing this for other people, and now, for the first time, for the community I am about to enter — free, because it should be free, and because I care.

I am glad to be back. I am glad you are here.

The next post is on its way.

— Micro