Losing Control

Words: 2464 Approximate Reading Time: 15-20 minutes

I want to talk about a complicated subject. It’s an aspect of game design that feels very easy to critique, and yet it speaks to an underlying problem of how we build systems. It reflects the complexity of systems and how creators may not fully understand how systems get used.

I want to talk about controls.

And I want to use a recent game to showcase this problem: Lorelei and the Laser Eyes. This is a puzzle game with a fairly open-ended design. In fact, it’s one of the better entries in this genre that I’ve seen. I’ve written before about how puzzle design in these games can devolve into a game of hide-and-seek. Lorelei still echoes this a bit, but also has a number of actual puzzles. It seems weird to say “actual puzzles,” but if you’re familiar with this genre, you understand the problem.

But while Lorelei’s puzzle design is pretty good, the controls are – to be quite honest – awful. Ironically, they are also incredibly simple. It seems like simple controls should be fine, but this ends up being a case where their very simplicity creates friction for the player. There are things you want the game to do that it cannot.

And it is this disconnect between what the player would clearly want and what the game provides that sparked this essay.

Control Design as a Subjectivity Problem

Let’s step back for a moment.

When creating any system with a number of moving parts, there’s a lot to keep in mind. You’re juggling numerous components that need to interact with one another. And of course the primary component is a player. And not just a player, but hundreds, thousands, maybe even millions of them. All with different ways of processing information, experimenting, retaining information, drawing conclusions, and so on.

So there’s not exactly a one-size-fits-all approach when it comes to designing a system for human interaction at all.

But one of the problems that can crop up when designing a system is how we understand the system from the outside. And the way that our internal understanding can conflict with how people use those systems.

The problem can be put best like this. When mapping controls, a designer will have to make a series of decisions about what they want a player to be able to do. Movement, attacking, navigating a menu, and so on will all need to be arranged in a way that allows for the game to function, and will also make sense.

But “making sense” is going to be a sticking point. In making your initial decisions, you likely justified why you wanted the controls set up the way they are. Which means that why a specific button triggers a specific action is something you already understand, because you thought about it and reached a conclusion. The “why” is an invisible thread connecting the bits of information – this button performs this action for this reason.

But since this metaphorical thread is invisible, the only person who knows it’s there is the designer. Which means from an outside perspective, the logic is absent. And if someone tries to use the controls in a different way that makes sense to them, then you get friction. The player wants to do something they feel they should be able to do, but the game doesn’t respond in kind.

This problem is not new, nor is it unknown. Indeed, one thing that developers of all sizes do throughout development is playtest. Ideally, they would strive to have some number of people from outside the development process – people off the street, if you will – who can come in and play. Observing how those people play, seeing what they find engaging, seeing what they ignore, seeing what they get frustrated by, all reveals information about the game’s design in one way or another. It can provide direction on what to lean into or away from.

But the quality of this information is dependent on the ability to get this kind of feedback, the quality of the feedback itself, and the willingness of the developer to listen to that feedback and address issues. If any one of those components is missing, a massive gap might occur. A game might have poor controls, but the problem might go unnoticed or unaddressed, until it is too late.

And that’s why it’s just as important to be constantly thinking outside of our own perspective. To try and get into the head of a player and ask what a player might wish to do, and how well the controls allow the player to act on those desires. Seeing how players play helps us gather this information directly. But stopping to rethink these systems from an outside perspective allows us to identify potential problems before they crop up. It certainly isn’t a foolproof method, and cannot be a sufficient substitute for other ways of identifying friction, but it should be employed on a continual basis.

Lorelei and Oversimplifying

Lorelei and the Laser Eyes has a very simple control scheme. You use whatever movement controls are designated to move your character around and navigate the menu, and use a button to interact. If you are next to and facing an object that you can interact with, it will light up, and thus when you press the interact button your character will…interact with it. That will likely take you to a new screen to manipulate the components of the puzzle, where you continue to use the same button. There is usually a mechanism that you use when you are finished (by pressing the same button on your controller) to basically say “okay, that’s my solution.” At which point, you either succeed and the puzzle is solved, or you fail and get kicked out of the puzzle screen.

Meanwhile, pressing your interaction button while not facing an object will open a menu. The menu contains a lot of useful information – your inventory, a collection of every note you’ve collected (which helps with solving the game’s puzzles), maps, and so on. You spend a decent amount of time in these menus referring back to the notes you’ve found along the way and looking at the game’s maps.

This incredibly simple control scheme sounds nice in theory. No need to remember complex combinations or press buttons in the right order to get your character to do something. But by the same token, the way that all of these interactions are set up creates a whole new set of issues.

So imagine you encounter a new puzzle. You take a look at it and realize that you found a clue earlier that you want to refer to. So what do you do? Well if you have a lot of experience with games, your instinct may be to seek a “cancel” button. You can’t solve the puzzle right this second, but you could back out. But pressing any button on your controller simply manipulates parts of the puzzle. So you have to navigate over to the “input my solution” mechanism so that the game can tell you your solution is wrong and eject you from the puzzle.

At which point, you then want to open your menu. To accomplish this, you then need to turn your character before pressing the menu button…because it’s also the button for interacting. If you forget this and try to open your menu, you just go right back to the puzzle.

So two questions come up. Firstly, why not separate these two functions in the first place? Why would there not be a button for interacting with puzzle objects, and a different button for opening a menu? After all, forcing the player to turn just so they can open up a menu is a point of annoyance. A small one, but a point of annoyance nevertheless. And the more frequently this occurs, the more the player is going to feel that annoyance.

Secondly, why not simply give the player a functionality to open the menu while they’re in a puzzle menu? Why must they exit the puzzle entirely simply to find the information for how to interact with it? Again, it’s a small point of annoyance, but one that is going to be frequently felt. In fact, it is almost certainly going to be the player’s core interaction with the various puzzle elements – open the puzzle, look at it, fail the puzzle to back out, then open the menu to find a relevant document.

The game is filled with all sorts of these little foibles. For example, I’ve mentioned that there’s no “cancel” button. All buttons perform the same function. So when you go into the menu and want to back out to return to the game or look at a different sub-menu, you can’t just press a button to back out. Instead you need to navigate the cursor to an exit icon and press it. Want to check your maps? There’s no convenient map button – you have to go to the menu, then go to the documents submenu, then to the maps submenu, then open the map you want to see.

Each of these elements is a minor bit of friction. The game not behaving quite the way you might want, creating a tiny amount of frustration. But adding all of this up, along with the sheer number of times you need to work with these controls, creates an overwhelming feeling of dissatisfaction.

As a system, controls are designed. So all of this was done on purpose. It was – presumably – not done with the purpose of creating friction. But friction is the byproduct of this system regardless.

So something was missed.

The game was undoubtedly playtested. Maybe the playtesters never noticed these issues. Perhaps each individual tester only had a limited time with sections of the game, and thus did not feel the overarching problem. Perhaps the playtesters felt the issue, but had difficulty identifying the problem.

Maybe the problem was brought up, but ignored. Maybe it wasn’t ignored, but was decided that fixing the issue would take too much effort.

The exact explanation doesn’t really matter. What matters is the product we got.

But part of the explanation lies in the fact that these issues were not considered from the start. The underlying system was designed because the individual components made sense. You aren’t going to be performing a bunch of complicated actions, so you don’t need tons of buttons. Perhaps it was asked: why even have multiple button functionalities at all? Just have one button (or more precisely, all buttons do the same thing). When all of these functions are observed in isolation, they make sense. It’s when they’re put together and utilized dozens or hundreds of times that the problem crops up.

In a sense, it feels as though the controls were designed without the player in mind. Which isn’t true and feels mean to say…but it is a sensation that it’s easy to come away with. Because there are actions that a player very easily could be envisioned wanting to perform…but they’re not allowed.

And this is where the subjectivity problem comes back in. The logic of the design for these controls makes sense internally. If you think about the issue purely through the lens of simplicity, there’s no question that this is superb design – you can’t get much simpler than this. No one is going to be confused and press the wrong button.

But games in general aren’t necessarily built around simplicity. They’re built around a set of functions that come about from a combination of the game’s rules and the player’s desires. And if those functions aren’t implemented properly or just don’t exist, then you get friction. You’ve created an annoying or even bad experience for the player.

And so in designing any system, it’s important to step back and ask what the system does. What is a user going to see and experience? What tools will they use most often? What kinds of tasks might be presented to the user as part of the program’s operation?

And then from there you break down each component and examine them through your user’s perspective. On a given page or screen or stage, what is the user going to want to accomplish? This is not simply the goal that you as a designer may lay out, but also a series of tasks and sub-tasks that the user might want to fulfill. If certain information might be useful to accomplish something, will the user want that information to automatically pop up, or to be readily accessible? If the user needs to access multiple tools simultaneously, will they need to go hunting for those tools, or will you make them easy to locate?

Technology is not magical, and there are limitations to what can be done, especially with the constraints of time and money.

And yet, I hope I have shown through this example that there are likely elements that can be overlooked. That had these kinds of questions been posed, we might have found ourselves with a different control scheme. That the player might walk up to a puzzle, recognize that they have a clue, and then just open up a menu while in the puzzle to find the clue. When they need to return to the puzzle, they just press a button to cancel out of the menu. That when they get lost, they just push a button to open up a map. These things would require time and effort to implement, but they would not impose massive demands. And the end result would be a significant boost to the user experience.

Concluding Remarks

In some sense, I wonder if what I have argued here is simply too obvious. After all, I’ve mentioned a couple of times now that game developers engage in precisely these kinds of tasks. They have their games tested and hire people who specialize in these very issues. I feel like I am simply stating something that does not even need to be stated.

And yet, in playing Lorelei – and perhaps in some way observing or hearing about all sorts of other tiny experiences with both games and software – perhaps this isn’t as obvious. Perhaps even for all of the time and money poured into researching this topic, it is still easy for people to make big mistakes. Maybe there is an underlying flaw in some of the systems that are employed, or maybe the necessary expertise is concentrated in too few people. Whatever the case may be, learning how to effectively overcome this subjectivity problem is a task that would suit anyone seeking to build any kind of system for others – even something as simple as the controls of a video game.