You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is some sense to this as it leaves out unnecessary information. For example, we do not need to send is_noisy information for our own bot.
This comes with a disadvantage, however, in that more advanced code that might want to use a different API has to revert these decisions. Specifically, code that wants to re-use the apply_move function to simulate a move has to reimplement the logic of apply_move targeted at the Bot API or write a conversion function from Bot API back to game_state (and fear that this breaks whenever new properties are added).
My proposal would be to create the Bot API on the client side and instead send a data structure similar to the game state (properly cleaned up from unnecessary/confidential data). A normal user would not see any difference when using the Bot API but a power user could still access the original game state behind a attribute.
Reference to a prior implementation of simulate_move: #399
The text was updated successfully, but these errors were encountered:
In principle it sounds as a good idea, especially if it can be done without changing the Bot API. My guess is taht the devil will be in the details of the implementation, but it is worth a try ;)
We currently prepare the bot state in
game.py
in a scheme that mirrors the way it is later used by theBot
API.There is some sense to this as it leaves out unnecessary information. For example, we do not need to send
is_noisy
information for our own bot.This comes with a disadvantage, however, in that more advanced code that might want to use a different API has to revert these decisions. Specifically, code that wants to re-use the
apply_move
function to simulate a move has to reimplement the logic ofapply_move
targeted at theBot
API or write a conversion function fromBot
API back togame_state
(and fear that this breaks whenever new properties are added).My proposal would be to create the
Bot
API on the client side and instead send a data structure similar to the game state (properly cleaned up from unnecessary/confidential data). A normal user would not see any difference when using theBot
API but a power user could still access the original game state behind a attribute.Reference to a prior implementation of
simulate_move
: #399The text was updated successfully, but these errors were encountered: