Thursday 1 August 2019

Gilbert's Rules of Thumb for Point and click adventure games

Gilbert's Rules of Thumb for Point and click adventure games:

In summary, the design rules are:

  • Make the end objective and sub-goals clear at all times. Don't let your player wander around wondering what they need to do next.
  • No puzzles that require the player to die to get to know what to do next.
  • No "Backwards Puzzles": never find the solution before you face the problem.
  • Do not require players to pick up items that are used later if they cannot go back.
  • Puzzles should emerge from the story; they should be part of the story and not slow down the game for no reason.
  • Don't use real time in time-based puzzles but allow for some clearance.
  • Reward players (by revealing new areas, new plot elements, twists, ...) for proceeding in the game.
  • Design puzzles that make sense.
  • Reward the intent of the players - don't design interfaces that punish the players even they already got the right idea.
  • Don't have unconnected events that allow for access to new areas.
  • Allow for options and exploration in the world, don't lock the players up in restricted areas.

End objective needs to be clear

It's OK if the objective changes in mid-game, but at the beginning the player should have a clear vision as to what he or she is trying to accomplish. Nothing is more frustrating than wandering around wondering what you should be doing and if what you have been doing is going to get you anywhere. Situations where not knowing what's going on can be fun and an integral part of the game, but this is rare and difficult to pull off.

Sub-goals need to be obvious

Most good adventure games are broken up into many sub-goals. Letting the player know at least the first sub-goal is essential in hooking them. If the main goal is to rescue the prince, and the player is trapped on an island at the beginning of the game, have another character in the story tell them the first step: get off the island. This is just good storytelling. Ben Kenobi pretty much laid out Luke's whole journey in the first twenty minutes of Star Wars. This provided a way for the audience to follow the progress of the main character. For someone not used to the repetitive head-banging of adventure games, this simple clue can mean the difference between finishing the game and giving up after the first hour. It's very easy when designing to become blind to what the player doesn't know about your story.

Live and learn

As a rule, adventure games should be able to be played from beginning to end without "dying" or saving the game if the player is very careful and very observant. It is bad design to put puzzles and situations into a game that require a player to die in order to learn what not to do next time. This is not to say that all death situations should be designed out. Danger is inherent in drama, but danger should be survivable if the player is clever.
As an exercise, take one complete path through a story game and then tell it to someone else, as if it were a standard story. If you find places where the main character could not have known a piece of information that was used (the character who learned it died in a previous game), then there is a hole in the plot.

Backwards Puzzles

The backwards puzzle is probably the one thing that bugs me more than anything else about adventure games. I have created my share of them; and as with most design flaws, it's easier to leave them in than to redesign them. The backwards puzzle occurs when the solution is found before the problem. Ideally, the crevice should be found before the rope that allows the player to descend. What this does in the player's mind is set up a challenge. He knows he need to get down the crevice, but there is no route. Now the player has a task in mind as he continues to search. When a rope is spotted, a light goes on in his head and the puzzle falls into place. For a player, when the design works, there is nothing like that experience.

I forgot to pick it up

This is really part of the backwards puzzle rule, but in the worst way. Never require a player to pick up an item that is used later in the game if she can't go back and get it when it is needed. It is very frustrating to learn that a seemingly insignificant object is needed, and the only way to get it is to start over or go back to a saved game. From the player's point of view, there was no reason for picking it up in the first place. Some designers have actually defended this practice by saying that, "adventure games players know to pick up everything." This is a cop-out. If the jar of water needs to be used on the spaceship and it can only be found on the planet, create a use for it on the planet that guarantees it will be picked up. If the time between the two uses is long enough, you can be almost guaranteed that the player forgot she even had the object.
The other way around this problem is to give the player hints about what she might need to pick up. If the aliens on the planet suggest that the player find water before returning to the ship, and the player ignores this advice, then failure is her own fault.

Puzzles should advance the story

There is nothing more frustrating than solving pointless puzzle after pointless puzzle. Each puzzle solved should bring the player closer to understanding the story and game. It should be somewhat clear how solving this puzzle brings the player closer to the immediate goal. What a waste of time and energy for the designer and player if all the puzzle does is slow the progress of the game.

Real time is bad drama

One of the most important keys to drama is timing. Anyone who has designed a story game knows that the player rarely does anything at the right time or in the right order. If we let the game run on a clock that is independent from the player's actions, we are going to be guaranteed that few things will happen with dramatic timing. When Indiana Jones rolled under the closing stone door and grabbed his hat just in time, it sent a chill and a cheer through everyone in the audience. If that scene had been done in a standard adventure game, the player would have been killed the first four times he tried to make it under the door. The next six times the player would have been too late to grab the hat. Is this good drama? Not likely. The key is to use Hollywood time, not real time. Give the player some slack when doing time-based puzzles. Try to watch for intent. If the player is working towards the solution and almost ready to complete it, wait. Wait until the hat is grabbed, then slam the door down. The player thinks they "just made it" and consequently a much greater number of players get the rush and excitement. When designing time puzzles I like to divide the time into three categories. 10% of the players will do the puzzle so fast and efficiently that they will finish with time to spare. Another 10% will take too much time and fail, which leaves 80% of the people to brush through in the nick of time.

Incremental reward

The player needs to know that she is achieving. The fastest way to turn a player off is to let the game drag on with no advancement. This is especially true for people who are playing adventure games for the first time. In graphics adventures the reward often comes in the form of seeing new areas of the game. New graphics and characters are often all that is needed to keep people playing. Of course, if we are trying to tell a story, then revealing new plot elements and twists can be of equal or greater value.

Arbitrary puzzles

Puzzles and their solutions need to make sense. They don't have to be obvious, just make sense. The best reaction after solving a tough puzzle should be, "Of course, why didn't I think of that sooner!" The worst, and most often heard after being told the solution is, "I never would have gotten that!" If the solution can only be reached by trial and error or plain luck, it's a bad puzzle.

Reward Intent

The object of these games is to have fun. Figure out what the player is trying to do. If it is what the game wants, then help the player along and let it happen. The most common place this fails is in playing a meta-game called "second guess the parser." If there is an object on the screen that looks like a box, but the parser is waiting for it to be called a mailbox, the player is going to spend a lot of time trying to get the game to do a task that should be transparent. In parser-driven games, the key is to have lots of synonyms for objects. If the game is a graphics adventure, check proximity of the player's character. If the player is standing right next to something, chances are they are trying to manipulate it. If you give the player the benefit of the doubt, the game will be right more than wrong. On one occasion, I don't know how much time I spent trying to tie a string on the end of a stick. I finally gave up, not knowing if I was wording the sentence wrong or if it was not part of the design. As it turned out, I was wording it wrong.

Unconnected events

In order to pace events, some games lock out sections until certain events have happened. There is nothing wrong with this, it is almost a necessity. The problem comes when the event that opens the new section of the world is unconnected. If the designer wants to make sure that six objects have been picked up before opening a secret door, make sure that there is a reason why those six objects would affect the door. If a player has only picked up five of the objects and is waiting for the door to open (or worse yet, trying to find a way to open the door), the act of getting the flashlight is not going to make any sense in relation to the door opening.

Give the player options

A lot of story games employ a technique that can best be described as caging the player. This occurs when the player is required to solve a small set of puzzles in order to advance to the next section of the game, at which point she is presented with another small set of puzzles. Once these puzzles are solved, in a seemingly endless series of cages, the player enters the next section. This can be particularly frustrating if the player is unable to solve a particular puzzle. The areas to explore tend to be small, so the only activity is walking around trying to find the one solution out.
Try to imagine this type of puzzle as a cage the player is caught in, and the only way out is to find the key. Once the key is found, the player finds herself in another cage. A better way to approach designing this is to think of the player as outside the cages, and the puzzles as locked up within. In this model, the player has a lot more options about what to do next. She can select from a wide variety of cages to open. If the solution to one puzzle stumps her, she can go on to another, thus increasing the amount of useful activity going on.
Of course, you will want some puzzles that lock out areas of the game, but the areas should be fairly large and interesting unto themselves. A good indicator of the cage syndrome is how linear the game is. If the plot follows a very strict line, chances are the designer is caging the player along the path. It's not easy to uncage a game, it requires some careful attention to the plot as seen from players coming at the story from different directions. The easiest way is to create different interactions for a given situation depending on the order encountered.

Content taken from article Source: https://grumpygamer.com/why_adventure_games_suck

No comments:

Post a Comment