by Michael Perce on 03/26/18 10:24:00 am

The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

An integral part of designing a game is following user-centric principles and iterating in order to provide the player with the best possible experience. However, some games have difficult components that are expensive in both money and time in order to iterate upon. This was the case with the game that I am the lead developer on that will be on Kickstarter later this year. Tiny Trees is a competitive Tree-building board game where unlike a large number of board games, it doesn't lie flat on your table, but instead becomes a physical object in three dimensions. As you grow your tree, you have to try to earn the maximum number of points while also literally balancing your tree so it doesn't collapse.

The game consists of 42 hexagonal cards that you slot together in order to grow a physical three dimensional tree. It was extremely time consuming to iterate on these components since the prototype needed high quality cardstock and had to be cut out by hand and individually drawn on. As such, the design process had to be predicated more on math and statistics rather than continuous playtesting in order to not waste valuable resources.

We had to determine what arrangement of cuts in the cards we wanted. The very first prototype had cuts on all six sides of the hexagonal cards, but I found myself growing roughly the same tree every time since there was no restrictions on what I could grow. Additionally, if each side of the hexagon had only one slit to reduce complexity, each side would have only two states: cut and not cut, represented below with a six digit binary equivalent.

When** **that six digit binary equivalent is converted to our standard ten digit unit of numbers, that gives a total of 63 possible arrangements of cuts on the hexagonal cards. However, this does not account for rotations or mirrored images. For instance, the leftmost hexagon shown above is still functionally identical when rotated 60 degrees. As such, when accounting for this repetition, there are in fact only 12 unique designs.

Although** **this number of unique designs seems innocuous, it was significant in my process since it established what could or could not be done with the cards. While we could create cuts that weren’t centered on each side of the hexagon or multiple cuts on one side, having knowledge of what options were available to us allowed for accurate design.

On a similar note, designer Mark Rosewater has repeatedly said that “restrictions breed creativity”, and I found that to be exceptionally true (Source). In the case of Tiny Trees, the very first paper prototype had cuts on all six sides. However, this did not lead to building any interesting trees since players would default to what they were familiar with rather than going out on a limb and trying a new structure. At the opposite end of the spectrum, if all of the cards had only two cuts, the players wouldn’t have enough choice in what they could grow. Having all of the cards with only two cuts didn’t provide enough options to the player, and six cuts provided too many, so the ideal must be somewhere in between. In the final version, there are five cards with two cuts, four cards with four cuts, and two cards with six cuts for each of three types of trees. We decided on this arrangement for three reasons: It gives an average of roughly 3.29 cuts per card, each number of cuts had a total roughly equal to 12 - the exception being the cards with two cuts - and the distribution of the values was appealing since each level has one fewer card. Additionally, by having more cards with only two cuts, it allowed the trees to become more interesting while the higher number of cuts allowed players to still have sufficient options in growing and balancing their tree.

While** **this math for achieving the average number of cuts per card (in which you add the total and then divide by the number of cards) is very simple, it still influenced our design decisions. Since we were aware of the average number of cards as well as the specific distribution, it gave us a much clearer understanding of the system that was in place and how that affected the player’s perception of the game. This in turn allowed us to quickly fix and understand any underlying issues that arose in playtesting. For instance, we were able to identify that even though playtesters didn’t directly address an issue with the distribution of number of cuts, we were able to more accurately identify it as the underlying issue due to the knowledge of the distribution.

At the end of a game of Tiny Trees, players earn points based primarily on two factors: the hexagonal cards that they grew onto their tree, and lifeforms that are also found on the cards. We added the lifeforms to increase the strategic depth of the game, as well as make the decisions more interesting.

**T**he three types of lifeforms: Beetles, Mushrooms, and Birds

From the** **player’s perspective, without an additional incentive, there was little reason in selecting the cards with fewer cuts since it restricted their growth and made balancing their tree more difficult. By adding lifeforms as a mechanic, we had to balance three main factors: the number of lifeforms, the distribution of lifeforms, and the amount of points that the lifeforms were worth. In order to achieve this through math due to the limitations of our ability to iterate, we used a hypergeometric calculator liberally in determining these factors. Hypergeometric calculators are often used in card games where you draw some number of cards and then want to know the odds for drawing a certain card. In this context, we wanted to know and be able to control the odds more precisely rather than just intuition. An important design decision that we had made previous to adding lifeforms was that each option available to the player should be of equal value to a similar decision. This comes from the number of cards for each type of tree being completely equal, even to the distribution of number of cuts. Thus, we wanted to do the same for lifeforms, but be willing to alter that methodology given the numbers and math behind them. As such, we needed three types of lifeforms and more than one of each. We ended up settling on six of each type of life form, separated evenly between each type of tree. The advantage to this is that if a player wants to grow their tree with all of the birds available to them, then they aren’t shoehorned into one specific type of tree.** **

When it comes to the math, that means that roughly 43% of all of the cards have lifeforms, and that there is a 45% chance that exactly one of the top three cards that the players can choose from will have a lifeform, and a 25% chance that none will have a lifeform. Obviously that percentage changes as more cards are selected, but this knowledge helped us quickly refine the game - similar to the knowledge of the distribution of cuts. When it comes to what cards have the lifeforms, we focused on the cards with fewer cuts on them. Our reasoning was that if lifeforms are worth additional points, then the players should be incentivised for restricting their growth options, but not so much that it is obviously better than the ability for options and balancing your tree.

Then came the question of how many points should each lifeform be worth. Since the cards reward you for collecting more of the same type, so should the lifeforms. However, the scaling of points can be either linear or exponential. We decided on an exponential growth model, so that players are incentivized to collect the same type, but that collecting them incidentally doesn’t have that large of an impact on the overall point total. Specifically, the first two are worth one point each, the next two are worth two points each, and then the final two are worth three points each.

By designing our game while taking the numbers into consideration rather than just working off of intuition, we didn’t have to playtest or iterate on our designs as much as we would have to if we only gathered data from reactions from playtesting. While using this math obviously doesn’t eliminate the importance of playtesting and iteration, we were able to save a lot of time and resources from creating additional paper copies of the hexagonal cards and allowed each playtest to be more efficient since we were able to more accurately identify underlying issues and needed balance changes.

If you're interested in the project and want to keep up to date, you can follow us on Facebook, Instagram, and Twitter!