Ross Esmond
@ross-esmond.bsky.social
Good Programmer, wannabe Board Game Designer, Math... Enthusiast, and half decent Technical Writer.
Here it is. This is the golden rule of feedback, and I've seen it everywhere: movies, video games, and board games.
People are good at identifying problems with the design, but bad at coming up with solutions.
People are good at identifying problems with the design, but bad at coming up with solutions.
November 2, 2025 at 2:31 PM
Here it is. This is the golden rule of feedback, and I've seen it everywhere: movies, video games, and board games.
People are good at identifying problems with the design, but bad at coming up with solutions.
People are good at identifying problems with the design, but bad at coming up with solutions.
You don't seem to define "protect" though. I believe it's targeting one of your own units, but it could also be a keyword thing.
This is a problem throughout the rule book. Like "contest", "attack", and "defend". I think you need to define these terms based on the physical state of the game.
This is a problem throughout the rule book. Like "contest", "attack", and "defend". I think you need to define these terms based on the physical state of the game.
October 31, 2025 at 1:10 PM
You don't seem to define "protect" though. I believe it's targeting one of your own units, but it could also be a keyword thing.
This is a problem throughout the rule book. Like "contest", "attack", and "defend". I think you need to define these terms based on the physical state of the game.
This is a problem throughout the rule book. Like "contest", "attack", and "defend". I think you need to define these terms based on the physical state of the game.
You can probably get by with just a little
"If the defending player has more banners (including cases where the village has *no* attackers)."
or something to that effect.
"If the defending player has more banners (including cases where the village has *no* attackers)."
or something to that effect.
October 31, 2025 at 12:51 PM
You can probably get by with just a little
"If the defending player has more banners (including cases where the village has *no* attackers)."
or something to that effect.
"If the defending player has more banners (including cases where the village has *no* attackers)."
or something to that effect.
I think you don't need full sections explaining what happens when you defend or attack a village uncontested. The rule book sets up the model that people will use to remember the rules, and it's much simpler to let the "most banners" rule encompass those cases, since it can.
October 31, 2025 at 12:51 PM
I think you don't need full sections explaining what happens when you defend or attack a village uncontested. The rule book sets up the model that people will use to remember the rules, and it's much simpler to let the "most banners" rule encompass those cases, since it can.
I got it. You're saying the units that were targeting the protected unit will instead target the unit doing the protecting.
When you say "targeted by rival units" you don't specify which "rival units" you're referring to, making it imprecise. That part could actually use its own example.
When you say "targeted by rival units" you don't specify which "rival units" you're referring to, making it imprecise. That part could actually use its own example.
October 31, 2025 at 12:39 PM
I got it. You're saying the units that were targeting the protected unit will instead target the unit doing the protecting.
When you say "targeted by rival units" you don't specify which "rival units" you're referring to, making it imprecise. That part could actually use its own example.
When you say "targeted by rival units" you don't specify which "rival units" you're referring to, making it imprecise. That part could actually use its own example.
The term "duel" is confusing. I thought the glossary would define it but it just references back to the page. Is that when two units target each other? How would that happen if they're placed one by one?
On this one, you could skip the jargon and just say what game state constitutes a "duel".
On this one, you could skip the jargon and just say what game state constitutes a "duel".
October 31, 2025 at 12:37 PM
The term "duel" is confusing. I thought the glossary would define it but it just references back to the page. Is that when two units target each other? How would that happen if they're placed one by one?
On this one, you could skip the jargon and just say what game state constitutes a "duel".
On this one, you could skip the jargon and just say what game state constitutes a "duel".
I'm running into a few problems. Like "Units that protect another unit will be targeted by rival units instead of the unit they are protecting."
I have no idea what that means. Maybe explain how "protection" works and who's targeting who in this scenario.
I have no idea what that means. Maybe explain how "protection" works and who's targeting who in this scenario.
October 31, 2025 at 12:34 PM
I'm running into a few problems. Like "Units that protect another unit will be targeted by rival units instead of the unit they are protecting."
I have no idea what that means. Maybe explain how "protection" works and who's targeting who in this scenario.
I have no idea what that means. Maybe explain how "protection" works and who's targeting who in this scenario.
Alright, cool.
Your export isn't using real text. In production your PDF export needs to use real text so that people can search for terms. It should be a setting in your design software. Something like turning off "for print".
Your export isn't using real text. In production your PDF export needs to use real text so that people can search for terms. It should be a setting in your design software. Something like turning off "for print".
October 31, 2025 at 12:08 PM
Alright, cool.
Your export isn't using real text. In production your PDF export needs to use real text so that people can search for terms. It should be a setting in your design software. Something like turning off "for print".
Your export isn't using real text. In production your PDF export needs to use real text so that people can search for terms. It should be a setting in your design software. Something like turning off "for print".
I think you can put the second page on the back and move everything else forward. That might be a better use of that reference.
October 31, 2025 at 11:38 AM
I think you can put the second page on the back and move everything else forward. That might be a better use of that reference.
There are also, sometimes, equivalent rules that are simpler and take up less space.
I read a rulebook that had 5 rules to explain a simple concept, and it still missed edge cases. I suggested the much simpler rule: "When you build, if you have more builders than buildings, gain a building."
I read a rulebook that had 5 rules to explain a simple concept, and it still missed edge cases. I suggested the much simpler rule: "When you build, if you have more builders than buildings, gain a building."
October 28, 2025 at 1:36 PM
There are also, sometimes, equivalent rules that are simpler and take up less space.
I read a rulebook that had 5 rules to explain a simple concept, and it still missed edge cases. I suggested the much simpler rule: "When you build, if you have more builders than buildings, gain a building."
I read a rulebook that had 5 rules to explain a simple concept, and it still missed edge cases. I suggested the much simpler rule: "When you build, if you have more builders than buildings, gain a building."
I stick to this. I have a few niche rules based on it. Like generally avoid prohibiting the player from doing something if it's almost always a worse move anyways.
And making something a choice is simpler than specifying what to pick: "choose one to keep" rather than "keep the one that's X, Y, Z."
And making something a choice is simpler than specifying what to pick: "choose one to keep" rather than "keep the one that's X, Y, Z."
October 28, 2025 at 1:36 PM
I stick to this. I have a few niche rules based on it. Like generally avoid prohibiting the player from doing something if it's almost always a worse move anyways.
And making something a choice is simpler than specifying what to pick: "choose one to keep" rather than "keep the one that's X, Y, Z."
And making something a choice is simpler than specifying what to pick: "choose one to keep" rather than "keep the one that's X, Y, Z."
There are other ways of doing it, like you said. Anything that allows for a mutually beneficial trade works, but tossing in a little extra or making the act of trading beneficial are two easy ways to do it. I also wanted to mention Catan, which doesn't do this, but I ran out of space.
October 17, 2025 at 6:31 PM
There are other ways of doing it, like you said. Anything that allows for a mutually beneficial trade works, but tossing in a little extra or making the act of trading beneficial are two easy ways to do it. I also wanted to mention Catan, which doesn't do this, but I ran out of space.
I got to something like that later in the chain. Limiting characters isn't great for nuance.
Combat is different though, in that usually only one player has to choose to start combat—the player who serves to benefit. When both players have to agree, that's when mutual benefit becomes a factor.
Combat is different though, in that usually only one player has to choose to start combat—the player who serves to benefit. When both players have to agree, that's when mutual benefit becomes a factor.
October 17, 2025 at 6:31 PM
I got to something like that later in the chain. Limiting characters isn't great for nuance.
Combat is different though, in that usually only one player has to choose to start combat—the player who serves to benefit. When both players have to agree, that's when mutual benefit becomes a factor.
Combat is different though, in that usually only one player has to choose to start combat—the player who serves to benefit. When both players have to agree, that's when mutual benefit becomes a factor.
In both of these games, any player who refuses to ever make a deal is almost guaranteed to lose, forcing player's hands.
This isn't strictly necessary—if two players need each others resources a trade can still happen organically—but I suspect it's way easier to just tip the scales a bit.
This isn't strictly necessary—if two players need each others resources a trade can still happen organically—but I suspect it's way easier to just tip the scales a bit.
October 17, 2025 at 12:25 AM
In both of these games, any player who refuses to ever make a deal is almost guaranteed to lose, forcing player's hands.
This isn't strictly necessary—if two players need each others resources a trade can still happen organically—but I suspect it's way easier to just tip the scales a bit.
This isn't strictly necessary—if two players need each others resources a trade can still happen organically—but I suspect it's way easier to just tip the scales a bit.
Bohnanza took the opposite approach by threatening you with bad beans. You want to get beans out of your hand, which you can only do with trades. Carrot and Stick.
Trades in a zero sum game are theoretically always lopsided. Injecting a flat +1 into the equation fixes that.
🎲✂️ #BoardGameDesign
Trades in a zero sum game are theoretically always lopsided. Injecting a flat +1 into the equation fixes that.
🎲✂️ #BoardGameDesign
October 17, 2025 at 12:25 AM
Bohnanza took the opposite approach by threatening you with bad beans. You want to get beans out of your hand, which you can only do with trades. Carrot and Stick.
Trades in a zero sum game are theoretically always lopsided. Injecting a flat +1 into the equation fixes that.
🎲✂️ #BoardGameDesign
Trades in a zero sum game are theoretically always lopsided. Injecting a flat +1 into the equation fixes that.
🎲✂️ #BoardGameDesign
A brick pattern is the exact same I believe.
October 10, 2025 at 11:26 AM
A brick pattern is the exact same I believe.
I like seeing those games in action, but there is a different feeling between the two, especially for repeat play tests.
I wrote this because of a prototype I've been playing repeatedly. The designer is super appreciative, which is fine, but I had to explain that I wasn't really doing him a favor.
I wrote this because of a prototype I've been playing repeatedly. The designer is super appreciative, which is fine, but I had to explain that I wasn't really doing him a favor.
October 7, 2025 at 8:06 PM
I like seeing those games in action, but there is a different feeling between the two, especially for repeat play tests.
I wrote this because of a prototype I've been playing repeatedly. The designer is super appreciative, which is fine, but I had to explain that I wasn't really doing him a favor.
I wrote this because of a prototype I've been playing repeatedly. The designer is super appreciative, which is fine, but I had to explain that I wasn't really doing him a favor.
I figured out how to do a Balatro board game and emailed the designer of Balatro about it.
I have a bad tendency to work on games from existing IP. I'm a programmer with a degree in math. So I'm really good at honing ideas, but I need to get better at working on my own.
I have a bad tendency to work on games from existing IP. I'm a programmer with a degree in math. So I'm really good at honing ideas, but I need to get better at working on my own.
October 7, 2025 at 10:43 AM
I figured out how to do a Balatro board game and emailed the designer of Balatro about it.
I have a bad tendency to work on games from existing IP. I'm a programmer with a degree in math. So I'm really good at honing ideas, but I need to get better at working on my own.
I have a bad tendency to work on games from existing IP. I'm a programmer with a degree in math. So I'm really good at honing ideas, but I need to get better at working on my own.
Depends on the standard of success. I'm not published, but I have a couple of board game prototypes that I'm proud of. One of them is sent off for consideration at the moment.
I then have maybe a couple of dozen shelved prototypes. That's where most of my thoughts come from.
I then have maybe a couple of dozen shelved prototypes. That's where most of my thoughts come from.
October 7, 2025 at 2:36 AM
Depends on the standard of success. I'm not published, but I have a couple of board game prototypes that I'm proud of. One of them is sent off for consideration at the moment.
I then have maybe a couple of dozen shelved prototypes. That's where most of my thoughts come from.
I then have maybe a couple of dozen shelved prototypes. That's where most of my thoughts come from.
I had the same thought process with the same game. I realized it was more intuitive to have that little bit at the start, so at least there's a counterexample.
September 25, 2025 at 11:39 PM
I had the same thought process with the same game. I realized it was more intuitive to have that little bit at the start, so at least there's a counterexample.
But, most importantly, the jargon and instructions in your rule book will naturally make more sense after you've explained what the player will be doing.
"I'm going to have to clear the wango cards from my play space? What the hell are wango cards and why are they in my play space?!"
🎲✂️
"I'm going to have to clear the wango cards from my play space? What the hell are wango cards and why are they in my play space?!"
🎲✂️
September 25, 2025 at 4:55 PM
But, most importantly, the jargon and instructions in your rule book will naturally make more sense after you've explained what the player will be doing.
"I'm going to have to clear the wango cards from my play space? What the hell are wango cards and why are they in my play space?!"
🎲✂️
"I'm going to have to clear the wango cards from my play space? What the hell are wango cards and why are they in my play space?!"
🎲✂️
It's usually equivalent. The phase happens in-between rounds either way, you're just presenting it differently: at the end of the prior round rather than start of the next.
You often don't even have to say "skip this in the last round" because the end-game trigger has already stopped the game.
You often don't even have to say "skip this in the last round" because the end-game trigger has already stopped the game.
September 25, 2025 at 4:55 PM
It's usually equivalent. The phase happens in-between rounds either way, you're just presenting it differently: at the end of the prior round rather than start of the next.
You often don't even have to say "skip this in the last round" because the end-game trigger has already stopped the game.
You often don't even have to say "skip this in the last round" because the end-game trigger has already stopped the game.