This is a post about finding my own design flow while making a game, and how that relates to talking about it online.

As I begin posting more detailed design journals, I need to start figuring out what I actually want and need to present about the game. Early on, I could be abstract and vague, as I was just setting the stage as it were. Now, things start to become more technical, more in-the-weeds. Already, I have a handful of drafts talking about this rule or that system, and it’s all …fine? It’s a little dry. Little boring. I’d like to tell a story with my posts, not just present the mechanics. Otherwise, I could just post excerpts of the WiP manuscript of the rules.

Maybe it’s time to carve out specific and interesting things to talk about, instead of just presenting more and more rules of a game that is not finished. After all, as a tactical combat game, a lot of the basics are just the same as in any other tactical game. A grid, line of sight/effect, cover, and so on. While I approach these foundational things in my own way, which is informed by the larger design intent, they aren’t revolutionary either.

See, when I design parts of a game, I always reach a point where I need to stand back and ask myself, “Do I actually need this?” I once worked on a mech-style game which I pitched as Lancer meets Borderlands*. A looter-shooter style, hyper-violent mech TTRPG. One of the systems I wanted to have for it was hacking. After all, Lancer has hacking as part of the core gameplay alongside shooting mech guns. But I always wanted hacking to feel different than launching rocket clusters or punching with your mech-fist. And I just couldn’t make it work within the core system without feeling forced, bloated, and just more complex than I wanted the game to be. So I cut it out. It’s gone. No more hacking. Until, that is, a player decides to buy character advancements and mech upgrades that add hacking back into their personal experience. In other words, I removed the complexity of hacking from the core rules, and added it back as a player choice they can add if they so desire.

I think that approach of cutting things back and focusing on the things that improve the experience is a valuable lesson I’ve learned. And I want to apply the same sort of thinking when posting about my game design journey here. Instead of just presenting parts of the manuscript of an unfished game, I want to instead zoom in to specific design choices I made, solutions I came up with for running and playing the game.

I have a lot of thoughts on what would make a tactical grid-based game more fun, friction points of traditional approaches I want to innovate on, and even some entirely unique (far as I know) systems. So why not single those out and highlight what I think makes my game stand out? Cut back the stuff that just bloats my posts and doesn’t improve the story I’m wanting to go on with this blog.

There’s a part of me that feels like I must present as much detail as possible to provide context. But I think it’s fine, right? I mean, game systems usually exists holistically with the rest of the game, but for the purpose of just presenting my design approaches and ideas, I should be able to single out specific parts of it without spending 10,000 words on setting it up first.

Can’t be that difficult, right?

*The game was called Borderlance, by the way. I’ll get into it eventually, it was quite something.