Hi @TheoCabannes,

Sure we can help but I have to understand your use case first.

Is it a simultaneous move game? If so are you loading it as a sequential game using turn_based_simultaneous_game?

Sounds you are indeed hitting some uncovered/unhandled/unanticipated use cases of our API.

Indeed, I am creating a simultaneous move game and I am loading it as a sequential game using turn_based_simultaneous_game. I am also currently writing it with python.

I am currently hitting several issues, so I will probably create a small use case in order to enable debugging my current issues.
Hopefully, the small use case can later be converted in a test.

Thank you a lot for your help!

If a simultaneous game, are you saying you have nodes where some players have actions and others don't have any?

Can we clearly exclude the case that it is a player's turn and they have zero legal moves?

Absolutely we will definitely make sure it is properly handled and covered in a test afterward. Thanks a lot for your help in following up.

Yes, in some nodes some players have actions and other not.
When converting into turn based it created nodes where there is no legal moves.
Currently, one fix is to use kInvalidAction in this case and comment the line https://github.com/deepmind/open_spiel/blob/53eeb6127578f91e88a6c0451983d10e3509446d/open_spiel/spiel.cc#L317

For more context, I am working on a research project based on the implementation of dynamic routing game very similar to this game http://www.professeurs.polymtl.ca/jerome.le-ny/docs/proceedings/2018_CDC_MFGrouteChoice_Salhab.pdf. I am in contact with Julien Perolat who is helping me.

Yeah absolutely not surprised that the code does not handle this case (nor that the docs are inconsistent). This should indeed be fixed, covered by tests, and documented more clearly. Should be an easy fix, will try to have it done by next sync github sync (Monday). Will update this thread as we progress.

This is great timing too, catching these before the release.

Dynamic routing games are definitely something I would love to see in OpenSpiel. Thanks for the context.

I created a PR to show my current issues: #589

Ok @TheoCabannes, I have looked into this and have some updates.

First of all, I would like to separate two things that are being mixed up currently:

1. Proper support for simultaneous move games where some players have no legal actions (along with clear documentation on how these are to be supported)
2. Implementation of a simultaneous move games in Python, and how they can be converted to sequential games to run CFR.

I will not talk at all about (2) because it unnecessarily complicates explaining of (1), which IMO needs to be handled first. @elkhrt is looking into (2) right now and I believe will have a fix soon.

On (1), it turns out we had most of the functionality already there, but there were bugs. I have just managed to fix those and to make a test that runs CFR on a game of this form. It will be merged in the next sync (Monday) and linked to this thread so you can see it. The fixes were entirely on the C++ side, and CFR running in C++.

Regarding documentation:

• LegalActions(player) should indeed return an empty list if player has no legal actions
• ApplyActions(const std::vector<Action>& actions) the vector argument has to have length equal to number of players, so something needs to be passed for every player, even if they have no legal moves. kInvalidAction actually doesn't work because it can't properly be converted from the mapping of flat joint action to vector of actions. So I have updated the docs to clearly explain this, and recommend using 0 for those cases.

The turn_based_simultaneous_game actually skips over the players without any legal moves. This was the intention all along, but it was buggy. My fix should address that. So when you convert to a turn-based game, CFR will never see those states because the converter skips over them, and hence does not need to have a policy defined for them (nor stores any info about them).

Thank you a lot @lanctot.
Two questions/remarks on the point (1).

1. In case LegalActions returns a empty list for player without actions and ApplyActions needs an argument so it takes as argument a list of length equal to the number of player, should generate_playthrough be changed? Also in this case, then the example here is not correct anymore.
2. On your suggestion to pass 0 as action of players without legal actions (instead of kInvalidActions). This seems to me a little bit weird because 0 can model an action which is not legal for the players without legal actions. Should we create a new variable (for example kNoLegalActions) with value num_actions() and consider that their are num_actions()+1 legal actions? It seems that in any case this documentation line should be changed

Yes generate_playthrough should be changed. I don't see why the example is not correct. Can you explain why you think so?

Yes the doc line has been changed. You will only see the change when we apply the sync of our internal repo with github, which happens on Mondays.

Sorry, the example is still correct. But it only applies to sequential games, as simultaneous games use state.legal_actions().

For simultaneous game this will be incorrect:

legal_actions = state.legal_actions()
actions = random.choice(legal_actions)
state.apply_action(actions)

Actually that should still work too, but I will add a test to be sure.

There is an inherited version of ApplyAction that converts a flat action into its equivalent joint action (see simultaneous_move_game.h).

I see. For a simultaneous python game my example fails. But this is due to the issue raised in #587:
LegalActions bindings does not cover LegalActions(player p) due to potentially some issue with overloading in python.

I will try it with C++ code