Dice Design 1 - Atomization
Amberspire Design Diary #9
After getting other systems like terrain and population up and running, the core dice rolling design gets a very thorough investigation. This is the first in a short series of design diaries explaining how I designed the very basics of dice rolling in the game. See the other design diaries, wishlist the game, or subscribe to our newsletter.
Up until now in these design diaries I have only loosely described how the resources and dice work, but not in full detail. That's because, simply put, up until this moment (in the design process, not when you're reading this) it wasn't particularly good, and this only became clearer once the game had other things going on.
I had initially designed the dice system to function with a simple tradeoff to provide friction for the player: you can roll as many dice as you want, but any resources you don't use add to a Fatigue value, which incurred some penalty and involved some other process to reduce. Buildings required a specific recipe of resources to construct them. This loop is what the core of Amberspire was at a fundamental level.
As a sidebar, the vagueness of 'Fatigue' in the paragraph above is not me editing this diary down to stay focused on the dice and resources, this is how I think about system design. In somewhat algebraic way, you can declare a system like an undefined variable to figure out later. Obviously the clearer your ideas are the better, but sometimes you have to focus on one thing and keep the rest as a loose sketch. I typically sketch by defining inputs and outputs, so this system adds Fatigue and then at some point Fatigue is removed. A system has to be strong enough to justify establishing a Fatigue system, which can ideally tie in to other systems as well. All this is done purely on paper.
Pretty quickly this system just felt bad. The goals were achieved, in that it provided an incentive for players not to roll every die they could because the Fatigue penalty would be high. But even in 'reasonable' play, trying to hedge which die would be used was not interesting. It just felt too penalizing. More often than not I would assemble a handful of dice, roll them, use what resources I could to build new buildings with, and proceed without much excitement. Sometimes I got the resources I needed and sometimes I didn’t, but neither way did the game feel like it was engaging me and drawing me into making meaningful decisions.
Atomization
So I began a process that I’ve done somewhat automatically for every game I've designed, but did very deliberately for The Banished Vault and will do very intently in the future. This process I call design atomization, and is essentially ripping apart every portion of the design at the every seam, following it through from start to end, and hopefully looking for the source of a very vague issue.
The rough procedure I use for the atomization process is to examine every element of the game, write out how it works, and alternatives to how it could work. This kind of abstract ‘wiggling’ is helpful to explore alternatives to the current design elements, but also discover what things I want to keep fixed in place and what is open for change. For example, I feel pretty strongly that each building can only roll one die at a time, not several, and that I want each face of the dice to have only one resource on it, not several. These two elements could be different, but they were constraints that I had other reasons for and wanted to keep in place. Another new constraint, emerging from the initial design that felt bad, is that not using a rolled die incurs no penalty.
A specific example, considering the dice and resources: at a basic level, buildings would roll dice to produce resources, and the player would then use to construct more buildings. Sometimes it would feel like when rolling a die and not getting the resource you want, the game simply shrugged and said “well, roll again”. This outcome is to some degree inevitable, but it should be very rare. My goal was a very fine balance between the game providing a few options for how to use a resource or occasionally none at all; also a gentle encouragement to not roll the maximum amount each turn.
A question on my atomization process that highlights my process and how tricky it is to find a solution: generally how many different resources should be on a die?
The first step is exploring a low amount, down to 2 or 3 resources per die. But this just felt wrong in that intangible way – if every building produces only 2 or 3 things, why even roll dice? The point of dice is to have lots of variety and drama in the result, not just flipping a coin. So, following the atomization process, I consider the alternative: how would it feel if every dice had lots of variety, 5 or 6 results? More dramatic and unpredictable, sure, but the problem of ‘not getting a usable result’ is now worsened. If a 50% chance to get what you want feels bad, 16% is pretty miserable.
Perhaps the issue was in the number of destinations for resources, or stuff the player can do with a result of a roll. A frequent issue with designing strategy games is they don’t fully click together until the player has enough plates to spin, so it’s hard to judge if a design is right when the player can easily spin one plate without distractions.
I did have other systems that I wanted players to commit resources to, like gaining influence, or upgrading buildings, and managing the algorithmic terrain. These are interesting, but I did not want to rely on them to patch over a fundamentally weak design at the center. The key here is that no matter how many different systems the game might present to the player, ultimately there’s nothing to stop them focusing on just constructing buildings. Put the other way around, the game should be inherently interesting even if the player is focused on constructing exactly one building at a time. I believe this is also a good heuristic for the perceived difficulty of the game, if the player can comfortably ignore everything else and focus on understanding (and being engaged by) the core system, the game will feel easier.
As a treat for reading this far, here is very early screenshot of the game, at about the time I was doing this process.
Exploring Other Games
So this atomization process continued. I compared and contrasted what I had with a city builder and a dice game, and experimented with bending this design to resemble those two games more to see what ideas might shake out.
The first model we’ll compare to the Anno games. I thought of a new model where once the player rolls dice the resources rolled are added to a global storage system of some kind. At any point the player could construct buildings if they had the required resources in storage and proceed forward. This made rolling dice at least feel like it was always moving something forward for the player, and not just leaving them with a null result with no value. At the logical conclusion of this path, however, was simply Anno again but with the dice fully removed. Even with infusing some kind of risk or push-your-luck element, the player is still just rolling until they get what they need without much nuance or specific goal.
The next game I thought about was Citizen Sleeper, a game that uses dice to great effect. I kept Citizen Sleeper in mind throughout this entire process, because I felt like it captured the feeling I wanted – immediately after the dice roll the player's mind is alive with the possibilities of what you can do with that roll. Whether the roll is great, or terrible, or a mix, you are engaged and thinking about what to do next. In comparison to my system where after rolling dice you rather automatically assigned the dice to where they should go and moved on.
To recast the design to the Citizen Sleeper system, I thought about the dice pool forgoing resources completely and just rolling numerical values. Buildings would then have operations they could perform, to a quality determined by the value on the die. On an immediate level this felt more interesting than what I had. Like Citizen Sleeper, the range of possibilities was great, and the player has a big set of options to proceed with.
Where it this falls apart however is in the details - for the player it’s hard to easily answer ‘how do I construct a building with two 3s and one 5’ as opposed to with ‘1 metal and 1 crystal’. Also I was quite attached to the resources, they greatly add to the overall theme and aesthetic of the game and I did not want to lose them. But at least as a design exercise, it was curious how much more engaging the game felt when I looked at it through this lens.
Next Time
Eventually I did find an answer to these issues and am very happy with where the dice system is now, but this diary is already quite long! Next time I go very deep on formal questions like player constraints, goals, and mathematical progress in a system. This very clearly describes the problem and a solution, and will eventually lead to another solution to the dice penalty issue further beyond.