Friendly Robot Overlord

My most recent project has been a stupid little board game I've called "Siege" which really has nothing to do with seiges in the current form of the rules. I wanted to make a board game, and a computer player for it, and since I know that my computer player will be pretty sucky, I thought that by inventing a new game, I would avoid having other people's programs beat mine.

So this is what the game looks like at the moment:

Currently the rules are:

• Each turn you can move one of your guys.
• A guy can move either left/right/up/down to an empty square
• A guy can jump over another guy or castle onto a square (which can be occupied, except by someone on that guy's team)
• If a guy jumps onto a tree, then he chops it down and carries it with him.
• Once he takes the wood back to the castle, somehow the wood encourages another guy to come out of the castle on the opposite side, and the wood goes into the castle.

It sounds like it would make for an interesting game, but I'm pretty sure it isn't at the moment. Possibly it is because the AI player is a bit too sucky, but more likely because these rules lead to a boring game.

The thing which I think is a little bit interesting is in the design of the interface between the game and the AI player. Since I'm planning on changing the rules lots I decided that the computer player would know as little about the game as possible. So it is allowed to ask the following questions:

How good does this position look for the current player?

What moves can I make from this position?

What would the board look like if I made this move?

From this, I think it should be possible to write a computer player that plays really well. The main problem is the first question - defining how good a position looks is tough. At the moment, I've settled for something really simple (basically a count of the number of guys each player has, plus a bonus if they have chopped down a tree). If we had infinite computing time, then we would only need a "Which (if any) player has won in this position?" question.

But, the reason I find this a bit interesting is that there is so much the computer player doesn't know about the game (it doesn't know what the moves represent, or what the board represents or anything), and I suspect that if you tried to get a person to play the game blindfolded and only let them ask these questions, then they would be really bad at it. So then what are the things that a person needs to know about the game that give them this advantage?

For example, when I play the game, it seems like a useful thing to do to go around the side, chopping my way through the trees so I can get near the other castle. But my computer player doesn't even know that there are trees on the sides. One question which I think I might allow it to ask is "Are these two moves the same?", which seems like a stupid question, but I have a suspicion that I can use it to speed up the algorithm a bit.

The computer player does have one very effective strategy though - when you are about to win, it crashes. Which means that it maintains an undefeated record.

Next time I write, I'll hopefully have it at a stage where it is actualy fun to play, and I'll give some source code (and an updated amkel that can handle gtk+ applications).