Monte Carlo compatible battles

[in-op]

Each of the selection choices needs to be playable by a MC search.

• [ ] Game is deep copyable
• [ ] Games can copy their values into another Game
• [ ] MC Search for simultaneous, beginning of turn selection
• [ ] MC Search for forced-switch
• [ ] Generate legal moves for simultaneous, beginning of turn selection
• [ ] Generate legal moves for forced-switch
• [ ] Random BattleActor
• [ ] Game can perform simultaneous selections
• [ ] Game can perform forced-switch selection

[in-op]

Copying

The game was not originally engineered with copying in mind, and it is very tangled to force it. Structure needs a major refactor. While simple classes like Substitute are easy, more involved classes like Move are not. Abstract hierarchies add to the difficulty.

Every instance of an abstract type must use CopyTo on its corresponding instance in the copy because you cannot copy the concrete method implementations that will still be hanging on to that copy instance, even if you copied all the data (PP, etc.).

BattlePokemon is just a wrapper to a Pokemon, and there are only two BattlePokemon in existence at any one time. You cannot copy a BattlePokemon's Pokemon field from within the copying of BattlePokemon itself. The party needs to be copied separately (as we need a copy of each Pokemon), then the specific Pokemon is given to BattlePokemon, then this BattlePokemon's wrapper data then need to be copied to the one which just hooked up its Pokemon. If this separation is not honored, the Pokemon will be copied twice!

It may be useful to use immutable classes/structs.

Properties obfuscate the data needed to be copied.

Events are superfluous during MC search.

Ensure that a Game copy uses RandomBattleActor