• Yukkafuzz

Did it work?

I watched a video yesterday titled "What Games Are Like For Someone Who Doesn't Play Games". As a lifetime 'gamer', it can be hard to get in the head of a person playing for the first time, or even just a less experienced player. The video illustrates that what many gamers find intuitive or obvious actually relies on an extensive base of knowledge built up by players from a young age. Even the introductions or tutorials of modern titles prove frustrating for a new gamer. Viewing this critically as a game developer, it shows that a balance must be struck between compelling gameplay and ease of use, or you're choosing to cater only to an audience of already established gamers. Now, that audience is quite large, and it is not wrong to choose to more or less ignore the problem of onboarding a new gamer; however, careful design can help to bridge this gap in experience.

The main tools for the designers are instructions and feedback. Unsurprisingly, it's not enough to write an instruction manual, nor to display the instructions when someone begins the game. But somewhat less obviously, even what can seem to be well-designed instructions, which appear only when a feature has been unlocked or steadily over the course of a tutorial, also frequently fail to serve their purpose properly. The video mentions a couple: accidentally clicking through them, or doing so on purpose because who wants to read a wall (or even short paragraph) of text when you could be, for example, exploring a vast, procedurally generated universe? ^_^ I can think of a few more: not noticing the instructions (yes, popups are unobtrusive, but is that what you want?), not remembering all the details when you need them, or unclear wording, usually from a lack of assumed knowledge.

Just because the instructions can fail does not mean you should not include them, but you also need to adapt to the player. Here the other tool, feedback, comes to the rescue. The most basic form of feedback, of course, is the functionality of the game. When I click on a star, the camera zooms to focus on it. When I hit the 'w' key, the camera moves forward. When I try to hit a grayed-out button, nothing happens. Using only this form of feedback, however, can be frustrating, especially for the "nothing happens" case.

When I click the "Travel" button, nothing happens. I could have guessed, since it's grayed out. But why?

Even when something happens, it's not often I consider the "oops, what key did I just press?" situation. I've had plenty of experiences playing a game where I have to open up the controls configuration or even just press each key on my keyboard to try to undo something I did accidentally. Can I, as a designer, help the player in that situation? Perhaps. For some functions that might not be that common, or would be a significant problem if pressed accidentally, it's probably a good idea to add a little hint. Imagine:

Just minding my own business exploring this solar system.

"Ack! What in the WORLD just happened?" (I entered screenshot mode. But would I know that?)

It would be fairly disastrous to lose the entire UI and have no idea why or how to get it back. The first idea would be have a nice-sized message permanently on the screen that reads, "Screenshot mode. Press F1 to toggle," but you can imagine how much someone actually intending to take a screenshot would appreciate that. Instead, I try to strike a balance with a hint you can permanently disable.

It would be pretty hard to miss this little hint, and it's relatively unobtrusive.

Still, you should be able to disable it for the full screenshot effect. You can hover over it and exit, optionally disabling it forevermore.

While accidental button presses do happen, this screenshot mode case is far less important than a few other types of feedback: the answers to "Why can't I do this (that I normally can do)?" and "Did that do anything?" These questions have probably occurred to you, if you play any games, at some point in distress during gameplay. I showed an example at the top of this post in EXO: "Why can't I travel to this star system, when I've been able to travel to star systems like this in the past?" If the player can't figure out the answer to that question, it's going to lead to frustration. Yes, with the way games often go these days, you would be able to Google the answer (if EXO: Perl was released....), but as a developer I believe the game should not rely on the existence of a wiki.

The thing that most players don't consider is that it can be a headache to actually provide them with this kind of feedback. There are several reasons why you would not be able to travel to a star system: not enough fuel, engine is not powerful enough, you've removed your engine entirely, you're carrying too much cargo. When creating this initially, I just had a few checks with a "CanFly" function, which the rest of the code could use as a yes or no (boolean). It was self-contained. But to give the reason why the ship can't fly, I need to create a new function that breaks it down, reason by reason, meaning I can't be just getting a yes or no answer. Basically, where before I had the small "CanFly" box, now I have two boxes whose contents should be really quite similar but not the same. Not to mention adding some user interface elements to display the message. You can see why that can be a headache, even if it's not particularly difficult.

Hovering over the button provides the player the reason it's grayed out.

To be honest, I am not sure this little hover-over tooltip is enough to make it obvious what's wrong. Will the player hover over the button? If they do, will they notice the tooltip? We like to think "of course", but I've seen it go the other way.

The other piece of feedback I mentioned was "Did that do anything?" People expect an instantaneous response to pretty much anything they do. That's how physics works: you touch something, and you feel something. If you push something, it moves. So when the player does something, whether that's pressing a key, clicking, or using a button on the interface, something needs to happen. Now, this sounds obvious, and in one way it is, but consider EXO's planet extraction. Once landed on a planet, you cannot simply walk into your spaceship - your crew stays in orbit (think Star Trek). The player needs to call for extraction in advance, and they can with the touch of a key. But imagine glancing at your air gauge and realizing there's just a sliver left. You panic and press the extraction key. Nothing happens. You press it again. Nothing happens. You look at your air gauge. It's empty. You look at your health. It's decreasing rapidly. You start to think "What the heck?" You press the extraction key for the third time. Still nothing. A thought crosses your mind, "This game sucks." You look at your health. It's at a quarter. Then suddenly, ZAP! and in a moment you are back to the spaceship view. Of course, in this situation, pressing the extraction key worked perfectly the first time. It started the timer for extraction and you panicked while the timer counted down. But the reason you thought "this game sucks" was because it did not tell you (or show you) that the countdown had begun.

A simple but prominent message can be a very effective feedback mechanism.

Visual feedback is easy to show in a blog post, but auditory feedback is also essential. Satisfying thrumming for, say, a laser activating or another high-tech tool, or a short error noise when you try to activate it with no power is processed by the player almost unconsciously. Without these cues, the player (myself included) is quick to assume the game is not functioning, when in reality almost every piece of feedback you get is an extra feature that the developers intentionally added in to assure you the game is still running smoothly.

I don't resent this, however. The player should not be left wondering whether the game is working as intended. Feedback in its many forms is essential to the experience of a game, even though it's not a glamorous feature to create or to talk about.

One Knight Studio © 2019