I've done all the programming (iOS, Android) for a game, only the A.I. is left.It is basically a turn-based board game (see below description) with easy rules, hard to master ;)I bet i need to use minimax, but i would like to discuss here possible solutions and strategies.

The game:- 2 players board game , turn basedSee Attachment for the playingfield

Each player has a home-base with 5 slots, inside each 3 figures (column 0 and 7)Player1 (green) is playing from left to right and Player2 (magenta) right to left

The "~" are traps, figures moving on these fields are destroyed

On each move a player can do this:

- move 1 or more figures out a base -> if there is a figure outside, that outside-figure is destroyed, doesn't matter friendly or not- move figures (not in the base) 1 field to left/right, -> 3 different moves possible: right, up-right, down-right. For top and bottom: If figure leaves the board it comes out on the other side. e.g. figure at row=0,col=2 moving up-right will land at row=4 , col=3 -> all figures must move, there is no selective move -> if a figure steps on a hostile figure, the hostile figure is destroyed -> if a figure steps into hosilte base, all hostile figures inside that slot are destroyed, the figure returns to home base (same slot on the opposite side)

A player wins, once all hostile figures are destroyed.

To be honest, I've already implemented an A.I. with minimax + alpha/beta pruning, but its not playing very well.One thing i need help is the evaluation function. I am not sure how handle it correctly.

Try to learn how to play the game decently. You should get some feel for what features of a position are desirable (e.g., is it better to concentrate your pieces or spread them around?). Then add terms to your utility function for those things.

Your description of the rules is two vague for me to give you more specific advice.

Those two statements are clearly contradictory. Can the player that starts on the left move only in those three directions and the other player only in the similar leftwards directions? I can't figure out whether your "->" are bullet points or comments on the previous statements.

For top and bottom: If figure leaves the board it comes out on the other side. e.g. figure at row=0,col=2 moving up-right will land at row=4 , col=3

OK.

-> all figures must move, there is no selective move

I still don't know what you mean by "selective move".

-> if a figure steps on a hostile figure, the hostile figure is destroyed

See, the word "figure" in English can refer to something like the number "3", so I don't know if you are talking about a piece or about a number.

-> if a figure steps into hosilte base, all hostile figures inside that slot are destroyed, the figure returns to home base (same slot on the opposite side)

Finally, this is an indication that "figure" means "piece", not "number". How is the destruction of the hostile figures different than in a non-base cell?

EDIT: By my understanding of your rules, All of player 1's pieces will be on an odd-numbered column after an odd number of moves and on an even-numbered column after an even number of moves, and the opposite for player 2. This means that player 1 is the only one whose figures can step on player 2's figures, and he just has to sweep through the board once to win. Another EDIT: Oh, I guess the "all figures must move" rule only applies to figures that are not on bases, right?

Sorry for my bad (hasty) english and explantation ^^ (lets. even don't. talk. about punctation... ;)
Well, with figures i meant pieces, each player has 15 pieces in 5 slots. If a piece moves out of a base it can land on another piece (friendly or hostile) and will destroy it.
So outside the bases there can by only one piece in a cell. If you decide to move (instead of bringing 1 or more pieces out of the base) then all your pieces must move in the SAME direction (straight, diagonal up or diagonal down).
The "3" means 3 pieces in the base. There can never be more than 1 piece in the outside field. So the piece moving into a new field always destroy the piece that have been there. Obviously, this can never happen with own pieces (because all pieces move) except by moving out of the base.

do all figures move on a players turn? this will mean a huge branching factor which is why minimax + alpha/beta pruning may not be working well (even if you have a better evaluation function - which would be essential for large branching factor games). You may have to consider implementing some pruning mechanism to reduce the lines of inquiry when delving deeper into the search. For other ideas you can reference some of the papers on the arimaa site http://arimaa.com/arimaa/ which also deals with a large branching factor game that doesn't work with monte carlo methods.

Yes, all pieces (except those in the base) move one step in the same direction. For left player e.g. the movement starts with the pieces from right-to-left, so one cann't land at own piece.Thankls for the link i will look at.

The starting function is MiniMaxAB(bool left, int maxdepth), where for "left"=true the cpu player is on the left side else right side.The evaluation of a move is done in the function ExecuteMove(...)

P.S: My Code in the code snippet doesn't seem to be shon correctly, parts are missing, is that a known bug?E.g. i can only see"GenerateMoves(&m_fields, left, movelist); for (unsigned int i=0; i bestmove.rating) { bestmove.rating = currentscore; bestmove.move = movelist[i].move; }..."

Evaluate just returns the number of pieces on the board for the given player (pieces in the base are slightly prefered).The result right now is not satisfactory. One reason could be the simple Evaluation function or maybe some bugs in my NegMax (with alpha beta) code?

How many moves do you have available in a typical position? If the answer is hundreds or thousands, you probably can't use minimax to play this decently. I would try with Monte-Carlo Tree Search (MCTS) instead. It's relatively easy to get something working (assuming random moves lead to a finished game eventually, which I guess would be the case). You may have to program some non-randomness from the beginning, if there are trivial decisions in some cases that are important to get right (in go, you shouldn't plug your own eyes).

The number of possible moves is not so high because there are always 3 moves for all outside pieces and 31 moves for bringing pieces out of the base. But since bringing too many pieces out is strategically not so good, my move generator only generates 5 moves for bases (+additional moves if hostile pieces are beneath the bases). So a typical position will have ~8 moves!

int score = eval.pirates_base * 5 + eval.pirates_outside * 4; // <-- You should be computing the number of figures for the player to move minus the number of figures for the opponent. This one-sided evaluation seems suspect.

I was doing this originally and the result was even stranger.I know that the evaluation-function is probably the main component to focus on. This might by the real challenge to do this properly for this game.

You are welcome to play the game and brainstorm with me possible ways for the evaluation function

Last night I wrote an alpha-beta searcher for this game. It's probably pretty fast (in nodes visited per second) because I used a few bit tricks to make things fast. It turns out undoing moves is kind of messy in this game, so I am copying boards, just like your code is.

It's not super friendly to interact with, because moves have to be entered in the strange internal format I devised:

Bringing figures out of the bases is encoded as 1, 2, 4, 8, 16 (top to bottom). If you want to bring more than one figure out, just use the sum.

Moving is encoded by 32 to go up, 33 to go straight, 34 to do gown.

The code is written to be reasonably portable (assumes 32-bit unsigneds; I think that's all).

"Run-Time Check Failure #2 - Stack around the variable 'moves' was corrupted"
Edit: found the problem, since there can be maximum of 34 moves the declarations of "Move moves[33];" must be changed to "Move moves[34];" !

P.S: there are 2 additional rules i idn't mention cuz of simplicity:
- once a piece moves into hostile base, that hostile base is broken, which means that any pieces moving into it will be destroyed
- a piece located directly beside a base will always move into it regardless of the move-type, e.g. if piece is on 3rd row beside the hosile base and the chossen move is "up", then the piece will go into the base on 3rd row and not , as expected, into base on 4th row.

PPS: i am not sure but bringing out too many pieces out of a base may strategically not be so good. So in my move generation i only consider moves with only one base (in your case 1,2,4,8,16) with additional base moves only if there is a hostile piece outside beside the base. This reduces the number of possible moves a lot.
I might also be wrong with this consideration ... i have to get a better player with this game.