Project #3 Notes, Spring 2006
This is a collection of (hopefully) helpful notes concerning
the Jumping Cubes project.
- We've updated the rules to cover the case where one player wins, but
the spots never stop jumping. The stopping rule for dealing with
overfull squares now states that the game stops as soon as all
squares have the same color (and that player therefore wins). As
an example where this matters, consider a 3x3 board containing
2r 3b 2r
3r 4b 3r
2b 3b 2r
At this point, it is Blue's turn. However, the board is full, so
no matter what move he makes, there will be at least one overfull square
thereafter. However, since all the squares will also turn blue, we can
use that fact to stop and declare victory for Blue.
Q:
What exactly is the effect of 'auto'?
A: It causes Player #1's moves to be machine-generated in
playing mode. It does not have any effect until the 'start' command is
issued.
Q: Does finishing a game in effect execute a 'manual' command?
A: No. An 'auto' command, once issued, stays in effect after a
game terminates. It simply has no effect until the next 'start' command.
[5/3/2006]
You are not required to wait for multiple events simultaneously.
For example, while you wait for an opponent's move, you are not
required to notice that your user has typed in "quit". Yes, your program
will hang as a result; tough.
Now if you want to be able to wait for commands both from
Player #1 and Player #2, you'll probably want to make these Players into
threads. A simple technique might be to have them communicate with
the Game (which can just be the main thread) through one purely local
Mailbox, and to somehow tag each command with what player sent it.
The Game can then loop, receiving commands from this mailbox.
As I say, you may do that if you like, but we do not require anything
so elaborate.
[CS61B Home Page]
Page was last modified on Fri May 5 01:30:40 2006.
Address comments and questions to
cs61b@cory.eecs.berkeley.edu