Skip to content
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

Separate Multi-agent interfaces for different formalisms #55

Open
zsunberg opened this issue Aug 7, 2023 · 0 comments
Open

Separate Multi-agent interfaces for different formalisms #55

zsunberg opened this issue Aug 7, 2023 · 0 comments

Comments

@zsunberg
Copy link
Member

zsunberg commented Aug 7, 2023

I recently wrote a proposal about multiple agent problems, and it convinced me that we should have separate interfaces (and maybe separate abstract types) for different multi-agent formalisms.

A few factors supporting this conclusion are:

  1. The extensive form game and stochastic/markov game formalisms are very different, and trying to accommodate all forms in one interface will be extremely complicated to document and error-prone.
  2. Petting Zoo has settled on two different interfaces (AEC for turn-based and parallel for simultaneous)
  3. Originally in my mind there was some question about whether we should have different abstract types for partial observability. This would complicate an approach that had multiple multi-agent interaction because there would be a matrix of different types, i.e. AbstractMDPEnv, AbstractPOMDPEnv, AbstractStochasticGame, AbstractPOSG, etc. I now think that interaction mode is the most important concept and interfaces should be separated based on that. Partial observability is secondary and can be handled as a trait.
  4. Conversion between the different formalisms through wrapping is a good solution for compatibility and should be recommended. When the current interface was designed, I thought that wrappers were a bad thing and should be avoided. But, with provided, AbstractWrapper, QuickWrapper, and AutomaticDefault, wrapping works so well that I think it is a viable solution.

This is in some ways a reversal of #43, but I think AbstractZeroSumEnv would not have been a good choice. Whether a game is zero-sum should be a trait.

I don't have any plans to actually make this change at the moment - this is just a note for the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant