Regarding implementation details of MonteCarlo AI playout.

Hello, I am making a game similar to Final Fantasy Tactics (gameplay video, skip to 0:30). I asked around at gamedev.net and got some very helpful advice that has allowed me to decide on a good AI approach. One of my last posts in that thread is a detailed breakdown of how I plan to implement the AI and may be crucial in addressing my question.

My only concern now is how to do it in Unity. The AI, a Monte Carlo Tree Search, requires me to basically run semi-random potential moves until the game reaches a win/loss state (called a playout).

I would have to run thousands of playouts every time the AI considers what to do this turn. Ideally, I would simply call a function that 'remembers' the game state before the playouts. After the playout I would then call another function to restore the state for the next one, and so on. Once a move was chosen, I would restore the game state to how it was before the AI... with the obvious exception that the AI Game Object would now know what move it was going to make.

However, all the time the player is still looking at the board. So.. I dont want the player SEES to change while the AI is running its playout simulations.

How can I achieve this?

I use Unity3D for running population based AI techniques, so I've faced a similar problem, but from the aspect of increasing efficiency whilst running experiments. There are two ways that you can do this: the first is as Tetrad mentioned above, where you abstract the game into something like the extensive form of the game and encode that mathematically, embed that game model into the control structure of the AI, and let it churn away itself (you'd obviously have to write an interpretation method from the move the AI chooses to make in the internal model to how that move is carried out in the actual game.)

The second option is to create a complete second copy of the game, but just turn rending on those game objects off. This could actually provide some good debugging information, as you can then just turn it on again to see what the AI is up to (this has proven invaluable for me in my experiments).

I chose the second method because the state of the game was held within Unity, I didn't have to model it myself. Less complication is better :-)

Hope that helps.

Well you don't have to actually run your simulation using the renderable objects in the world. Just have some internal structures that represent your game state, and when things need to change you just modify the pieces to do what you need them to do.