Switch statement vs. If Statement in "Choose Your Own Adventure"

Question

How could I explain how and when to use an if-statement vs. a switch statement in a "Choose Your Own Adventure" game?

The game is basically structured that if you put in a certain answer, it changes the flow or direction of the game. I've usually used if-statements with functions, but is that the most efficient and simple way to teach?

Thanks!

Edit: Wow, thank you SO much for so many great answers!! Just one last note: if you were a 13-year-old trying to grasp this concept without any previous knowledge of programming, how would you try to go about to understand it? Seriously, thanks so much for the help!!

Answer 1

There are (give or take) five different solutions to "I've received this input, what do I do now".

1. If/else if/else ... chain. Advantage is that you can use any expression that can be made into true or false. Disadvantage is that it can get pretty messy when you have a long chain of them.
2. Switch - great for "there are lots of almost similar things to do". Drawback is that the case labels have to be integer values (or char values, but not strings, floating point values, etc).
3. A table which makes the long if/else into a much simpler if(table[index].something) ...
4. Function pointers - sort of a table pointer variant - store a pointer to the function that does whatever you want to do if you move in that direction.
5. Objects using virtual functions. Again, a variant on the table solution, but instead of storing function pointers, we store objects with some member function that we can use to "do whatever you need to do".

The correct solution in this case is perhaps a combination/variation on one of the latter 3 - in my opinion, at least.

Answer 2

Use a switch statement when you're identifying cases of numeric or ordinal values.

switch (number)
{
    case 1: DoSomething();
        break;

    case 2: DoSomethingElse();
        break;
}

Use if, elseif and else for more complex conditions, like numeric ranges.

if (number > 0 && number <= 100)
{
   DoSomething();
}
else if (number > 100 && number <= 1000)
{
   DoSomethingElse()
}
else
{
   NotifyOutOfRange();
}

Answer 3

In this very scenario you've described an if statement is pretty much your best option since the code needs to compare an answer provided by the user with some pre-defined options.

Those options will most likely be strings. switch statements in C++ cannot work on strings. Thus a series of if statements will probably be simpler.

A switch statement can be used when the answer only consists of a number or a single character.

For example, the code piece for the game's main menu could look like this:

Console output:

Please select an action:
1) Start a new game.
2) Go to options screen.
3) Quit game.

code:

int userChoice = getUserInput();

switch(userChoice){
case START_NEW_GAME: //1
    startGame(); break;
case OPTIONS: //2
    showOptions(); break;
case QUIT: //3
    exit(); break;
}

Answer 4

switch statements are for speed. That's why they are only numeric. The compiler will attempt to make a lookup table for non-sparse (i.e. contiguous) value ranges which can improve performance significantly when the code is constantly being executed. This is because it only needs to do 1 comparison for a contiguous range to determine what piece of code to execute.

switch statements potentially can cause hard to find bugs since at the end of each case you need to specify a break or the execution will fall through to the next case.

if/else if/else statements are for more general use. They are in general, slower than an equivalent switch statement if there are many comparisons against the same value. However if that if chain of statements is not executed a lot and the chain is not that long, the performance improvement is negligible.

For more general usage, if is the way to go. In a CYOAG, you will not be needing speed. The slowest part of the game is the user.

To explain this to a 13 year old:

If you think that you will be executing a comparison on a single integer (whole number) value over 1,000,000 or more times all at once and you need it to be done as quickly as possible, use a switch statement. Otherwise, doesn't matter. Just be careful when using a switch, because if you don't have a break at the end of each case you will be scratching you head trying to figure out what just happend? when two or more cases are executed.

Answer 5

You can use switch statements if you have too many "else if" statements :)

More seriously, if a player has many different choices (like picking from 26 different options (a-z), then switch is the way to go).

Answer 6

Well, you can't really put strings into switch/case. That leaves you with if. or you'll need to implement parser that reads strings, maps them to some enum type, and then uses said enum within switch/case.

However a better (more extensible) way would be to use map of function callbacks.

Something like this:

#include <map>
#include <string>
#include <iostream>

typedef void(*ActionCallback)();
typedef std::map<std::string, ActionCallback> ActionMap;
static bool running = true;

void leftAction(){
    std::cout << "\"left\" entered" << std::endl;
}

void rightAction(){
    std::cout << "\"right\" entered" << std::endl;
}

void quitAction(){
    std::cout << "game terminated" << std::endl;
    running = false;
}

int main(int argc, char** argv){
    ActionMap actionMap;
    actionMap["left"] = leftAction;
    actionMap["right"] = leftAction;
    actionMap["quit"] = quitAction;

    while(running){
        std::string command;
        std::cout << "enter command. Enter \"quit\" to close" << std::endl;
        std::cin >> command;

        ActionMap::iterator found = actionMap.find(command);
        if (found == actionMap.end())
            std::cout << "unknown command " << command << std::endl;
        else
            (*found->second)();
    }
    return 0;
}

The big advantage of this approach is that you can change commands at runtime. Add new commands, remove them, etc. You could even go a bit further and add lisp/python/lua binding and make it even more extensible.