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 ,

Decisions in Love Letter

The popularity of Love Letter has surprised a lot of the gaming community accustomed to critical praise focusing on lengthy, complicated games. Love Letter contains 16 cards and a simple premise: draw a card, play a card.

But if you give the game a few plays it’ll reveal some interesting play patterns. It is dynamic, packed with an endless number of game states, and the play interactions are fun to observe and engage in. I would argue that enjoyment comes from looking at how the cards are situated against each other and the unstable nature of a player’s position within the game. Because each turn involves playing one card or another card, play possibilities can be mapped onto a decision matrix (see table).


See full-size table

This doesn’t reveal much by browsing every individual play possibility. But some broader play themes can be seen in the ways the resulting card play helps or hinders a player, in addition to other benefits they receive from playing a card. In no particular order below are some themes I’ve discovered by playing the game and looking over the matrix.

Is card play always dictated by rank comparison? Mostly.

As indicated by the table, playing the lowest ranked card in hand will advance a player’s position. This isn’t surprising because it correlates to the win condition (highest ranked card wins). In a way, then, that choice (“what card do I play?”) is actually involuntary because players want to hold their highest ranked card.

So should a player ever play their highest ranked card? The table can’t answer that, but probably not. There are instances where playing the highest ranked card will knockout another player from the round. But like a million other brawl games (Bang! comes to mind), Love Letter is zero-sum so sacrificing your best card to attack one opponent thereby helps your other opponents.

However, when a player with a low ranked card draws another low ranked card (Baron and under, say) they can probably play either because the chance of an opponent holding a higher rank is so high. As I’ll get to in the third theme, players with low ranked cards can have the most power.

Players holding high rank cards are at high risk for detrimental interactions.

The interaction between high cards is inherently risky, so holding onto a high card can be dangerous. Additionally, players are encumbered by the high ranked cards they’re holding. The penultimate example is the Princess, which is essentially a dead card because it forces every subsequent draw to be a mandatory play. The Countess also has mandatory play effects, so mixing them with any other higher cards can create compromising situations.

Players holding high rank cards are also highly vulnerable to outside attack. The Princess is vulnerable to knockout attacks from roughly 2/3 the card pool: Guard, Prince and King. She’s additionally vulnerable to a follow knockout from a Priest play, and is dead against forced discard from opposing Handmaids. Of course the Princess can also offer up the best positions: Princess /Handmaiden is the safest combination in the game, and Princess/Baron is an easy knockout.

Players with the lowest ranked cards are often the most empowered.

Love Letter does a great job at giving every player, no matter their current position, opportunities to engage in risk and power plays. Players with the lowest cards are often the freest to employ aggressive strategies. Because both cards are low ranking they are open for use, the opposite of the above problem where one card was always your win condition because of its rank. So players with Priest / Guard or Guard / Baron can freely employ multiple-turn strategies because neither card is worth saving. And while weak to the Baron, low rank hands can actually benefit from trading or discarding attacks from other players.

The passive cards promote interaction between the other cards.

The Handmaid and Countess aren’t active cards. In this way, they’re somewhat anti-fun or anti-play because they inhibit player interaction. However, they foment important play dynamics amongst the other cards. The Countess is important because she creates an unstable footing for players holding onto a high rank card. This promotes a livelier game state instead of letting players hold high cards and coast to victory. The Handmaid’s role isn’t quite that pivotal and because of that she’s my least favorite card, although she does have important one-on-one effects (forcing Princess discard).

The human factor in Love Letter is around targeting and guessing.

The first theme I mentioned declared that choosing a card to play is a false choice and not really what the game is about. The game is really about the fallout after the card is played: Is the Guard choice correct? Who should be targeted with the Baron? These are the decisions that are interesting, and become more involved as the game grows because each player’s discard pile reveals more information.