Support multiplayer nonlinear games #6
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for games with 3+ players and nonlinear payoffs using MultiPlayer.jl, which is an external dependency that is not yet publicly available.
Key changes include:
- Implementation of utility-based sampled games for multiplayer nonlinear games
- Refactoring of the Sample type to use OrderedDict for consistent player ordering
- Addition of solver dependencies (Gurobi, Juniper, Ipopt) required by MultiPlayer.jl
Reviewed Changes
Copilot reviewed 18 out of 19 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| src/IPG.jl | Adds temporary inclusion of MultiPlayer.jl source files with warning |
| src/SGM/SampledGame.jl | Introduces Sample type and automatic game type selection logic |
| src/SGM/UtilitiesSampledGame/ | New module implementing utility-based sampled games with MultiGame integration |
| src/SGM/PolymatrixSampledGame/ | Refactored to use new Sample type and removed players parameter |
| test/ | Updated tests to use new Sample type and added multiplayer game tests |
| examples/multiplayer_cfld.jl | New example demonstrating 3-player nonlinear competitive facility location |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| # TODO: pass optimizer_factory to compute_nash_equilibria. this will likely need some modifications of MultiPlayer | ||
| # The above will be much trickier than I initially thought. MultiGame uses Gurobi, | ||
| # Juniper, and Ipopt extensively, changing solver-specific parameters. Also, it uses | ||
| # Gurobi's PWL features under some settings. I believe we would need to dissect | ||
| # MultiGame quite a bit to make it solver-agnostic. | ||
| # For now, I added Gurobi (and Juniper (and Ipopt)) as a dependency :( |
There was a problem hiding this comment.
The ignored optimizer_factory parameter makes the function signature inconsistent with the polymatrix solver interface. This breaks the abstraction and could confuse users who expect to be able to specify their solver. Consider adding parameter validation or documentation about this limitation.
Add support for games with 3+ players with nonlinear payoffs. This uses MultiPlayer.jl, which is not publicly available yet. Also, and because of MultiPlayer.jl, I had to add solver dependencies, such as Gurobi and Juniper.
Gurobi, in particular, bothers me because it requires a license. This makes testing more complicated and limits adoption IMO. However, refactoring MultiPlayer.jl is a delicate operation that will require some time.