MCS-177 Project: Nim with Strategies

Due: April 28, in class

MCS 177: Computer Science I, Spring 2003
Recommended preparation and schedule


How do you modify the program for playing Nim so that the computer can play using different strategies? In this project, you should work through the exercises in section 6.5 (except for 6.20 and 6.21). Before coming to lab, be sure that you have read and understood sections 6.1-6.3 and the beginning of section 6.5, if you haven't already.

Computer Exercises

  1. Using your favorite method, save the file ~mc27/labs/nim/nim.scm somewhere under your home directory, and then evaluate everything in it in DrScheme. (Note: The easiest way to save the file is to go to the link, and then do a Save As... under the File menu in Netscape.) This file contains the Nim program and the game-state implementation from the book, except that computer-move and human-move are modified as indicated in exercise 6.13(c).

  2. In order to make the Nim program work, you will need an implementation of the move-instruction ADT (exercise 6.13(b)). For your convenience when doing the implementation of the move-instruction ADT, we have included ``stubs'' for the three ADT operations near the bottom of the file; the constructor is called make-move-instruction and the two selectors are called num-coins and pile-number. You should write them correctly by removing the error expressions which they currently contain and replacing them with the actual procedure bodies.

    Keep in mind that make-move-instruction just constructs a move-instruction object, while next-game-state actually performs the move.

    Once you have implemented the move-instruction ADT, you can test your implementation in two ways. First, you could test the ADT in isolation with expressions such as:

    (num-coins (make-move-instruction 4 2))
    Second, you can test the ADT in the context of the whole application by playing Nim games with the computer by evaluating, for example, the expression:
    (play-with-turns (make-game-state 5 8) 'human)
    Both kinds of tests are critical in any large application, so be sure to do both kinds of tests throughout this lab.

    Play a couple of games so that you get a hang of how the interaction works. (You needn't include transcripts of your game playing in the lab writeup.)

  3. Do exercises 6.14-6.19 in the text. When working with the random procedure, keep in mind that each time you use it you may get a different result; if you want to use the same randomly chosen integer twice, you should hold onto it, for example by naming it with a let, as you won't be able to regenerate it.

    Again, as with the move-instruction ADT, be sure to test each strategy in isolation as well as in the context of the whole application. If you are unsure about how to test the strategies in isolation, ask!

  4. Maintaining a modular program is critical to the success of any large programming project. A good way to test to be sure that your program is truly modular is to take out one working module, and swap it for a different, but also working, module. We'll do this, treating the move-instruction ADT as a module:

  5. (Optional) You are encouraged to do exercises 6.20 and 6.21 if you have time, but they are not required.

  6. (Optional) One other optional activity is to error-proof your Nim program, so that if the user enters an invalid move, the program handles the error appropriately. Ideally, you should have the program detect the invalid move, and then ask the user to enter a valid move instead. How can this be done most easily?

Project Report

As you know, we are assigning a specific style and audience for each report. For this project, the style might be called a "Strategy-writers' manual" and the audience should be programmers that want to extend the software system.

Your finished product in this project is a software system that allows users to play a game of Nim against various different strategies. Even though the game is relatively simple compared to games you might actually purchase, the situation is a familiar one: you have created a software system which might later be revised and extended by other programmers. Your task is to write a manual for future programmers describing the structure of the programming system and how they should go about extending that system.

More specifically, you first describe what your system is intended to do -- namely, playing a game of Nim, which you should briefly describe. Then you should explain the structure of your software system for programmers who are competent in Scheme, but are unaware of the system itself. Give a good overview of the structure of the software system, giving special attention to its two ADTs. Furthermore, explain what a strategy is (as a Scheme procedure) and how a programmer should go about writing a new strategy for the system. You may also, if you wish, add suggestions for possible improvements or extensions that could be made to the system.

For the purposes of my grading your report, I ask that you also include an appendix that includes all of the system's code, and in particular all of the procedures you wrote. You should also describe the testing you did on those procedures. This should include examples of the testing, but should also be descriptive of your general testing strategy.

You can get some sense of how this project report will be graded by looking at the grading sheet that we use.