State via the API

[benjaminpjones]

State via the API

[JonKo314]

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:

• Players only see their own moves
• If they try to make an illegal move, they are prevented to make that move and may make a different move
• Players are told, how many stones they have captured at any given moment

[benjaminpjones]

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:

If we add all this to the exported game state, It might add a lot of complexity to the variants.

Passing nextToPlay, gamePhase etc. need not complicate variant implementations. We could also pass all these "common" attributes over the state API as well. The payload could look something like:

{
  "variant_state": { "board": [...], captures: {...} },  // output of exportState()
  "next_to_play": [0],
  "phase": "gameover",
  "result": "B+R",
  "round": 103,
}

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?

[benjaminpjones]

I'm thinking on working on this next.

Wonderful! Many thanks in advance ☺️

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'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

[benjaminpjones]

Can probably be done at the same time as #7

[merowin]

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).

[merowin]

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),
Hidden move variants could obfuscate moves

However, I'm not sure if its preferable. This approach might give us less flexibility that your proposal does.

[merowin]

Yeah, you two convinced me. I'm on board with this 🙂

[benjaminpjones]

Marking this high priority as there are other related issues (#266, #174), and the cost of this tech debt grows quickly as other features are start to depend on the full game object existing client-side (#168, #214)

[merowin]

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).