MO Connect 4, Breakthrough and Samegame

[rradules]

• MO Connect 4, Breakthrough and Samegame environments
• Also adds the "is_parallelizable" key to the metadata dict of the environments, when missing, to allow selective testing of the parallel environments

[ffelten]

Did a very quick check because I don't have much connection :-)

[ffelten]

I think the PZ convention is to store self.seed and self.np_random from that call now. And use the self.np_random for rng stuff

[threepwoody]

np.random generators seem to not actually have all their state defined by the seed alone, which is why I store/restore their entire state in samegame.py. What do you think about that solution?

[rradules]

So the only stochastic environment is samegame, right?

[threepwoody]

Right

[wilrop]

Looks good! I just had some small questions or suggestions, but I think this is ready to be included into main.

I also very much liked the introduction of the check_[ENV].py files and think it might be useful to add one of those for every supported environment. The benefit is that you can just run the file to see if the output of the game still makes a little bit of sense. We could even put such sanity checks into an automated test for every environment. What do others think? @rradules @ffelten

[wilrop]

I actually very much like these "check" files you have implemented. I think it would be good to have one of these sanity checks for each environment, maybe in a dedicated test runner? This should be discussed also with @rradules

[umutucak]

I agree. CrazyRL environments have these as well in the main environment files 👍

[ffelten]

Looks good! I just had some small questions or suggestions, but I think this is ready to be included into main.

I also very much liked the introduction of the check_[ENV].py files and think it might be useful to add one of those for every supported environment. The benefit is that you can just run the file to see if the output of the game still makes a little bit of sense. We could even put such sanity checks into an automated test for every environment. What do others think? @rradules @ffelten

I'm not sure what's the addition here exactly but we can if needed define a run_episode helper somewhere and call it from __main__ in the env file.

[wilrop]

@ffelten Having thought about it a little bit more, I realised that having such a check env file is only useful during development, and after that has concluded its role is taken over by the test_module method. Therefore, you can ignore the remark :)