This code works, for 2-D. When you get to three dimensions (if you do plan to) it becomes possible for the opponent to threaten win just to distract you. You would at that point want to decide what squares are more beneficial without tying yourself down to one branch of a search tree. The minimax algorithm, while useful for 2-D, has some significant fail cases for 3-D (most especially with odd sized boards, eg 3x3x3 or 5x5x5). Clipping the search space in 3-D can be detrimental to your algorithms health.

As for checking for traps, the best way i came up with (probably not the best way) was to assign values to the moves which corresponded to whether squares in the same line were occupied or not. Then a trap would be more apparent because two different squares should have the same values. It took a lot of work to determine what a (valid) 3-D line was and how many pieces were in it. This method also has some serious drawbacks, in fact, the same ones that plague minimax (as its a derivation).

In the end you will have to assign a value to a move, either qualitatively or quantitatively, and the accuracy of that value to judge a good move from a bad one will probably decide whether your algorithm works or not. It took me quite a few rewrites to come up with the ok scheme that i did. Sit down at the drawing board and think about how you want to assign values to moves. That's the most promising thing i can tell you.

Hope This Helps,
jynx