Answers.Body: <p>This exact bot has already been created. On lichess, <a href="https://lichess.org/@/simpleEval" rel="noreferrer">it is simpleEval</a>. You could potentially use it to debug a lot of your issues by seeing what this engine does against you in a given position.</p>
  <p>Having played this bot several times, no that move Nxf2 would probably be incorrect. This seems like a bug on your end. Assuming you have enough depth in the bot's calculation, that type of a blunder would be the last possible way it blunders. Specifically, your bot should make incredibly terrible moves from a positional standpoint as long as it doesn't see any tactics that win material in the upcoming moves. I've seen &quot;+10&quot; positions where technically the bot is up material. This is much more likely to be the bot's response to a specific situation than sacrificing anything unless it finds a forced win of material back in the near term.</p>
  <p>Sorry that you might have to revisit some code you thought was already working.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-06-28T22:55:57.000Z
Answers.Text: Hmm ok, no problem. I'll look into some of what you said. Thanks!
Answers.UserDisplayName: Chris
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-06-29T19:00:54.900Z
Answers.Text: @NoseKnowsAll I'm not convinced that simpleEval is the same thing at all. The engine is way too advanced to be looking at the material count 3 moves ahead and nothing else. My guess is the evaluation itself uses material count only (none of the other factors in Stockfish's evaluation) but is otherwise (pruning etc) full-fledged Stockfish. A real engine which looks (even 100) moves ahead purely materially should not, for example, have by default anything to avoid even one-move checkmate.
Answers.UserDisplayName: Mobeus Zoom
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-06-29T19:39:00.013Z
Answers.Text: @MobeusZoom I would expect an engine that looks only at material to evaluate the King as some absurdly large amount of material, i.e. +100.  That would allow it to find checkmate without violating its "material count only" rule.  (The alternative of evaluating the King as worth 0 seems rather silly to me.)
Answers.UserDisplayName: Brilliand
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-06-29T21:28:21.223Z
Answers.Text: @Brilliand That isn't actually how engines like Stockfish treat king safety, however; they have separate components for it. And simpleEval seems to me like a pretty involved fork of Stockfish to just be looking at material count n moves deep. It's been identified here that simpleEval has some odd behaviour: https://chess.stackexchange.com/questions/34933/why-doesnt-simpleevals-eval-change-in-multiples-of-1. (With a claim there may be a bug: there is no bug - simpleEval is a relatively *strong* agent and the reason is likely inclusion of more than it says on the tin.)
Answers.UserDisplayName: Mobeus Zoom
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-06-29T23:09:51.750Z
Answers.Text: @Brilliand Well that's how some engines operate, particularly ones that use king-capture to filter out pseudo-legal moves such as Sunfish (written in Python). Other engines however, including mine, simply detect when a mate has occurred in the minimax function (1. The king is in check, and 2. has no legal moves) and return a relatively infinite value, so that the engine is always looking for mate over say, capturing an enemy queen.
Answers.UserDisplayName: Chris
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-26T01:45:10.913Z
Answers.Text: Anyone went the other way?  To make it completely blind to material gains?  If it might work somehow, and just for the fun of what it could find as desirable leafs with the rest of its optimized parameters in context of the simple eval (or when it was called classical, only the material overlapping features turned off.  I did not think this through, though.  if might wreak havoc with the notion of quiescence.  Although it seems to me that captures can exist without evaluation.   Not a developer, but tried once with someone versed in code digging, to get some understanding.
Answers.UserDisplayName: dbdb
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-06-28T22:09:00.227Z
Answers.LastActivityDate: 2021-06-28T22:09:00.227Z
Answers.UserDisplayName: NoseKnowsAll
Answers.Body: <p>It's always a question at what depth you stop. Eg.g, with 5 plys, your engine might be happy with</p>
  <ol>
  <li>... Nxf2   <strong>one pawn ahead</strong></li>
  <li>Bxf2 Bxf2  <strong>still one pawn ahead</strong></li>
  <li>Kxf2 Qxf3+ <strong>still one pawn ahead and even check!</strong></li>
  </ol>
  <p>and not see 4. Kxf3. Something like this chould be prevented e.g. by selectively expanding until no capture / no check is made. Even then, the evaluation might stop with the last move leaving your queen attacked.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-06-29T23:12:24.720Z
Answers.Text: Right. @adrasthea, so I don't really think search depth is the issue. I recently scrapped what I had and just decided to write things from scratch, and I've gotten good results. Currently the engine is playing fairly solid chess, and doesn't make stupid blunders anymore (even more exciting it seems to know when to make tactical *sacrifices* now) and so I think the bug came from how I used my transposition table, so I'm going to be adding that feature back in very carefully.
Answers.UserDisplayName: Chris
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-06-30T00:16:40.983Z
Answers.Text: @ChristianDean: If you have not already done so, you may wish to create a suite of unit tests which run your evaluation function (and *just* the evaluation function) against a series of fixed positions. That way, if your evaluation function suddenly changes its opinion of one of those positions, you will be able to look at the change and judge for yourself whether it is intentional.
Answers.UserDisplayName: Kevin
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-06-29T13:19:09.213Z
Answers.LastActivityDate: 2021-06-29T13:19:09.213Z
Answers.UserDisplayName: Hagen von Eitzen
Body: <p>For the past couple of weeks, I've been making a chess engine, and right now I'm working on creating its search and evaluation phases.</p>
  <p>To start off with, I made the evaluation phase a simple count of material so I could focus on the search phase, and then I would come back to create a more nuanced evaluation function. So right now, I have negamax, with alpha-beta pruning, iterative deepening, and quiescence searching implemented, which I'm pretty happy about.</p>
  <p>But the problem is sometimes my engine still decides to willing blunder away pieces. <a href="https://lichess.org/analysis/r1b1k2r/pppp1ppp/2n5/1Bb4q/Q1N1P1n1/2P2NB1/P4PPP/R4KR1_b_kq_-_4_14#27" rel="noreferrer">Here's</a> an example from a recent game, where the computer is black and it's black to move. For some reason, my engine decided that Ng4xf2 was the best move here. And then once it lost the knight for a pawn, it just went on as if it had made an equal trade.</p>
  <p>Can this kind of blundering by a chess engine be explained away by a very naive evaluation phase, like my engine currently has? If it can be then, then of course the solution would be to create a much stronger evaluation function, which I'll do.
  But if it can't - and I must admit I don't see how it could - then I'm afraid there's a problem with the search phase, which would be a disappointing, but not impossible, setback.</p>
  <p>I found <a href="https://stackoverflow.com/questions/33438026/alpha-beta-chess-engine-search-algorithm-not-making-proper-moves">this</a> question, which seems to give an answer, but the reason why I still don't see how the evaluation function could be the culprit is that at the very least, in my mind, an evaluation phase based purely on material gain shouldn't make basic blunders where it loses material literally on the next move (especially with quiescence searching!)</p>
  <p>Can anyone with experience in this area of AI programming offer any insight here? Also, let know if you need to see any code and I'll be more than happy to provide it.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-06-29T08:59:22.590Z
Comments.Text: I'm not 100% sure, but suspect that an eval function only based on material can be tricky. Just to get sure you're on the safe side, I'd think of adding piece square tables. They're easy to implement, and suddenly your engine will play much better.
Comments.UserDisplayName: emdio
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-06-29T14:47:12.120Z
Comments.Text: Hmm maybe so @emdio, but I'll double-check my search code first I suppose.
Comments.UserDisplayName: Chris
Tags: <engines><programming><computer-chess><minimax>
Title: Is it normal for a chess engine to blunder material if its evaluation is only based on naive material evaluation?
ThreadText: # Is it normal for a chess engine to blunder material if its evaluation is only based on naive material evaluation?
  
  (Asked by: username_0 on 2021-06-28)
  
  For the past couple of weeks, I've been making a chess engine, and right now I'm working on creating its search and evaluation phases.
  
  To start off with, I made the evaluation phase a simple count of material so I could focus on the search phase, and then I would come back to create a more nuanced evaluation function. So right now, I have negamax, with alpha-beta pruning, iterative deepening, and quiescence searching implemented, which I'm pretty happy about.
  
  But the problem is sometimes my engine still decides to willing blunder away pieces. [Here's](https://lichess.org/analysis/r1b1k2r/pppp1ppp/2n5/1Bb4q/Q1N1P1n1/2P2NB1/P4PPP/R4KR1_b_kq_-_4_14#27) an example from a recent game, where the computer is black and it's black to move. For some reason, my engine decided that Ng4xf2 was the best move here. And then once it lost the knight for a pawn, it just went on as if it had made an equal trade.
  
  Can this kind of blundering by a chess engine be explained away by a very naive evaluation phase, like my engine currently has? If it can be then, then of course the solution would be to create a much stronger evaluation function, which I'll do.
  But if it can't - and I must admit I don't see how it could - then I'm afraid there's a problem with the search phase, which would be a disappointing, but not impossible, setback.
  
  I found [this](https://stackoverflow.com/questions/33438026/alpha-beta-chess-engine-search-algorithm-not-making-proper-moves) question, which seems to give an answer, but the reason why I still don't see how the evaluation function could be the culprit is that at the very least, in my mind, an evaluation phase based purely on material gain shouldn't make basic blunders where it loses material literally on the next move (especially with quiescence searching!)
  
  Can anyone with experience in this area of AI programming offer any insight here? Also, let know if you need to see any code and I'll be more than happy to provide it.
  
  **Tags:** engines, programming, computer-chess, minimax
  
  > **Comments:**
  > **username_1**: I'm not 100% sure, but suspect that an eval function only based on material can be tricky. Just to get sure you're on the safe side, I'd think of adding piece square tables. They're easy to implement, and suddenly your engine will play much better.  
  > **username_0**: Hmm maybe so @username_1, but I'll double-check my search code first I suppose.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_6 on 2021-06-29. Score: 7 | Accepted answer
  
  It's always a question at what depth you stop. Eg.g, with 5 plys, your engine might be happy with
  
  1. ... Nxf2 **one pawn ahead**
  2. Bxf2 Bxf2 **still one pawn ahead**
  3. Kxf2 Qxf3+ **still one pawn ahead and even check!**
  
  and not see 4. Kxf3. Something like this chould be prevented e.g. by selectively expanding until no capture / no check is made. Even then, the evaluation might stop with the last move leaving your queen attacked.
  
  > **Comments:**
  > **username_0**: Right. @adrasthea, so I don't really think search depth is the issue. I recently scrapped what I had and just decided to write things from scratch, and I've gotten good results. Currently the engine is playing fairly solid chess, and doesn't make stupid blunders anymore (even more exciting it seems to know when to make tactical *sacrifices* now) and so I think the bug came from how I used my transposition table, so I'm going to be adding that feature back in very carefully.  
  > **username_7**: @ChristianDean: If you have not already done so, you may wish to create a suite of unit tests which run your evaluation function (and *just* the evaluation function) against a series of fixed positions. That way, if your evaluation function suddenly changes its opinion of one of those positions, you will be able to look at the change and judge for yourself whether it is intentional.  
  
  ---
  
  ### Answer by username_2 on 2021-06-28. Score: 13
  
  This exact bot has already been created. On lichess, [it is simpleEval](https://lichess.org/@/simpleEval). You could potentially use it to debug a lot of your issues by seeing what this engine does against you in a given position.
  
  Having played this bot several times, no that move Nxf2 would probably be incorrect. This seems like a bug on your end. Assuming you have enough depth in the bot's calculation, that type of a blunder would be the last possible way it blunders. Specifically, your bot should make incredibly terrible moves from a positional standpoint as long as it doesn't see any tactics that win material in the upcoming moves. I've seen "+10" positions where technically the bot is up material. This is much more likely to be the bot's response to a specific situation than sacrificing anything unless it finds a forced win of material back in the near term.
  
  Sorry that you might have to revisit some code you thought was already working.
  
  > **Comments:**
  > **username_0**: Hmm ok, no problem. I'll look into some of what you said. Thanks!  
  > **username_3**: @username_2 I'm not convinced that simpleEval is the same thing at all. The engine is way too advanced to be looking at the material count 3 moves ahead and nothing else. My guess is the evaluation itself uses material count only (none of the other factors in Stockfish's evaluation) but is otherwise (pruning etc) full-fledged Stockfish. A real engine which looks (even 100) moves ahead purely materially should not, for example, have by default anything to avoid even one-move checkmate.  
  > **username_4**: @username_3 I would expect an engine that looks only at material to evaluate the King as some absurdly large amount of material, i.e. +100.  That would allow it to find checkmate without violating its "material count only" rule.  (The alternative of evaluating the King as worth 0 seems rather silly to me.)  
  > **username_3**: @username_4 That isn't actually how engines like Stockfish treat king safety, however; they have separate components for it. And simpleEval seems to me like a pretty involved fork of Stockfish to just be looking at material count n moves deep. It's been identified here that simpleEval has some odd behaviour: https://chess.stackexchange.com/questions/34933/why-doesnt-simpleevals-eval-change-in-multiples-of-1. (With a claim there may be a bug: there is no bug - simpleEval is a relatively *strong* agent and the reason is likely inclusion of more than it says on the tin.)  
  > **username_0**: @username_4 Well that's how some engines operate, particularly ones that use king-capture to filter out pseudo-legal moves such as Sunfish (written in Python). Other engines however, including mine, simply detect when a mate has occurred in the minimax function (1. The king is in check, and 2. has no legal moves) and return a relatively infinite value, so that the engine is always looking for mate over say, capturing an enemy queen.  
  > **username_5**: Anyone went the other way?  To make it completely blind to material gains?  If it might work somehow, and just for the fun of what it could find as desirable leafs with the rest of its optimized parameters in context of the simple eval (or when it was called classical, only the material overlapping features turned off.  I did not think this through, though.  if might wreak havoc with the notion of quiescence.  Although it seems to me that captures can exist without evaluation.   Not a developer, but tried once with someone versed in code digging, to get some understanding.  
  
  ---
  
  