XJCO1711 Coursework 2 (22/23)
1. Guidance
Programs must be implemented in C. You can develop your solutions on any suitable platform.
Programs must compile and run on linux. It is your responsibility to test this before submission, in
particular that the application builds with ‘make’.
Work submitted is expected to be your own work. Discussion of the work is permitted. Sharing of
your code is strictly not permitted. Please read the guidance on Academic Integrity.
Please use the labs for individual help with this work. You can post questions on Class Teams but
please do not post code to the group. If you send individual Teams messages or email on the work,
answers will be posted to the Class Teams area.
2. Submission of work
Work can be submitted from now until 10am (UK time) on Wednesday 14th December. Late
penalties are applied after that date.
You should submit a single zip file for each part, cwk2.zip, containing only your source code (.c and .h
only).
Gradescope will use a pre-defined Makefile – do not upload your own version.
In your working folder compress only the source (.c) and header (.h) files. For example, on linux:
zip cwk2.zip *.c *.h
Work is submitted on Gradescope. You will get immediate feedback on only the compilation of your
code. You will see a grade of 1 awarded if this is successful. If your code does not compile or you see
a grade of 0 then compilation has failed and no further tests will run. You will receive an email
confirming submission if it is successful. You can submit multiple times.
It is your responsibility to test your code so that it meets the specification.
Further tests will not run until after the deadline.
There are 2 parts to the work described below and 2 submission points on Gradescope.
3. Coursework brief
3.1 Outline
This program implements the 2-player game of Noughts and Crosses (tic-tac-toe) where each player
places a symbol (X or O) alternately and attempts to make a line of 3 of their symbol in any direction.
If you have not played this game before please see, for example,
https://playtictactoe.org/ (warning – this page has adverts)
For part 1 of this work you play on a 3x3 grid.
For part 2 of the work you can play on a larger size board up to 8x8 and with any length of winning
line from 3 up to the board size.
3.2 Skills tested
Procedural programming design; I/O; Pointers; Functions; Structures; Modular programming;
Makefiles
3.3 Part 1
You are provided with a template for the solution in the zip file included with the work. This includes
several source code files and a Makefile for the compilation of your project.
Although you can develop on any platform you must ensure your code builds on linux with the
Makefile that is given. The Makefile is provided as a generic template and you must complete the
details of the code that is provided.
You should not rename the given files or edit the print statements that are already included.
You should complete functions in the C source code files as indicated in those files. You should use
the data structure provided to store the game state.
You can add functions if you require them and should add appropriate function prototypes to the
header files so that the application builds with the Makefile.
Please look through the provided source code for more information:
game.h: the data structure for the game state
main.c: entry point for the application
initGame.c: functions that initialise data before the game starts
playGame.c: functions for control of the game logic, order of operations, and output to screen
endGame.c: functions that test for winning or drawing conditions
Output to screen must be done to a precise format, which is implemented in the code. If you deviate
from this format you will not pass the automated tests. The example output file can be used to
compare your program output (use diff on linux machines for a precise comparison).
You will choose when to use the other print statements to properly control the flow of the game.
Players of this game will often enter their moves incorrectly. You should ensure that this does not
cause your program to fail. Appropriate messages are provided for this situation.
Your approach may require you to implement further functions. You should include these in the
appropriate source code file and update the relevant header file. You should not introduce further
source code files or header files.
3.4 Part 2
This part is an extension of the Part 1 solution to a more general case. You should not complete this
unless you have completed Part 1.
Your program will now accept two integer command line argument – the grid size, which is from 3 to
8, and the winning line length which is from 3 to the chosen grid size.
For example, to run this application with a grid size of 6 and winning line of 4 would use:
./tictactoe 6 4
You should verify that these arguments have appropriate values before starting a game. If they do
not you should exit the application with the appropriate warning message (provided in the code).
You should extend the display of the board to allow the increased size, but keeping to the same
formatting as the existing 3x3 implementation.
You will need to generalise the conditions for winning and drawing a game.
3.5 Testing
You are provided with a sample file of input (game.in) and output (game.out) for the 3x3 game. You
can compare your own program output to the files provided for both parts.
To test the input file you can redirect the keyboard input to read from the file:
./tictactoe < game.in
To capture output to the terminal you can redirect the program output to a separate file.
./tictactoe < game.in > myout.txt
This will redirect any program output from the terminal to the named file.
On the linux command line you can use the ‘diff’ utility to compare 2 files. eg.
diff –y myout.txt game.out
will compare the program output side by side and show differences.
It is important that you can exactly replicate the results that are provided, including whitespace,
before submitting.
You should consider how to further test your code based on the requirements.
Further tests will be run to produce the final grade.
3.6 Coding advice
You are provided with template C files for the solution of each part.
You should not rename these files
You should add any further variables and appropriate code for each part.
You should use only the output messages (printf) that are provided in the code. You will
decide when these messages are triggered.
Any further print statements you may use should be removed from your final submission as
they will cause the grading to fail.
The template code breaks the task down into several modules:
This is a standard design process for procedural programs.
Some functions are specified in each module and you should complete the implementation.
For the game logic you should first plan out your algorithm for the game play.
Compile your code frequently to help with finding errors.
You can add further functions to the implementation. In this case you should also modify the
appropriate header file. You should consider the appropriate source code file to add a function
based on its purpose.
You must test your code compiles in a terminal window on our school linux machines with the
Makefile.
3.7 Mark scheme ( 60 marks overall )
This work is 60% of the overall module assessment.
Automated tests will ensure your solution meets the specification as described above.
Code quality will consider the overall structure and presentation of your code, the use of functions,
appropriate use of comments and consistent style.
Part 1
Automated tests 25
Code quality and consistency 10
Part 2
Automated tests 20
Code quality and consistency 5