<jupyter_start><jupyter_text>Explaining the games.py module*Author: <NAME>**Date: 12th March 2016*  An Introduction   Hello all!    In this IPython notebook, I plan to help you a little so that you will be able to use the [games.py](https://github.com/aimacode/aima-python/blob/master/games.py) module. You might already know that the `games.py` module implements the algorithms in Chapter 5 (Adversarial Search) of the book *Artificial Intelligence: A Modern Approach*.      Before we begin, if you are unsure of how to use the [aima-python](https://github.com/aimacode/aima-python) repository or are not familiar with IPython notebooks you should read the [intro notebook](https://github.com/aimacode/aima-python/blob/master/intro.ipynb) first. Also, if you are more comfortable with Java than you are with Python we also have the [aima-java](https://github.com/aimacode/aima-java) repository.    What we will do to learn to use the code in this module is simply dive in! I feel this is the correct approach as I assume you must have already read Chapter 5 of AIMA. If you haven't, you might want to go back and do that first. If you are tired (or just lazy), at least read the chapter upto Sec. 5.3 because this module covers the algorithms only till that section anyway. So, I will start by explaining what the class `Game` is and then we will immediately start implementing the `TicTacToe` game. After we define the rules of the `TicTacToe` game, we will create AI players who use different search strategies, namely Minimax Search and Alpha-Beta Search. We will make these players play among themselves, and later on we ourselves will play against these AI players (Yay!).    The reason I chose the `TicTacToe` game for demonstration of this module should be obvious to you. Everyone knows it and has played it, it is analyzed in quite some detail in AIMA, and most importantly, it has comparatively few states (fewer than 362,880) so that we can explore the search tree completely.      So let's begin.  Implementing TicTacToe To use the code in `games.py` let's import everything from it:<jupyter_code>from games import *<jupyter_output><empty_output><jupyter_text>Note that, here, as the module `games.py` does a `from utils import *`, all the names (global variables, functions etc.) available in `utils.py` are directly available to us now.  The class `Game`    Let's have a look at the class `Game` in our module. We see that it has six functions, namely `actions`, `result`, `utility`, `terminal_test`, `to_move` and `display`. We see that these functions have not actually been implemented. This class is actually just a template class; we are supposed to create the class for our game, `TicTacToe` by inheriting this `Game` class and implement all the methods mentioned in `Game`. If you forget to implement any one of those, a `NotImplementedError` will be raised. So, in this sense, the `Game` class is what you might call an abstract class in Java: it implements nothing, just tells you all that you are supposed to implement and screams at you if forget to implement what it asks.      Now let's get into some details of all these methods in our `Game` class. You have to implement these methods when you create the new class that would represent your game.  * `__init__(self, )` :  When you create a class inherited from the `Game` class (class `TicTacToe` in our case), you'll have to create an object of this inherited class to initialize the game. This initialization might require some additional information which would be passed to `__init__` as variables. For the case of our `TicTacToe` game, this additional information would be the number of rows `h`, number of columns `v` and how many consecutive X's or O's are needed in a row, column or diagonal for a win `k`. Also, the initial game state has to be defined here in `__init__`.* `actions(self, state)` : Given a game state, this method should generates all the legal actions possible from this state, as a list or a generator. Returning a generator rather than a list has the advantage that it saves space and you can still operate on it as a list.* `result(self, state, move)` : Given a game state and a move, this method returns the game state that you get by making that move on this game state.* `utility(self, state, player)` : Given a terminal game state and a player, this method returns the utility for that player in the given terminal game state. While implementing this method assume that the game state is a terminal game state. The logic in this module is such that this method will be called only on terminal game states.* `terminal_test(self, state)` : Given a game state, this method should return `True` if this game state is a terminal state, and `False` otherwise.* `to_move(self, state)` : Given a game state, this method returns the player who is to play next. This information is typically stored in the game state, so all this method does is extract this information and return it.  Deciding the game state representation    Now, before we start implementing our `TicTacToe` game, we need to decide how we will be representing our game state. Typically, a game state will give you all the current information about the game at any point in time. Yes, all of it. When you are given a game state, you should be able to tell whose turn it is next, how the game will look like on a real-life board (if it has one) etc. A game state need not include the history of the game. If you can play the game further given a game state, you game state representation is acceptable. While we might like to include all kinds of information in our game state, we wouldn't want to put too much information into it. Modifying this game state to generate a new one would be a real pain then.    Now, as for our `TicTacToe` game state, would storing only the positions of all the X's and O's be sufficient to represent all the game information at that point in time? Well, does it tell us whose turn it is next? Looking at the 'X's and O's on the board and counting them should tell us that. But that would mean extra computing. To avoid this, we will also store whose move it is next in the game state.      Think about what we've done here. We have reduced extra computation by storing additional information in a game state. Now, this information might not be absolutely essential to tell us about the state of the game, but it does save us additional computation time. We'll do more of this later on.      The `TicTacToe` game defines its game state as:<jupyter_code>GameState = collections.namedtuple('GameState', 'to_move, utility, board, moves')<jupyter_output><empty_output><jupyter_text>The game state is called, quite appropriately, `GameState`, and it has 4 variables, namely, `to_move`, `utility`, `board` and `moves`.      I'll describe these variables in some more detail:  * `to_move` : It represents whose turn it is to move next. This will be a string of a single character, either 'X' or 'O'.* `utility` : It stores the utility of the game state. Storing this utility is a good idea, because, when you do a Minimax Search or an Alphabeta Search, you generate many recursive calls, which travel all the way down to the terminal states. When these recursive calls go back up to the original callee, we have calculated utilities for many game states. We store these utilities in their respective `GameState`s to avoid calculating them all over again.* `board` : A dict that stores all the positions of X's and O's on the board* `moves` : It stores the list of legal moves possible from the current position. Note here, that storing the moves as a list, as it is done here, increases the space complexity of Minimax Search from `O(m)` to `O(bm)`. Refer to Sec. 5.2.1 of the book.  Representing a move      Now that we have decided how our game state will be represented, it's time to decide how our move will be represented. My advice on this: keep it simple. Becomes easy to use this move to modify a current game state to generate a new one.      For our `TicTacToe` game, we'll just represent a move by a tuple, where the first and the second elements of the tuple will represent the row and column, respectively, where the next X or O is to be made. Whether to make an X or an O will be decided by the `to_move` variable in the `GameState`.  The class `TicTacToe`      Take a look at the class `TicTacToe`. All the methods mentioned in the class `Game` have been implemented here. Some points to note in this class might be:      * The class `TicTacToe` has been inherited from the class `Game`. As I mentioned earlier, you really want to do this. Catching bugs and errors becomes a whole lot easier.* A `display` function has been implemented. This function prints the given game state on the console. This might come in handy for debugging and is great when we play ourselves against AIs that we will be creating.* Additional functions `compute_utility` and `k_in_a_row` are created, which are used by other functions. Well, no one said that you can't do this.  Creating players to play the games    `random_player` and `alphabeta_player`      So, we have finished implementation of the `TicTacToe` class. What this class does is that, it just defines the rules of the game. We need more to create an AI that can actually play the game. This is where `random_player` and `alphabeta_player` come in.      The `random_player` is a function that plays random moves in the game. That's it. There isn't much more to this guy.      The `alphabeta_player`, on the other hand, calls the `alphabeta_full_search` function, which returns the best move in the current game state. Thus, the `alphabeta_player` always plays the best move given a game state, assuming that the game tree is small enough to search entirely.  `query_player` and `play_game`      The `query_player` function allows you, a human opponent, to play the game. This function requires a `display` method to be implemented in your game class, so that successive game states can be displayed on the terminal, making it easier for you to visualize the game and play accordingly.      The `play_game` function will be the one that will actually be used to play the game. You pass as arguments to it, an instance of the game you want to play and the players you want in this game. Use it to play AI vs AI, AI vs human, or even human vs human matches!  Examples      I will show some code examples below that you can run. The games' classes which I will use are `TicTacToe` and the `Fig52Game`. The `Fig52Game` is already implemented (actually both are) in the module. This is that small game in Fig 5.2 of the book.      Have fun executing and modifying these examples!  Let's start by experimenting with the `Fig52Game` first. For that we'll first create an instance of this game:<jupyter_code>from games import *
game52 = Fig52Game()<jupyter_output><empty_output><jupyter_text>First we try out our `random_player`. Given a game state it will give us a random move every time:<jupyter_code>random_player(game52, 'A')
random_player(game52, 'A')<jupyter_output><empty_output><jupyter_text>The `alphabeta_player` will always give us the best move:<jupyter_code>print( alphabeta_player(game52, 'A') )
print( alphabeta_player(game52, 'B') )
print( alphabeta_player(game52, 'C') )<jupyter_output><empty_output><jupyter_text>What the `alphabeta_player` does is, it simply calls the method `alphabeta_full_search`. They both are essentially the same. In the module, both `alphabeta_full_search` and `minimax_decision` have been implemented. They both do the same job and return the same thing, which is, the best move in the current state. It's just that `alphabeta_full_search` is more efficient w.r.t time because it prunes the search tree and hence, explores lesser number of states.<jupyter_code>minimax_decision('A', game52)
alphabeta_full_search('A', game52)<jupyter_output><empty_output><jupyter_text>Now let's play `TicTacToe`. First we initialize the game:<jupyter_code>ttt = TicTacToe()<jupyter_output><empty_output><jupyter_text>We can print a state using the display method:<jupyter_code>ttt.display(ttt.initial)<jupyter_output><empty_output><jupyter_text>Hmm, so that's the initial state of the game; no X's and no O's.      Let us create a new game state by ourselves to experiment:<jupyter_code>my_state = GameState(
    to_move = 'X',
    utility = '0',
    board = {(1,1): 'X', (1,2): 'O', (1,3): 'X',
             (2,1): 'O',             (2,3): 'O',
             (3,1): 'X',
            },
    moves = [(2,2), (3,2), (3,3)]
    )<jupyter_output><empty_output><jupyter_text>So, how does this game state look like?<jupyter_code>ttt.display(my_state)<jupyter_output><empty_output><jupyter_text>The `random_player` will behave how he is supposed to:<jupyter_code>random_player(ttt, my_state)
random_player(ttt, my_state)<jupyter_output><empty_output><jupyter_text>But the `alphabeta_player` will always give the best move, as expected:<jupyter_code>alphabeta_player(ttt, my_state)<jupyter_output><empty_output><jupyter_text>Now let's make 2 players play against each other. We use the `play_game` function for this. The `play_game` function makes players play the match against each other and returns the utility for the first player, of the terminal state reached when the game ends. Hence, for our `TicTacToe` game, if we get the output +1, the first player wins, -1 if the second player wins, and 0 if the match ends in a draw.<jupyter_code>bot_play = Canvas_TicTacToe('bot_play', 'random', 'alphabeta')<jupyter_output><empty_output><jupyter_text>The output is +1, hence `alphabeta_player` wins.      Since, an `alphabeta_player` plays perfectly, a match between two `alphabeta_player`s should always end in a draw. Let's see if this happens:<jupyter_code>for _ in range(10):
    print(play_game(ttt, alphabeta_player, alphabeta_player))<jupyter_output><empty_output><jupyter_text>A `random_player` should never win against an `alphabeta_player`.<jupyter_code>for _ in range(10):
    print(play_game(ttt, random_player, alphabeta_player))<jupyter_output><empty_output><jupyter_text>Now, let's play a game ourselves against a `random_player`:<jupyter_code>rand_play = Canvas_TicTacToe('rand_play', 'human', 'random')<jupyter_output><empty_output><jupyter_text>Yay! We win. But we cannot win against an `alphabeta_player`, however hard we try.<jupyter_code>ab_play = Canvas_TicTacToe('ab_play', 'human', 'alphabeta')<jupyter_output><empty_output><jupyter_text>Demonstrating the `play_game` function on the `game52`:<jupyter_code>play_game(game52, alphabeta_player, alphabeta_player)
play_game(game52, alphabeta_player, random_player)
#play_game(game52, query_player, alphabeta_player)
#play_game(game52, alphabeta_player, query_player)<jupyter_output><empty_output>
{'fraction_non_alphanumeric': 0.06809141778466932, 'fraction_numerical': 0.005663048607833884, 'mean_word_length': 4.790007806401249, 'pattern_counts': {'":': 0, '<': 74, '<?xml version=': 0, '>': 74, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'chain_length': '18', 'dir': 'jupyter-structured-clean-dedup', 'id': '28469', 'license': 'MIT', 'n_tokens_mistral': 4208, 'n_tokens_neox': 4078, 'n_words': 2156, 'path': 'games.ipynb', 'repo_name': 'lgmoneda/aima-python', 'size': '14840'}