代写ECS 170、代写Python，Java编程

日期：2022-05-13 09:14

ECS 170: Spring 2022

Homework Assignments 3 and 4

Due Date:

Assignment 3 is due no later than Saturday, May 14, 2020, 9:00pm PDT.

Assignment 4 is due no later than Saturday, May 21, 2020, 9:00pm PDT.

The Assignment:

Consider the game of Oska, whose rules are as follows:

Oska is played on a board like that shown below. The two players face each other across the

board. Each player begins with four pieces, placed one to a square in each of the four squares

nearest that player. The white pieces always start at the top of the board.

The player with the white pieces makes the first move, and the players alternate moves after that.

A player may choose to move one of his or her pieces in one of these ways:

A piece may be moved forward on the diagonal, one space at a time,

to an empty space, as in checkers or draughts.

A piece may jump forward on the diagonal over an opponent's piece

to an empty space, thereby capturing the opponent's piece and

removing it from the board. This capturing move is again like that

seen in checkers or draughts. Unlike checkers, however, only a

single capture is permitted on one turn; multiple jumps are not

allowed. Also, even if a capture is possible, it does not have to

be made if other moves are possible.

The players alternate moving pieces until one of the players wins. If a player can't make a legal

move on a given turn, the player loses that turn and the opponent makes another move. A player

wins when:

All the opponent's pieces have been removed from the board, or

All the player's REMAINING pieces have been moved to the opponent's

starting (or back) row. Note that this rule makes the strategy for

this game most interesting. A player may want to sacrifice pieces

in order to have fewer pieces to move to the opponent's starting

row. But this approach carries some risk in that every sacrificed

piece brings the player closer to having all of his or her pieces

removed from the board, thereby losing the game.

As envisioned by its inventor, Bryn Jones (with refinements by Michael Woodward, who made

this charming game available commercially), the game of Oska was intended to be played with

only four pieces on each side. Now, however, we are extending the definition of Oska to include

any similar game involving n white pieces, n black pieces, and a correspondingly larger board of

2n - 3 rows (where n is greater than or equal to 4). Thus, an Oska game with 5 pieces on each

side would look like this:

Over the next two and a half weeks, you are to construct a Python function (and many many

supporting functions, of course) which takes as input a representation of the state of an Oska

game (i.e., a board position), an indication as to which color (black or white) is being played by

the function you have created, and an integer representing the number of moves to look ahead.

This function returns as output the best next move that the designated player can make from that

given board position. The output should be represented as an Oska board position in the same

format that was used for the input board position.

Your function must select the best next move by using recursive MiniMax search.

Assume for now that the name of your top-level function is "oskaplayer". Your "oskaplayer"

function must then be ready to accept exactly three parameters when called. The sample

function call explains what goes where in the argument list:

oskaplayer(['wwww','---','--','---','bbbb'],'w',2)

^ ^ ^

| | |

The first argument is a list of 2n - 3 | |

strings. Each of these elements is | |

a row of the board. The first element | |

is the first or "top" row, and contains | |

n elements. The second element is the | |

next row, and contains n - 1 elements. | |

The elements of each of these sub- | |

lists are either 'w' to indicate a white | |

piece on that square, 'b' to indicate a | |

black piece, or '-' to indicate an empty | |

square. The leftmost element in one of | |

these nested lists represents the leftmost | |

square in the row represented by that | |

list, and so on. | |

| |

The second argument will always be 'w' or --+ |

'b',to indicate whether your function is |

playing the side of the white pieces or the |

side of the black pieces. There will never |

be any other color used. |

|

The third argument is an integer to indicate --+

how many moves ahead your minimax search is to

look ahead. Your function had better not look

any further than that.

This function should then return the next best move, according to your search function and static

board evaluator. So, in this case, the function might return:

['www-', '--w', '--', '---', 'bbbb']

or some other board in this same format. That result corresponds to the following diagram:

The deliverables for this task are due in two parts. First, we'd like to see your move generation

function (Homework Assignment 3) by 9:00pm, Saturday, May 14. You can make upgrades to

this function after that, but you must turn in a credible working version of the move generator by

9:00pm, Saturday, May 14. The move generator function takes as input only two arguments, a

board and an indication as to whose turn it is next ('b' or 'w'), in exactly that order, and returns a

list of all new boards that can be generated in one move by the indicated player.

Then, 9:00pm, Saturday, May 21, we'd like to see your entire Oska program (Homework

Assignment 4) – move generation, minimax control, and your static board evaluator, all merged

into one impressive Oska machine.

Some extra notes:

1) We may need to modify the specifications a bit here or there in case we forgot something. Try to be

flexible. Don't complain.

2) A static board evaluation function is exactly that -- static. It doesn't search ahead. Ever.

3) You can convert our board representation to anything you want, just as long as when we talk to your

functions or they talk to us, those functions are using our representation. Thus the interface to your

move generator must be in terms of our board representation, and the interface to your top level

function must be in terms of our board representation.

4) We are not asking you to write the human-computer interface so that your program can play against a

human. You can if you want to, just for fun, but we don't want to see it.

5) Program early and often. A simple board evaluator is easy. The move generator is harder, but you

can adapt some of the peg puzzle program The minimax mechanism is harder still. Get the move

generator done in a hurry, then start working on everything else as soon as possible.

6) Name your top-level game-playing function “oskaplayer”, just like in the example above. Name your

move generator function “movegen”. Use those exact names. If the TAs try to run your program by

calling “oskaplayer” and your function is named something else, you will lose many many points.

Calling your move generator something other than “movegen” will have a similar outcome.

7) You may use any representation your wish within your functions, but for testing and grading

purposes, the arguments to your “oskaplayer” and “movegen” functions, as well as what those

functions return, must use the representations specified above.

8) You have two weeks to finish the move generator. You already have plenty of experience creating

move generators, so it should not take you two weeks to make a move generator. Get that component

done early and start working on the rest of program. Do not wait until the last minute. Start working

on it now.

9) Before writing any code, play the game a few times.

10) If the final move of the game leaves both players with all their remaining pieces on their opponent's

starting (or back) row, the player with the most pieces remaining wins. If both players have the same

number of pieces, the game is a draw.

11) Just like with Homework Assignment 2, we want to see lots of well-abstracted, well-named, cohesive,

and readable functions in Homework Assignments 3 and 4. Comments are required at the beginning

of every function and must provide a brief description of what the function does, what arguments are

expected by the function, and what is returned by the function. Missing comments result in missing

points. Additional comments that help the TA who grades your program understand how your

program works may make the TA happy and, as you know, happy graders are generous graders.

Copyright 2022 by Kurt Eiselt, except where already copyrighted by Bryn Jones, Michael Woodward, or anyone

else. All remaining rights reserved, not that there would be many.