Assignment 1: Solvability of the NxN sliding tile puzzle
The sliding tile puzzle is a game that requires you to move tiles on a board. The board is NxN, and there are N-1 tiles numbered from 1..N-1 that occupy the board. There is hence 1 location on the board that is empty (referred to as a blank).
There is some (arbitrary) start configuration of the numbered tiles on the board. Starting with this configuration, the aim is to move tiles until some chosen goal configuration is reached, and to do this in the least possible number of moves. You may only move a tile into the blank if the tile neighbours the blank. Moves can be only be in the horizontal and vertical directions (not diagonal).
The sliding-tile puzzle also has other names, such as the 8 Puzzle (for the special case of a 3×3 board) or 15 Puzzle (a 4×4 board) and so on. Sometimes the name N Puzzle is used (indicating an NxN board).
You can play the game online at:
In this assignment you are asked to write a C program that determines whether a given puzzle is solvable. (Note that you do not have to actually solve the puzzle.)
There are some conditions that you should strictly adhere to:
the program reads text from stdin with a format described below (we will be auto-testing your program with our input so you must conform to this format)
your program should be able to handle any sized board, starting with 2×2
- note that the size of the board is determined by the number of tiles on the input
- if the input is correct and the goal configuration is:
reachable from the start configuration, your program should generate the output text solvable (to stdout)
not reachable from the start configuration, your program should generate the output text unsolvable (to stdout)
if the input is not correct, your program should generate an error message (to stdout)
if a system call fails in your program, the program should generate an error message (to stderr)
- design and programming restrictions:
- you are not allowed to use any arrays
- you are not allowed to use linked lists/trees/graphs
- you should use an ADT to represent the board and operations on the board
Two lines of text on stdin specifies the start and goal configurations, read from left to right, top to bottom. Each line consists of a sequence of integers, separated by any number (>0) of blanks and/or tabs, that represent the tile numbers, and a single letter b to represent the blank space on the board. These integers should of course be in the range 1..N-1 where the board is of size NxN. The first line specifies the start board, the second line the goal board. For example:
9 12 5 4 2 b 7 11 3 6 10 13 14 1 8 15 1 2 3 4 5 6 7 8 9 10 11 12 13 14 b 15
represents a sliding-tile puzzle on a 4×4 board with the tiles initially placed on the board as shown in the image at the top of page. The goal configuration has the tiles ordered row by row.
In the case of incorrect input
Checking the correctness of each configuration is vital. For example, an input line may not represent an NxN board, or the blank may be missing, or one or more of the tile numbers 1..N may be missing, or the 2 boards may not be the same size or the input contains something other than a number or b. There may be more possibilities.
If the configuration is erroneous, your program must generate an appropriate error message (to stdout). Note that it is possible to have more than one error, and in that case you only need to generate a single error message. For example, consider the configuration 1 2 b 1. There are 2 errors in this configuration: the tile 3 is missing, and the tile 1 is duplicated. It does not matter which error is detected by your program, just as long as the error is correct. When an error is detected and reported, your program should exit gracefully, with status EXIT_FAILURE. The text you use in error messages should be informative, but please keep it brief.
In the case of correct input
If the input is correct, the program should write the following 3 lines to stdout:
the text start: followed by the start configuration
the text goal: followed by the goal configuration
the text solvable or unsolvable as appropriate
The output for the 4×4 game above is for example:
start: 9 12 5 4 2 b 7 11 3 6 10 13 14 1 8 15 goal: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 b 15 solvable
The output for a game on a 2×2 board that happens to be unsolvable is:
start: 2 1 3 b goal: 1 2 3 b unsolvable
If the input is correct the program should exit with EXIT_SUCCESS.
You should make an ADT to implement the puzzle. The client, which is the main program, calls functions in the ADT to read the input, check for correctness and determine solvability. The interface between the client and the ADT is a header file.
Marks will be deducted if you fail any of our tests for incorrect input, or incorrectly determine the solvability of the puzzle. Marks will also be deducted for poor design (e.g. not using an ADT), poor programming practice or violating any of the rules above.
The assignment is worth 10 marks.
You should submit exactly 4 files:
a Makefile that generates the executable puzzle (you should use the dcc compiler)
the C source code of the ADT (call it boardADT.c)
the header file of the ADT (boardADT.h)
the main program (puzzle.c)
Before submission make sure your Makefile is working correctly: the command make should generate the target executable puzzle using the 3 source files boardADT.c, boardADT.h and puzzle.c.
To submit, simply click on the Make Submission button above. You should submit exactly 4 files: Makefile and the 3 source files.
The following describes a simple test harness (is it’s called) that will help you organise and run your test cases. The basic idea is to separate your test cases into good boards that are solvable, those that are unsolvable, and bad boards. A test case is simply a file containing puzzle input of course. Carry to the following steps:
Create a directory, Tests say, to house all your test input. Each file in this directory is a test case. Name the files systematically, so for example, the following input
1 2 3 1 1 2 3 b
could be called bad01.inp. Another ‘bad’ input file would be called bad02.inp. Likewise, create files sol01.inp, sol02.inp etc to represent solvable boards, and unsol01.inp, unsol02.inpetc for unsolvable boards. All these files are in the Tests directory. You could also make the names even more meaningful by coding in the board size into the name: e.g the prefix of all the 2×2 ‘bad’ boards could be bad2, and of 3×3 boards bad3 etc, and similarly for sol and unsol.
In the parent directory, which should contain your puzzle executable, create a file called Testrun containing the following shell script
#!/bin/sh PROG=./puzzle case $1 in 1) T=Tests/bad* ;; 2) T=Tests/sol* ;; 3) T=Tests/unsol* ;; esac if [ A$T != A ] then for i in $T do echo ================= $i ================== $PROG < $i done else echo Usage $0 "[1|2|3]" fi
which assumes you have used my naming convention in part 1.
To run all the bad-board tests in one go, simply run the corresponding script:
sh Testrun 1
and similarly sh Testrun 2 and sh Testrun 3.
The advantage of the separating into different kinds is that is makes it easy to see that the program is behaving correctly for all the tests with the same kind of input (bad, solvable and unsolvable). It is also easy to add new test input to the Tests directory.
You can make this script much fancier of course. You could for example add a 4th case to test bigger boards if that is where you want to focus on at a particular stage in the development.