Dom Camus said:
Yes, yes indeed. But in talking about failings of game design I didn't just mean things like bad puzzles. Some designers have begun to realise that, as you say, it's all about what users want. People like to have all the weapons? Give them a mode where they do. And so on.
I'm a little confused on this one, so I apologize if I'm reading it wrong--do you mean that providing this mode is a
failing, or an example of
correcting a failing?
Also, I agree with your point that not every instance of walkthrough use involves a bad puzzle. However, I'm pretty sure I wouldn't use them at all if I could be 100% confident that all the puzzles were fair. For example, you'll notice where I mention Machinarium above that I say it didn't require a walkthrough. That wording was carefully chosen... because I did use one for one puzzle, then regretted it because it turned out there was no need. The problem was that my trust ran out before I solved the puzzle legitimately.
An excellent point made on player-developer interaction. Especially for a new developer, this process is a lot like "first contact" with an alien: First, you have to establish what
language you'll use to communicate, then you try a few simple things out to make sure that language is working, and then you get down to business.
A lot of game designers allow certain assumptions to cause them to skip that first step. Usually, this involves either 1) assuming the player has a certain body of prior knowledge and failing to provide it in the game, or 2) assuming the player will see this puzzle/problem from the same point-of-view as the designer. In either case, it means the designer isn't properly
creating the language they're attempting to use to communicate with the player.
Like all relationships, trust is about communication. If communication is spotty, trust is going to be lacking. And if the language isn't well codified (
by the designer,
for the player), communication will be spotty. The payoff for all this is pretty simple: It is always the responsibility of the designer of a game to
teach the player the language of the game.
Provide activities that show the player the skills, props/tools/items, signals and hints, and thought processes that you'll be asking them to use. Be very careful what you assume the player will already know or understand. And, of course, don't go to the other extreme and make your game a walkthrough for itself. Show them how, let them practice, and
then make them do it.
A great example of a game that did this was
Myst. The puzzles were tricky, and the various parts and buttons involved weren't usually labelled. But, being based around books, the game provided you instructions spread across the various books and pages you'd find. In these "hints," you were given clues as to what the pieces of the puzzle did, as well as what result you needed, and then it was up to you to connect the dots.
But most importantly, the "people" writing those books
showed you how to play! They were making charts and diagrams, which in turn suggested to you (the player) to do the same as you worked it out. Not only were you being taught the mechanical aspects of the puzzles, but you were being shown a demonstration of the
process of solving the puzzles.
(
Myst also had its failings, occasionally, in that there'd be an object that was important and clickable... but the art design didn't appropriately draw attention to that item, occasionally leaving the player looking at a puzzle with what seems to be a missing piece...)
