My christmas gift …
to myself and others: Beginning the design blog
Now that I’m on my Christmas holiday I’ve had time to think about things, and especially after reading Taron Pounds (Indestructoboy)’s Patreon post I’ve decided that this is a good time for me to get my feet wet. So before I start getting into the nitty gritty, I wanted to kind of go over my intent for this blog.
First and foremost, this blog is a design journal.
It isn’t a guide on how to design a tabletop roleplaying game, and it isn’t an attempt to present a finished philosophy. What I’m documenting here is the process of designing a single TTRPG from start to finish—MY TTRPG—including the parts that don’t work, the assumptions that turn out to be wrong, and the revisions that only make sense in hindsight.
The goal isn’t to arrive at clean conclusions. It’s to record decisions as they’re made, while the outcome is still uncertain.
Why This Project Exists
This project started for a simple reason.
Rather than continuing to mold my ideas into existing systems—compromising here, house-ruling there—I wanted to see what would happen if I designed the game I actually wanted to play. One built from the ground up around my own interests, sensibilities, and tolerances as both a player and a GM.
I’m not trying to make a “D&D killer.” I don’t expect this project to become widely popular, commercially successful, or definitive in any meaningful way. At its core, this is a selfish project in the most literal sense: it exists because I want it to exist.
If other people end up enjoying it, that’s great. If they borrow ideas from it, even better. But those outcomes aren’t the motivation. They’re side effects.
Designing without the pressure to appeal broadly frees me to be explicit about tradeoffs, to lean into ideas that might not be universally appealing, and to discard conventions that don’t serve my own table. That constraint—designing for myself first—is what gives this project its shape.
Why Write About It Publicly?
Most design write-ups are written after the fact. By the time they’re shared, the messy parts have already been edited out. The logic is clean, the narrative is linear, and the uncertainty has been resolved.
This blog is meant to capture the opposite.
Each post is written during the design process, while ideas are still in motion and outcomes aren’t guaranteed. That means you’ll see mechanics before they’re refined, changes that contradict earlier decisions, and solutions that introduce new problems instead of cleanly fixing old ones.
Writing publicly forces me to slow down and articulate why something feels right or wrong, not just whether it works. Even when a change doesn’t pan out, understanding why it failed tends to be more useful than the version that replaces it.
If there’s value here for anyone else, I expect it to come from that transparency rather than from any particular result.
On Notes, Drafts, and Process
A lot of this design work starts on paper.
I tend to sketch ideas, mechanics, and diagrams by hand first—often without a clear endpoint—before coming back later to translate them into something more structured on the computer. As a result, some posts will include photos of handwritten notes, margin diagrams, or half-formed ideas alongside more formal write-ups.
Those notes aren’t meant to be artifacts or conclusions. They’re snapshots of where my thinking was at a particular moment. In many cases, the ideas in them will change or be discarded entirely by the time they’re written out properly.
I’m including them anyway, because they’re part of how the design actually happens.
How These Posts will be Structured
Every entry will follow the same basic format (as best as I’m able):
What I worked on
The specific system, mechanic, or design problem I was focused on.What went wrong
Where assumptions didn’t hold, friction emerged, or testing revealed unintended consequences.What I changed
The adjustments I made in response, and why they seemed reasonable at the time.What I’m testing next
The next iteration or experiment, before I know how it will turn out.Questions
One or two focused questions, or occasionally a poll. Feedback is welcome and considered, but not every suggestion will be adopted.
This structure isn’t meant to be prescriptive. It’s just a way to keep each post grounded in concrete decisions rather than abstract theory.
On Feedback and Expectations
Comments and critique are encouraged. Disagreement is expected.
That said, this isn’t a community-designed game. Feedback helps surface blind spots and alternative approaches, but final decisions are filtered through the goals and constraints of the project as a whole—most of which are rooted in my own preferences as a player.
Sometimes a suggestion is good in isolation but doesn’t fit the direction I want the game to go. Other times it solves a problem the game simply isn’t trying to address.
When feedback isn’t adopted, that doesn’t mean its being ignored—it just means it didn’t belong here.
What This Blog Will Cover
Over time, this journal will touch on several broad areas:
Vision & Goals – What I want this game to do, and what I’m intentionally not designing for.
Core Mechanics – Resolution systems, action economy, and failure states.
Supporting Systems – Advancement, resources, and long-term play considerations.
Playtesting – How testing is conducted, what I’m paying attention to, and what surprised me.
Revision & Polish – Cutting, consolidating, and refining.
Release & Reflection – What worked, what didn’t, and what I’d change next time.
These topics won’t necessarily be addressed in order. Design rarely moves in a straight line.
A Final Note
Mistakes will show up here. Some will be obvious. Others won’t be apparent until much later. That’s part of the point.
This is a record of one person designing one game for their own table. If that perspective is useful to others, great. If not, the project still succeeds on its own terms.
The next post will start with the first real design question.
We’ll see where it goes from there. I hope you join me on this journey.
- TTRPG Traveller
