Where Everything Meets
Rules meet stories. Economies meet human behaviour. Tools meet the people who use them. Few things ask this many disciplines to become one experience — which is why I keep having the same thought: I need a place to put everything.
Games are where everything meets
A marketplace reveals and shapes what people value. An economy turns that value into choices. Rules create pressure; social systems turn pressure into alliances, habits, jokes, and betrayal. Story gives those choices meaning. Tools decide which ideas creators can afford to try. Architecture determines how safely all of it can change. Then human beings arrive and use the whole thing in ways nobody predicted.
Few products put marketplaces, social systems, economies, rules, storytelling, tools, architecture, and human behaviour in one place. Fewer still make every boundary part of the experience. A clean rule can produce a dull choice. A useful tool can change the kinds of stories a team tells. A tiny social gesture can matter more than a system built to look important.
That convergence is the fascination for me. Architecture is part of it, and it is the part I naturally reach for, but architecture is not the subject. The subject is what becomes possible when all the parts can meet.
I spent more than ten years of my career working on game teams, then about five years outside games. When the itch returned, there was no grand plan attached. I just knew I had to build something and find out where the feeling led.
↓ Continue to the mapThe Cliff Notes
The reason is above. Six turns through the build are below, with the parts that went wrong left in.
- The projectA Discord adventure bot became a rules toolkit, a game server, and a shared 3D dungeon. Most of the work stayed invisible until the halfling above walked into it.
- The architectureConditions, features, equipment, spells, and terrain share one participation model. The rulebook supplies meaning; the engine supplies room.
- The failureRage deadlocked while trying to end itself. I discarded the implementation and kept what it taught the event system.
- The boundaryThe game server stores Rage as data it cannot interpret. The rulebook restores the behaviour without spreading the rule.
- The artProfessional art finally made the game visible. The engine did not have to change to accept the halfling.
- The payoffDice roll on the dungeon floor. When you help a teammate, they roll your die. The architecture becomes a shared social moment.
↓ the whole thing, with the failures left in
“This is what you wanted to add?”
The first nudge came from a Mastodon bot that ran adventures through polls. People voted on what the party did next, and the story moved. I loved it. I contributed exactly one pull request.
It was not a new adventure or even a feature. I found a tangled piece of logic and simplified it until it read clearly. The maintainer’s response was, more or less: this is what you wanted to add?
He was not being unkind. He was surprised that, given a whole game-shaped thing to touch, I had reached for the place where the parts were hard to reason about.
I have thought about that comment ever since. Somebody had named the way I make things before I had.
I am a creative. It is just architectural creativity, and not so much on the visual side.
That does not make architecture a lesser form of creativity. It does make it a form that needs something else to meet. A beautifully arranged system with nobody making, playing, or caring on top of it is just a beautifully arranged system.
Forms meant character creation
I started building a D&D bot for Discord along the same lines: polls to steer the adventure, text coming back.
Then I learned Discord bots could have forms. The project changed immediately, because forms meant character creation. Not voting on what the party did next. Sitting down and making someone.
That is a small interface capability with a large human consequence. A form created ownership. Everything after it had a person on the other end who had made someone and cared what happened to them.
Around then I built an ASCII scene of a room and was thrilled with that too. The honest scale was a character sheet inside a chat window and a room made of text characters.
Then two more things landed close together. Discord Activities could put a real web application inside a voice channel, with everyone in it. Three.js could put 3D in a browser. The paragraph could become a place the party shared.
I did not yet have a place for everything. I had something more useful: a reason all those things might need to meet.
The question that was too small
Once the room could be more than text, the project needed rules underneath it. I began with what looked like a contained question: what is a condition? Poisoned, blessed, enraged. How should the engine represent that?
The question was too small. A condition, a class feature, a weapon enchantment, a spell effect, and difficult terrain all have the same shape: each hooks into what is happening and changes it. The little bus I had built to pass combat modifiers around was the place all of them could meet.
The note from that week puts it more bluntly than I would have: “we realized our event bus isn’t just for conditions — it’s the nervous system of the entire game.”
The creative consequence mattered more than the diagram. A designer could define dawn restoring a paladin’s power, a story milestone refilling a resource, or a spell topping up an ally without asking for a new kind of engine each time.
I learned that by first doing the opposite. I built a concentration manager, realised it belonged to one game’s rules, and removed it. I put ProcessShortRest() on a generic resource pool and called it a red flag in my own notes. The engine should not know what a short rest is. It needs to know something happened and give every relevant part a chance to care.
Rage was supposed to be a hundred lines
Barbarian rage: you get angry, you hit harder, you take less damage. I estimated about a hundred lines.
In 5e, rage ends if you go a round without attacking or being hit. Rage listens for the end of your turn; when it is over, it has to stop listening. That is where the engine stopped dead. The event system held a lock while handing out the event, and un-listening needed the same lock. The feature could not switch itself off. A barbarian could not stop being angry.
The fix is the first thing in the engine I would still defend today. A listener never reaches into the machinery mid-flight. It returns what it wants to happen, and the machinery acts once the event finishes. Events complete, then the world changes.
That was the useful failure. The rest was mine: untyped strings everywhere, plus infrastructure I had already written, ignored, and rebuilt worse. I threw the pull request away and filed five issues from the wreckage.
Two lines I wrote that night and still stand by: “Sometimes the best code is the code you don’t ship.” And “Better to have no combat than broken combat.”
Over the next thirty-six hours, rage became one self-contained object. It listens for three things, tracks whether you swung and whether you were hit, and removes itself when neither happened. Nothing polls it. No combat code asks “is this character raging?”
That is an architectural result, but the payoff belongs to everyone making content: a new effect can be attached to a player, monster, or trap and manage itself. A new idea no longer requires a new branch through combat.
↑ Back to the mapThe server never learns what rage is
Saving the game exposed a different boundary. A character may have a rage with two uses left and a bless that expires in four rounds. If the server has to understand both, then the rules live in two codebases and every change becomes a negotiation between them.
Instead, every piece describes itself. A feature knows how to write itself down and read itself back. The server stores a blob it cannot interpret. On the way in, the engine reads one field — a name like dnd5e:feature:rage — and hands the whole thing to whoever owns that name.
The game server never learns what rage is.
It arrived as one line buried in a list on the least confident day of that week, when I wrote four documents and decided nothing in any of them: “ToJSON for storage, ToData for internals.”
Fourteen months later it is load-bearing across the codebase. The idea I was excited about that week is the one that did not ship.
A good boundary is not interesting because it is clean. It is interesting because two parts of a team can change what they own without forcing the other part to impersonate them.
↑ Back to the map“I have a place to put everything”
The feeling first arrived when the event bus existed:
I have a place to put all of the things I need.
I did not, quite. I had a place for conditions, features, and interruptions. That was a great deal, but it was not everything. Still, this was the first time the shape of the project felt bigger than the feature list.
The error is revealing. I was measuring “everything” in rules. Games keep moving the boundary outward.
A +2 shows up in a combat log
A barbarian rages. The condition attaches itself to the damage calculation. A +2 appears, itemised, in the breakdown a player reads: not a number from somewhere, but a number with its reasons attached.
It was the first visible proof that any of the invisible work reached a human being. The architecture, rule, interface, and explanation had finally met on one line.
Then I went and did something else for four months.
No design documents. No architecture decisions. Ten merged pull requests across three repositories in February.
Life had become busy in a literal, measured way. I was training for a 108-kilometer ultra with five kilometers of elevation gain, regularly taking my weekly running past 100 kilometers. That takes time.
Work was consuming the same kind of attention. My company was learning how to use AI effectively, and I was deep in the practical questions: how to deploy agents, and how to help developers make the tool useful in their actual work.
The game did not lose to one thing. It waited while two demanding, interesting things won the calendar.
I came back needing an audit
When I came back, the work detour came with me. The questions I had been answering there had changed the way I worked across a rules engine, server, and 3D client.
They did not spare me from understanding any of them. I no longer trusted my memory of the codebase I had written, so I re-derived it by searching the source.
Two packages on the combat hot path did not appear anywhere in my documentation. Something I would have said confidently about my own architecture came back marked partially true — needs correction.
That is worth saying plainly. Tools can increase reach. They do not make judgment, context, or reorientation optional.
I found out I could just buy the halfling
The thing holding me up was never the engine.
I cannot model a character. I cannot texture a crypt or animate a greatclub swing. That is a real wall for one person, and no amount of architecture gets you over it. For a long time the honest answer to “when will this look like a game?” was: it will not.
Then I found Synty asset packs: professional low-poly art, buyable in bulk. A marketplace closed a creative gap I could not close by pretending to be another discipline. At the same time, the way I was working had changed.
In the month after the art landed, more work shipped across the three repositories than in any previous month — against a trough of ten merged pull requests five months earlier.
Two things changed in that window, not one. The art arrived and the way I was working changed. I am not going to claim the assets alone did that.
The meeting worked because of what came before it. The engine did not have to change to accept the halfling. He could walk, swing, open a door, and be seen by a monster that reasoned about him, because none of that had ever depended on what he looked like.
But the reverse was also true: the engine finally mattered differently because someone else’s art gave players a person to see. Neither half was the game by itself.
↑ Back to the map
The die belongs to someone
Throwing dice is a large part of what tabletop play actually is. It is the moment everyone leans in. So this game rolls them as a table does: on the dungeon floor, in front of everyone.
They are objects. They bounce off walls and can fall off the table. When a check happens, the die is there, on the ground where somebody left it, and you click it.
The part I like best happens when you help someone. If you are buffing a teammate, they roll your die. Your bless. Your d4 in their hands, on the floor, in front of the party. Helping becomes an event in the room instead of a number quietly added to a total.
That one decision is the thesis in miniature. A rule meets a 3D object, ownership meets generosity, and a calculation becomes theatre. The technical system succeeds by getting out of the way of a human gesture.
Damage dice are coming. The camera moves with the moment — over the shoulder when it is yours, pulled back to tactical when it is the party’s, and all the way out to a tabletop view when you want the board. Dice will be customisable, because of course they will. Everybody has a set.
I am not a game designer. This is the decision I would defend hardest anyway.
The parts were never the point
I could write the rules engine, the server, and enough of the client to connect them. I could not model the halfling. Each time the project crossed into another discipline, it became more like a game and less like an arrangement of systems.
I am not going to pretend the halfling is my work. Somebody at Synty modelled him. What I built is why he can pick up a club that is obviously too big for him, have the rules agree that he may try, have the room remember that he did, and leave the skeleton in the corner unaware of it.
After more than ten years on game teams, this should not have surprised me. Five years away had not made me miss leadership; I kept leading and mentoring. What I had missed was the exchange: different disciplines changing one another’s answers, then shipping the thing none of them would have made alone.
Building alone made the absence of that exchange unusually visible. But I do not have to keep building alone. A couple of my friends have joined me on this journey. One of the earliest tools in the project came from one of them. The rest of the architecture was not ready for it then, and I have finally been able to integrate it.
That may be the better test of the architecture: whether somebody else’s idea can find a place in it without having to become mine first.
I might not have everything I will need. But it currently looks like I have a place to put everything we want to build.
For now, that place contains a halfling carrying a club roughly one and a half halflings long. I am very happy with it.