NMFORCE BLOG

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…

As our game’s prototype is nearly complete and the GameCon is over the corner, we playtested the game once again.

And we think we have successfully achieved all our goals (not gameplay goals, design goals):

• The game features simple gameplay.
• The game features an easy control scheme that don’t require additional tutorial
• The game has a simple goal that’s easy to understand and achieve.
• The game has a fast pacing to make use of the simple goal.
• The game supports multiplayer and has social interactions in the form of a leaderboard.
• Alternative strategies are made possible using a combination of gameplay mechanics and dynamics.
• Further increases replay value due to the unpredictable nature of PvP

As our prototype game is only a tutorial stage, there are no other players to be fought there, however the controls and core mechanics are all in place.

In the tutorial stage, the player can run on walls, shoot at AI targets, pick up ammo, and explore the stage. The Lobby and Room system is also in place but since Tutorial Stage is now designed for single player only so it’s currently unused. The game will feature LAN netplay when completed.

The gameplay itself is smooth and most test players can finish the tutorial stage without problems. The tutorial itself is done by displaying the controls in a clear fashion above the screen. It’s actually built in as a part of the map so it gives direct feedback to the players when they completed a part of the map. The map itself is divided into multiple parts, each part explains a single mechanic (1st part is moving, 2nd part is shooting, 3rd part is running on walls, etc.) After the entire tutorial process is completed. the player is left in the final part of the arena where they need to use what they had learned just now to take down several AI targets. The tutorial stage ends after all the targets has been dealt with.

Overall, I see this game is going according to the plans and the design document and has no doubt that it will do well on the gamecon. We still have a long road ahead of us though but as of now, everything is in place.

It’s always better if a game could be played with more people. Super Smash Bros. is successful because of that, and with the recent launching of Super Smash Bros., 8 players could duke it out on the arena. Which inspired us to put more than 2 players in the game. The problem here is how to implement it.

For our programmers, it’s of course feasible to implement a sort of lobby and room system that supports more than 2, maybe 4 to 8 players in the same map. However, our group members pointed out that having more players will likely results in an even faster game.

Not that it’s a bad thing.

However, we are not casual games, we don’t have a hi-score board either. Since there are no sources to get points. Leaderboards can surely be implemented using the “Most rounds survived” as standard and it’s surely a good incentive for players to compare among themselves.

The shorter game times are actually a good thing here because the players can rack up in points very quick since a match will likely ends in shorter than 5 minutes with 8 players eagerly killing each other. A Team Battle Mode can be similarity implemented to promote teamwork and lessen the pace.

The point of making more people playing the game is that for a game with a single goal and very fast pacing, more people playing means there are more random factors (without us throwing random factors built-in the game here or there.) since people will tend to have different strategies. Which will provide a random factor of unpredictability in the process. In other words, having more players will increase the re playability of our game which is always a good thing to look forward to.

Of course, add in multi player functions require us to focus more about the balancing of the game play, but thanks to the simple goal and game play mechanics, this won’t be hard to do.

This passing week has been slow due to some of our members went to MIGS, so I want to look back and discuss the UI and Controls on our games this time.

I listed examples of platforming games in my UI blog. Because originally our game will be played similar to one. However, we have since changed our game design for a faster paced-PvP arena game. The thing is, the discussions of UI and Controls are still relevant even if the game genre is changed.

Currently, our game features a very simple UI: On the screen is a number showing the remaining bullets, there are also a crosshair in the middle of the screen that can help aiming. There is no need for HP since you die in one hit. However when you have a shield on, your weapon will change color to reflect that. Obviously, the color will be removed (and with a sound) when you get hit.

We don’t need more things on our screen since we want our players to focus on the arena and their opponent. As far as we tested, this is a good design choice since no one questioned for the absence of UI or HUD.

Control wise. the game features the standard WASD moving, mouse aiming and firing control that everyone with an experience on games such like Counter-Strike would known of. Most similar games on the market features the same control scheme. Currently, joystick/gamepad control haven’t been implemented, but when it eventually does, it will also resemble the control scheme used in those games. This is to ensure that our intended player base would pick up this game and know how to play it without any additional tutorials.

Our player profile indicates that our player bases are likely the more casual FPS players, which will like the streamlined UI and Controls.

The programmers are working to align the crosshair so it fits better with the camera. And we’ll be moving on the designing of the main menus and menu items when that’s done.

After we finish our goal design and gameplay design. We started to actually implementing the gameplay. The engines are being fired up and classes constructed in Visual Studio that loads the map, handles the physics and the gameplay input, etc. However, before a part of the game is completed and tested, nobody, even the programmer himself would know how the game would have worked. So testing is important.

Since our gameplay is simple, anything that will make the gameplay harder should be considered unfitting and should be fixed.

One such problem that surfaces through testing is that the wall runs are registered differently and sometimes it will not work, resulting the player fall off during the wall jump and run if they jumped from a specific angle. Luckily, this gets discovered very soon and is easy to fix.

Another problem is related to how the engine handles the camera in relation of the player’s screen. Since the engine registers camera angles and position differently from what we actually saw on-screen, the shots would miss if the camera is in an odd position ( for example, if the camera, for some reason, is not related to the player – often resulted by shooting while falling or wall-running). We thought of taking out the option of shooting when the player is in odd positions, but ultimately decided against so since this drifts from the initial goal: The player should be able to aim and shoot at any given time. Thus, additional works are done on the camera class to ensure that the bullets fire track is more closer to what the player will actually see on screen.

We are starting to make a tutorial stage with a special arena together with instructions to both familiar the players and serves of the further playtesting stage for our own. Our prototype will be featuring this tutorial stage too.

Previously, some different games was discussed because we are still discussing what to do about our own game, including an complete rewrite of the game’s design document and other related information, and since this week most of our own game’s design is ironed out we’ll starting to discuss our own game.

Originally, our game is featured in a fantasy setting where 2 players need to be teamed up in order to defeat a huge boss. However, in our discussion regarding the implementation of the idea, we found out a problem: No matter how we make the boss fight, there ought to be repetitions, such like climbing on the boss’s back while the boss tries to shake your character down, how the boss attacks and how the player will dodge the attack. Even though we can spice up the boss fight by giving the bosses different sets of attacks or completely different bosses, the results would be the same – The player would quickly exhaust all the alternative patterns and bosses and will get bored pretty soon.

To cater to this problem, we have once discussed the possibility to make the game extremely hard (not unlike one of the platformer above), however even we make the gameplay fair through the feedbacks and controls, it’s still not enough to not make the player feel frustrated. So we scrapped the entire idea.

We think the lack of the replay value is cause by the lack of alternative strategies and randomness, so we ultimately remade the game into something entirely different – Instead of two players fighting a boss, now we have 2 players fighting each other in an arena with the same amount of resources – each player get 3 bullets and have only 1 HP. The arena is quite big so there are lot of space for alternative strategies, also because the opponent is a human now instead of an AI or preset pattern, there are more fun in outwitting a fellow player.

Now, the problem comes to how to actually make it so the process itself would be fun, we’re thinking of a very fast-paced gameplay that will make the player replay again and again in a relatively short time. The match itself will be about 3 to 5 minutes long, and give the player incentive to play the game again and again, using different ways but under the same goal.

Now this is one problem solved. The other problem, would be how to make this gameplay itself more interesting so the player will want to play the game again and again.