Escolar Documentos
Profissional Documentos
Cultura Documentos
Summer 2015
winner. For more information, see http://vanshel.com/Hexy/ . You can get a lot of
information from internet about this game and sample programs.
You must show a game board on the manager process window so that the user can see the
status of the game. The board does not have to be this elaborate.
The manager process will tell one of the player processes to make a move. Once the
move is made and communicated back to the manager, the manager will update its
display, decide if there is a winner, and if not, will wait for the user to click a button on
the manager display before the next move is made. (Deciding if there is a winner may
end up being one of the more interesting challenges of this lab.) It will then ask the other
player to make a move. The player processes do not have to have a strategy - they can
just move at random. It will probably be more interesting if you try to make a players
next move somewhere close to its last move, although I believe it has been proved that
the game can never end in a draw.
If the parent process detects a winner, it should display a message in its window about the
outcome of the game and give the user an option to play again or terminate the game. If
the user elects to terminate the game then the parent should end the game in an orderly
way: i.e., the child processes should be stopped first and then the parent process can
terminate. Again, this should be done in such a manner that the TA could see that each
child (or both) has ended before the parent ends. If the user elects to play again then the
players will have to be able to reinitialize the game and to realize that they are being told
to do so. Three different types of game mode are possible: Computer vs. Human,
Computer vs. Computer, and Human vs. Human. You must provide Computer vs. Human
mode. The other two modes, i.e., Computer vs. Computer or Human vs. Human are
optional.
Note that the game itself is not the point of this lab. If you need to make assumptions, do
so. When in doubt, ask the professor or the GA.
Write-up
You should submit a write-up as well as your program. Your write-up should include any
known bugs, limitations, and assumptions in your program. This write-up should be in
text-format and titled as README. It should be submitted along with your code. GA
will use the README file to compile (or install) and run your program. If the GA has
trouble with your program then he will contact you to makeup it.
Submission
You will submit your program using Canvas Assignment
(https://bridgeport.instructure.com/login ). If you have any trouble to use Canvas, you can
contact GA or instructor.
You should zip your source files and write-up (README) into a single file and submit it.
Be sure that you include everything necessary to unzip this file on another machine and
compile and run it. This might include forms, modules, classes, configuration file, etc.
DO NOT include the executable file itself, we will recompile it. The name of your
submitted zip file should be your UB account_ID_Project1. For example,
jelee_000000_Project1.zip.
Make sure your name and UB ID are listed in both your write-up and source code. You
may resubmit your program at any time. However, please do not ask the GA to grade
your program and then resubmit it. The submission time of the latest submission will be
used for determining whether the assignment is on time or not. Late submissions will be
accepted at a penalty of 10 points per day. In other words, it may pay you to do this
project early on the off chance that something prohibits your submitting it in a timely
way. If your program is not working by the deadline, submit it anyway and review it
together with GA for partial credit. Do not take a zero on any lab just because the
program isnt working yet. If you have trouble getting started, ask the professor or the
GA.
Grading
15 Multiple processes started successfully
20 GUI interface for each process working as required
30 Successful process control and communication
10 Legal moves only
10 Play next game with same processes
10 Termination of processes before exit
05 Comments in code + Write-up
Bonus +3 for each optional game mode
To receive full credit for comments in the code you should have headers at the start of
every module, subroutine, or function explaining the inputs, outputs and function of the
module. You should have a comment on every data item explaining what it is about.
(Almost) every line of code should have a comment explaining what is going on. A
comment such as /* add 1 to counter */ will not be sufficient. The comment should
explain what is being counted.