user27860: 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 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 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.

user4149: It's always a question at what depth you stop. Eg.g, with 5 plys, your engine might be happy with

... Nxf2   one pawn ahead
Bxf2 Bxf2  still one pawn ahead
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.

user3884: This exact bot has already been created. On lichess, it is 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.

27860: <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>
 4149: <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>
 3884: <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>
