Ability to express all extensive-form games

[zsunberg]

When we start to handle more general games - we may want to follow the wikipedia description of an extensive form game and make sure that we can express all possible extensive-form games.

[findmyway]

I'm still struggling to fully understand the incomplete information games. But I can share some thoughts on imperfect information games:

• State.

  • Information of the current player to distinguish different info sets.
  • Game state. (May be distinguished by histories.)
  • Public/Private states
  • Even the same kind of state may have different representations: Tensor, String, Structural...

• Players

  • A chance player is needed.
  • The behavior of the chance player may break the current definition of actions(env), state(env), and some others.

[zsunberg]

After looking some more at the OpenSpiel paper, I think we can accommodate most of this with the current interface. The information set of any player is the set of all observations that it has received. For this reason, I think it is ok to get rid of abstract env subtypes (#43).

A few things I think we'll need:

• Add an optional function player_indices(env) that returns a collection that has an index (an integer or other object) for each player, e.g. 1:n. The default would be (1,)
• act! should return rewards for all players in a container that has an entry for each player index, e.g. a vector or dictionary or NamedTuple. (In the single player case it is acceptable to return a scalar - note that 1.0[1] == 1.0[] == 1.0)
• Optional all_act!(env, as) and all_observe(env) functions for simultaneous-action games.
• Ways to indicate various properties such as zero-sum or deterministic transitions.