Hi all, this is my fiirst post here, nice to meet you all I've been working on my engine for over a year now it lives at https://github.com/phaul/chess-2 I run a lichess-bot on my laptop, so it's on and off, but give it a go on lichess if you like. It's actively worked on so its behaviour might change over time.
Tech details:
written in C from scratch
bitboard rep
negascout / PV search
killer moves
no transpos cache as of now
main heuristics is PV > killer > checks+captures > other, ordered within category by static exchange eval / psqt gain-loss
Lazy move generation is definitely worth the effort (it was for my engine), but I would guess that you would get much more bang for your buck by implementing a transposition table. I'm working on optimization now, but I also want to investigate lazy evaluation. Good luck. One of these days I need to look into lichess.
I tried transpos tables once, in fact I still have the branch hanging around, although needs a rebase. From what I remember I had problems and it didnt seem to give much, but probably I just messed it up slightly. as far as i remember I wasn't sure about what depth to probe / insert move into in case of late move reduction It would make sense to insert at depth x when the reduced depth is x but then, there is no guarantie that the score at the next recursive call is not going to be at reduced depth so the assumption of it being x-1 breaks . not sure. This doesn't hurt me with killer moves somehow, probably because that's just affect move order, but with transpos I am returning scores - and maybe incorrect scores.
I've been working on my engine for over a year now it lives at https://github.com/phaul/chess-2 I run a lichess-bot on my laptop, so it's on and off, but give it a go on lichess if you like. It's actively worked on so its behaviour might change over time.