Words: 2256 Approximate Reading Time: 15-20 minutes
As someone who loves puzzle games, I not only play a number of those games, but like to watch other people play them. Which means that you get to see how others’ brains work. What one person struggles with or finds simple is not reflective of what others find tough or easy. And how people process the information in puzzles gives some insight into what you might be missing.
But in watching others, talking to others, or reading about puzzles, there is a common phrase that comes up. It isn’t unique to puzzle games, but it is where you are most likely to hear this phrase – or some variant of it – uttered:
“Is that what I was supposed to do?”
The question invokes the idea of “intended play.” Whenever something is designed for a player to solve, the question becomes about trying to figure out what the designer meant for the player to do. There are a wide varieties of ways to talk about this concept. Sometimes it might be finding unintended solutions. Sometimes it might be someone saying they “cheesed” the solution. Sometimes it might be a player asking what the “intended solution” is meant to be. Sometimes it might be a player arguing that there isn’t an intended solution.
This essay was spurred on by an article about this very topic relating to Tears of the Kingdom. Specifically the argument that there are no intended solutions in that game – and that this lack of intended solutions was a revolutionary form of game design. The article highlights a particular puzzle and the myriad ways in which it can be solved – as evidenced both by the author’s solution and the various other solutions offered by others on Twitter. This wide range of possibilities implies that there is in fact no intended solution. Instead, all that needs to be done is make sure some kind of solution is possible, and then just let the player figure out whatever they want from there.
But the article (and many of the other articles and videos discussing TotK and “cheating” to get around problems) makes multiple mistakes at once. Mistakes which are common in these discussions of “intended solutions.” So it is useful to look at puzzle design through the lens of intent and what “intended solutions” really mean.
Design and “Intent”
Let’s start with just the absolute basics: what constitutes an “intended solution?”
An initial definition we might provide is “a solution that is possible given what is available to the player.” That might include items, information, the structure of a room, and so on.
But even this initial attempt would be a bit too broad. Because in certain games – such as Tears – players can bring in items that they’ve collected throughout the game. Sometimes these items will be possessed by other players, sometimes not. These are the kinds of things that you may be unable to anticipate as a designer, and so do not build around.
So a better definition would be “a solution that is possible given what is immediately available to the player.”
I stress the idea of “immediacy,” because a core component of good design is that if you want a player to solve a problem, you give them the tools to do so. Especially so in a puzzle game – you want to make sure that some kind of solution is possible regardless of what the player walks in with. In fact, you ideally want them to be able to solve these kinds of puzzles with nothing, or only with the elements that you know they would have to possess.
I focus on that part because the article I brought up suggested that all you’d need to do is make sure that the basic victory conditions are possible, and then you’re done. “There’s a hole in the wall, is it possible to fit Link and the chest through it? Yep! We’re good, then.” But you actually have to do more. Because what if the game gave you absolutely nothing? That might mean you need to return later with something to help you solve the puzzle – weapons to make a ramp or a fishing hook, devices to raise Link, and so on. But that’s the kind of design you don’t want – when a player encounters a puzzle in a game, they are generally inclined to tackle it then and there, unless there is a very clear indicator that they shouldn’t. Which means you need to provide something that any player with any equipment could overcome.
So what do you do? You build puzzles around not necessarily using that equipment at all. Or, again, only using whatever equipment the player must have at that stage. That becomes the “intended solution.”
Calling that the “intended solution,” however, merely means it is the solution that the developer specifically built the puzzle around. How other parts of the game interact with those elements may then create other possibilities which may or may not be realized by the designer at the time.
Usually it is much easier to talk about these intended solutions in terms of more constrained puzzles. Something where everything is placed precisely to be utilized by the player to arrive at the goal. Something like Baba Is You or Myst will have intended solutions, because the games give you puzzle elements and information in very specific ways.
But as we start expanding the number of gameplay mechanics available to the player, the “intended solution” loses its meaning. The wide array of possibilities available to the player may lead to solutions that the designer did not specifically anticipate, but which were broadly anticipated.
To draw an example from Tears as provided by the article: there is a small hole in a wall that it is possible to make Link crawl through, as long as you can create a walkway to reach it. You could use the large icicles available to you (i.e. the element that is put there deliberately and thus would be part of the “intended solution”), or you could take your weapons, stick them together, and use those to create the walkway. Either way accomplishes the same task. Is the latter option “unintended”? We could certainly say so, but it wouldn’t really mean anything. If the designer still anticipated you getting Link to crawl through the hole somehow, it doesn’t matter that much how you reach it. The multiple possibilities simply reflect the different ways our brains work and the openness of the mechanics. They don’t really suggest anything about the design of the puzzle, or our ability to grasp that design.
A truly “unintended” solution, then, would be one that is genuinely impossible to anticipate in all aspects. If you discovered that it was possible to access the goal through some glitch or from an entirely different room, then that could certainly be conceived as an unintended solution. But trying to talk about the multiple number of ways we might use the elements of a puzzle that are provided to us to solve in terms of “intended” design doesn’t accomplish anything.
“The” Intended Solution
One problem that we encounter in this discussion is the way that we usually talk about the intent behind design as singular. We are looking for the intended solution, as though there is only one.
But that makes a fundamental mistake in understanding puzzle design, especially when it is capable of being open-ended in some way. Even fairly constrained puzzles can have multiple solutions. Indeed, a lot of those games will have “extra” or “bonus” levels based around puzzles you’ve already completed with a single element removed – because those constraints were always possible before, but might not have been noticed.
There is certainly nothing radical about this idea, and it still relies on pretty conventional rules for puzzle design. You still need to make sure that the components for a solution are possible in the first place. You still need to arrange things in a way to help draw the player’s attention to those components. You still need to make sure that a player knows when they can’t solve a puzzle right now. You still need to remove distractions from the player’s space.
And this can even be what is frustrating about the conversation. Because a puzzle can have multiple intended solutions, players can wind up arguing over which is the “real” intended solution. Because both will arrive at solutions that feel correct (and, of course, are correct), but will have no way to convince the other.
Indeed, this can be a problem in more open-ended gameplay in general. Players can be given multiple options for overcoming an obstacle – a boss fight, a difficult zone, a gap – and fixate on what the “correct” way to do it is. Even if multiple possible strategies work perfectly well, players can still end up sharing their approaches not in the spirit of presenting alternative solutions, but trying to figure out who “got it right.”
Intent vs. Ingenuity
Certainly one part of the conversation that is somewhat baffling is the ways in which players will often align the “intended solution” with the “correct solution.” That is, it is not enough to merely overcome an obstacle. You ought to do it in the way that the designer intended.
This all goes back to problems about “correct” play. There are multiple debates that exist in all sorts of venues about what the “right” way to play a game is. Sometimes the answer is optimization. Sometimes the answer is authenticity. Sometimes the answer is completion. And sometimes the answer is in playing as the designer “meant” for the game to be played (whatever that means).
And so when faced with a puzzle, the intended solution is the “correct” way to solve it. And while technically unintended solutions will get you to the goal, they are the “wrong” solutions.
But this framing misunderstands…just about everything.
Firstly, it misunderstands the “intent” of game design at a core level. The purpose of a game is ultimately for the player to have fun in some capacity. If the player is not enjoying themselves, then something has gone wrong, and it’s almost certainly an issue of the design. In this sense, it doesn’t matter in the slightest how a player solves a puzzle. What matters is that they had fun doing it. If they used the intended solution, an unintended solution, or just broke the game apart entirely, as long as the player enjoyed themself, that’s what matters.
Secondly, it misunderstands the purpose of puzzles. The goal of any puzzle is to get a player to think analytically and have fun doing so (see the above point). It is not about creating some kind of mental fusion between the creator and the player. Sometimes a puzzle can be perfectly constrained in such a way that there really is a single intended solution and you need to effectively backwards-engineer the design. But even then understanding the puzzle in the way the designer does is merely a product of the design. It isn’t the goal. Exactly how a player reaches the goal is irrelevant, as long as the puzzle was not so blindingly obvious as to be dull, nor was it so complicated as to be frustrating.
Intended solutions should be treated effectively as curiosities or trivia, for the most part. There are good reasons to investigate these intended solutions if you are interested in design, or learning how to make puzzles, or finding different approaches to a problem. But if you just want to play the game, the intended solution is irrelevant. Did you solve the problem? Did you have fun? Then you’ve played the correct way. There’s no other discussion to be had on the matter.
Concluding Remarks
I originally got interested in the intention behind design as a product of my interest in learning about how game design works. How do developers actually approach these problems and try to solve them? The kinds of problems that players don’t normally think about, because they’re busy playing the game.
But the more I tried to delve into intent, the more I found it not really mattering. Who cares what a developer intends, if the product they intended just isn’t fun? Why does it matter if a designer meant for you to approach a problem in one way, if other approaches just work better? Intent is valuable for investigation, but not really for comparison. We can use that intent to figure out how things might have gone right or wrong, but not whether someone is playing correctly or incorrectly.
So much of the language that we use around intent – the way in which we might loudly announce our certainty that our solution isn’t or probably isn’t intended, or that we cheesed a puzzle – winds up reinforcing this idea of “correct play.” I have a strong feeling that for most – or nearly all – developers, they could not care less whether a player was approaching a game in a very specific way. They would want to know if someone is enjoying the game. After all, one thing about games, art, life, and so on is the way in which we can all appreciate different facets and come away with different experiences. And that fact may sometimes lead to frustration, but it also makes things interesting.
So why bother with the intended solution? We should be sharing these solutions to show how clever we are, not to talk about whether and how much we might have surprised the designers.
Abstracting Games 