Features – Hidden versus Growing

Changing the User Interface

This section is most applicable to point-and-click adventure games but has some relevance for related types of games

In a point-and-click adventure game the player is able to click on certain hotspots on a painted map (i.e., click on a bucket to pour water). By clicking in different locations outcomes can be triggered to help progress the adventure forward. Or not.

A fun indie game called Samorost 2 (play C1 online for free) is a great example of this system. In that game you play a man searching for a dog that aliens have kidnapped. You click on various locations to progress across beautifully painted maps.

Yet at times some of the puzzles can be frustrating — as they are in most games of this nature.

One of the difficulties is that you can click on an object early on in the puzzle — as you experiment with trying to figure out how to solve the obstacle — and nothing happens, no user feedback of any occurring. And then later after you do the first few steps that previously inactive location is now where you have to click next.

So a feature that was not there before gets revealed. This really leads to two schools of thought in regards to feature revealing — Hidden Features versus Growing Features.

Hidden Features

Hidden features (or levels or other types of bonuses) are those that appear in areas that the player has already explored (whether it be the user interface, or the actual level, as described above).

When the user interface does this it can be a useful design tactics — more buttons appearing as the player gets better in the game. If there is a visual indicator when the new feature appears this can become a progression tool to get players interested in building their gameplay experience.

When the level itself does it, as in puzzle games, it becomes a difficulty issue — the game is harder to play. This, when intentional is great — a valid design decision. But sometimes designers make their games work this way simply because ‘its the way it is done’ or out of habit.

Not only does it make the game more difficult but it also makes the designers miss out on adding gameplay experience for the player. Sometimes trying and failing can be fun (and certainly more fun then pixel-hunting a painting to see if an object is now usable).

Growing Features

An advantage of allowing a player to do everything even before they can actually succeed is that it helps inform the player what can and cannot be done.

Take this example:

Though this example is simple, some players are going to enter the room and then click the first lever, the wheel (and nothing happens), and the second lever. Because the levers animated and the wheel DID NOT, it is perfectly reasonable for that player to assume the wheel is not something that CAN be used — i.e., it is part of the background. In such a simple example the player is likely to figure out that they can indeed click the wheel now. But imagine a more complicated game, with more areas to interact with… difficulty increases.

Now instead of the first example, consider this.

The advantage here is that the player is told that they have the capability of making the wheel move… eventually. So they know they have to somehow make it so the wheel can move. If their end goal is to open a door, there is now an intermediate goal of enabling the wheel to turn. The puzzle is now a richer experience.

And the failure experience allows for lots of design cleverness — as long as art and programming have the resources to support it.

Conclusion

Learning by failure is an important design element to harness. In my opinion it should be leveraged as often as possible. I prefer games that allow me to do everything I can do, from the start (or at least once past the tutorial). I accept that I won’t actually be able to do everything but knowing I can try lets me remember actions I failed at performing earlier. And I’ll try again.