If there’s one thing that is well known within the circle of game developers, that is the players of their games are very, very hard to please. It’s true that game developers and designers aren’t telepaths and know everything the player’s thinking, but that still didn’t justify player’s actions sometimes. It seems they always have the way of getting the intentions of the designers wrong, then come back and blame the designers for everything they haven’t done wrong.

In other words, no matter what the developers do, there are always someone that’s not happy.

While this is indeed a very sad matter, there are ways to get around that.

Remove unnecessary stuff

We humans may have unlimited potential, but we do have limited attention. Most of the time, we don’t need every single piece of information, even if it’s something that seems important. One example comes from the Mega Man series. The first game in the series feature a score counter that’s shown on the top of the screen, there’s also an item that when collected, adds up a multiplier at the end of the stage which gives more points. Each Robot Master also comes with a Clear Point. (and I must add, I don’t know why some of them are higher than others when they’re equally hard, maybe that’s just because of me.) Then, Capcom found out that this game is so difficult that clearing the game is a feat in itself, and since score is only calculated from enemies and boss destroyed and multiplier items gotten, meaning people are going to get the same range of score anyways, later Mega Man games do away with the scoring system altogether, and never speaks of it ever again in all Mega Man games after that. (Well, some of the other spin-offs has a rank system, but players with better techniques are getting higher ranks thus make the system actually useful)

Obviously, Mega Man Series get away with the entire score system is just a Special case due to the game’s difficulty and linear gameplay. In most of the games, it’ll be confusing to throw every single unnecessary mechanic out. Thus, the more accessible way of managing unnecessary data, is to keep them under the hood so players can direct their attention elsewhere. A common practice in STGs (Shoot’em ups) is to blur out the HUD Elements when the player sprite is on top of them. Since the player’s current location, together with the bullets’ current location are something players want to have more attention directed to.

Make necessary stuff stand out – But not too many

While we’re still on the topic of STGs, it’s not uncommon for these games to notify the player, either by audio or video means, that they have extra resources. (Bombs, Lives or Power-Ups) which stems from the similar practice. The reason being that while we want to keep the user’s attention on the main gameplay, we also want to direct their attention to their available resources when these changes. Now, if they actually used said resources, they’ll get feedback in the form of actually using resources – It’s only fair that they’ll get some kind of feedback when things go the other way.

So we let the unnecessary stuff become hidden, and the core stuff becomes the center of attention. Then for the really necessary stuff, we’ll just make it stand out so it can grab the user’s attention.

Note that this tactic, while seems cool on paper, has a big chance to mess up if the player don’t know what to do. For example, say there’s an adventure game with some puzzle elements. The player is now facing a control panel full of buttons. Suddenly, a red button lit up. Most of the players will then reach for the red button since it grabs their attention. Then, after doing that, a green and a blue button lit up together.

Now the player is confused – which button should I press? The green one, the blue one? Or press them together? While the player is busy thinking about that, the control panel exploded due to inactivity, killing the player.

This exact practice is actually popular in older adventure games. However ultimately the trial and error approach would leads to more angry players than clever or lucky players that figured out the correct way in the first few tries.

In short, don’t overwhelm player with big number of “necessary stuff”, in most of the cases, one is enough. If absolutely needed to do two or more in one go, try using some way to warn the player (a.k.a grabbing their attention) first.

We can actually continue talking about perceptions and how that’s also unreliable, but for a specific reason, we’ll leave this to the next blog.

In the next blog, we’ll talk about how to extract what the player really want from their feedback. Yeah, this totally seems like telepathy now…

Until the next time….

I understand this is a game design blog, but today, we’ll look at something that’s more general before we get into the topic. That’s the Design Principles.

According to Donald Norman, there are several kinds of key design principles that works in everyday things: Visibility, Feedback, Constraints, Mapping, Consistency and Affordances.

Of course, what could apply in everyday things can also apply to game design. Actually, some of these principles has become so well-used and well-known, that they already become tropes that is often discussed by gamers and designers alike.

And we’re talking about some of them in this blog article.

Trope: Interface Spoiler

There is a well-known trope in video gaming called Interface Spoiler. This refers to the fact that sometimes players can try to guess what would happen in the game from just the game UI elements. For example, in any RPG game with a bestiary system, where the player can see all the monsters/enemies they’ve defeated in the game, the player can guess what point they’re at within the story from the completion rate of the bestiary: It may be usual if you’re at the final dungeon with a 80% completion rate since the rest of them would be mostly residing in the last dungeon. However, if the bestiary is only at 30% or such, and the game has already placed the player at somewhere that resembles a final area, this would almost always mean that there are some twist coming ahead and the story is far from over. Especially if the existing content seems underwhelming.

“I’ve already defeated this Dark Lord, why do I still at 28%?”

This, is mostly caused by one of the above design principles backfire on us. The game is giving more feedback than the player should know. Normally, a completion rate system is implemented to remind the users how far they’re in and what has been done. In this case, it tracks the unique kinds of monsters they encountered. Players can easily put one and one together and instantly know something was fishy from the get-go.

Now, for the game in the screenshot, it’s no big matter because the game above is meant to spoof those overused RPG tropes. However, if one’s game focus on storytelling and various twists much, they need to work to get around this matter.

Luckily, as a certain Chinese proverb tells us “The only ones able to untie the bell, is usually the same people that tied it up in the first place.” To solve a problem caused by accidental backfire of design principles, the best thing we need to do is make use of another design principle, in this case, constraints.

Let’s assume we’re making a mystery-themed game. There is a killing spree going on in a classic closed house scenario, the people are dying one by one and new information are constantly updated from the player’s investigation. Everything finally ends on a climax where the main character trapped the killer (who we, the player don’t know the identity of) in a room with no escape. And as the protagonists rush to the door, a prompt appears that tells you to enter the suspect’s name. It’s also the old-fashioned way: The player need to type out the suspect’s name manually, as if he really is a detective and is writing things down in his notebook.

Now, if we’re doing proper design and feedback, we normally want to just give the player a choice from every character in the game because it’ll be hard for the player to remember the exact name of every character in the game. But that will decrease the difficulty of the game since this actually give players a clean range of possible suspects – while the killer could be anyone the player has met, there are always other “spoilery” possibilities. By taking away the player’s ability to select from a pre-defined list of characters,  we give the players more options to choose (and more possible for them to choose wrong!) However to prevent the earlier problem of “player not remembering the names”, we’ll make the list of characters accessible instead – just taking away the ability to directly select one of them is enough in this case.

Of course, for this trick to be actually working decently, make sure to write out every single possibility in-game for every single possible wrong and right answer – one such wrong answer can be used as a catch all for typos or names that plainly doesn’t exist in the story, but we’d want to get everything covered, just in case.

Trope: Tomato in the Mirror

Sometimes, we may want to play up the narratives for a bit, especially if the game is heavy on storytelling and twists (notice a trend there?) To do that, we have 2 approaches:

Hiding things from the player so they will be surprised by the reveal. Or make something different to make the player aware that they may not be playing the same character. Both are Visibility matters.

Example of hiding things from the player can often be see in games where you’re required to name your character, or customize your character in some way. The game will give the player the interface and telling them to name/design this character. However, they did not state that the character they’re naming and designing is actually the player character. By cleverly limiting the visibility, we can leave room for storytelling twists and makes interesting design choices in our games.

Undertale is a game using a similar system. It also makes use of the constraints principle discussed earlier, in which the game would stop you if you name yourself after some certain important in-game characters. After all, if naming your character provides a twist for the player, you don’t want the player to do anything to mess that up.

On the other hand, by introducing small, different feedback, we can also make the player aware that something isn’t right. For example, if an interactive visual novel suddenly changed its interface to be played like a normal audio book (where all of your potential choices has been taken away when they appears), the player would know that something went wrong.

By cleverly controlling feedback and visibility, we can let the players know only we want them to know.

And that’s all for today, for the next blog, we’ll be talking about our players.

Until the next time…