A5 Option 1: Baroque Chess Agents
CSE 415: Introduction to Artificial Intelligence
The University of Washington, Seattle, Spring 2019
OPTION 1: Baroque Chess Agent.

For option 1, you will work with a partner to create a Python module (typically just a single .py file) that will be able to play a game of Baroque Chess and compete in a tournament. Although the tournament is not part of the assignment itself, your program must be technically able to participate in it. (The tournament will take place after the assignment is due; we may offer some extra credit for programs that place highly in the rankings.) Your player's file name should be of the form [free_name]_BC_Player.py, where you get to choose an original name, but that name is followed by "_BC_Player.py". An example might be Magnifico_BC_Player.py. If you need to split your agent to use any additional modules, please name them using the convention: [free_name]_BC_module_[module_name].py. Here an example could be Magnifico_BC_module_static_eval.py.

Game rules: A good overview of the rules of Baroque Chess is given in the Wikipedia article on Baroque Chess. However, since there are a number of variations of Baroque Chess, we have to specify some version, and we will use an operational definition of the rules. ''When in doubt, try it out, at the validation page.''


Image courtesy of Chess Guide at multionline.net.

It will be essential that your program use the specified representation of states, so that it is compatible with all the other Baroque Chess programs developed in the class. Some code for representing states of Baroque Chess is shown near end of this page. (This is included as BC_state_etc.py in the Starter code.)

Your program should be designed to anticipate time limits on moves. There are two aspects to this: (1) use iterative deepening search, and (2) poll a clock frequently in order to return a move before time runs out.

Starter code is available. This code provides a game-master to handle the turn-taking between a pair of playing agents, and it provides a class definition for states of the game. Some simple agent stub files are included to help get the project going.

We are playing Baroque Chess with rules that: do not permit (a) any choice of center-counter symmetry (see the Wikipedia description of Baroque Chess), or (b) long-leaper double jumping (it's considered detrimental to having balanced and dynamic games), or (c) "suicide" moves. We will assume that the game ends when either player loses a king.

Your program should implement the following functions, so that they can be called by the game administration software:

  • prepare(player2Nickname playWhite=True). This function will be called by the game administration software before a game starts, and usually before any of the other functions below are called. If your agent needs to initialize any data structures, this is a good place for that to be done, as the time taken to execute this will not be "on the clock" that is running during game moves. It also allows your agent to know in advance whether it will be playing White or Black.

  • parameterized_minimax(currentState, alphaBeta=False, ply=3, useBasicStaticEval=True). This function is for testing the basic capabilities of your agent. It should be able to work for any combination of values of arguments, within reason, except that it is not required to integrate Zobrist Hashing into your agent. For example, it should be OK with any legal state for currentState; either using or not using alpha-beta pruning; a specified number of ply (maximum depth) from 0 (statically evaluate the current state only) to perhaps 8 (which might not be too bad if there are only a few pieces left on the board).

    When useBasicStaticEval is true, you'll evaluate leaf nodes of your search tree with your own implementation of the following function: White pincers are worth 1, the White king is worth 100, and all other White pieces are worth 2. Black pieces have the same values as their white counterparts, but negative. When useBasicStaticEval is False, you should use your own, more discriminating function. The value of the function is the sum of the values of the pieces on the board in the given state.

    The use of Zobrist hashing in your agent is optional. However, if you do use it, it should be disabled while running the parameterized_minimax function.

    In order for parameterized_minimax to be a good testing function, the order for move generation must be controlled. Although your agent may generate successors in any order when playing a game, in parameterized_minimax it must use a prescribed order. Here is that order, based on the source and destination squares for each move. This order should be respected whether the agent is playing White or Black. Moves of a piece at (a, 1) come before moves of a piece at (a, 2), which come before moves of a piece at (a, 3), etc., which come before moves at (b, 1), etc. Among all moves of a piece from (M, N), we break ties according to the destination squares, using the same ordering as for source squares. Here is the board layout:

    Although your makeMove function should use IDDFS to be able to come up with a move no matter how much time is given, you should NOT use IDDFS in parameterized_minimax.

    The return value of parameterized_minimax should be a dict object with the following attributes:

  • 'CURRENT_STATE_STATIC_VAL': The static eval value of the current_state as determined by your minimax search
  • 'N_STATES_EXPANDED': The number of states expanded as part of your minimax search
  • 'N_STATIC_EVALS': The number of static evals performed as part of your minimax search
  • 'N_CUTOFFS': The number of cutoffs that occurred during the minimax search (0 if alpha-beta was not enabled)

  • introduce(). This function will return a multiline string that introduces your player, giving its full name (you get to make that up), the names and UWNetIDs of its creators (you), and (optionally) some words to describe its character.

  • nickname(). This function should return a short version of the playing agent's name (16 characters or fewer). This name will be used to identify the player's moves in game transcripts.

  • makeMove(currentState, currentRemark, timeLimit=10). This is probably your most important function. It should return a list of the form [[move, newState], newRemark]. The move is a data item describing the chosen move, of the form ((r, c),(r1, c1)). Here (r, c) gives the starting row and column coordinates of the piece that is being moved, and (r1, c1) give the coordinates of the square where it ends up. (fr, new_fr). Here fr is a string such as "e2", where the first character gives the "file" (column) and and the second character gives the "rank" (row) on the board of the piece being moved, and new_fr gives the coordinates of the square where that piece ends up.

    The newState is the result of making the move from the given currentState. It must be a complete state (an instance of class BC_state) and not just a board.

    The currentRemark argument is a string representing a remark from the opponent on its last move. You may (optionally) use this as input to your own agent's remark.

    The timeLimit represents the number of seconds available for computing and returning the move.

    The newRemark to be returned must be a string. During a game, the strings from your agent and its opponent comprise a dialog. These remarks should reflect a "personality" of your agent. They could be canned remarks from a list of 10 or more, but you may make this more elaborate and context-sensitive, commenting on the current state or the direction in which the game seems to be heading.

    Your makeMove function should use IDDFS so that it can implement an "anytime" version of the mimimax search, and it should check the clock often enough to make sure it can return its best move found so far, if there is little time left.

  • staticEval(state). This function will perform a static evaluation of the given state. The value returned should be high if the state is good for WHITE and low if the state is good for BLACK. This function is not the same as your basic static evaluation function mentioned above in association with parameterized_minimax, but should be custom-designed by your team to help your agent be a strong player. The staff plans to test your staticEval function separately at some point during the grading, so it should be possible to use it by executing code such as the following. (This example assumes your agent is named "The_Roman_BC_Player".)
    import The_Roman_BC_Player as player
    staticResult = player.staticEval(some_state)    
        

    The quality of your agent's playing will probably depend heavily on how well your staticEval function works.

  • You may incorporate Zobrist hashing into your agent. It is optional. The staff may provide some assistance in terms of a module with methods for Zobrist hashing, but using it will not be required whether you choose to use Zobrist hashing or not.

    In the code example above, the starting board is shown using ASCII text, and the encoding is as follows: (lower case for black, upper case for WHITE):

        p: pincer
        l: leaper
        i: imitator
        w: withdrawer
        k: king
        c: coordinator
        f: freezer
        -: empty square on the board
        
    Here are the contents of the starter code file BC_state_etc.py. It's presented here for convenient references, but it is part of the .tar archive linked above.
    BLACK = 0
    WHITE = 1
    
    INIT_TO_CODE = {'p':2, 'P':3, 'c':4, 'C':5, 'l':6, 'L':7, 'i':8, 'I':9,
      'w':10, 'W':11, 'k':12, 'K':13, 'f':14, 'F':15, '-':0}
    
    CODE_TO_INIT = {0:'-',2:'p',3:'P',4:'c',5:'C',6:'l',7:'L',8:'i',9:'I',
      10:'w',11:'W',12:'k',13:'K',14:'f',15:'F'}
    
    def who(piece): return piece % 2
    
    def parse(bs): # bs is board string
      '''Translate a board string into the list of lists representation.'''
      b = [[0,0,0,0,0,0,0,0] for r in range(8)]
      rs9 = bs.split("\n")
      rs8 = rs9[1:] # eliminate the empty first item.
      for iy in range(8):
        rss = rs8[iy].split(' ');
        for jx in range(8):
          b[iy][jx] = INIT_TO_CODE[rss[jx]]
      return b
    
    INITIAL = parse('''
    c l i w k i l f
    p p p p p p p p
    - - - - - - - -
    - - - - - - - -
    - - - - - - - -
    - - - - - - - -
    P P P P P P P P
    F L I W K I L C
    ''')
    
    	
    class BC_state:
      def __init__(self, old_board=INITIAL, whose_move=WHITE):
        new_board = [r[:] for r in old_board]
        self.board = new_board
        self.whose_move = whose_move;
    
      def __repr__(self):
        s = ''
        for r in range(8):
          for c in range(8):
            s += CODE_TO_INIT[self.board[r][c]] + " "
          s += "\n"
        if self.whose_move==WHITE: s += "WHITE's move"
        else: s += "BLACK's move"
        s += "\n"
        return s
    
      def __eq__(self, other):
        if not (type(other)==type(self)): return False
        if self.whose_move != other.whose_move: return False
        try:
          b1 = self.board
          b2 = other.board
          for i in range(8):
            for j in range(8):
              if b1[i][j] != b2[i][j]: return False
          return True
        except Exception as e:
          return False
    
    def test_starting_board():
      init_state = BC_state(INITIAL, WHITE)
      print(init_state)
    
    test_starting_board()
    	
    What to Turn In:

    Turn in your files via Canvas. Do not zip up the files.

    1. Your agent file(s). See the naming requirements at the beginning of this page. If Canvas renames your files, we will fix them.
    2. Report.pdf: Include the following. Title; Team member names; Intended personality of the agent; Status of agent -- features that work and any that don't; Design retrospective of about 200 to 500 words describing how you designed your agent; Optional partnership retrospective including how you operated as a team, what issues you had in terms of collaboration, and how you did or did not overcome those issues, and what if anything you learned in terms of collaboration. A thoughtful parnership retrospective is worth 3 to 5 points of extra credit, and a 5-point one will typically include a group portion and an individual statement of several lines of text from each of the two partners.
    3. Transcript1.txt: One game transcript of your player playing against another team's agent.
    4. Transcript2.txt: Optional second transcript if you are entering the tournament. (Turn this in as part of a separate Tournament submission by Thursday Friday night, May 16.) To qualify for entering the tournament, you need to turn in two transcripts, representing games with two different players, and your agent must be the winner of each game. Note: If your agent A, plays agent B several times, winning at least once, you can use the transcript of that winning game as one of your two qualifying transcripts. One additional requirement to qualify for the tournament is that your agent must not make illegal moves in any games, whether in the transcripts or not. (It might not always make a move when a move exists, and that could possibly mean losing a game, but failing to make a legal move when one exists is not in itself disqualifying.) Note: Extra credit is available for tournament participation as follows: 5 points for qualifying, 5 more points for being a finalist (among the top 5 agents), and 5 more for being the overall winner.
    Updates and Corrections: Due date pushed back to May 15. The spec for the returned move has been changed to match the starter code (May 14, 10:30 AM). The "prepare" function's parameter was clarified in Piazza on May 13, and then updated here. Minor corrections to the BaroqueGameMaster.py program in the starter code were incorporated, and the new version is here. (It's also included in an updated version of the starter code, but nothing else is changed in the starter code.) Any additional changes will be described here.