Objectives:
1. Work with multiple processes
2. Become familiar with Inter-Process Communication
3. Gain experience with an IDE
Due: Wed. March 6, 2019 12:59 pm (via Blackboard)
Grade: 10% of your course grade
This lab can be done individually or in pairs. If you plan to complete in pairs, you must let me know preferably at the end of the lecture today or at the latest at the beginning of the lecture on Wednesday. For Lab 1 you may use any operating system that you prefer (Windows, Linus, UNIX, Mac OS) however using a version of Windows might be easier due to more availability of tools and online support.
You may write the program in any language that is supported under any Integrated Development Environment (IDE). Keep in mind that more help may be available to you in some languages (such as C or C++) than in others. You must demo your lab in class on the due date. If lab is done in a pair, one of the members will present it. You may bring a laptop to demo the program.
You are to implement a game of Hex. Your implementation should consist of three processes. Each process must have a visible window as it runs. The main process is the manager. It should start the other two (player) processes and manage the game. It is responsible for evaluating the game and declaring a winner or a tie. The player processes may be two copies of the same program. Use whatever mechanism you wish to coordinate among the manager and the player processes. You must include enough information in the displays of the player processes to convince me that the two processes are making the moves.
Hex is a 2-player game. In this case the two players are the child processes. You will simulate a 6×6 hex board. Here is a sample board.
The rules of Hex are very simple: The players take turns placing opposite colored markers on empty hexagons on the board. The players attempt to connect opposite sides of the board with a continuous line of pieces. (The line does not have to be horizontal or diagonal – it can twist and turn as it crosses the board. The first player must connect the (more or less) vertical sides, and the second player must connect the horizontal sides. The first player to connect his two sides of the board is the winner.
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, it will then ask the other player to make a move. Deciding if there is a winner may end up being one of the more interesting challenges of this lab. 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 player’s 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 I 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. You must provide for the mode: computer vs. computer; the mode of computer vs. human is optional (see extra points below). Note that the game itself is not the point of this lab. If you need to make assumptions, do so. When in doubt, ask.
Write-up:
You should submit a write-up which should include any known bugs and limitations in your programs. If you made any assumptions, document what you decided. This write-up should be submitted along with your code. Ideally, your program will be written with Visual Studio and I will be able to use the instructions in your write-up to run your program without your being there. I may attempt to run your submission without your presence or I may ask you to demo.
Submission:
You should ZIP your source files, executable and write-up into a single file and submit via blackboard. Be sure that you include everything necessary (or instructions on how) to unzip this file on another machine and compile and run it. This might include forms, modules, classes, configuration files, etc. Please do not include system development environment components such as VB or Java runtime system with code. It helps if you name your submitted zip file as “CSC3391-Lab1-SP2019-{Last name1}-{Last name2}”.
Please make sure your name is listed in your write-up, and in a comment in your source code. Late submissions will be accepted at a penalty of 10 points per day. If your program is not working by the deadline, send it anyway and review it together for partial credit. Do not take a zero on any lab just because the program isn’t working yet. Feel free to research the web on resources however do NOT copy other people’s work.
Grading:
This lab will be 10% of your course grade. The following point distribution will be used when 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
05 Termination of processes before exit
05 Comments in code
05 Write up
To receive full credit for comments in the code you should have headers at the start of every module/ subroutine/ function explaining the inputs, outputs and function of the module. (In VB, many modules will be sufficiently clear to need no other header.) 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.
Extra credit:
10 Support the mode of computer vs. human
05 Great Game board and graphics
Important Note:
You may discuss the lab requirements and the project design with others. All other work must be your own or pair. You may not discuss or share code and implementation. You may use any book, www reference or other people’s programs (but not those of other students in the class) as a reference as long as you cite that reference in the comments. If you use parts of other programs YOU MUST CITE THOSE REFERENCES. If I detect that portions of your program match portions of any other student’s program it will be presumed that you have collaborated unless you both cite some other source for the code. You must not violate university laws or professional ethics as described in class syllabus.
