Currently all the moves returned via the HTPP API are optimized for money games (via get_move in web_api.rs)
All moves via the C-API are currently optimized for 1-pointers (via best_move in wildbg_api.rs)
In match games we might have different best moves, depending on whether the player should optimize for gammons and backgammons, or not. So we need HTTP parameters for that.
I propose to introduce two new optional parameters player-away and opponent-away (or x-away and o-away). Default value would be 0. If both values are 0, this would indicate money game. If both values are bigger than 0, this would indicate match play. So if we have a 7-pointer and the player on turn has 5 points and the opponent has 4 points, then player-away would be 2 and opponent-away would be 3.
Right now we only have logic for money game and one pointers, so right now we could return the values for 1-pointers once those HTTP parameters are not 0.
This task may need several PRs. Also the web crate might need some refactorings. The logic, which move is best should be handled in the crate logic, so that it could also be used by the C API one day.
Currently all the moves returned via the HTPP API are optimized for money games (via
get_moveinweb_api.rs) All moves via the C-API are currently optimized for 1-pointers (viabest_moveinwildbg_api.rs)In match games we might have different best moves, depending on whether the player should optimize for gammons and backgammons, or not. So we need HTTP parameters for that.
I propose to introduce two new optional parameters
player-awayandopponent-away(orx-awayando-away). Default value would be0. If both values are0, this would indicate money game. If both values are bigger than0, this would indicate match play. So if we have a 7-pointer and the player on turn has 5 points and the opponent has 4 points, thenplayer-awaywould be2andopponent-awaywould be3.Right now we only have logic for money game and one pointers, so right now we could return the values for 1-pointers once those HTTP parameters are not
0.This task may need several PRs. Also the
webcrate might need some refactorings. The logic, which move is best should be handled in the cratelogic, so that it could also be used by the C API one day.