Description
Purpose
In this assignment, you will write a group of three C99 programs to play a game (described later). One of the
programs will be called 2310dealer it will control the game. The other two programs (2310A and 2310B will
be players.
The dealer will be responsible for running the player processes and communicating with them via pipes
(created via pipe()). These pipes will be connected to the players’ standard ins and outs so from the players’
point of view, communication will be via stdin and stdout.
Other than the dealer starting player processes, there should not be any other parallelism used in this
assignment. For example, no multi-threading nor non-blocking operations. Your programs are not permitted
to start any additional processes1 nor are your programs permitted to create any files during their execution.
Your assignment submission must comply with the C style guide (version 2.0.4) available on the course
blackboard area. It must also not use banned functions or commands listed in the same place.
Game
What follows is an abstract description of the game. Precisely what your programs need to output will be
described separately.
The game is played using a sequence of sites called the path. Each site has a type and a limit of the number
of players that can visit that site. Each player starts the game with seven money. Players take turns
moving forward some number of steps, the type of site they end on determines what action they take.
1other than those specified on the dealer commandline arguments
1
Prepared for s4532397. Do not distribute.
Site types are:
Site Action taken by player
Mo gain 3 money.
V1 At the end of the game, gain 1 point for each V1
site they have visited.
V2 At the end of the game, gain 1 point for each V2
site they have visited.
Do Convert all money into points (1 point for each 2
money spent; rounded down).
Ri draws the next card from the item deck.
:: No action. But all players must stop at this site.
(This type of site will be referred to as a barrier)
Each card in the item deck is represented by a single character {A, B, C, D, E}.
Turn order
At the beginning of the game, players will be arranged with the smallest player-id furthest from the path; in
increasing order so the highest player-id is closest to the path. eg:
:: Mo1 Do1 Ri1 Ri1 ::
1
0
Note that:
• each site label is followed by a space (including the final barrier).
• all lines in the path display should have trailing spaces added as necessary to make them the same length
as the top line.
The next player to make their move is the one furthest back. This means that a player which makes smaller
steps may get more turns. The largest move a player can make is to move directly to the next barrier.
For example:
:: Mo1 Do1 Ri1 Ri1 ::
0 1
Player 0 is furthest back so it is their turn. Player 0 moves one step.
:: Mo1 Do1 Ri1 Ri1 ::
0 1
Player 0 is furthest back so it is their turn. Player 0 moves two steps.
:: Mo1 Do1 Ri1 Ri1 ::
1 0
Player 1 is furthest back. Player 1 moves two steps.
:: Mo1 Do1 Ri1 Ri1 ::
0 1
Player 0 moves one step.
:: Mo1 Do1 Ri1 Ri1 ::
1
0
2
Prepared for s4532397. Do not distribute.
Game end
The game ends when all players have moved to the final barrier site.
Sites with limit >1
Some sites will allow multiple players to visit. For turn order purposes, players at a site take turns in order of
most recent arrival. Barrier sites are assumed to have enough capacity to hold all players.
:: Do1 Ri1 Ri1 :: Mo1 Mo1 ::
0 1 2
Player 0’s turn.
:: Do1 Ri1 Ri1 :: Mo1 Mo1 ::
1 2
0
Player 1’s turn.
:: Do1 Ri1 Ri1 :: Mo1 Mo1 ::
2
0
1
Player 1’s turn.
:: Do1 Ri1 Ri1 :: Mo1 Mo1 ::
2 1
0
Player 0’s turn.
:: Do1 Ri1 Ri1 :: Mo1 Mo1 ::
2 1 0
Player 2’s turn.
:: Do1 Ri1 Ri1 :: Mo1 Mo1 ::
1 0 2
Player 1’s turn
:: Do1 Ri1 Ri1 :: Mo1 Mo1 ::
0 2
1
Points from items
At the end of the game, players gain points based on the item cards them have collected.
• Each complete set of ABCDE is worth ten points.
• Each set of four types is worth seven points.
• Each set of three types is worth five points.
3
Prepared for s4532397. Do not distribute.
• Each set of two types is worth three points.
• A single type is worth one point.
For example:
• AAABCCDE → ABCDE + AC + A = 10 + 3 + 1
• AABBBCCDDDEE → ABCDE + ABCDE + BD = 10 + 10 + 3
Note: a player’s total score includes both points from items and points derived in other ways.
2310dealer
The dealer will take the following commandline arguments (in order):
• the name of the file to read the item deck from.
• the name of the file to read the path from.
• one or more player programs to start
Eg: ./2310dealer d1.deck 1.map ./X ./X ./Y
Would start a game with two X players and a Y player.
Note: your dealer should run whatever program names it is given. Do not try to adjust your dealer’s
behaviour based on the names it is passed.
When running player processes, the dealer must ensure that any output to stderr by players is supressed.
As soon as the dealer reads a ˆ from a player process, the dealer should send the path to that player.
When the dealer receives SIGHUP, it should kill and reap any remaining child processes. Note: We won’t
test the exit status for 2310dealer when it receives SIGHUP.
Deck file format
Deck files consist of a single line beginning with the number of cards in the deck. The cards immediately follow
the number and are represented by the characters ’A’. . . ’E’ (inclusive). The line must have at least four cards
in it and must be terminated by ’\n’.
For example:
7ABACDEE
Note: We won’t test for leading or trailing whitespace in this file.
If the dealer runs out of cards in the deck, go back to the beginning of the deck and keep going.
Path file format
The file consists of a single line of text (‘\n’ terminated). The line begins with the number of stops in the path
followed by a semi-colon. The rest of the line represents the path.
Barriers will be represented as ::-. All other types are encoded as type {Mo, V1, V2, Do, Ri} followed
by capacity (a number between 1 and 9 inclusive) The path must start and end with :: sites. Paths must
contain at least two sites.
For example: 7;::-Mo1V11V22Mo1Mo1::-
4
Prepared for s4532397. Do not distribute.
Dealer output
All of the following output is to stdout.
At the beginning of the game the dealer will display the path. After each valid move received from a player,
the dealer will print information about the moving player:
• Player ? Money=? V1=? V2=? Points=? A=? B=? C=? D=? E=?
substitute in the current amount of each the player has.
Then redisplay the path. Eg:
:: Mo V1 V2 Mo Mo ::
0 1
Each site takes 3 columns (first two are the label for the site followed by a space). The ids of the players are
output (vertically) in the first column of the site. The other two columns of the site are spaces.
At the (normal) end of the game, print out the scores in player order (comma separated, newline terminated).
eg:
Scores: 5,3,5
Dealer errors
All error output to be sent to stderr. Check the following conditions in order:
Exit Condition Message
0 Normal end
1 Incorrect number of args Usage: 2310dealer deck path p1 {p2}
2 Invalid deck file or contents Error reading deck
3 Invalid path file or contents Error reading path
4 Error starting one of the players Error starting process
5 Communications error Communications error
The dealer should check whether the site a player wishes to move to is valid, including if it would move past
a barrier site.
Players
All player processes take the following commandline arguments (in order):
• Number of players
• This player’s ID (starting at 0)
Once the player has checked its commandline arguments, it should:
1. Print a caret(ˆ) to its standard out (no newline following it).
2. Read the path from stdin (in the same format as the path file).
Regarding strategy: you must always check to see if there is a “barrier” site between the player and the site
they would have chosen. The player must not move past a barrier in order to reach their destination. For the
purposes of strategy, sites past the next barrier should be ignored. When looking for closest sites of a given
type, ignore any sites which are full.
5
Prepared for s4532397. Do not distribute.
Player A strategy
In the following, check the following in order, stop when a condition matches.
• The player has money, and there is a Do site in front of them, go there.
• If the next site is Mo (and there is room), then go there.
• Pick the closest V1, V2 or ::, then go there.
Note that this player does not visit Ri sites. Your players should still be able to cope with other players
visiting them.
Player B strategy
In the following, check the following in order, stop when a condition matches. Where there is more than one
possible match within a single rule, choose the closest one.
• If the next site is not full and all other players are on later sites than us, move forward one site.
• If we have an odd amount of money, and there is a Mo between us and the next barrier, then go there.
• If we have the most cards or if everyone has zero cards and there is a Ri between us and the next barrier,
then go there. Note: “most” means than noone else has as many cards as you do.
• If there is a V2 between us and the next barrier, then go there.
• Move forward to the earliest site which has room.
Player output
Players should produce the same output as described in the “Dealer output” section, but must send it to stderr
instead of stdout.
Player errors
All error output should be sent to stderr. Check the following conditions in order:
Exit Condition Message
0 Normal end
1 Incorrect number of args Usage: player pcount ID
2 Player count is < 1 (or contains invalid chars) Invalid player count
3 Player-id is < 0 or ≥ playercount (or contains invalid chars) Invalid ID
4 Error in path Invalid path
5 Early game over Early game over
6 Communications error Communications error
Communications errors from the player’s point of view include:
• unexpected EOF on stdin
• messages not being in the correct format
• messages that describe non-existent players or site numbers.
We will not test other types of semantically invalid content (eg moving backwards or gaining points on the
wrong type of site) to players. You are free to flag such messages as invalid if that makes your coding easier.
6
Prepared for s4532397. Do not distribute.
Messages
Direction Format Detail
dealer → player YT Player should send back a move
player → dealer DOn Player wants to move to site n (beginning at zero)
dealer → all EARLY Game ended early due to comms error
dealer → all DONE Game ended normally
dealer → all HAPp,n,s,m,c A player made a move.
p=player-id
n=new site for player
s=additional points for player
m=change in money for player (This could be < 0)
c=card drawn by player (0, 1=‘A’, . . . 5=‘E’)
For any of the fields in HAP messages which do not apply, use zero.
Compilation
Your code must compile (on a clean checkout) with the command:
make
Each individual .c file must compile with at least -Wall -pedantic -std=gnu99. You may of course use
additional flags but you must not use them to try to disable or hide warnings. You must also not use pragmas
to achieve the same goal. Your code must be compiled with the gcc compiler.
If the make command does not produce one or more of the required programs, then those programs will not
be marked. If none of the required programs are produced, then you will receive 0 marks for functionality. Any
code without academic merit will be removed from your program before compilation is attempted [This will be
done even if it prevents the code from compiling]. If your code produces warnings (as opposed to errors), then
you will lose style marks (see later).
Your solution must not invoke other programs apart from those listed in the command line arguments for
the dealer. Your solution must not use non-standard headers/libraries.
Submission
No late submissions will be marked for this assignment under any circumstances. Submission must be made
electronically by committing using subversion. In order to mark your assignment, the markers will check
out /trunk/ass3/ from your repository on source.eait.uq.edu.au. Do not create subdirectories under
/trunk/ass3/. The marking may delete any such directories before attempting to compile. Code checked
in to any other part of your repository will not be marked.
Test scripts will be provided to test the code on the trunk. Students are strongly advised to make use of this
facility after committing.
Note: Any .h or .c files in your trunk/ass3 directory will be marked for style even if they are neither
linked by the makefile nor #included by some other file. If you need help moving/removing files in svn, then
ask. Consult the style guide for other restrictions.
You must submit a Makefile or we will not be able to compile your assignment. Remember that your
assignment will be marked electronically and strict adherance to the specification is critical.
7
Prepared for s4532397. Do not distribute.
Marks
Marks will be awarded for both functionality and style.
Functionality (42 marks)
Provided that your code compiles (see above), you will earn functionality marks based on the number of features
your programs correctly implement, as outlined below. If only some of your programs compile, the ones which
compile will be marked. 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.
• 2310A player
– Arg checking (2 marks)
– Initial path output (2 marks)
– Making first move (2 marks)
– Complete games as solo player (2 marks)
– Complete games with multiple players (2 marks)
– Early disconnect and comms error handling (3 marks)
• 2310B player
– Arg checking and initial path output (2 marks)
– Initial move (2 marks)
– Complete games (4 marks)
– Early disconnect and coms error handling (1 marks)
• For dealer
– Argument checking (2 marks)
– Starting player checks (2 marks)
– Complete game with only 2310A players (5 marks)
– Complete game with unspecified players (9 marks)
– Comms error handling, early disconnect and SIGHUP handling (2 marks)
Style (8 marks)
Style marks will be calculated as follows:
Let A be the number of style violations detected by simpatico plus the number of build warnings. Let H be the
number of style violations detected by human markers. Let F be the functionality mark for your assignment.
• If A > 10, then your style mark will be zero and M will not be calculated.
• Otherwise, let MA = 4 × 0.8
A and MH = MA − 0.5 × H your style mark S will be MA + max{0, MH}.
Your total mark for the assignment will be F + min{F, S}.
8
Prepared for s4532397. Do not distribute.
Specification Updates
It is possible that this specification contains errors or inconsistencies or missing information. It is possible that
clarifications will be issued via the course website. Any such clarifications posted 5 days (120 hours) or more
before the due date will form part of the assignment specification. If you find any inconsistencies or omissions,
please notify the teaching staff.
Example session
./2310dealer d1.deck p1.path ./2310A ./2310A
:: Mo V1 V2 Mo Mo ::
1
0
Player 0 Money=10 V1=0 V2=0 Points=0 A=0 B=0 C=0 D=0 E=0
:: Mo V1 V2 Mo Mo ::
1 0
Player 1 Money=7 V1=1 V2=0 Points=0 A=0 B=0 C=0 D=0 E=0
:: Mo V1 V2 Mo Mo ::
0 1
Player 0 Money=10 V1=0 V2=1 Points=0 A=0 B=0 C=0 D=0 E=0
:: Mo V1 V2 Mo Mo ::
1 0
Player 1 Money=7 V1=1 V2=1 Points=0 A=0 B=0 C=0 D=0 E=0
:: Mo V1 V2 Mo Mo ::
0
1
Player 1 Money=10 V1=1 V2=1 Points=0 A=0 B=0 C=0 D=0 E=0
:: Mo V1 V2 Mo Mo ::
0 1
Player 0 Money=10 V1=0 V2=1 Points=0 A=0 B=0 C=0 D=0 E=0
:: Mo V1 V2 Mo Mo ::
1 0
Player 1 Money=13 V1=1 V2=1 Points=0 A=0 B=0 C=0 D=0 E=0
:: Mo V1 V2 Mo Mo ::
1 0
Player 1 Money=13 V1=1 V2=1 Points=0 A=0 B=0 C=0 D=0 E=0
:: Mo V1 V2 Mo Mo ::
0
1
Scores: 1,2
In the above, Player 0 recieved:
7;::-Mo1V11V22Mo1Mo1::-
YT
HAP0,1,0,3,0
HAP1,2,0,0,0
YT
HAP0,3,0,0,0
9
Prepared for s4532397. Do not distribute.
HAP1,3,0,0,0
HAP1,4,0,3,0
YT
HAP0,6,0,0,0
HAP1,5,0,3,0
HAP1,6,0,0,0
DONE
Player 0 sent to standard out:
ˆDO1
DO3
DO6
10
Prepared for s4532397. Do not distribute.
Tips and Fixes
1. Your work will be made much easier if you place code used in multiple places into a source file shared by
multiple programs. eg:
• Encoding and decoding messages
• Where is the next site of type X?
2. Write some test code to check shared functions before using them in the programs.
3. Remember that there is no ‘\n’ after the initial ‘ˆ’
4. Do not make your players’ behaviour depend on argv[0]. There is no guarantee that programs will be
named the way you think they will.
5. Use tee to capture the input and output to your players for debugging purposes.
6. Messages not terminated by ’\n’ (ie EOF happens), should still be processed.
7. You are not permitted to use non-blocking I/O in this assignement.
8. You are not permitted to use multi-threading in this assignment.
9. We strongly recommend not using read() or write() in this assignment fread() and fwrite() are
better but still not as useful as you might think.
10. Start work on the players (remember you can feed input to them via standard in).
Changes 3.2 → 3.3
1. Having the “most cards” in the B player means that the player has strictly more cards than any other
player.
2. Note that the points in B player strategy should be checked in order.
3. Recording what we’ve said on piazza — paths must have at least two sites in them.
4. Added an example path output to the Dealer output section. Previous versions said to look in at the Turn
order section. The problem with that was that those examples have the site capacities in them which your
programs are not supposed to output.
5. If the dealer receives an invalid message eg: EOF, Player moving to illegal location, . . . the dealer ends
with communications error (after informing the players via an “EARLY” message).
6. Corrected typo “in order of most recent arrival” instead of “in order or most recent arrival”.
Changes 3.1 → 3.2
1. Corrected sample session to reflect behaviour A spec.
2. Added note about “next” site in behaviour description.
11
Prepared for s4532397. Do not distribute.
Changes 3.0 → 3.1
1. Added game end description.
2. Added that score includes both items and other points.
3. Removed stray reference to Si site.
4. Cards in HAP messages are sent as integers {0, . . . 5}. Zero indicates “no card”.
5. Put deck file parameter back in dealer usage message.
6. Fixed references to hub.
7. Fixed due date to match ECP.
8. Fixed typo in movement example (fixes @466)
9. Specify which components of HAP can be negative.
10. Change to first point of player B strategy.
11. Change to last point of playerB strategy (skip any sites which are full when moving to next site).
12. Modify player error criteria to include invalid chars.
13. Reorder dealer error checks to be consistant. The exit statuses from dealer have changed.
14. Fixed marking scheme to total 42.
15. Sites V1 and V2 only grant points at the end of the game.
16. Tip: Always use the ’p’ forms of exec. (This allow scripts to act as players.)
17. Added sample session.
12
