Multiple Game Support

[alecpm]

This PR pulls most of the game specific code from the GridUniverse experiment class into a new Game class. The experiment class creates a number of networks and creates a Game instance for each network. It currently relies on standard behavior from Dallinger where the experiment_repeats value determines how many networks are created and the get_network_for_participant method determines which network/game in which to add new participants.

This implementation still runs the game_loop and send_state_thread tasks as gevent threads in the process running the web worker which happened to have /launch run. I've tried to set things up so that the state passed when intializing Game consists of simple python values objects. We may eventually be able to use the multiprocessing module to launch each Game in a separate process.

The experiment instance is currently responsible for receiving the all WebSocket messages and calls methods directly on Game instances based on the channel that messages were sent to. Moving to a multiprocessing model will require subscribing each game directly to the WebSocket channel (which should be more efficient) and providing a send method on the Game class, or some intra-process communication mechanism.

In order to support multiple games and waiting room like functionality I've added the following configuration options:

• num_games: The number of games to run in parallel
• quorum: The total number of players needed before the waiting room closes and games can begin. Defaults to max_participants (the maximum number of players in a game).
• game_quorum: The number of players needed before an individual game can start. Defaults to max_participants (the maximum number of players in a game).

If you wanted to e.g. require all games be filled before starting any games you could set quorum to max_particpants * num_games. You can also disable the Dallinger waiting room by setting quorum to 0. And you can have games start before they have filled up to max_participants by setting game_quorum to e.g. 1.

Because the waiting room only works for the initial game, it's not possible to use the pre_difi_question feature on multiple concurrent games, and the waiting process looks a bit different between the first game and subsequent games.

[alecpm]

A couple implementation notes:

• The game template code no longer has access to a Gridworld object for determining settings. Because of that I've removed all properties from Gridworld that were exclusively used to provide initial JS settings in the templates. The default values for these configuration settings now live in the templates instead of in python code.
• Currently, the Experiment (GridUniverse) instance handles all incoming WebSocket messages for all game channels and determines which game will handle each message based the channel name. If we want to move to a multi-process architecture, we will probably need the individual games to handle WebSocket messages for their game channels directly. There may even be some benefit to having the games subscribe individually to their channels in the current single process architecture.

[jessesnyder]

This feels like a reasonable compromise between backwards compatibility with the status quo and support for executing multiple games in a single experiment deployment, which is the main goal. We have lingering performance concerns, but it definitely makes sense to address those separately when and if we see them.