Designing for Minimalism

I spoke about this on last night's stream, but wanted to dwell on the subject a little.

I've made a bit of a point about wanting to make games that push up against the minimalist end of the spectrum, rather than drifting toward the middle. So what does this actually mean when it comes to the process of making a game?

I'll be referring to some parts of Project 10 as examples, but it's the same process I use when working on RPGs.

My thoughts on this can be summarised into a few main points. This isn't intended to be an exhaustive thesis on the matter, so much as the things that are currently at the forefront of my mind.

Minimalism is Compromise

Minimalism in games goes hand in had with abstraction. You're using a few simple rules to (typically) simulate something complex. In Project 10 terms you could break down every clash between units into its own game lasting hours. You'd consider the qualities, position, and condition of every individual soldier on the front line, and the wealth of specific manoeuvres and tactics that they could implement. 

Instead we roll the deliberately swingy Combat Dice and accept that all those factors are tied up in that roll. An attack came up with maximum damage? I guess the defender's front line got broken wide open. Roll a single point of damage, which got blocked by their Shield trait? Guess they pulled up the shield wall and held strong. 

The compromise is that the players don't get to have input on those little fictional details, but in return they get to focus on everything else. Which leads to...

What's the Point?

Making a quick, simple game is all well and good. You sit down and play it in less than an hour, pack it away, and declare it a good, elegant game. Then you forget it exists and start thinking about that monster-sized boardgame you've never managed to get to the table, or that RPG campaign you've been planning since you were twelve. 

In its current state, Project 10 runs nice and quickly, has a balance of strategic manoeuvring with chaotic drama. But what's the point of it all?

In all honesty, that's something I'm still working out, and it's all part of the process. I like that you can run battles so quickly that you can bash out a short campaign in an evening. I like that it's easy to make new army lists that feel different to each other. I like that the short, chaotic games lend themselves well to weird, asymmetric scenarios. But I need to put this all into practice on the page. The sample campaign and army lists are a start, but there's more room to grow here.

For a more complete example look at Electric Bastionland's single spread of rules being supported by hundreds of pages of flavour-filled characters, conducting procedures, and an oddendum of essays. Because the reader isn't spending hours learning the system I can bank on them actually exploring and absorbing that other stuff. 

Table Outranks Desk

It's so easy to sit at your computer and think about rules that this game should have.

I mean of course there should be a rule that lets skirmishers move after shooting. Of course these rocks should slow down units that move over them. Of course pikes should get a specific bonus against cavalry. People who read your game might even suggest these changes, whether they've played the game or not. Some people just want to help, after all. 

Don't go too far down the rabbit hole. Make the minimal viable game and get it to the table yourself, even if you're playing both sides. The stuff that happens on the table is the real test of whether a game needs to have more rules or not.

When you're getting feedback from others, ask for how the game felt at the table, not what they think they'd change or add if they were making this game. Ask them for their problems, you don't want their solutions. 

Cost Every Rule

At this point it's worth pointing out that I love rules! I think every game should have at least one.

And things get really interesting when you have two rules (see below) but for now let's look at the two sides of every rule.

Every rule has a cost. There's the cognitive load on the player of learning another rule, the literal space on the page, the indirect problems that could arise from its interaction with existing or future rules, and even an opportunity cost that comes from closing up an area of the design space. 

Sure, they sound bad, but remember the point here is to weigh them up against the benefits. I recently added a rule to P10 where units that are halfway to being destroyed are Shaken and no longer benefit from the second of their two traits. This rule definitely adds complexity, and it meant I had to reconsider each of the individual traits, but so far I feel like the benefit has been worth it. Now a unit with Shield and Brutal is significantly different to a unit with Brutal and Shield, and there's more incentive to pull your shaken units away from combat so that they can regroup, which is the sort of manoeuvring I want to encourage. 

But really the most interesting thing about that new rule is how it interacts with the traits and prebuilt units. It's almost like...

When there's less, each part matters more.

This can be both a good and bad thing. It's great when you have two simple mechanics that interact with each other in an interesting way, but finding those moments can be tough. It's a bit of a cliché to say that designing a simple thing is more difficult than designing a complex thing, and I don't necessarily think it's true, but it definitely carries a different sort of challenge. You've got to look out for those moments where things click together and jump on them before they escape.

Indulgent Epilogue

Last year I wrote about my early experiences with tabletop gaming, specifically how I spend the months before I actually owned any Warhammer rules or miniatures pouring over issues of White Dwarf, especially the battle reports with their armies arrayed and top-down maps of the battle as it played out.

I think Project 10 is all about trying to capture how those battles felt as I read them at ten years old.