Specification Due Date: Friday April 7 at 6am Top-down Program Outline Due Date: Wednesday April 19 at 6am Program Due Date: Monday May 15 at 6am

Transcription

1 Kerry Ojakian s CSI 31 Class Specification Due Date: Friday April 7 at 6am Top-down Program Outline Due Date: Wednesday April 19 at 6am Program Due Date: Monday May 15 at 6am HW: Final Project Do ONE of the projects listed below (if you want to do something else, you must check with me now!). As usual for all homework: Work on your own, without help from others, whether a person, someone online, or by copying code from some source. For all projects, the first part consists of typing up a detailed and clear specification. The projects are somewhat open-ended and not fully specified; in your specification, you should make everything completely precise. For all projects, the second part consists of writing up a Top-Down outline of the program. As we did with the raquet ball simulation, this should be a functioning piece of code broken down into all (or almost all) the functions that you plan on using. It should be organized in a top-down fashion with the functions at the top-levels fully written, and the functions at the bottom levels completely unwritten. Your main function must be complete, though other parts do not need to be. For each function, its interface (inputs and outputs) should be complete. For each function you should have comments precisely describing it. Project Descriptions 1. Multiple-Pile Nim Nim is a 2-player game. There are some number of piles (say p piles) each with some number of objects (say each pile has n objects). Play alternates between the players. On a turn, a player may remove any number of objects (at least one) from any one of the piles. The player to remove the last objects wins. Design Nim for the computer (if you want to do this using graphics, you must first do a text interface version and submit it to me, receive the okay from me, and then work on one that uses graphics). First the program should prompt the user for the p and the n (you can require that p is at most 5 and n is at most 20, especially for a graphical version). Then it should prompt the user for the option of a two player game or a one player game (in the one player case, the other player is the computer). Then play commences. The program should be fool-proof and easy to use, for example: If a player wants to remove no objects, the program should object (i.e. it should be fool-proof!). 1

2 After each move inform the user whose turn it is and what the state of the piles are (i.e. it should be easy-to-use!). Final Feature: Once the above is working, add ONE of the following features: (a) When played against the computer design it so that the user is prompted for difficulty levels (the hardest should be one which always wins when it can; there is a known best strategy in Nim and this will require understanding that strategy). (b) Add a feature that allows the computer to play itself. Then design various strategies (at least 3). Then pit the various strategies against one another in hundreds to thousands of games to see how the strategies compare. You must describe the different strategies and describe the outcome of your experiments. 2. Dominoes Implement a simplified version of dominoes in which there are two players and the dominoes all go in one line, so there is always a left side and a right side. The program follows these rules of dominoes: Distribute 7 dominoes to each player. There are 28 dominoes (each side of a dominoe goes from 0 to 6). The rest of the dominoes are in the boneyard. Determine some way for deciding who starts. Then play alternates. On a turn, a player can play a dominoe that has a side matching one of the ends. If a player does not have a legal play, she must draw from the boneyard till she has a legal play. As soon as the player can play, she must play. A player scores if the total of the two ends adds up to a multiple of 5 The game ends when a player runs out of dominoes or both players cannot play. If the game ends because one player runs out of dominoes, then that player gets the other player s remaining dominoes as her points (rounded to the nearest 5). If the game ends because both players cannot play, then each gets the other player s dominoes as their points (rounding to the nearest 5). Whoever has the most points wins. Your program should give the user the option of playing two player or against the computer. The computer does not have to be a good player, but make the computer as good as possible. Your program should be text based but nicely display all the dominoes already played in the current game. If you want to do this using graphics, you must first do a text interface version and submit it to me, receive the okay from me, and then work on one that uses graphics. But I do not recommend even trying to do this one graphically. Your program should be fool-proof and easy to use, for example: 2

3 (a) It should not allow the player to take from the boneyard if the player can play (i.e. it should be fool-proof). (b) It should let the player know how many dominoes are left in the boneyard (i.e. it should be easy to use). 3. Othello Implement a simplified version of the game of Othello. The (simplified) rules are as follows. The board is a 4 by 4 grid (so it has 16 squares). There are two players: Black and White. Players alternate placing a piece of their color onto an unoccupied square. Suppose it is White s turn: If the piece White places causes White to have a piece of her color on either end of a row or column of Black pieces, then the Black pieces are all turned White. The same rules apply to Black on her turn. The game is over when the last piece is placed, and the winner is the player with more pieces on the board; a draw is possible. Your program should have the following properties: (a) All interaction should be through the graphical interface. (b) It should allow two players to play against one another. (c) At the beginning, the empty board should be displayed. Players alternately click on the square where they want their piece and it should appear. (d) The program should indicate when the game is over and who won. Then it should offer the chance to play a new game. (e) The program should be fool-proof and easy to use, for example: If a player clicks on an occupied space, the program should inform the user (politely?) of her mistake and wait for a legal move (i.e. it should be foolproof!). At each move inform the user whose turn it is (i.e. it should be easy-to-use!) (f) Final feature: Once the above is all working, create an option for playing against the computer. While the computer does not need to play well, try to make the computer play as well as possible. 3

4 4. Crytopgraphy Write an encoder and decoder (as we did in class) but instead of the key being a shift, it should be a rearrangement of the 26 letters of the alphabet indicating how to do the substitution in the encoding. The encoder and decoder should take a file as input and create a file as output. For example if the key starts out: then ACE would be encoded as BYA. BSY JA... Also write a code cracker: It takes a coded file (and no key) and tries to decode the file using frequency analysis. To decode, it should take the file and an ordered list of the frequency of letters in English (call this the frequency list), starting with most frequent letter. The program should use the frequency list to try to crack the code by matching the frequency of letters in the coded file with the frequency list. For example, suppose the frequency list is as follows (middle missing): EIS... XZ Then the most frequent letter in the coded file would be replaced by E, the second most frequent by I, and so on. To emphasize: The frequency list is one of the inputs to the function; you do not need to find it. Once you have written the encoder, decoder, and code cracker, run experiments to see how good your code cracker is. Do this by: Taking longer texts, encoding them, and then running the code cracker on them; try different frequency lists and look up established frequency lists. The program should be fool-proof and easy to use, for example: If the key is too short or repeats letters, the program should ask for a new key (i.e. it should be fool-proof!). In using the program, it should clearly direct the user on what to input at each step (i.e. it should be easy-to-use!). Final Feature: Write another piece of code to determine a frequency list experimentally; call it the frequency finder. The frequency finder should read in a file and then output a frequency list of the 26 letters of the alphabet. Run the frequency finder on many files to come up with a frequency list, then use this frequency list on coded files to see how it works. 4

5 5. Simulation: Left, Right, Center This project is a mini-mini-research project. If you cannot deal with an open-ended project, choose something else! Consider the game of Left-Right-Center. For the rules, see your kit. Consider the game generalized to allow the players to start with a various amounts of starting chips (not just 3). Write a simulation that you use to answer the following questions as well as you can. (a) How long does the game last as a function of number of players and number of starting chips? (b) Consider the last question, but ask about how long the game lasts till one person gets to 0, or till two people get to 0, and so on? How about till half the people get to 0, and so on? (c) How is the game effected by starting the various players with an unequal number of starting chips? Test out various scenarios that seem interesting. (d) How are your answers to the last questions effected by changing the rules in various ways: i. Allow more dice. ii. Change the dice in various ways (example: make them 8-sided with 3 L s 4 R s and 1 C; etc) (e) Use the simulation to investigate other questions that occur to you (for example: if players were allowed to have a negative number of chips, how would you change the rules and how would the simultation answer the above questions differently?) 5