programming of Inter-Process Communication

These will be individual projects. The main purpose of this programming assignment, i.e. Project 1, is to become familiar with the programming of Inter-Process Communication. For Project 1, you may choose any programming language, such as .NET, Visual C++, Java, C, etc. However, keep in mind that the first programming assignment (Project 1) includes Graphical User Interface. Therefore, the students are encouraged to choose the programming language that supports GUI, and runs on Windows. Also, the other OS that support GUI desktop, e.g. Gnome and KDE for Linux, are possible. Finally, your final program should be compiled and run on GA’s computer. To do that, you need to provide all materials as well as source code, such as run time module, integrated development environment (Visual Studio, .NET or C#), and any other program to run your 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 the TA 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 deceptively 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. For more information, see . 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 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 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 ( ). 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, “”. 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 isn’t working yet. If you have trouble getting started, ask the professor or the GA .