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

Game classification #1414

Open
alexhroom opened this issue Apr 20, 2023 · 4 comments · Fixed by #1418
Open

Game classification #1414

alexhroom opened this issue Apr 20, 2023 · 4 comments · Fixed by #1418

Comments

@alexhroom
Copy link
Contributor

Following up from #1413, to ensure strategies and algorithms are being used with compatible games there should be a method of classifying and organising games.

Some ideas:

  • a 'games' directory in the package, which contains a sort of 'mini-package' for a specific game. For example, the import path axelrod.games.rockpaperscissors would contain a Game, Actions and Strategy objects for rock-paper-scissors.
  • Maybe for convenience, the axelrod.games directory could contain a function where a user enters a game name and it returns a dict with the various components of the game, e.g.:
>>> from axelrod.games import get_game
>>> get_game("rock_paper_scissors")
{"game": axl.AsymmetricGame([RPS MATRICES HERE]),
 "actions": [R, P, S],
 "strategies": [[RPS STRATEGIES HERE]]
}
  • Strategies themselves should have classifications for what action set size they're for, and raise an error or warning if used on an inappropriate game size.
  • If we're worried about the package getting too big with more games/strategies it may be a good idea to use namespace packages so that other games can be installed separately but used from the axelrod namespace - particularly if a few games are added before the release of 5.0.0 this would be a good way to "generalise" the library completely.
@drvinceknight
Copy link
Member

This is all awesome @alexhroom, I think #1413 really unblocks a bunch of stuff going forwards towards 5.0.0.

  • a 'games' directory in the package, which contains a sort of 'mini-package' for a specific game. For example, the import path axelrod.games.rockpaperscissors would contain a Game, Actions and Strategy objects for rock-paper-scissors.

So this would imply moving a lot of the "current" functionality of the library to axelrod.games.ipd right?

  • Maybe for convenience, the axelrod.games directory could contain a function where a user enters a game name and it returns a dict with the various components of the game, e.g.:
>>> from axelrod.games import get_game
>>> get_game("rock_paper_scissors")
{"game": axl.AsymmetricGame([RPS MATRICES HERE]),
 "actions": [R, P, S],
 "strategies": [[RPS STRATEGIES HERE]]
}

Not sure if we need something like this (for example the strategies for axelrod.gams.ipd would be huge). It feels like get_game would be trying to do the job of good documentation. So I think 🤔 I'd prefer us to ensure the documentation structures evolves/improves with the changes.

  • Strategies themselves should have classifications for what action set size they're for, and raise an error or warning if used on an inappropriate game size.

👍

  • If we're worried about the package getting too big with more games/strategies it may be a good idea to use namespace packages so that other games can be installed separately but used from the axelrod namespace - particularly if a few games are added before the release of 5.0.0 this would be a good way to "generalise" the library completely.

I suggest not worrying about this until it becomes a problem (but I like the suggestion of namespace packages as a solution).

@alexhroom
Copy link
Contributor Author

if we're thinking towards 5.0.0 (i.e. being willing to make breaking changes) then yeah axelrod.games.ipd would contain a lot of the specific IPD functionality. in general I was trying to point towards the idea of having Axelrod "main" be the library classes and algorithms, and then each game as a "game box" with an easy way for users to load that game into their Python session - you're right that for IPD a strategy list would get huge

@drvinceknight
Copy link
Member

if we're thinking towards 5.0.0 (i.e. being willing to make breaking changes) then yeah axelrod.games.ipd would contain a lot of the specific IPD functionality.

Yeah I feel like we're certainly going towards 5.0.0 here with breaking changes.

@marcharper
Copy link
Member

@gaffney2010 worked on this for the ultimatum game, see this branch for some ideas and implementation details.

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

Successfully merging a pull request may close this issue.

3 participants