user12906: I've built a chess game engine using Minimax and when I play AI against the AI, everything goes fine(for sometime) until both the AI players make the same set of moves again and again. 
Observe the moves made by the AI players in the move-log(Right panel).
How do I eliminate this scenario?

user825: You may want to consider third-repetition in your search. Stockfish does that:
https://github.com/official-stockfish/Stockfish/blob/30c583204f97da2c67b5042c30327013e70ae209/src/search.cpp
    // Step 2. Check for aborted search and immediate draw
    if (Signals.stop.load(std::memory_order_relaxed) || pos.is_draw(ss->ply) || ss->ply >= MAX_PLY)
        return ss->ply >= MAX_PLY && !inCheck ? evaluate(pos)
                                              : DrawValue[pos.side_to_move()];

https://github.com/official-stockfish/Stockfish/blob/master/src/position.cpp
/// Position::is_draw() tests whether the position is drawn by 50-move rule
/// or by repetition. It does not detect stalemates.

bool Position::is_draw(int ply) const {

Implementing third-repetition is important, otherwise your engine might waste moves and think it can still keep the advantage after some meaningless checks.
EDITED
You should implement the check, otherwise your engine doesn't know the move it tries to make is just simple repetition draw. You will need to program the knowledge. Someone else had the problem  like you:

http://talkchess.com/forum/viewtopic.php?t=59322&highlight=move+repetitions


user6885: Unfortunately, the only right answer to "How do I eliminate this scenario" is "fix your algorithm."  Yes, you could implement the 3-fold repetition rule, but you should also figure out what it tells you about your algorithm.
This sort of repetition happens when there is an oscillating pattern that arises in your scoring.  Think of it like rock paper scissors.  White makes move to try to achieve a rock position, so black tries to make a counter-move that turns it into a paper position.  Then white tries to create a scissors position and black replies by creating a rock position.
The only way to fix this is to look at your algorithm, and make the algorithm better.  My advice is to put your chess program into a debug mode and have it dump out an analysis of what it is "thinking" with each move.  Look at the factors which lead up to your final score, and understand how they're acting.
Once you understand why the algorithm is doing what it's doing, you can fix it.  Look at the game and decide what move you'd rather see them do, and why you like that move.  See if you can add additional scoring which encourages the type of play you want to see.
One thing in particular I've seen that can cause this sort of behavior is a discontinuity on the horizon.  If your scoring stops at your ply limit, and that position looks good from black's perspective, looking one ply further may show a good position for white instead!  This, of course, will always happen in real life, but you can try to minimize how often it happens by doing a better job of scoring each position.
If all else fails, a little randomness can help nudge the game along.  One mode I implemented when I had to write one of these programs was a variable depth algorithm.  Sometimes it would look at 100,000 positions before making a decision, other times it might make 200,000.  That decreased the probability that I would run into a simple issue just past my horizon, because my horizon kept moving.  Instead, I might blunder into the bad move, but at least the game moved forward!

12906: <p>I've built a chess game engine using Minimax and when I play AI against the AI, everything goes fine(for sometime) until both the AI players make the same set of moves again and again. </p>

<p>Observe the moves made by the AI players in the move-log(Right panel).<a href="https://i.stack.imgur.com/k34ry.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/k34ry.png" alt="AI vs AI repeats moves"></a></p>

<p>How do I eliminate this scenario?</p>
 825: <p>You may want to consider third-repetition in your search. Stockfish does that:</p>

<p><a href="https://github.com/official-stockfish/Stockfish/blob/30c583204f97da2c67b5042c30327013e70ae209/src/search.cpp" rel="nofollow noreferrer">https://github.com/official-stockfish/Stockfish/blob/30c583204f97da2c67b5042c30327013e70ae209/src/search.cpp</a></p>

<pre><code>    // Step 2. Check for aborted search and immediate draw
    if (Signals.stop.load(std::memory_order_relaxed) || pos.is_draw(ss-&gt;ply) || ss-&gt;ply &gt;= MAX_PLY)
        return ss-&gt;ply &gt;= MAX_PLY &amp;&amp; !inCheck ? evaluate(pos)
                                              : DrawValue[pos.side_to_move()];
</code></pre>

<p><a href="https://github.com/official-stockfish/Stockfish/blob/master/src/position.cpp" rel="nofollow noreferrer">https://github.com/official-stockfish/Stockfish/blob/master/src/position.cpp</a></p>

<pre><code>/// Position::is_draw() tests whether the position is drawn by 50-move rule
/// or by repetition. It does not detect stalemates.

bool Position::is_draw(int ply) const {
</code></pre>

<p>Implementing third-repetition is important, otherwise your engine might waste moves and think it can still keep the advantage after some meaningless checks.</p>

<p><strong>EDITED</strong></p>

<p>You should implement the check, otherwise your engine doesn't know the move it tries to make is just simple repetition draw. You will need to program the knowledge. Someone else had the problem  like you:</p>

<blockquote>
  <p><a href="http://talkchess.com/forum/viewtopic.php?t=59322&amp;highlight=move+repetitions" rel="nofollow noreferrer">http://talkchess.com/forum/viewtopic.php?t=59322&amp;highlight=move+repetitions</a></p>
</blockquote>
 6885: <p>Unfortunately, the only right answer to "How do I eliminate this scenario" is "fix your algorithm."  Yes, you could implement the 3-fold repetition rule, but you should also figure out what it tells you about your algorithm.</p>

<p>This sort of repetition happens when there is an oscillating pattern that arises in your scoring.  Think of it like rock paper scissors.  White makes move to try to achieve a rock position, so black tries to make a counter-move that turns it into a paper position.  Then white tries to create a scissors position and black replies by creating a rock position.</p>

<p>The only way to fix this is to look at your algorithm, and make the algorithm better.  My advice is to put your chess program into a debug mode and have it dump out an analysis of what it is "thinking" with each move.  Look at the factors which lead up to your final score, and understand how they're acting.</p>

<p>Once you understand why the algorithm is doing what it's doing, you can fix it.  Look at the game and decide what move you'd rather see them do, and why you like that move.  See if you can add additional scoring which encourages the type of play you want to see.</p>

<p>One thing in particular I've seen that can cause this sort of behavior is a discontinuity on the horizon.  If your scoring stops at your ply limit, and that position looks good from black's perspective, looking one ply further may show a good position for white instead!  This, of course, will always happen in real life, but you can try to minimize how often it happens by doing a better job of scoring each position.</p>

<p>If all else fails, a little randomness can help nudge the game along.  One mode I implemented when I had to write one of these programs was a variable depth algorithm.  Sometimes it would look at 100,000 positions before making a decision, other times it might make 200,000.  That decreased the probability that I would run into a simple issue just past my horizon, because my horizon kept moving.  Instead, I might blunder into the bad move, but at least the game moved forward!</p>
