Chapters Part 2
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.
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.