Lately I was wondering what is the thing every game designer for an adventure game is afraid? I'm especially talking here about that part of game design where you decide what are the “rooms”, their connections, item placing inside them and other such things.

My idea for the post came from the TV Tropes articles “Unintentionally Unwinnable” and “Unwinnable by Design”. I then tried to get into the boots of such a designer and I've found that making a game unwinnable from a mistake might be a serious problem for them.

Imagine that you have forgot to put a vital item in some room. Now the player can't win your game because of this. How can you find such an error? Can you do this without actually playing the whole game from the beginning to the (probably unreachable) end?

I'm curious if this is your nightmare as a game designer and how you try the best to have got good dreams ?

felix.speagel said:
Now the player can't win your game because of this. How can you find such an error? Can you do this without actually playing the whole game from the beginning to the (probably unreachable) end?

If the game is simple enough, e.g. Maniac Mansion, one could write a test program to extract the graph of all potential actions a player could do, to verify it's always winnable.
But if it's complex, e.g. a modern RPG, that's probably not enough. Other, seemingly unrelated ‘bugs’ could cause slightly ‘illegal’ player states, and such test program would only consider ‘legal’ player states, i guess.
In this sense, the unrelated bugs only turn out to be real bugs due to their indirect effect on some other system. Which makes it practically impossible to find them all.
A solution could be to minimize potential side effects of other systems (loot, crafting, building a base…) on the system which handles story / quest progress.
But that's kind of the opposite from what we promise, which is ‘you can do everything in our game’.

Another cause would be that potential player actions are just too many, so a test program would never finish.
We could make smaller and simpler games to prevent this. But again not what we promise with games becoming bigger.

I consider the true solution is to give the player so many options, he likely can find a way to win from any situation. Kinda like real life.
Ofc. this can't work. But maybe it works good enough so a failing player would think it's his own fault, but not a bug or failure from the game.
However, that's far away from what we do now. We rely on static story. Eventually a branching story, but that's not dynamic or adaptive either. It still needs offline text, audio and animation to tell the story, and the branching tree remains static.
Thus, it's unavoidable a player might get stuck on some bug preventing progression of story. So we would need to give the player the option to bypass story entirely, showing how much control we loose by giving options.
We may end up with some reality simulation sandbox, which is no longer a lot of fun to play. If we can do anything for real, there might be no more motivation to do it at all.
Still, there must be some sweet spot. So i think that's still promising on our way.

felix.speagel said:
I'm curious if this is your nightmare as a game designer and how you try the best to have got good dreams

Recently i did read some interview about Maniac Mansion, probably with Ron Gilbert iirc.
He mentioned the unwinnable states are the biggest issue of the game, but overall he's happy and he thinks it's good.

My impression was, he was not aware about this problem when releasing the game. He realized it only after many people played it.

I guess to most it's just a problem, but not a nightmare.

You obviously need to test your game before releasing it. Not just once, but many times, while actively trying to mess up in as many ways as possible. Expect to spend as much time testing your game as you spend developing it. Doing so is not sufficient for guaranteeing that your game cannot be rendered unwinnable, but it'll catch most the low-hanging fruit (such as forgetting to put an item in a room) at least.

Beyond that, you need to examine every puzzle in the game and make sure it cannot be rendered unwinnable. If puzzle A requires item B from room C, then one of the following must be true:

• The player can go (back) to room C and fetch item B before the player is required to solve the puzzle.
• If the player already visited room C and cannot go back, then it must be impossible to reach puzzle A without picking up item B.

Even with both of these done, expect your users to find game-breaking bugs. You're just going to have to fix them when they are reported.