-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
State via the API #48
Comments
Can probably be done at the same time as #7 |
My concern with this is the following. Currently the game view creates a whole game object, using all moves. That gives us a lot of flexibility; We can use the method nextToPlay, the gamePhase and result, the round method, etc. One could argue that these things are (strictly speaking) part of what defines the game state. But currently we don't handle it that way. If we add all this to the exported game state, It might add a lot of complexity to the variants. And the api endpoint would be called a lot (e.g. when navigating through the moves). |
I agree with the fact that it is nice to have the game object in the client. That said, I want to address this part specifically:
Passing
That said, there are always multiple approaches to a problem. Is there a solution to "hidden information gets leaked via the API" that you see as preferable? |
I haven't worked out the details, but an alternative might be to allow variants to modify the move sequence before it is sent to clients. Parallel move variants could remove the staged moves (except yours), However, I'm not sure if its preferable. This approach might give us less flexibility that your proposal does. |
One thing to consider: It might not always be possible to create the subjective game state by all moves that are shared with a user. Example variant, like Baduk but:
|
Yeah, you two convinced me. I'm on board with this 🙂 |
I'm thinking on working on this next. I'm thinking of adding a server side endpoint like "get_game_state(gameId, round)" With respect to the move navigation, that would mean that traversing through the move history, each round requires one network request. Just to make sure, are we (still) ok with that? I believe there are alternatives that would optimize the data traffic etc. better, but 1.) would be a lot of work and 2.) probably add a lot of complexity to variants (especially hidden information variants). |
Wonderful! Many thanks in advance
I'm okay with that. Fixing this is higher priority than network optimization IMO I do have some ideas on the network optimization if/when we want to approach that though |
We are now passing state thanks to #267 |
In hidden information games, the clients should not have access to the whole moves list. My thought is that the following endpoints can be created:
/games/%id%/state
/games/%id%/state/%seat%
(partial state)It would return the output of
exportState()
.The text was updated successfully, but these errors were encountered: