In a text based adventure game, how do I prevent long confusing conditional code?

Question

I am creating a text-based, choose your own adventure game in C++.

In this game, there will be lots of possibilities on where you choose to go, what you choose to do etc.

My question is, how do I prevent this from becoming extremely confusing.

Example:

Lets say at one point in the game you can be asked whether to go to the forest or the desert. If you choose desert, thats a COMPLETELY different story line from the forest.

So how would I prevent from my code looking like this.

if (player goes to the desert)advice? { 
    /*Whole story line of the desert*/
else if (player goes to the forest) {
    /*Whole story line of the forest */

Inside of these story lines there would be more conditionals like that, and more elaborate story lines, so is there any way that I can write the code for one story line in a separate file, then just run that file for that conditional? Anyways I can do that separately instead of writing everything out inside of the conditionals? If I did that the code would quickly become long and confusing to look at/edit.

I was thinking about doing headers and making functions inside of the headers that write out the story line, so I would just have to type out the function, but if I did that, then I couldnt access the global variables in the game such as playerName or playerRace etc.

Any and all suggestions are appreciated. I'm new to C++ so please forgive me if I've missed something painstakingly obvious.

Answer 1

I am going to expand a little on Trevor Hickey state machines proposition, because it is a great idea.

First you need to realize that your story lines can be modeled using a good old graph

1. The independent stories are the element of your game which you consider whole and non dissociable. For instance there is the DesertStory, the ForestStory. They are the nodes, vertices. You should uniquely identify a story, by its name for instance
2. The relationship between the stories are the edges. These edges need to be serializable, which mean being able to be represented both as objects and in some persistent format, and that you can load and save between. Because You want to customize your game, you may want to allow the persistent format to be text based so they can be edited manually and loaded at the start of the game.
3. Now the state machine come from the fact that the transition between a story to another is conditional.

In programming term it may means : a virtual Story class

struct Story 
{
     virtual std::string name() = 0;
     virtual int play() = 0;
};

A Story Arc, which link between stories. It need a condition to trigger, which can be what the last story returned

struct StoryConnection
{
    std::string nameStorySource;
    std::string nameStoryDestination;
    int condition;
};

With this you can write individual stories on one side, and then write story arcs separately. You can also adapt and modify the logic of your game by the modifying the story arcs. You can have multiple game play possible, each one being just a group of StoryConnections.

The logic is going to be simple as:

Story* s = new InitStateStory; 
while(!endOfGame(s))
{
      int decision = s.play();
      StoryConnection conn = getConnection(s.name(), decision);
      Story* nextstory = creatNextStory(conn.nameStoryDestination);
      delete s;
      s = nextstory;
}