Words: 1925 Approximate Reading Time: 15-20 minutes
Occasionally when we get into the subject of criticizing games, and in particular the various systems within a game, we get bogged down in a problem. Let’s say, for example, that you wanted to subject a game’s exploration system to critique. The exploration is technically open-ended, but in a way that the game essentially directs you on which paths to explore first. You can technically go where you want, but the game punishes you in certain ways for going the “wrong” way. I give this not as an example of any particular game, but just as a general hypothetical for our purposes.
So upon giving this criticism, someone then responds by explaining what the intent behind the system is. The game designers meant for the exploration to be more directed so that you would see events of the game in a sequential order, so that other parts of the game would make sense. Let’s say that while you can technically go anywhere you want, there is a narrative tied to exploration that could be viewed out of order if you don’t take the intended pathways.
The premise behind this response is that the intent behind a system trumps any problems of execution. Sure, you may have a problem with how the game works, but you shouldn’t, because you’re just not playing the game right, or you’re misunderstanding how the game is supposed to work.
We don’t often encounter the intent argument in quite this straightforward manner, but it’s something we occasionally see and perhaps even fall into ourselves when getting into the subject of criticism. In part, it can feel difficult to disentangle the two because we may sometimes see the efforts of a designer as worthwhile on their own. Someone put in work, and so that work needs to be respected, and the only way to respect it is by only responding to that work on its own terms.
But this logic doesn’t really pan out, because it misunderstands how video games work and what systems are ultimately supposed to accomplish.
So in this essay I want to explore the nature of “intent” and “execution.” In particular, I want to explore what value each part has, and how they each fit into the subject of criticism. These are two separate components of a system’s design, and we need to know what we’re doing when we bring each of them up.
Allow me to lay down a very simple principle for us to keep in mind throughout this essay:
Intent is not a shield for execution.
When we talk about systems, one thing we often gravitate towards is an explanation: why does this system exist? What is its purpose? Why was the game made this way, rather than some other way?
Those questions then lead us to thinking about how a developer was thinking about each particular component of the game, as well as how those components fit together. The answers provide us with a logic that helps us to put systems, their strengths, and their flaws into context. Maybe a system is flawed, but it is flawed because of limitations due to time or technology. Maybe a system is flawed in a way that is meant to encourage players to engage with other systems. Maybe a system is constructed in a different manner than we would normally expect to fit better with some other system.
All of this questioning, and the answers (or potential answers), we receive ultimately matter. But they matter in a particular way. Specifically, they matter for helping us to simply understand why a system is set up the way that it is. This question can be helpful for a variety of purposes, including by telling us why things might go wrong or why things might succeed.
Occasionally, these trains of thought can also lead us to appreciate the system in ways we might not have before. Perhaps seeing how things are supposed to fit might make us change our opinions, because they put the system into a new light. However, while this can be a result of the exercise, it is not a required result of the exercise. Sometimes understanding the intent behind a system doesn’t change our opinion for the better.
What is key, though, is that knowing about the intent behind a system doesn’t actually justify the system’s existence, both on its own or in the particular way it is designed.
To get to why, we need to move to talking about execution.
The reason that intent doesn’t really matter is that video game systems rely upon usage.
Think of it like baking a cake. You may attempt to bake a cake. You grab a variety of ingredients, throw them into a bowl, mix them, pour the results into a pan, and then bake it. And from that you get…a weird mound of inedible sludge. And you call it a cake.
But regardless of your intentions behind your actions, the claims of what you are doing, or what you call the end product, the result is either not a cake at all, or is just a terrible cake.
And at the end of the day, that’s what really matters. Cakes are meant to be eaten. Whether it’s a good or bad cake depends on how it tastes.
And the same principle applies to a system in a video game. Players are supposed to use the system. Whether it’s a good or bad system depends on how it feels to use.
So when we analyze a video game, our goal is to look at the system and figure out whether it’s actually fun to use.
There are three things we want to look at.
Firstly, a system may simply be unfun on its own terms. Whether it’s combat, movement, or something else, simply interacting with the system may be dull or annoying. Players might simply stop playing the game, or might avoid the system as much as possible because of how bad it feels.
Secondly, a system might not be fun on its own, but could be made fun because of how players interact with it. While the system as intended isn’t particularly good, players might find some trick makes the system interesting. This might be a bug in the programming, or an interaction that was not realized during development.
Thirdly, a system might not be fun on its own, but may be designed to be unfun to direct players to some other task. We usually might frame this issue as the system being complicated or ineffective so that players seek some simpler or more effective means to accomplish their goals. For example, fighting might be such a poor way to get through the game that players might seek out some other pathway such as stealth.
All three are ultimately problems of design. A system needs to be fun and interesting to interact with on its own. The measure for all of these things are players, and the good intentions of the designer cannot save a game from these problems. We need to judge a system by how we engage with it. If engagement does not feel good, then it is tough to get over that sensation.
Now the second issue is still a problem, but one that can be better overlooked. Because we as players still have fun with the system, we can still look favorably upon the end product. But the problem comes from the fact that the fun is – effectively – a matter of good luck. Insofar as design is specifically a matter of control, it is important to leave as little to luck as possible. If a system is fun on its own and players find something additional to enjoy, that’s fine. But it is not good to rely upon players finding something to enjoy in a system that doesn’t feel good on its own.
The third issue, though, is what we want to focus on. Because we can commonly see the idea of intent as a justification. Sure, this system isn’t fun to interact with, but it’s not supposed to be fun. You’re supposed to dislike it, so that you play the game some other way.
But this justification doesn’t really work. While the logic my be valid, it relies on the premise that the only way or the best way to encourage the player to interact with the game in the “right” way is by discouraging other forms of interaction. But neither claim is true. It’s certainly not the only way, because the system in question could simply be scrapped entirely: if you want players to do X instead of Y, then just don’t allow them to do Y in the first place. And in terms of the best way, players will ultimately respond better to rewards than to punishments. Do you want players to use stealth rather than fighting? Then offer them rewards for playing stealthily, rather than punishing them for fighting. Rewards will build the habits for intended behavior. But punishments will hurt both parts of the game: the player will not have fun with the “bad” system, because it isn’t fun on its own; they will learn to hate the “good” system, because they’re forced to use it. Giving players a choice and then slapping their hands when they choose wrongly builds greater resentment than not offering a choice in the first place.
Now one possible exception to these rules exist. It is possible to make a system that is not fun to interact with, but that lack of fun may be important for the game’s narrative. We often see this discussion take place in the context of survival horror games. In such games, combat is usually clunky and ineffective, but such problems are generally justified because of the game’s themes: the player character shouldn’t be good at combat, and the game’s systems are designed for players to enter combat sparingly. This setup could conceivably be framed as a failure of design as well, but the justification here is stronger. Namely, the thematic justification of the game’s clunkiness is more powerful than a systematic justification based on redirection. It should be noted that this clunkiness will still tend to drive players away, and as a consequence there may be significant risk in intentionally hindering a system for these thematic purposes. But insofar as a developer is willing to take that risk, the intent behind the design does offer some kind of saving grace. But the basis of that grace is not the intent itself, but rather the way in which the intent and execution interact with each other.
When we talk about video game systems, our instinct is to rely on our own impressions: do we find the game fun or not? And ultimately, that is all we have to rely on. Much as we can explain away criticisms, we cannot explain away a player’s actual issues. If we don’t enjoy something, an explanation will not make us enjoy it.
So when analyzing a video game, we need to begin from the standpoint of how fun the game is. For any given system in the game, we must ask ourselves whether it is executed well: is it enjoyable to interact with? The intent behind that system might be interesting to investigate, but not for the purposes of criticism. Criticism must focus upon the end product. If the end product doesn’t do its job well, that is what matters. A good intention cannot make a criticism go away.