OK. Here's it is, the big design challenge for the board game we're working on. We've been trying to solve this problem in-house for months, going as far as posting it on game-design message boards, trying to outsource the problem to smarter minds. Only recently did I decide I could solve the problem with good design somehow, and set myself to it.
I thought of you, Lennard, when I was finishing up production for this problem, because of how much fun it is to confront a design challenge that you simply cannot figure out, but you know you need to solve it to keep some intrinsic function in your game. I had so much fun solving it, I starting praying that we could solve some problems like this for our video game.
So. To understand the problem, of course, you'll need to understand the game, to some extent...
__________
So, a basic mechanic of the game (and in real life bee-keeping) is:
You, the player, have Hives, and these hives can have bees in them. Bees produce honey, having the most honey is how you win the game.
(this is our alpha "Hive" piece and the analogous structure irl)
Like in the image above, once the hive has bees in it that are producing honey, you can add a "Super" to the hive (those boxes on top) that allow the bees to expand their colony, and produce more honey.
(adding Supers to Hives. "Up" arrows mean the supers are full of honey, "Down" means they're empty. In this example, the hive on the far right is at full capacity - the supers are full, and there is nowhere for the bees to expand their colony)
...Thing is, if the bees start producing honey, but there is nowhere for them to expand (Supers), then the hive will "Swarm". When a hive "Swarms", half of the bees and the queen leave the hive and go look for a new home, dramatically decreasing the strength of the original hive (this is true in the game, and in real life as well). Once the hive weakens in this manner, it has to grow back up in strength before it can start producing honey again. Does all this makes sense?
So you can see, the basic mechanic to the game is a balancing act of doing your best as the player to have strong hives that are filling lots of Supers full of honey (a full Super = honey = winning the game), and also keeping up production of the Supers, so that your hives always have room to expand - because if they don't, they swarm, and they weaken, and they stop producing honey for awhile.
OK, a fairly simple and clever mechanism. There's one more thing though: Hive Strength.
There are 4 Hive Strength States: Empty, Weak, Healthy, and Strong.
-Empty hives have no bees, and do not grow.
-Weak hives grow into Healthy Hives
-Healthy Hives grow into Strong Hives
-Strong Hives produce Honey.
Don't worry about how or when Hives grow (or weaken) in strength, it's a basic weather mechanic that is cool, but doesn't effect this design problem. You can see, if you want to win the game, you need to grow your hives into Strong Hives, because only Strong Hives produce honey. But there's a fundamental design question here, and it's the design problem I've been leading up to:
How do you signify Hive Strength?
To better illustrate the problem, here's one of the early ideas Fletch came up with:
A base would go under each hive, and the forward side of the base would display the hive strength. 0=empty, 1=weak, 2=healthy, 3=Strong. By flipping and rotating the base, you could change the Hive State. Hive State is probably the most important variable in the game, and it is called upon frequently.
But there are some basic and unacceptable design flaws in this method, maybe you can spot some of them just by imagining gameplay.
-The pieces are vulnerable to shifting on their base: Hives are frequently being moved, changing states, adding/subtracting supers, and every time they are moved, you risk "losing" the Hive State, or not being able to read it properly.
-The Hive States are not legible from all sides. The game works better if all players know the strength of all hives around the game board, and these bases only allow you to read the hive strength if you're lucky enough to be in front of them.
-Flipping and turning the piece feels clumsy and lacks elegance. Often you're caught flipping and turning the piece looking for the correct strength level, which risks the player forgetting what they're doing, ruins game flow, and most importantly, diminishes the tactile fun-ness of the game.
-The hive stacks get a bit precarious. Often, the hives have many supers on them (currently there is no limit) so moving this stack around the game board so often risks dumping the stack when it slides around on it's base.
-The bases too-closely resemble the hive and supers in shape and form. With so many hives and supers around the game board, the rectangular shape of the bases, with it's vital information, is often obscured.
We all agreed early on the problem of properly displaying Hive States needed to be figured out in an elegant, simple, intuitive and interesting way. This method above could never go to market. Hive states needed to be discerned easily from both sides, they need to move around the game board easily with the rest of the stack of pieces, and there can't be any risk of the Hive State shifting during these moves. Beyond that, there are several fundamental design thoughts at play: the solution should be fun, or, at least, not un-fun, it shouldn't muddy gameplay, it shouldn't be too hard to manufacture, it should be thematic in some way, etc.
We wracked our frigging brains on this dilemma. We had several meetings that completely devolved into us discussing this basic problem, and everyone just wringing their hands in silence saying "yeah, I just don't know...". I mean, if you have a moment, I encourage you to try and think of something off the top of your head that is better than the above solution.
Months passed. We tried a couple other tactics, thinking outside the box. We built an entirely new pre-alpha version of the game based around a new solution: "Ok, well, what if the Hive State is signified by WHERE on the game board it rests?" The thought was, each location on the game board, called "Apiaries", would have a location within it entirely devoted to Hive State. When your hives grew or weakened, they would slide up and down inside the Apiary. We thought it might work. It was a simple motion - sliding the hive stacks up and down - it eliminated the extra base pieces we were using, and it was legible from all around the table. We thought we'd finally figured it out.
...Buuuuut, there were some basic problem with this method, as well.
There are 4 Hive Strength States: Empty, Weak, Healthy, and Strong.
-Empty hives have no bees, and do not grow.
-Weak hives grow into Healthy Hives
-Healthy Hives grow into Strong Hives
-Strong Hives produce Honey.
Don't worry about how or when Hives grow (or weaken) in strength, it's a basic weather mechanic that is cool, but doesn't effect this design problem. You can see, if you want to win the game, you need to grow your hives into Strong Hives, because only Strong Hives produce honey. But there's a fundamental design question here, and it's the design problem I've been leading up to:
How do you signify Hive Strength?
To better illustrate the problem, here's one of the early ideas Fletch came up with:
A base would go under each hive, and the forward side of the base would display the hive strength. 0=empty, 1=weak, 2=healthy, 3=Strong. By flipping and rotating the base, you could change the Hive State. Hive State is probably the most important variable in the game, and it is called upon frequently.
But there are some basic and unacceptable design flaws in this method, maybe you can spot some of them just by imagining gameplay.
-The pieces are vulnerable to shifting on their base: Hives are frequently being moved, changing states, adding/subtracting supers, and every time they are moved, you risk "losing" the Hive State, or not being able to read it properly.
-The Hive States are not legible from all sides. The game works better if all players know the strength of all hives around the game board, and these bases only allow you to read the hive strength if you're lucky enough to be in front of them.
-Flipping and turning the piece feels clumsy and lacks elegance. Often you're caught flipping and turning the piece looking for the correct strength level, which risks the player forgetting what they're doing, ruins game flow, and most importantly, diminishes the tactile fun-ness of the game.
-The hive stacks get a bit precarious. Often, the hives have many supers on them (currently there is no limit) so moving this stack around the game board so often risks dumping the stack when it slides around on it's base.
-The bases too-closely resemble the hive and supers in shape and form. With so many hives and supers around the game board, the rectangular shape of the bases, with it's vital information, is often obscured.
We all agreed early on the problem of properly displaying Hive States needed to be figured out in an elegant, simple, intuitive and interesting way. This method above could never go to market. Hive states needed to be discerned easily from both sides, they need to move around the game board easily with the rest of the stack of pieces, and there can't be any risk of the Hive State shifting during these moves. Beyond that, there are several fundamental design thoughts at play: the solution should be fun, or, at least, not un-fun, it shouldn't muddy gameplay, it shouldn't be too hard to manufacture, it should be thematic in some way, etc.
We wracked our frigging brains on this dilemma. We had several meetings that completely devolved into us discussing this basic problem, and everyone just wringing their hands in silence saying "yeah, I just don't know...". I mean, if you have a moment, I encourage you to try and think of something off the top of your head that is better than the above solution.
Months passed. We tried a couple other tactics, thinking outside the box. We built an entirely new pre-alpha version of the game based around a new solution: "Ok, well, what if the Hive State is signified by WHERE on the game board it rests?" The thought was, each location on the game board, called "Apiaries", would have a location within it entirely devoted to Hive State. When your hives grew or weakened, they would slide up and down inside the Apiary. We thought it might work. It was a simple motion - sliding the hive stacks up and down - it eliminated the extra base pieces we were using, and it was legible from all around the table. We thought we'd finally figured it out.
...Buuuuut, there were some basic problem with this method, as well.
-It's not very elegant. Sure, it's simple, but sliding hives around inside an apiary to signify strength is not intuitive. Where something is located has nothing to do with it's strength in real life, so it required extra explanation, and beyond that, so much of the game is true to life and thematic in some way - this one thing was pulling you out of the beekeeping experience.
-Apiaries now required 4X the real-estate. These locations around the board have Hive-limits, only 2 or 6 or 8 Hives on any particular apiary allowed. But now, each apiary would need to accommodate for the maximum number of hives in each Hive State zone, just in case all the hives were in the same state at the same time. Not an efficient use of game-board space
-Worst of all: Hive States don't move with the Hive. By removing the base piece, we made it so that Hive States are connected to the location rather than the Hive Stack itself. This meant when you moved your hives to a different location, you would need to be careful to put it in the right location inside the location to which you were moving it. Players were forgetting the Hive State during movement, and the information can't be recovered once it's moved and forgotten.
This is when I became obsessed with it. I just wrote it all out and started drawing pictures, starting playing with pieces, moving the pieces around, testing testing testing. And then I got a wild idea that I was positive was not going to work, but I think it totally did (the jury is out until more play testing).
-Apiaries now required 4X the real-estate. These locations around the board have Hive-limits, only 2 or 6 or 8 Hives on any particular apiary allowed. But now, each apiary would need to accommodate for the maximum number of hives in each Hive State zone, just in case all the hives were in the same state at the same time. Not an efficient use of game-board space
-Worst of all: Hive States don't move with the Hive. By removing the base piece, we made it so that Hive States are connected to the location rather than the Hive Stack itself. This meant when you moved your hives to a different location, you would need to be careful to put it in the right location inside the location to which you were moving it. Players were forgetting the Hive State during movement, and the information can't be recovered once it's moved and forgotten.
This is when I became obsessed with it. I just wrote it all out and started drawing pictures, starting playing with pieces, moving the pieces around, testing testing testing. And then I got a wild idea that I was positive was not going to work, but I think it totally did (the jury is out until more play testing).
This is what I did:
I created a hexagonal base that uses the same "bee" symbol we use elsewhere in the game - it's a symbol that already means "bees present" in different contexts, so here it means the same, intuitively. Therefore, a Hive that has a hexagonal base under it now signifies that it has a bee colony living in it (and a Hive without a base is empty).
The hexagon perfectly accommodates a rectangular piece, such as the Hive, in 3 different orientations (at 60-degree intervals) which means that the Hexagon allows either 6 states, or 3 states in two directions. In this way, the Hive State can be read from both sides of the game board.
The hexagon perfectly accommodates a rectangular piece, such as the Hive, in 3 different orientations (at 60-degree intervals) which means that the Hexagon allows either 6 states, or 3 states in two directions. In this way, the Hive State can be read from both sides of the game board.
The base also carries the Hive within it perfectly, meaning that when in any orientation, the Hive is rotationally "locked", and can't accidentally shift states when being moved around. When you go to change Hive States, the transition is fairly effortless, and has a nice tactile feel which adds some "umph" to the growing-or-weakening action of hives.
The Base is wider and shaped differently that the other pieces in the game, making the information on it easier to spot on a busy game board. It also picks up in-hand very easily, and won't slide off in transport the way it did on the old base.
When you have a collection of hives in one apiary, you can now group your hives in clean little honecomb groups to organize them away from other players' hives in the same location, as seen below.
Finally, and perhaps obviously, it's hexagonal! Which is thematic to bees! Fletch, the game-maker and Trav, have both been verrrrrry resistant to using any kind of hexagon in the game, in spite of the honeycomb relationship, almost entirely because hexagons are played out in tabletop gaming. I understand, they're right. But DAMN, this piece has to be hexagonal by design first, and theme as an afterthought.
So there you have it, our current design solution to a problem that had been nagging us for months. Much more exciting if you had been bothered by it the whole time, but hopefully you see and draw from the intrinsic joy that can come from solving design challenges, and we can put similar energy into making games in the future, even if I don't get to use the glowforge to solve those problems.