47.1 CS 3 Projects: general information(2 steps)

47.1.1 (Display page) Project information
CS 3 Big Project information
This document provides information about your last assignment in CS3: the big project. Included are details about the check-offs, working with partners, and other things of importance. There there two projects for you to choose from:

Connect Four - For the classic game of connect four, make the computer player smarter and write some basic representations.
Blocks World - Write the "smarts" of an artificial intelligence program that understands english commands to manipulate colored blocks.
You will choose a partner, if you wish, and do one of these for your final project. Descriptions of each project are in additional steps following this one.
Due Dates
There are four important dates in this assignment: three check-offs, and the final due date.
First Check-off. by the end of lab on Wednesday, August 6th, (whenever you have lab), you must explain to your Gilbert or Colleen which project you are choosing to work on along with the following information: who, if anyone, you're working on it with; how you plan to split the project between members of your partnership if you're working with a partner; and which parts of the project you plan to have ready for the next progress check. You also need to have a "to do" list for the project that contains all of the things you think you need to do to finish the project. Each step should also have a short description and a time estimate. You can revise these estimates, and while working on the project you should write down the actual amount of time that it took. If you do not do this during your lab, you will lose 5% of your total project score. Second Check-off. By Friday, August 8th During lab you must show Colleen or Gilbert significant progress on the project: some procedures coded and tested, with a fairly detailed plan for proceeding on the rest. (The individual project writeups have suggestions for what to provide.) We are looking for at least 50% of the code completed. Your "to do" list should be updated with any revised estimates and the actual amount of time each thing took. You won't be graded on how accurate your estimates are, but we want to see how your estimates changed and how accurate they were. If you do not do this during your lab, you will lose 5% of your total project score. Third Check-off. In lab on Monday, August 11th you must show Colleen or Gilbert an essentially complete program and . Your "to do" list should be updated with any revised estimates and the actual amount of time each thing took. You won't be graded on how accurate your estimates are, but we want to see how your estimates changed and how accurate they were. Again, if you do not do this, you will lose 5% of your total project score. Final Due Date. Your completed project program is due at the end of the day (midnight) on Tuesday, August 12th There is no leeway here; you will be penalized for a late submission. Be sure to submit your finalproject directory.
With these check-offs, you can't stay home or wait until the last minute to start your project. Even if you submit a perfect project, if you miss these three deadlines, you will get only 85% of the points.
Grading
The project is worth 30 course points, which works out to 15% of the points on which your final grade will be based. Half of the points will be awarded based on project correctness and adherence to specified requirements; the other half will be awarded for displayed correctness (test cases), readability, and the general case you make that your program works correctly. The points your project earns will be multiplied by a factor based upon the number of successfully completed checkoffs. For example, if you completed all of the checkoffs your project score will be multiplied by 100%. If you missed 1 checkoff it will be multiplied by 95%. If you miss 2, 90%. If you miss 3, 85% Readability includes comments, indenting, sequence of procedures in your file, appropriate use of Scheme (e.g. by avoiding the use of sentence/word procedures with lists), and choice of names for procedures and their placeholders. Some readability guidelines:
Procedures that deal with the same kind of structures should be together in your file, so that they are easy to find. Rather than using a cond with a zillion conditions, you should probably use assoc with a table or list-ref with a list. Use procedures for side effects only where necessary (e.g. to do output).
Your comments at the start of the program should include an overview of how all your procedures fit together. Each nontrivial procedure should be accompanied by a description of the procedure's purpose, a sample call, and the types and expected values for its inputs. Appropriate test cases are described in each project writeup. Also test your component procedures in isolation, to provide more evidence that they will work together correctly. Students in the past have attempted to fake their tests. This is not all that difficult to catch, since you are submitting your program solutions; the penalty will be a 0 on the project. To avoid looking like you faked your tests, be sure to re-run your tests after you make any final changes to your code.
Working in a partnership
You are encouraged though not required to do the project in a partnership of two. A partnership should turn in only one solution (with both your names and logins in it). A partnership should also supply a file named partners.readme that describes the following:

how you split the work between partners, and

how, if you were given 10 extra points to split between you, how you would distribute these points between you and your partner. (Both partners will receive the same project grade.)

Note that there will be no difference in how we assign grades between projects that were worked on by a partnership versus those worked on singly. They will be treated the same.
One final thing
Turning in unacknowledged code not written by members of your partnership or supplied by us constitutes cheating. It will be penalized by a grade of F in CS 3 and referral to the Office of Student Conduct. We value the benefits you get from working on a large project and in a partnership—please take this seriously and do the work honestly.
47.1.2 (Display page) Submission instructions

Final project submission instructions
From within unix, place your files in the directory finalproject and submit them with the command
submit finalproject
For the blocks project, your files should be named
blocks.scm
blocks.tests
For the connect 4 project, your files should be named
connect4.scm
connect4.tests

47.2 Blocks World(1 step)
47.2.1 (Display page) Blocks World project details

CS 3 "Blocks World" project

Background
Robotics is a leading research area in computer science. A program that controls a robot must represent the environment somehow, and be able to sense changes and update its internal representation accordingly. It must also be able to plan actions of the robot and anticipate possible consequences of those actions. Robots are often programmed to act autonomously; some, however, are guided through a user interface that may involve complicated language processing. This project is intended to give you a small taste of some of the programming techniques needed to guide a robot.

Project overview
In this project, you complete a program that manipulates stacks of blocks (all the same size) in a two-dimensional environment. In Scheme, the environment is represented by a list of stacks. A stack is represented by a list of blocks, which may be empty; the first block in the stack is the top block, which rests upon the second block, and so on; the last block in the stack rests on the table. A block is represented by a two-word sentence. The first element is the block's id number; no two blocks in the environment have the same id. The second element is the block's color. (The display system provides eight colors: black, blue , green, cyan, red, magenta, yellow, and white. Cyan is blue-green. Black blocks won't show up on the display very well.) An example appears below.

picture of environment Scheme representation

(((1 red) (2 cyan)) () ((4 red) (3 green)))

The program will read and execute commands that move blocks in the environment or request information about the environment. There are three kinds of commands: (quit) The quit command writes the current blocks environment to a file named blocks.out, and terminates the program. (put block-description1 on block-description2 ) The put command clears the tops of two blocks, then moves the first block onto the second. (what is preposition block-description ) The what is command is a question about the environment. ("On" and "under" are the prepositions that are legal in this command.) (add block-description)
The add command randomly adds a new block to an existing stack in the environment. Note, the block description in this command is a subset of the block description in other commands. (remove block-description)
The remove command with the above format will remove a single block, clearing blocks off the top of the target block as necessary. (remove number multiple-block-description)
The remove command, when followed by a number 2 or greater, should remove number blocks matching multiple-block-description from the environment. Blocks are not described by their ids, but may be described by their colors. Each block description is one of the following: "a block", "it", "a color block", or "the color block", except in the add command, where it is one of "a block" or "a color block". A multiple block description (only used in the remove n command) is one of the following: "color blocks" or "blocks". Block descriptions have different meanings in the different commands.

Block descriptions in the "put" command
In the put command, each block description must refer to exactly one block. For a block description that starts with "the", the environment is searched for blocks that qualify. If there is exactly one such block, that's the one that's referred to; otherwise, the program should print an error message and ignore the command. In the sample environment given previously, "the cyan block" refers to block #2; "the red block" is ambiguous and "the yellow block" is nonsense. For a block description that starts with "a", the environment is similarly searched for blocks that qualify. If there are one or more, one of the blocks that qualify is chosen randomly but in such a way that the block isn't moved on top of itself; otherwise, the program should print an error message and ignore the command. That means, for instance, that the command
(put a block on a block)
should always be legal in an environment with two or more blocks. The block description "it" is described below.

Block descriptions in the "what is" command
In the what is command, a block description that starts with "the" is handled as in the put command. Thus the response to
(what is on the cyan block)
should be
(1 red)
while the response to
(what is on the red block)
should be the error message
(more than one red block exist)
A block description that starts with "a" may refer to more than one block. For such a description, the response should include all the relevant blocks. For example, the response to
(what is under a red block)
should be
(2 cyan) (3 green)
It may happen that no blocks are on or under the specified block(s). The appropriate response is "nothing". For example, the question
(what is under a green block)
produces the response
(nothing)

Block descriptions in the "add" command
In the add command, a block description can only come in the form "a block" or "a color block". Descriptions starting with "the" or consisting of "it" should generate errors. Legal block descriptions to the add command are handled the same way as in the corresponding descriptions in put and what is commands. As a result, a call to add should create a new block. The block should have a unique id -- that is, a positive integer different than any of the ids of the other blocks in the environment. When the block description is "a block" and a random color should be chosen from the possible colors. The location of the block should be in a randomly chosen stack, placing the block on the top of any existing blocks in the stack. If your environment is empty, with no stacks, you should create an empty stack and add the new block to it. For example, the command
(add a green block)
given in the environment (((1 green) (2 blue)) ((4 white))) can result in the following environments:
(((3 green) (1 green) (2 blue)) ((4 white)))
or
(((1 green) (2 blue)) ((3 green) (4 white)))
Note, the "id" of the added block need not be 3, but cannot be 1, 2, or 4.

Block descriptions in the "remove" (a single block) command
Block-description should be checked in the same manner as put command: the description should refer to a single block. The target block should be removed from the from the environment.

Block descriptions in the "remove" (multiple blocks) command
The remove number command takes a multiple block-description, which is one of "blocks" or "color blocks". If there are not number blocks that satisfy the description in the environment, the command should return
(there are fewer than number color blocks)
or
(there are fewer than number blocks)
if a color was specified or not.

What is "it"?
"It" essentially means the block most recently mentioned or asked about. If this cannot be determined unambiguously, the program should print an error message and ignore the command. In the command following a successfully executed put command, "it" refers to the block moved. In the command following a successfully executed question, "it" refers to the answer. If there are more than one block in the answer, "it" is ambiguous in the following command. "It" is undefined in the command following a command that produced an error message.

Example
Given below is a sample dialog that illustrate how the program should behave. It starts with the environment given on the previous page.

command resulting environment
or response notes

(put the cyan block on a red block) Block #1 was moved to the table to clear the top of block #2. Then block #2 could be moved atop either of the red blocks.

(put it on the green block) "It" means block #2 here. That block didn't need to be cleared, but block #3 did.

(put it on the red block) (more than one red block exist) "It" still means block #2.

(put it on a red block) (please explain what is meant by "it") "It" was forgotten because of the error message.

(put the cyan block on a yellow block) (no yellow block exists)

(put a cyan block on a cyan block) (the cyan block cannot be moved onto itself) Putting a red block on a red block would work; one of the red blocks would be randomly chosen and moved atop the other one.

(what is on a red block) (nothing)

(put it on a cyan block) (please explain what is meant by "it") "It" is undefined here since nothing satisfied the preceding question.

(what is under the cyan block) (3 green)

(put it on a red block)

"It" is now block #3. Block #2 is moved to the table to clear block #3, and then one of the red blocks is randomly chosen for the destination.

(put the cyan block on the green block)

(what is on a block) (3 green) (2 cyan) The blocks could be listed in the opposite order.

(what is under it) (please explain what is meant by "it") The previous question was answered with two blocks, so "it" is ambiguous.

(what is on a yellow block) (no yellow block exists) An error message resulted instead of "nothing".

(put the cyan block on the green block)

A clever program would notice that the cyan block is already on the green block. Straightforward processing, however, would first move block #2 to the table, then move it back on block #3.

(put a red block on it)

"It" is now the cyan block. Choosing the other red block, block #1, would have required moving blocks #2 and #3 to the table before moving block #1 atop block #2.

(remove a green block)

We find block #3, clear everything on top of it, and then remove it.

(add a block)

Any block could have been added, but we randomly generated block #5 and placed it on the third stack.

(remove 2 red blocks)

block #1 and block #4 are removed.

(remove 3 blocks)
(there are fewer than 3 blocks)
There are only 2 blocks in the environment, so removing 3 is impossible.

Code you are to provide
A framework for this program appears here and in the file ~cs3/public_html/programs/blocks.fw.scm. It includes calls to two procedures that you are to write. 1. analyzed
Given a command submitted by the user, a blocks environment, and the current value of "it" as arguments, analyzed returns the result of translating the command to a form that's easier to handle and resolving references to "the ... block", "a ... block", and "it". If these references cannot be resolved successfully, analyzed returns #f .

A put command should be translated to a three-element list whose first element is the word put and whose second and third elements are blocks.

A what is command should be translated into a list of at least two elements whose first element is either under or on and whose remaining elements are blocks.

A add command should be translated into a list of two elements whose first element is the word add and whose second element is a block.

Either remove command should be translated into a list of at least two elements, whose first element is the word remove and whose remaining elements are blocks.

Analyzed is also where you should display error messages. Analyzed won't return an error message; rather, when there is an error, it will return #f. Within the body of the procedure, use the show function to display the appropriate error message.

command possible analyzed results

(put the cyan block on a red block) (put (2 cyan) (1 red)) (put (2 cyan) (4 red))

(put it on the green block) (put (2 cyan) (3 green))

(put it on the red block) #f

(put it on a red block) #f

(put the cyan block on a yellow block) #f

(put a cyan block on a cyan block) #f

(what is on a red block) (on (1 red) (4 red))
(on (4 red) (1 red))

(put it on a cyan block) #f

(what is under the cyan block) (under (2 cyan))

(put it on a red block) (put (3 green) (1 red)) (put (3 green) (4 red))

(put the cyan block on the green block) (put (2 cyan) (3 green))

(what is on a block) (on (1 red) (2 cyan) (3 green) (4 red)) (The four blocks may appear in any sequence in the list.)

(what is under it) #f

(what is on a yellow block) #f

(put the cyan block on the green block) (put (2 cyan) (3 green))

(add a green block) (add (5 green))

(remove it) (remove (5 green))

(add a block) (add (6 magenta))

(remove a magenta block) (remove (6 magenta))

(remove 2 blocks) (remove (2 cyan) (3 green))

(remove 2 red blocks) (remove (1 red) (4 red))

2. execute
Given an analyzed command, a blocks environment, and the current value of "it", execute executes the command by moving relevant blocks or answering the specified question. Execute then calls handle-cmds with the updated blocks environment and "it" values.
3. resolved-descr
Your code should include a procedure named resolved-descr (short for "resolved description"). Resolved-descr will take three arguments: a block description such as (a red block) , a blocks environment, and the value of "it". It will return a list of the blocks in the environment that satisfy the description. Thus
(resolved-descr '(a red block) '(((1 red) (2 cyan)) () ((4 red) (3 green))) '( ) )
should return
((1 red) (4 red))

Miscellaneous requirements
In the what is command, "under" means "directly under" and "on" means "directly on". Thus in the environment
(((1 red) (2 green) (3 blue)))
the command
(what is under the red block)
should only list (2 green) , not (3 blue) . Similarly, the command
(what is on the blue block)
should list only the green block, not the red block. The two versions of the what is command—"what is on ..." and "what is under ..."—have almost identical behavior. You should minimize the amount of duplicate code you use to implement these two types of command. In both the analyzed and the execute procedures (and in your helper procedures), "it" is to be represented as a list of blocks. An undefined "it" is represented by the empty list; an ambiguous "it" corresponds to a list that contains more than one block. In the situation where a block is to be moved to an empty stack and the environment doesn't contain any empty stacks, an empty stack should be added to the end of the list and the block moved there. For example, moving block #2 to the table in the environment
(((1 red)) ((2 green) (3 blue)))
(which consists of a stack containing one red block and a stack containing a green block and a blue block) should produce the environment
(((1 red)) ((3 blue)) ((2 green)))
Don't rearrange the stacks while moving. Your program should simulate a robot that moves single blocks from stack to stack; it shouldn't move entire stacks at once. You may assume that the environment read from the file is a legal and reasonable one. That is, it's a list of stacks, each of which is a list of blocks, with each block having a unique id number and a legal color, and there are at least two blocks in the environment. You may also assume that user commands are formatted correctly as described on the previous page. The errors you must detect are the following:
referring to "the" block when there aren't any, or more than one;

trying to move a block on top of itself;

referring to "it" when it's not defined, or is ambiguous.
Any error message not involving "it" must name the color of the relevant block(s). Don't change the framework code we provide. We will be testing analyzed, execute, and resolved-descr in isolation so they need to return values in a format exactly like the examples above. Put your completed program in a file named blocks.scm in a directory named finalproject. In a file named blocks.tests , include tests that exercise your program completely. (Also provide the file partners.readme if you're working in partnership.) Provide example runs in which all the commands, block specifications, and error conditions appear. The example dialog on the previous page is a good start. You should also include commands such as
(put a red block on a red block)
and
(put it on a red block)
with environments that contain two red blocks and a red block identified as "it". Test your procedures individually as well as in combination, and include the results of these tests in your blocks.tests file.

Suggested approach
One possible approach to this project would be to design and test the blocks movement procedures first. (Our solution uses three: one to clear a block, another to move a block to the table, and a third to move one block on top of another.) Since these procedures only involve blocks environments—actually, they only involve lists of sentences—they will be easy to test in isolation. Another approach is to focus on the command analysis first. The put command can be implemented separately from what is; the resolved-descr procedure, as mentioned above, will be useful for both.
47.3 Connect4(1 step)
47.3.1 (Display page) Connect4 project details
CS3 Project: Connect Four
In this project, you will finish a program that plays the game Connect Four. You will need to understand the framework code, come up with a storage structure for the board, write some "smarts" for the computer player, and implement a "bomb" piece.
Background
The game Connect Four involves dropping pieces into a board that is seven spaces wide by six spaces high (making 7 columns by 6 rows). Two players alternate turns and the first to place four pieces in a row (either horizontally, vertically, or diagonally) wins. The board is held vertically, and a player only chooses which column to place a piece; the piece will fall to the lowest unoccupied row. Connect Four is a very old game, although the name comes from a board game released by Milton Bradley. There are many on-line versions of Connect Four available, and it will be especially valuable for you to familiarize yourself with it through playing games. As it turns out, the game has recently been "solved", and a computer can be programmed to play perfectly (you are not being asked to program a perfect solution, however!). The wikipedia entry (at http://www.wikipedia.org/Connect_Four) has a bit more information (much has been deleted recently, it seems), while the wikibooks entry may have too much. One version can be played here. While the standard version of Connect Four involves two players on a 7x6 board, the program you write will be able to handle any number of players and any (reasonably) sized board. We won't test it with anything that wouldn't fit on the screen.
Framework code
The framework code, available at here, is able to play on a board that is only one row high right now. Additionally, any computer player is quite stupid, choosing randomly when placing a piece, and the game doesn't correctly end when four pieces are place in a row. It also has some bugs, like accepting moves that are outside the width of the board. The framework code contains several distinct groups of procedures:

Code to represent a "player" with a name, a piece color, and a way to choose a next move for that player. Constructors and selectors for a player are included. (You need to add some code here)

Code to represent a "board". (You will be changing this.)

Code to play the game and take turns.

Code to represent moves, which in most cases is a 0-based column index. That is, the move 0 means the piece is to placed in the left-most column. Also in this section are procedures to get next moves for humans and computer players. (You'll need to change the code that figures out the computer's next move.)

Graphics routines, divided into a few straightforwards ones and a bunch of ugly ones you can safely ignore. (You will need to change one of the straightforward procedures.)

The first thing you should do is spend some time investigating how these procedures work together, playing the one-row-high game and testing out individual procedures. Understanding the existing code will help you complete the tasks below.
Problem
There are three tasks that you need to complete. 1) Represent a two dimensional board.
In the framework code, a board is represented by "association lists" of column and piece color. In this scheme, there is no way to keep track of the row in which a piece sits. You will need to choose a way to store which pieces are currently in a two-dimensional board of any (reasonable) size. You probably don't want to use the association list strategy that was used in the framework code. You will need to change all of the procedures that are in the "board" section of the code,

new-board: the constructor, returns an empty board for a new game

possible-move?: returns #t or #f depending on whether the player can make the move.

add-piece: returns an updated-board after a player has made a certain move

winner?: a predicate that determines whether the last move created a winning position for a player

as well as the procedure

draw-pieces: goes through each piece on the board and calls the graphics routine draw-piece. This is in the section titled "drawing the board", near the end of the framework code.

Any representation you come up with that can correctly implement these 5 procedures is fine for the purposes of this project. This is the whole point of data abstraction! Be sure not to change the arguments that the procedures take or the type of return value that they provide: this is also an important part of data abstraction. (For instance, don't change how a move is represented, or which arguments add-piece takes). There are several different strategies you can use in task 1, and your choice will make some of the 5 procedures easier (or more difficult) to write. Remember, any solution you implement will have to work with variable sized boards. Make sure to test things out by changing *board-width* and *board-height* (using define) and starting a new-game without restarting STk.
2) Make the computer play smarter
In the end of the section titled "moves", the procedure get-computer-move takes a board and a computer player and decides what the computer should do. To this end, it first determines if there are any moves that the computer can make. If there is at least one, it chooses the best one, prints out its choice, and returns that best move. In the framework code, the computer chooses randomly from all the possible (non-bomb) moves that it can make. You need to fix things so that:

the computer will win if it can on its next move
the computer will choose a move, when it can, that blocks another player from getting 4-in-a-row on their next move.
the computer will make a random yet valid move if it can't win or block. (When the board is full, the only valid move is to quit).
Remember, you solutions need to work for games with more than two players. This will be particularly important to consider for the second point above. (If more than one opponent can win when the computer has to decide where to place its piece, you can block any of them). With your additions the computer will still be pretty stupid and, hopefully, easy to beat. If you want to implement more strategies, by all means feel free to do so:

If the computer can't win or block, have them choose a piece towards the middle of the board rather than the edges. (If the middle column isn't too high ).
If the computer can't win, have the computer choose bomb pieces some of the time (see below). Or, have it choose bomb pieces at good times.

Don't let the other player complete three in a row with open ends on either side, especially on the bottom row!

etc.

You'll need to be familiar with how a "move" is represented in the code. A move can be one of three things

a number that indicates the column to place a "normal" piece. This is 0-based, so 0 represents the left-most column.

a word starting with "b" and ending in a number (as above). This indicates a move to place a bomb piece.

#f, meaning there were no moves left to make or the player decided to quit.

3) Add "bomb" pieces
To make things more fun, you'll add functionality to allow players to place a certain number of "bomb" pieces during the game. A bomb piece should remove pieces in a 3x3 box centered on the space where is detonates. The bomb should detonate in the same cell as the topmost piece in the column it has been placed. (Note, the bomb will never remove a piece from the space above where it detonates, so it can remove at most 8 pieces). If, after removing the pieces in nearby columns, any still-remaining pieces are suspended they will need to drop into the lowest unoccupied space in that column. Bombs that are dropped on columns at the edges of the board will only affect two, rather than three, columns. It isn't clear how this will change the strategy of the game (we have no idea!), so after you get this and task 1 above working, you might play some human versus human games and see how things play out. If you want to change the default number of bombs available, or add additional special pieces please feel free to do so. Last semester, some students implemented a 'cb' or column bomb that when dropped on a column, deleted everything in that column. A few details:

To implement this, you will need to change the add-piece procedure from task 1 to correctly handle bomb moves.
After a bomb is played by a certain player, a different player may have 4-in-a-row. With the arguments to winner?, however, it is difficult to test this. You can assume that a player can only win on his/her/its turn. When the other player's turn comes around, he/she/it can win at that point.
If a bomb is dropped on a full column, it should detonate on the topmost piece. If a bomb is dropped in an empty column, it should fail to detonate at all (but, still count as a turn).
Think about how you're going to represent your board.
We have some cool bomb animations you can use if you want (this is optional). In order to do so, you need to call the procedure draw-bomb with a column and row number when you want the animation to take place -- presumably, sometime after you have figured out that somebody made a valid bomb move. You can see the draw-bomb procedure near where the draw-pieces procedure is defined.
You should copy the three bomb picture files -- bomb_s.gif, bomb_m.gif, and bomb_l.gif, available here -- into the same directory as your code. You'll notice that the framework code complains if it can't find these files. Make sure to start up emacs in the same directory as you have stored the files, or it may not find them!

Suggested approach and tips
Certainly, you want to implement task 1 first, and get the basic game working for two dimensional boards. You should have this working, or close to working, for checkoff #2. The winner? procedure is likely to be the most challenging part of task #1. As there are several different approaches you could go with, take time to plan, debate with your partner, and consult with your TA before you start. You can play a bomb-free games (human versus human as well as human versus computer) as soon as you finish task 1 -- even before you finish winner?, really. Definitely do this, to help you get a feel for the code as a whole. As you start to implement task 2, you may find that you want to change the board representation, or at the very least add more accessor procedures. Computer programming is an iterative process, and going back to improve one part of your code to make other parts easier to write is usually the right thing to do! The strategy used in tic-tac-toe should prove useful, in part. You should probably write a procedure opponents, which returns a list of the other players in the game. And, you will certainly make use of the winner? procedure you wrote for task #1! While you have things partially developed and are testing things, you may find that the graphics stop working properly. Usually new-game will fix things (by calling initialize-graphics), but you may need to quit and restart STk. It is particularly important, in task 1, for you to make an effort to implement add-piece correctly. We will use it to test your solution to task 1.

CS 3 Big Project information

Due Dates

Grading

Working in a partnership

One final thing

Final project submission instructions

CS 3 "Blocks World" project

Background

Project overview

Block descriptions in the "put" command

Block descriptions in the "what is" command

Block descriptions in the "add" command

Block descriptions in the "remove" (a single block) command

Block descriptions in the "remove" (multiple blocks) command

What is "it"?

Example

Code you are to provide

Miscellaneous requirements

Suggested approach

CS3 Project: Connect Four

Background

Framework code

Problem

Suggested approach and tips