New Engine Development: Bullet

[algerbrex]

Hi Everyone,

It's been a while since I've done some chess programming, and even longer since I've posted here.

I'm happy to say over the past few weeks I've been inspired to jump back into the chess programming scene, and I've been working on the development of a new engine I've decided to name Bullet.

Part of the inspiration for this name was a bit of a tongue-in-cheek reference to the fact that I wanted to try to make an engine that was faster/more efficent than Blunder in certain aspects. But also because I have a serious addiction to playing bullet chess on Lichess (over 5k+ games on Lichess in the 1+0 format).

Development has come along well, and I'm pretty happy with the design of the codebase.

I decided for this go around, I would use a copy/make approach. I was worried this design would unacceptably slow, but I'm very happy about the movegen and copy/make speed. Compared to Blunder, Bullet's perft results are a decent bit faster, and on my machine (with an i3 processor and 8gb of ram) it's perft speed is comparable to Rustic Alpha 1's (I made the comparison after I added incremental Zobrist hash updating to Bullet's DoMove function to make the comparison more fair).

This evening I wrapped up the the search, evaluation, and UCI interface code for Bullet. Both the search and evaluation are purposely bare bones at the moment. The feature list is the same as Rustic Alpha 1, with the addition of ordering moves from the principal variation of shallower searches first.

From very preliminary testing, Bullet's current Elo is ~1600, but there's no official release at the moment. Right now, for experimentation/testing purposes, Bullet's PSQT are copied from Rustic. But probably my biggest goal with this new engine is originality and trying new things. So I don't plan on making the first official release of Bullet until I write a gradient descent tuner, and use the tuner with data generated entirely from self-play games from Bullet.

Because of my goal of novelty, I've also played around a bit with MCTS + negamax to see what the results would be. It was fun, but it would definitely take a lot of work for me to combine them in any meaningful way. So I've put that branch to the side for the moment.

My main focus going forward will be the gradient descent tuner, and I've been thinking about how to accomplish my goal of using no outside data to tune. I'll have to find the exact post, but when discussing NNUE training, one user proposed the idea of starting with labeled positions closer to the end of the game, since intuitively the placement of the pieces should correlate more with the outcome of the game.

I found this idea intriguing and wonder if it could be helpful in pursuit of training Bullet without using any external data. So I'll probably play around with it after I get the tuner working.

Hopefully the first official release will be before the new year, or early next year. And I'm not sure ultimately what direction I'll take Bullet in, but I'm interested in the journey!

[Ciekce]

you could consider trying the extremely popular NNUE trainer bullet https://github.com/jw1912/bullet /s

[algerbrex]

you could consider trying the extremely popular NNUE trainer bullet https://github.com/jw1912/bullet /s

Thanks, looks like an interesting project. NNUE will definitely be something that comes further down the line honestly. And when it does, I'd like to write all of the training code myself. This isn't the most efficient way to do things of course, but I write chess engines because I find the hobby fun.

[op12no2]

But probably my biggest goal with this new engine is originality...

...I've been thinking about how to accomplish my goal of using no outside data to tune.

Just a thought, you could go 'zero' and use a random init of the PSTs to boot from. NNUEs have been booted like, this so presumably PSTs can be too by including the main material values in the PSTs.

[op12no2]

sorry, I meant, presumably a material + PST eval can be too by including the material in the PSTs.

[JacquesRW]

you could consider trying the extremely popular NNUE trainer bullet https://github.com/jw1912/bullet /s

Thanks, looks like an interesting project. NNUE will definitely be something that comes further down the line honestly. And when it does, I'd like to write all of the training code myself. This isn't the most efficient way to do things of course, but I write chess engines because I find the hobby fun.

I think the point was more to rethink using a name that is already ostensibly taken in the chess programming community (to avoid confusion).

[algerbrex]

you could consider trying the extremely popular NNUE trainer bullet https://github.com/jw1912/bullet /s

Thanks, looks like an interesting project. NNUE will definitely be something that comes further down the line honestly. And when it does, I'd like to write all of the training code myself. This isn't the most efficient way to do things of course, but I write chess engines because I find the hobby fun.

I think the point was more to rethink using a name that is already ostensibly taken in the chess programming community (to avoid confusion).

Not how I read that comment, but sure, fair point. I'm not hard set on the name, so I wouldn't mind renaming it to something more unique.

[algerbrex]

But probably my biggest goal with this new engine is originality...

...I've been thinking about how to accomplish my goal of using no outside data to tune.

Just a thought, you could go 'zero' and use a random init of the PSTs to boot from. NNUEs have been booted like, this so presumably PSTs can be too by including the main material values in the PSTs.

I had the same thought too, so I'm adding to my tuner the ability to generate reasonably random values for the various material and PSQT values. Hopefully useful data can be derived from this approach.