Question

I have this project that I’m working on for a class, and I’m not looking for the answer, but maybe just a few tips since I don’t feel like I’m using true recursion. The problem involves solving the game of Hi Q or “peg solitaire” where you want the end result to be one peg remaining (it’s played with a triangular board and one space is open at the start.)

I’ve represented the board with a simple array, each index being a spot and having a value of 1 if it has a peg, and 0 if it doesn’t and also the set of valid moves with a 2 dimensional array that is 36, 3 (each move set contains 3 numbers; the peg you’re moving, the peg it hops over, and the destination index.)

So my problem is that in my recursive function, I’m using a lot of iteration to determine things like which space is open (or has a value of 0) and which move to use based on which space is open by looping through the arrays. Secondly, I don’t understand how you would then backtrack with recursion, in the event that an incorrect move was made and you wanted to take that move back in order to choose a different one.

This is what I have so far; the “a” array represents the board, the “b” array represents the moves, and the “c” array was my idea of a reminder as to which moves I used already. The functions used are helper functions that basically just loop through the arrays to find an empty space and corresponding move. :

void solveGame(int a[15], int b[36][3], int c[15][3]){

    int empSpace;
    int moveIndex;
    int count = 0;

    if(pegCount(a) < 2){

        return;

    }
    else{

        empSpace = findEmpty(a);
        moveIndex = chooseMove( a, b, empSpace);

        a[b[moveIndex][0]] = 0;
        a[b[moveIndex][1]] = 0;
        a[b[moveIndex][2]] = 1;

        c[count][0] = b[moveIndex][0];
        c[count][1] = b[moveIndex][1];
        c[count][2] = b[moveIndex][2];

            solveGame(a,b,c);

    }

}

Answer 1

Here’s the key concept to keep in your mind: you’re not actually playing the game. What you’re doing is searching for a solution – this is called a space search, because you have a space of possible boards through which you want to chart a path. To guarantee that you’ll find the right answer, you have to write code that can search all possibilities – since, as you know from finding your house keys, the right answer is always in the last place you look.

So, you can’t just make one recursive call and phone it in for the day. You’re going to have to write code which will loop over every possible move from a given board state, and make a recursive call for each one.

From the perspective of each of those calls, their parents don’t even need to exist – the current call is just examining a board which happens to be a little further into the game than the ones which came before it.

Now, when you actually run a space search, it’s likely you won’t really bother checking all those moves out – if you’re at all lucky, you’ll find the “right” move before then. So you return something from the function saying “I’ve got it, everybody above me bail out” and all your parent callers break their loops.

This pattern is what’s called depth-first search. I’m going to illustrate by creating a hypothetical simpler game. Imagine you had to choose “A”, “B”, or “C” at each move, and the game lasts three moves. First you’d explore A, then AA, then AAA, then if that’s no good you look at AAB, then AAC, then AB, then ABA, then ABB, then ABC, then AC, then ACA, ACB, ACC, B, BAA, and so forth.

That’s why it’s depth-first: you go all the way to the bottom, then backtrack as little as possible. It’s not easy to recursively implement breadth-first search, which would explore A, then B, then C, then AA, then AB, then BA, then BB, and so on until it finally got to the “complete-game” states with three moves. This requires using a queue instead of the implicit stack you get from recursion.

Now, because you’re using recursion, you’re limited in how deep you can go: you’re not generally allowed to have too many frames. So in the real world you usually make an explicit stack instead, but the heart of the algorithm doesn’t much change for a depth-first search.

There are entire textbook chapters on searching algorithms (“hill climbing”, “heuristics”, “A-star search”, and the like). Some of the algorithms are very interesting.

As for your first question, on “using a lot of iteration” – it’s not how much iteration you’ve got but how smart it is :-). That is to say, if you don’t know you have a performance issue, you probably don’t need to optimize, and even then, intuition about what takes time can be bad. Get something where you can say “it works, but…” before you worry about getting something you’re proud of to put on your metaphorical trophy wall. Come back here if you need help with topics like pruning, or building a better heuristic for an A-star search.

Good luck with your game program!