Game Data Analysis: Splendor

Splendor has become a very popular game recently, likely due to its Spiel des Jahres nomination. Splendor is a card game about using limited resources to build an efficient engine. There are five colored gems, and playing only a few times it might feel like the costs and distribution of the colors are the same. In other words, the colors are different currencies with no other differentiating qualities. If that were true, we’d be able to add up all the costs and find that the colors are evenly distributed. But even with a few plays of Splendor that assumption is difficult to maintain. The rules are simple and there are no exception-based cards, so it’s a great game to analyze by number crunching. I’ve set out some research questions to help guide the analysis. Some of them are basic, but I think they’ll open up other directions for exploring the data.

Research Questions

RQ1: are color bonuses evenly distributed?

RQ2: are color costs evenly distributed?

RQ3: what is the average point:cost ratio for a level one, two, and three card?

RQ4: what is the percentage of “on color” cards? (Cards that give a bonus for a color that is also in the cost).



Figure 1. Card Description.

It’s always useful to communication the analysis process, but if you’re interested strictly in results then scroll down to the Results section. The process first involved developing a taxonomy to store the attributes, entering and cleaning the data, then validating the data. Some of this may seem excessive for a small project like this, but there are always unexpected events that a formal procedure can mitigate.

To operate on the card data I input it into Excel. The data entered would consist of the cards and all their attributes, including the bonus, level and cost (see Figure 1). Noble cards would also be input. There was some taxonomic thinking that went into the process: how should I manage the terms used? For example, instead of writing out the word “black,” it’s easier to input “b,” but there’s also “blue” then term management needs to standardize that “blue” becomes “u” instead.

Data validity was also an issue because I was manually uploading the information; I didn’t perform a second check nor have others do it, so I had no reference to determine whether the uploaded data was correct. I did do a card count to ensure I had input the correct number of cards, but nothing beyond that. An auto-incrementing CardID attribute was created to ensure I could individually track each card.

Analysis and data visualization was performed in R Studio.



RQ1: are color bonuses evenly distributed?

Yes. See Table 1.

RQ2: are color costs evenly distributed?

No. If you sum all the card’s costs, the colors are relatively equal. But when slicing those costs by level, the distribution becomes uneven.

Table 2 charts the frequency of color cost. That means it counts occurrences of color cost. So the Black row under Level One indicates that White and Blue occur as a cost in four level one black cards. Note that this table does not track intensity of those costs (that’s for later).


In terms of frequency, on-color costs are infrequent (few cards with a color bonus also have that same colored cost). There are some other odd frequency dynamics: level two blue cards feature a blue cost five times, with other colors appearing two times. So each color has a unique frequency of cost, as seen in the figures below.


Figure 2. White costs by card color.


Figure 3. Red costs by card color.

These figures displays the distributions of White and Red costs among the cards. Because the two figures are different, we can conclude that certain card colors require varying degrees of red and white costs. Because the figures are box plots we can also discern the expected white or red cost depending on the card color. A white card will have a higher red cost on average when compared to a green, red, or blue card.

While each color has a unique frequency of cost, those patterns do not occur from level to level. In other words, investing in white bonuses to buy red cards at level one will not be a reasonable strategy at level two or three because the white cost frequency changes.

Table 3 charts the intensity of color cost, which is where the uneven distribution really comes into perspective. The level three cards are representative of this trend. Like a lot of other games, the expensive cards reward a vertical strategy of investing a lot in a few colors. For example, the sum total of white costs in level three blue cards is 23, with all other colors totaling less than 8. As a proportion of the total costs of all level three blue cards, that’s 70%. So there are clear color affinities, but they change at each level, so white costs won’t always be strongly tied to blue bonuses.


RQ3: what is the average point:cost ratio for a level one, two, and three card?

For cards with point values, the average cost of a point goes down as the card level increases. At level three, the average cost a point is 2.7, level two is 3.7, and level one it is 4 (every level one card with a point costs 4). This isn’t too surprising; a lot of games reward big investments by making them more efficient. The trade off, of course, is that they require long-term planning to efficiently buy them, while low-level cards require little.


Figure 4. Card Points and Card Costs.

After a few plays of Splendor you’ll probably notice that some cards cost more for the same point value. Indeed, Figure 4 shows that some cards are just strictly more efficient. However, the cards that cost the most (14)  spread the cost among 3-4 colors, while the highest value cards (5 points) are concentrated on high costs of one or two colors. So the design of the costs provides two clear paths to efficient point gain.

Table4RQ4: what is the percentage of “on color” cards (Cards that give a bonus for a color also in the cost)?

My playgroup assumed these cards are high value because players have a tendency to collect things they already own. They occur infrequently in level one, but in card levels two and three they’re at least 50% of all cards.


One important aspect of this analysis is that it’s dealing with static information. This data tells us about the set information of the game, but it doesn’t describe any behaviors. We can infer some behaviors based on the incentives provided by the set rules of the cards, but we should be conservative in those conclusions.

That said, the frequency and intensity of the color costs does validate the potential for a vertical, one or two color strategy. But it seems like those strategies require careful planning, as by level 3 each color is essentially “locked” into buying up one particular color. So if that color is available to buy, well, you might have some problems. At the same time, it may be a viable strategy if every other player is competing for a wider strategy with nobles.

That said, I remain skeptical of a strategy concerned with concentrating on level three high value cards, and remain convinced that Splendor is very much a game of opportunistic, incremental victories that rewards turn-by-turn efficiency rather than grand strategies. Consider for example that the average point value of a level three card is four. To win, you would need to purchase three plus something else or four. That’s a tall order, especially considering the bonus return is the same as a level one or two card. Instead, it seems much more likely that–like all other parts of the game–level three cards are purchases of opportunity. If a player is able to efficiently purchase a level three card, it is because they just happen to have the correct bonuses and gems at hand, rather than a “from turn one” plan. That said, without behavioral data to acknowledge that, I can only speculate.

Tagged ,

Menus in Games: Rollercoaster Tycoon 3

Rollercoaster Tycoon 3 is a classic simulation game known for its surprisingly deep take on a light subject. It’s also fairly complex, but that complexity can be exaggerated if the interface doesn’t work to ease that complexity. In this article, I want to dive into a specific instance of complexity as represented by a user interface. I’m going to take a specific menu in RCT3 and do some modest wire-framing in an attempt to improve it based on my needs. I’m not going to take any specific approach other than being reflective and user-centered. Hopefully, we’ll explore the ways in which an overly complicated interface can impede playability because of its arrangement and the way it represents the game’s mechanisms.


The panel seen above is part of a food stall menu. This single panel allows players to examine the products (donuts), their differentiation (small, etc.), garnishes (the tiny icons shown as the middle columns) that can be added to the donuts, and the price at the right. The other panels, seen as circular buttons on the right, display a variety of other food stall-related options.

First off, it’s somewhat mind-boggling that a game would allow players to micro-manage so deeply. Do I want to add ice in my lemonade? How much ice? How much should I adjust the price based on that ice addition? How will that alter people’s enjoyment of my product? I’ve always been impressed by RCT3’s depth. These are great questions to ask players in a simulation game. These questions, and the decision paths they inspire, add a richness to the game and lets players feel like they fully control their environment. Of course, it’s likely that the game dumps price and garnish into an algorithm and makes no distinction about what kind of garnish and that there is inherently a superior garnish-to-price level. But the player doesn’t know that.

But to return to the menu: in some ways it’s a spreadsheet. Donuts and their prices in the rows, garnishes in columns. This is perfectly logical, but it doesn’t necessarily adhere to how a player wants to play the game. Those tiny little up/down buttons next to the price? They’re in intervals of five cents. Five cents! If I wanted to increase the price of a small bag of donuts to $1.30, I’d have to click four times. If I wanted to increase each product that much, I’d have to click 16 times!

To pull back from the details for a moment, we should ask what the panel is supposed to accomplish. Display the array of options available to players for customizing their donuts? From a game design perspective, that’s not the real point. The real point of the panel is to give players an exhilarating sense of control over the tiniest details of their donut shop in order for them to feel like they’re really running this theme park. So the goal of this panel is to contribute to the simulation atmosphere by giving players more decisions that have consequences about revenue, customer satisfaction, etc.

When we think about the menu in that perspective, I think it could use some improvement. Being a long-time player of RCT3, this particular menu has always felt burdensome and detracted from the smooth simulated experience because it took me forever to fiddle around with the controls. Because of that, the game loses some of its micromanagement energy because the UI can’t really match the complexity in a way that is simple and fun for players.

I’ve listed those grievances out below in order to address each one separately:

Issue Interpretation Problem Category
“Changing the product price takes forever.” No UI options for large increment changes. Interface
“Adjusting all the products takes forever.” Lack of “change all” options means every product must be altered separately. Interface
“I don’t understand how the garnishes or price affect customer satisfaction or behavior.” No feedback on customer reaction. No metrics on customer satisfaction, behavior changes. Feedback representation
“Why would I want to change products individually?” The game gives no feedback on how individualizing product choices impacts customer satisfaction or behavior. Feedback representation

Again, these are just personal reflections and I’m sure we could find more. The interpretation column is representative of the designer ingesting the issue and directing it into an actionable critique. After reviewing those issues, I mocked up the wireframe below.

Wireframe 1


In terms of solutions it’s the smallest step in terms of changes: the spreadsheet nature of the menu remains the same and players still need to click quite a few times to get what they want. What the menu addresses, though, are some of the more tedious processes. The “All” row was added to allow players to add every garnish to every product, reducing the potential clicks from four (add one kind of garnish to each product) to one. The pricing buttons were changed to a scroll bar to allow players to adjust prices at larger increments. Additionally, the “All” price bar adjusts each product’s price by a specified increment.

So what did we gain? The chart below speaks to our previous issues. We reduced the number of clicks required to adjust all garnishes and all prices. We also reduced the number of click required when changing prices at greater increments.

Issue Interpretation Wireframe 1
“Changing the product price takes forever.” No UI options for large increment changes. A scroll bar was added to allow players to increment at larger amounts.
“Adjusting all the products takes forever.” Lack of “change all” options means every product must be altered separately. An “All” row was added to allow players to modify all products at the same time.
“I don’t understand how the garnishes or price affect customer satisfaction or behavior.” No feedback on customer reaction. No metrics on customer satisfaction, behavior changes. No solution developed.
“Why would I want to change products individually?” The game gives no feedback on how individualizing product choices impacts customer satisfaction or behavior. No solution developed.

The first wireframe addressed the simple issues. It often requires some investment of time to play around with the UI before player “desire paths” become apparent. The fact that the wireframe fails to address the other two problems is not a failure of the wireframe, but representative of the iterative nature of design. Seizing issues by category (addressing interface first, then feedback issues) often eases the solution-making burden and mitigates the risk of over-complicating the design.

But that still leaves the other two issues. These two feedback issues are, in some ways, outside of the scope of the menu we’re examining. I don’t know how the game responds to these pricing or garnish changes. But I can make some assumptions, so we’re going to move forward with those in order to continue this design exercise.

I’m first going to assume that the pricing and garnish algorithm is relatively simple: the garnishes represent some value change to the donut that makes them less or more satisfying to customers. I don’t think the game evaluates each garnish individually (some amount of sprinkles is the same as some amount of glaze). So really what garnishes represent are some additional cost to increase some amount of customer value.

I also am going to assume that donut size is simply matched to some customer attribute (hungriness, size preference) and that the individual garnish setting doesn’t figure into that decision model. With those two assumptions in mind, we can move forward with a new wireframe.

Wireframe 2


I cheated a little bit. There’s another panel in the donut shop that displays customer comments, so I brought that in to address some of the feedback issue. Shouldn’t it be here if you’re looking at the comments in order to judge how customers like your product? As for the bottom half, the above assumptions really just highlighted the fact that the individual products don’t add much to the game experience, and the player doesn’t know why each product is different anyway. By reducing to a single product, feeling of management is still present, but now each part feels like it has understandable value. With the comments above, the levers and pulleys should have an immediate feeling of feedback. If I were to go a step further, I might say that the individual garnishes don’t add much to the game either and should be condensed into a single “how much stuff” lever or scroll bar.

I don’t think the process ends there. The menu addresses some of the basic issues, but there’s some work to be done. One additional step would be to consider a new feedback method, like a chart or customer display that would be a better way for players to experience the changes they make when adjusting the donut options. Lastly, I want to mention that RCT3 remains a fantastic simulation game and holds up wonderfully well–I think simulation games of that caliber take a tremendous amount of effort and time, and I wish more of them would be developed.

Tagged ,