Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It's Always A Design Problem #57

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
108 changes: 108 additions & 0 deletions content/post/always-as-a-design-problem.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,108 @@
+++
title = "It's always a design problem"
description = "Why you can't blame the player for making your game unfun"
tags = [
"game-design",
"fonts-of-power"
]
date = 2021-03-30 #TODO: Update date
author = "Alice I. Cecile & Rose Peck"
draft = true
+++

As a designer, watching players actually experience your game (or application!) for the first time can be an excruciating experience.
They'll miss the "obvious" approach to a task, use bizarre workarounds, skip all of your attempts to teach them and then complain that nothing works!

Faced with this, it's tempting to blame the foolish players for failing to grasp your vision: calling them lazy or dense and exclaiming that no, it's the kids who are wrong!

But, not only is this morally questionable, it's a useless dead-end.
Think like this and you'll often miss both important design flaws and clues from players about how to fix them.
Try as you might, you will not be able to build a better gamer.
You can curate your audience to some degree, but, by-and-large you're stuck with them.

Instead, understand that it's **always a design problem**.
Once you accept this bitter truth, you can start to make games that players understand naturally.
At its heart: make it so **the easy thing to do is the right one**.

## The Consumables Problem

Let's make this a little more concrete by talking about a common case and how we solved it in our RPG, *Fonts of Power*.
**Consumables** are a staple of the RPG genre, and see widespread use outside of that.
In almost every game that they're used however, you see the same pattern play out again and again:
Most players (especially casual players) will horde consumables until the end of time, never using them even when faced with a serious challenge.
At best, you may see them used all at once, completely trivializing a plot-critical climatic boss battle as they guzzle potions and drown the charismatic but creepy vampire in holy water.

As mentioned, it's tempting (and often quite common!) to blame this pattern on the players.
To say that they are too risk-averse, too stingy, or too afraid of a fair fight.
However this misses the core problem that your players are responding to.
Most consumable systems **fail to communicate their design** to the players.
Players are left wondering:

- What challenges they'll face, and how hard this particular challenge is
- How much a given consumable will affect the outcome of a fight
- When they'll be able to get more consumables
- How many consumables they can sustainably use each fight
- Whether this is the best time to use a particular consumable

Players don't have interesting or meaningful choices, and so they become overly conservative or act randomly.

It's not the player's fault that the game didn't balance and communicate what the trade-offs are for using a consumable.
As we said, it's always a design problem.
sixfold-origami marked this conversation as resolved.
Show resolved Hide resolved

In this case, the core problem is the game's inability to facilitate rational planning.
And if we'd stopped at "those damn players, not using their potions like they're supposed to", we never would have found it.
Now that we've recognized the true design problem at the heart of consumables, we can actually solve the underlying issue.

## Solving Consumables

sixfold-origami marked this conversation as resolved.
Show resolved Hide resolved
Realizing that there's a design problem at play, it can be tempting to toss on a band-aid solution: disincentivizing the pathological behavior directly.
You see this play out in tabletop RPGs, where the Game Master (GM) plays a dual-role as a game designer.
Out-of-character, the GM begs, exhorts and bribes to get players to drink their damn healing potions when they're at 2hp, promising that they'll discover more soon.
Or worse, they implement a last-second nerf to the players cunning hording strategies under the guise of "realism": explaining how the seven potions they just drank reacted in the wizard's stomach, causing them to take 6d6 poison damage and salvaging the tension of the epic boss battle.

Obviously, last-minute band-aid solutions are suboptimal and often rob the player of meaningful choice in a similar way to the original problem: the players still don't have sufficient information or agency to reason and strategize around the consumable system.

So, what's required to do this right?
There are several successful methods that we've seen, and all of them answer the core problem by providing the following things:

1. Consumables are more effective when used regularly (over long time scales), rather than used all at once.
2. There's clear ways to get more consumables, and transparent pacing for how frequently that should occur.
3. 1 and 2 combine to give the players have a sense of how frequently they should be used.
4. The system makes clear how effective a consumable will be in a given situation.
5. The system clearly communicates relative scale of threats and challenges.

### Slay the Spire: Potion Belts and Enemy Telegraphing

TODO: add.

### Darkest Dungeon: Inventory Limits, Purchasing, and Predictable Dungeons

TODO: add.

### Fonts of Power: Essence Overload and Generous Crafting

TODO: add.

### Speedrunning: Optimizing Consumable Routing with Perfect Information

TODO: add.

## General Strategies

TODO: add

- understanding motivations and patterns of users
- incentives and optimal behavior
- friction and discoverability

## Conclusion

TODO: flesh out

Much more productive to view as problem that can be solved.
Not only one solution: "it's always a design problem" is about accurately defining the problem to solve
it also puts the problem into a space that you, the designer, have control over
Don't take this as gospel: sometimes players *are* just being dumb. Look at numbers, try to attract an audience with opinionated design and marketing that communicates your vision.

Thanks!
mild call to action: [GMTK](https://www.youtube.com/watch?v=7L8vAGGitr8), and let us know if you see other things like the consumable problem