Reference no: EM13833903
In this assignment, you will write two programs to play a card game ("clubs"). A separate document describing the rules of "clubs" will be provided.The first program (clubber) will listen on its stdin for information about the game and give its moves to stdout.The program will send information about the state of the game to stderr.The second program (clubhub) will start a number of processes (eg clubber) to be players and communicate with them via pipes. The hub will be responsible for running the game (sending information to players; processing their moves and determining the score). The hub will also ensure that, information sent to stderr by the players, is discarded.
Your programs must not create any files on disk not mentioned in this specification or in command line arguments. Your assignment submission must comply with the C style guide (version 2.0.2) available on the course blackboard area. This is an individual assignment. You should feel free to discuss aspects of C pro-gramming and the assignment specification with fellow students. You should not actively help (or seek help from) other students with the actual coding of your assignment solution. It is cheating to look at another student's code and it is cheating to allow your code to be seen or shared in printed or electronic form.
You should note that all submitted code may be subject to automated checks for plagiarism and collusion. If we detect plagiarism or collusion, formal misconduct proceedings will be initiated against you.
A likely penalty for a first o
ence would be a mark of 0 for the assignment. Don't risk it! If you're having trouble, seek help from a member of the teaching sta
Don't be tempted to copy another student's code.
As with Assignment 1, we will use the subversion (svn) system to deal with assignment submissions. Do not commit any code to your repository unless it is your own work or it was given to you by teaching staff. If you have questions about this, please ask.
Functionality
Provided that your code compiles (see above), you will earn functionality marks based on the number of features your program correctly implements, as îutlined below. Partial marks may be awarded for partially meeting the functionality requirements. Not all features are of equal difficulty. If your program does not allow a feature to be tested then you will receive 0 marks for that feature, even if you claim to have implemented it. For example, if your program can never open a file, we can not determine if your program would have loaded input from it. The markers will make no alterations to your code (other than to remove code without academic merit). Your programs should not crash or lock up/loop indefinitely. Your programs should not run for unreasonably long times.
• (Player) argument checking
• (Player) correctly handles early hub loss and "end" message
• (Player) Correct choice for initial move
• (Player) Correctly handle one round
• (Player) Correctly handle complete game
• (Player) Detect invalid messages
• Hub argument checking
• Detect failure to start players
• Correctly handle players which close early
• Correctly handle 2 player games using a single deck
• Correctly handle invalid messages / invalid plays
• Play complete games with 2 players
• Play complete games with 3 and four players
• Correctly cleanup still running subprocesses on exit
The items marked (Player) indicate that the player will be tested independently of the hub (so the hub does not need to be working in order to get these marks). Keep in mind that tests of complete games may use varying numbers of deck in the deckfile.
Style
If g is the number of style guide violations and w is the number of compilation warnings, your style mark will be the minimum of your functionality mark and:
8 x 0.9g+w
The number of compilation warnings will be the total number of distinct warning lines reported during the compilation process described above. The number of style guide violations refers to the number of violations of the current C Programming Style Guide. A maximum of 5 violations will be penalised for each broad guideline area.
The broad guideline areas are Naming, Comments, Braces, Whitespace, Indentation, Line Length and Overall. For naming violations, the penalty will be one violation per offending name (not per use of the name) up to the maximum of five. You should pay particular attention to commenting so that others can understand your code. The marker's decision with respect to commenting violations is final - it is the marker who has to understand your code.
To satisfy layout related guidelines, you may wish to consider the indent(1) and expand(1) tools. Your style mark can never be more than your functionality mark - this prevents the submission of well styled programs which don't meet at least a minimum level of required functionality.
Attachment:- Assignment.rar