Today, Rustic gained basic time management:
Code: Select all
available = (base_time / moves_to_go) + increment - overhead.
if elapsed >= available { stop }
If "moves_to_go" is not supplied (= all base time for the entire game), Rustic for now assumes the game will be 80 moves long, and it'll calculate "movestogo" accordingly. Many games in my early tests are between 50 and 100 moves with an average of about 75, so I thought 80 would be a good guess for a first time management version.
In the coming week I'll create an engine pool with engines between 1500 - 1800 Elo, as I suspect Rustic to hover around 1650 Elo on CCRL blitz. (It obtains around 50% against "Pulse 1.7.2", which has a rating of 1650. It obtains -70 Elo against ShallowBlue, which has a rating of 1720.)
It still has no features besides MMV-LVA and PSQT's, but it does seem to be very fast compared to other engines in its Elo range. I add one node just before the move loop in alpha/beta and qsearch (so I only add a node when I'm actually going to do some work in the node). Rustic calculates at 4500 kNodes/sec, where other engines I'm testing against hover somewhere between 800 kNodes and 1500 kNodes; they make up for it with much more features and a much better evaluation though.
The only UCI features it's missing now are ones that are minor (such as Send Mate to GUI, and "go mate x", which I've never used), ones that I haven't needed yet (setoption), or never going to implement (go searchmoves and copy protection). I can implement those at any time.
The last big feature it doesn't have yet is CECP (xBoard/WinBoard) support. The UCI-communication module translates incoming UCI-commands from strings to enums/structs, and outgoing responses from enums/structs to strings. Those enums and structs basically constitute a "nicely packaged" internal UCI-protocol so the engine can send commands and responses from one thread to another. The xBoard module will hook into those and translate from and to these structs. Where xBoard can do things that UCI can't, I can extend the engine's internal protocol to support those features.
that will be next (up to the point where the xBoard implementation supports the same features as the UCI one), before I can make a build script that produces all of the executables, and then release the engine as Rustic Alpha 1.
From there on, I can add features and test Elo progression for each feature I add.
Almost there...