Design Principle – Only keep what’s important

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.20160226101239

“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…

Post a Comment