Chapters Part 2

Bottlenecks

Goal #1: Always a way out

You should always make sure that your game can be won (or: find a meaningful end) from any point with any set of states that are possible at this point (unless the game is obviously over and doesn't offer any more choices, like when the player died, which you may or may not want to allow).

Problem: Even with the debugging method described, it is hard to keep track of a complex mixture of states. You could construct a possible dead end because you forgot that rusty key #14 wasn't necessarily picked up way back in a place to which the player has lost access.

Solution: Complex state interdependences should be avoided. Once in a while in a long adventure, try to introduce a story "bottleneck" after which you reset the states. The player now simply does not need anything from the old part of the story, and if he does it was something that was crucial to enter the new part in the first place.
Chapters are suited for that. Besides structurizing your story and your files, the big advantage is that you only have to play-test the single chapter or sub-location, with default states. (You can directly link to the chapter by changing the HTML file.)
This doesn't mean you have to make a linear story: you can introduce several bottlenecks which lead into totally different chapters/ locations (which in turn may lead back to a single plot after a while).

Goal #2: Always a clear direction

You should always make sure the player isn't overwhelmed by meaningful possibilities to solve a puzzle.

Problem: If the player is overwhelmed by possibilities, your adventure might actually seem less interactive. If you can't predict what action would make sense to a player in a certain situation, you cannot offer that possibility to choose from. This would leave the player frustrated.

Solution: Guess-predict what the player could think of in a certain situation. Do that by knowing where he must come from, what he must have seen, where he might want to look for items to a puzzle. Small sub-locations reduce the options to a controllable number.

Example of bottleneck structure

The player has to find an item in a maze. The maze itself is a little world on its own, with many locations to pass through in order to get to that one wanted item. The player can enter the maze whenever he wants to by leaving a city in which the main action takes place at the moment. To leave the city and get to a certain castle, the item from the maze is needed.

Structure: Maze and city will be sub-locations with a two-way relation: the player can go back and forth between them. He may see a monster in the maze, for example, and remember he saw a weapon he didn't buy in the city. He may then go back to the city to get the weapon. Therefore, the states for both sub-locations are persistant, and there is a way leading back from maze to city. Because of the many new rooms/ locations, it is good to have a new subset of station IDs for the maze.
The castle in which the evil wizard has to be defeated however is a chapter with no way back. It would get too complex to predict possible player actions if the interaction is between these three locations. The story would also loose impact if the player sees the wizard, can get back to the city to buy a certain weapon, then realize when returning to the wizard the weapon has no effect, as there was no additional choice offered. Every reasonable player action should result in something meaningful (if it's just the hint that it made sense, but wasn't the solution to the puzzle). Also, the plot would lose timing and structure, and the switch between a more dramatic and a more light mood might not do well. Therefore, "castle" would be a new sub-location, and the states for it would be reset.