As a developer and a lifelong chess lover, this video made me happy! Your pacing was simple, easy to understand and though the ideas were complex, you demonstrated and explained them in a neat and organized fashion. Cheers my friend - looking forward to the next one!
Damn, I felt like the video had just started, and then boom, it's already over. If you keep up the style/quality, you definitely have a future among the greats of video essays on programming/CS
@@ahmoin freya Holmer, Tsoding, Sebastian Lague, mattkc, no boilerplate, 3blue1brown, fasterthanlime And these are just the ones that came to mind first, there are many others
I love how walked through implementing the minimax algorithm - the whole explanation felt very natural in the way you explained it, and the animation adding the bits of code was lovely because that's exactly how implementation unfolds. Great work!
After watching this video, so many "informative" programming related videos seem so over the top edited or cinematic. I don't want a dramatic intro or unnecessarily upbeat music. I want THIS
I was confused by the King placement evaluation since those values would quickly have the opposite gradation as pieces are traded off. This type of value assumption based on board placement would have to be dynamically evaluated and not taken as a static truth.
This is usually solved by having two king placement tables: one for opening/middle game and one for the endgame. One then computes something like a number for "endgame-ness" (might be based on the number of pieces left) that smoothly interpolates between the two tables.
Wow! Ok Bartek, just want to say thank you. Not just for the video but for the raw inspiration. I’ve got a learning engine to build, which like your chess engine, needs to be able to strategize on how to best position a learner for further strategic positions. So the challenge is to design the engine to provide the learner with a weighted numerical map of where they might want to head to learn more things. This way a learner can try to grasp the rabbit holes they can possibly traverse, prior to traversing them and strategize as they see fit for themselves. I have to do this in a more 3d type of board, but the principle is the same. So THANK YOU for the nudge I needed to just start building this as an engine. I owe you a beer/coffee/highFive!
Wonderful video. I loved how you walked through your processes in making this. Wished it was a bit longer/more in-depth, but that's just a personal preference.
You just got another subscriber. I hope you keep it up with the channel. This video is awesome! Simply explained, to the point and clear. Makes me want to get back into my chess engine, which I abandoned at a time of too much "real work". Thanks!
While programming a computer/engine to evaluate chess, some things needs to be taken into consideration. One crucial factor is mobility of pieces. Stronger the piece is placed (depends on how many squares it controls), better is the position for that side. Also, though brute force algorithm would be required for evaluating the position, but to make the engine take lesser time, candidate moves can be programed via recursion. Surely not easy, but as a programmer, that can well be done.
This is an amazing video! I have no idea about coding, but ur animations and the style of the video made me very invested. It seems to be a very intriguing process in which we developed a need for a chess computer and how incredible and unbeatable they are now.
can you tell me how do you do your presentation( the video you showed) I need to present my project about the same topic and I don t know how to start?
I got an idea while watching this! What about caching the board positions instead of calculating them every time? But then… how do we know what to cache? Well… maybe let two computers place a few thousand games and just take their boards and cache that. Would be cool to see what that would improve in performance
Great, video, although I have a question. What about sacrificies? You said that evaluation comes from the value of the pieces and their position on the board. What if the best move is to sacrifice the queen, which after 8 moves gives a real advantage. This situation will not be filtered by the logic tree?
The evaluation function is naive, lets say. It really only tries to estimate the board and who's in the lead (if any). Sacrifices can be tricky to wrap ones head around, but it is the search algorithms job to notice this. Minimax searches all nodes in the tree exhaustively, and so won't miss finding these sacrifices. Alpha-beta can prune the tree and evaluate fewer nodes, but does so in a way that guarantees that it too won't miss advantageous nodes, even sacrifices.
Isn't it a bad idea to prune immediately, because if you have a position that sacrifices a piece to gain a better piece, or a win, that path would be pruned because of the sacrifice, if you don't search it deep enough?
Is there any benefit to be gained from representing bitboards in even more compressed ways? For example, there is only one king per player, and he can only be in one of 64 squares, so you can represent him in a 6-bit number. Same for the other king, and the queen. And all other pieces. You could use a 6 × 32 pieces = 192-bit number, or just 3 int64s instead of 12 int64s, to represent the entire board.
Unfortunately that would break the idea of using Bitboards. For example, in move generation, Bitboards can be used to create occupancy masks by ANDing all the bitboards together.
Awesome video! One question: do you take the different stages of the game into consideration when evaluating a board? For example the value of a king position changes in the endgame when the king is needed for checkmages or the queens position shouldnt really matter in the first couple of opening moves
I’m not sure what he’s implemented, but there is a technique called Tapered Eval that does this. Essentially, two different evaluations for midgame and endgames using different tables are tracked at the same time, and a computed stage is used to weight each one.
Considering the way this engine prefers the king to be in the corner, what happens when the position reaches the endgame? Will the engine insist on keeping the king in the corner, or will the concrete calculations outweigh the slight difference in evaluation for the positioning of the king? The king can often be the most powerful piece in the endgame, so it would be good to have something to account for that. Perhaps you could have it switch from king safety to king activity once material on the board is low enough
You're completely correct. If you only have one set of these adjustment tables, the king would gravitate towards the corner even in the endgame. So ideally, you would use different adjustment tables for different phases of the game. Like you say, you could switch when material gets low enough. You could also switch to slightly different middlegame tables after a certain amount of moves. Thanks for pointing this out!
You are correct, usually, there are two tables for each piece. One for the Middlegame and one for the Endgame. The less pieces there are on the board, the higher the endgame weight is
The point is not to maximize chess strength but have it play like a human, ie make sometimes blunders and mistakes, and overall don’t play like a machine. If it sees a checkmate it should not fail obviously.
Wait, but the branch with -4 is not neccessarily worse than the one with -2, no? It could've been a sacrifice of a piece which only turns out to be good a couple moves later
If that's the case and that sacrifice leads to something better than -4, say -1, then black won't allow it and choose the move leading to -4. Therefore, there is no need to calculate the other nodes. Hope that makes sense :)
