C代写-COMP20003-Assignment 3
时间:2021-10-23
Assignment 3: Sokoban
General Info
You must read fully and carefully the assignment speci�cation and instructions.
Course: COMP20003 Algorithms and Data Structures @ Semester 2, 2023
Deadline Submission: Friday 20nd October 2023 @ 5 pm (end of Week 12)
Course Weight: 15%
Assignment type: individual
ILOs covered: 2,4
Submission method: via ED
Purpose
The purpose of this assignment is for you to:
Increase your pro�ciency in C programming, your dexterity with dynamic memory allocation
and your understanding of data structures, through programming a search algorithm over
Graphs.
Gain experience with applications of graphs and graph algorithms to solving combinatorial
games, one form of arti�cial intelligence.
Walkthrough

Sokoban
In this programming assignment, you’ll be expected to build an AI algorithm to solve Sokoban. The
game invented in 1980 (program released in 1982) is one of the classics among arcade puzzle games.
You can play the game compiling the code given to you using the keyboard, or using this web
implementation with tutorials (alternative without tutorials).
The code in this assignment was adapted from the open-source terminal version using ncurses made
available by CorrentinB.
Game Rules
As explained in the wikipedia entry, The game is played on a board of squares, where each square is
a �oor or a wall. Some �oor squares contain boxes, and some �oor squares are marked as storage
locations.
The player is con�ned to the board and may move horizontally or vertically onto empty squares
(never through walls or boxes). The player can move a box by walking up to it and pushing it to the
square beyond. Boxes cannot be pulled, and they cannot be pushed to squares with walls or other
boxes.
The number of boxes equals the number of storage locations.
The puzzle is solved when all boxes are placed at storage locations.
For the courious reader
The Science of Sokoban
Sokoban can be studied using the theory of computational complexity. The problem of solving
Sokoban puzzles was �rst proved to be NP-hard [4][5]. Further work showed that it was signi�cantly
more di�cult than NP problems; it is PSPACE-complete [6]. This is of interest for arti�cial intelligence
(AI) research because solving Sokoban can be compared to the automated planning required by some
autonomous robots.
NP-complete problems are hard to solve. The best algorithms to solve NP-Complete problems run in
exponential time as a function of the size of the problem and the shortest accepted solution. Hence,
be aware that your AI solver will struggle more as the number of boxes increases. We talked in the
lectures about the Travelling Salesman Problem as one example of an NP-Complete problem. In fact,
many real-world problems fall under this category. We are going to learn more about NP-Complete
problems in the last lecture of the course via an invited talk in week 12.
Sokoban is di�cult not only because of its large branching factor, but also because of its large search
tree depth. Some level types can even be extended inde�nitely, with each iteration requiring an
exponentially growing number of moves and pushes.[7] Skilled human players rely mostly on
heuristics and are usually able to quickly discard a great many futile or redundant lines of play by
recognizing patterns and subgoals, thereby drastically reducing the amount of search.
Some Sokoban puzzles can be solved automatically by using a single-agent search algorithm, such as
IDA*; enhanced by several techniques that make use of domain-speci�c knowledge.[8] This is the
method used by Rolling Stone,[9] a Sokoban solver developed by the University of Alberta GAMES
Group. Festival[10] was the �rst automatic solver to solve all 90 levels in the standard benchmark test
suite. However, the more complex Sokoban levels are out of reach even for the best automated
solvers.[11]
Above and Beyond
Below I added interesting material for those that want to take a deeper dive on Sokoban Solvers.
O�cial benchmarks and results and best Sokoban solvers from 1980-2021. The best solver,
Festival, was introduced at a conference last year, in 2020. A collaboration by a Google
employee and a great professor Jonathan Schae�er who made outstanding contributions to AI
and games.
Relevant publications, A great starting point in that list is to read Andreas Junghanns Ph.D.
dissertation about Sokoban. 1999. Pushing the Limits: New Developments in Single-Agent
Search. Ph.D. Dissertation, University of Alberta, 1999.
Everything about Sokoban: WIKI
The juice of the great computational ideas & insights behind the best Sokoban solvers.
The Algorithm
A con�guration of the Sokoban game is speci�ed by the location of walls, boxes, storage areas and
player. A con�guration is called a state. The Sokoban Graph is implicitly de�ned. The
vertex set is de�ned as all the possible con�gurations (states), and the edges connecting two
vertexes are de�ned by the legal movements (right, left, up, down). All edges have a weight of 1.
G = ⟨V ,E⟩
V E
Your task is to �nd the path traversing the Sokoban Graph from the initial state (vertex) leading to a
state (vertex) where all the boxes are located on a storage area. The best path is the shortest path. A
path is a sequence of movements. You are going to use Dijkstra to �nd the shortest path �rst, along
with some game-speci�c optimizations to speed up your algorithm.
When the AI solver is called (Algorithm 1), it should explore all possible paths (sequence of move
actions) following a Dijktsra strategy, until a path solving the game is found. Note that we use
transposition tables to avoid duplicate states in the search. If a state was already expanded (popped
from the priority queue), we will not include it again in the priority queue (line 23 in Algorithm 1). We
will also ignore states where the player doesn't move as a result of moving towards an adjacent wall,
or a box which cannot move (line 18). We will �nally avoid states where boxes are located in a corner
(line 18, see �le utils.h ). The algorithm should return the best solution found. This path will then
be executed by the game engine if the option play_solution was used as an argument.
You might have multiple paths leading to a solution. Your algorithm should consider the possible
actions in the following order: left, right, up or down.
Make sure you manage the memory well. When you �nish running the algorithm, you have to free all
the nodes from the memory, otherwise you will have memory leaks. You will notice that the
algorithm can run out of memory fairly fast after expanding millions nodes.
The applyAction creates a new node, that
points to the parent,
updates the state with the action chosen,
updates the depth of the node,
updates the priority (used by the priority queue) of the node to be the negative node's depth
(if the node is the dth step of the path, then its priority is -d). This ensures the expansion of the
d
shortest paths �rst, as the priority queue provided is a max heap,
updates the action used to create the node.
Check the �le utils.h, hash_table.h, priority_queue.h where you'll �nd many of the functions
in the algorithm already implemented. Other useful functions are located directly in the �le ai.c ,
which is the only �le you need to edit to write your algorithm inside the function findSolution .
Look for the comment FILL IN THE GRAPH ALGORITHM . All the �les are in the folder src/ai/.
Deliverables
Deliverable 1 - Dijkstra Solver source code
You are expected to hand in the source code for your solver, written in C. Obviously, your source
code is expected to compile and execute �awlessly using the following make�le command: make
generating an executable called sokoban . Remember to compile using the optimization �ag gcc -O3
for doing your experiments, it will run twice as quickly as compiling with the debugging �ag gcc -g
(see Makefile , and change the CC variable accordingly). For the submission, please submit your
make�le with gcc -g option, as our scripts need this �ag for testing. Your program must not be
compiled under any �ags that prevents it from working under gdb or valgrind.
Your implementation should work well over the �rst 3 layouts, but it will not be expected to �nd a
solution to any layout, as it may exceed the available RAM in your computer before �nding a
solution. Feel free to explore maps given in the folder maps_suites. They are taken from the o�cial
benchmarks of sokoban. All you have to do is to copy and paste a single map into a new �le, and
then call it with your solver.
Deadlock Detection (optimizations)
The simplest way to improve the code is by improving the deadlock detection implemented
(SimpleCornerDeadlock) in Algorithm 1-line 18. You can �nd the C implementation inside
utils.c:235 . Implement at least 1 deadlock detection in the link above.
Take a look at these 2 links for further optimization ideas & insights.
If you do any optimizations & changes to the Data Structures & deadlock detection improvement,
please make sure to explain concisely what it is that you implemented, why you chose that
optimization, how it a�ects the performance (show number of expanded nodes before and after the
optimization for a set of test maps), and where the code of the optimizations is located. This
explanation should be included in the �le located at the root of the basecode: README.md . Please
make sure that your solver still returns the optimal solution.
Deliverable 2 - Submission Certi�cation Form
Once you submit your code, please also �ll out the form, no later than 24h after the deadline.
The form is mandatory, and shouldn't take more than 5 minutes.
Rubric
Assignment marks will be divided into three di�erent components.
1. Solver (12)
1. Finds solution for the capability test cases (10)
2. No memory error (1)
3. No Memory leak (1)
2. Code Style (2)
3. Optimizations (1)
Please note that you should be ready to answer any question we might have on the details of your
assignment solution by e-mail, or even attending a brief interview with me, in order to clarify any
doubts we might have.
We will follow the same Ungrading approach used for Assignments 1 and 2.
Maps & Solution formats
Puzzle File Format
We adapted the sokoban �le reader to support the following speci�cation, but we don't support
comments speci�ed by % .
Solution File Format
solutions returned by the solver follow this format
You can load your map and solution into the JS Visualiser.
JS Visualiser
For the visualiser to work, puzzles must be rectangular. If your map is not rectangular, just �lled it in
with walls instead of empty spaces.
The Code Base
You are given a base code. You can compile the code and play with the keyboard (arrows). You are
going to have to program your solver in the �le ai.c . Look at the �le main.c (main function) to
know which function is called to call the AI algorithm.
You are given the structure of a node, the state, a max-heap (priority queue) and a hashtable
implementation to check for duplicate states e�ciently (line 23 in the Algorithm 1). Look into the
utils.* �les to know about the functions you can call to apply an action to update a game state. All
relevant �les are located in the folder src/ai/ .
In your �nal submission, you are free to change any �le, but make sure the command line options
remain the same.
Input
You can play the game with the keyboard by executing
./sokoban
where map points to the �le containing the sokoban problem to solve.
In order to execute your AI solver use the following command:
./sokoban -s play_solution
Where -s calls your algorithm. play_solution is optional, if typed in as an argument, the program
will play the solution found by your algorithm once it �nishes. All the options can be found if you use
option -h :
$./sokoban -h
USAGE
./sokoban <-s> map
DESCRIPTION
Arguments within <> are optional
-s calls the AI solver
play_solution animates the solution found by the AI solver
for example:
./sokoban -s test_maps/test_map2 play_solution
Will run the 2nd map expanding and will play the solution found.
Output
Your solver will print into an solution.txt �le the following information:
1. Solution
2. Number of expanded nodes.
3. Number of generated nodes.
4. Number of duplicated nodes.
5. Solutions length
6. Number of nodes expanded per second.
7. Total search time, in seconds.
For example, the output of your solver ./sokoban -s test_maps/test_map2 could be:
SOLUTION:
rrrrrrdrdLLLLLLLLullluRRRRRRRururRRRRRRRRRR
STATS:
Expanded nodes: 978745
Generated nodes: 3914976
Duplicated nodes: 2288345
Solution Length: 43
Expanded/seconds: 244506
Time (seconds): 4.002942
Expanded/Second is computed by dividing the total number of expanded nodes by the time it took to
solve the game. A node is expanded if it was popped out from the priority queue, and a node is
generated if it was created using the applyAction function. This code is already provided.
Code Submision - Deliverable
This code slide does not have a description.
Re�ection Submission
Question 1
No response
Question 2
No response
Question 3
No response
Question 4
Re�ection
This form provides an opportunity to both look back at your work to re�ect on it, as well as evaluate
how you did.
Self-Evaluated Marks
1. Solver (12)
1. Find Solution for the test cases (10)
2. No memory error (1)
3. No Memory leak (1)
2. Code Style (2)
3. Optimizations (1)
If you were assessing your assignment against these marking criteria, how many marks would you
give your solution?
Learning and Challenges
Please include your top lessons learnt and challenges faced in this assignment.
Ideas that Almost Worked Well
If there were any ideas you tried or wanted to try, include them here and explain why they didn't
make it.
New Test Cases Shared on Ed
No response
Question 5
No response
Question 6
No response
Question 7
Tell us about your test cases and why they were useful.
Justi�cation
Let us know why you assigned yourself the marks you did.
(General) Understanding Demonstrated
Academic honesty is important, however there are academically honest ways to complete the
assignment which do not demonstrate understanding (e.g. crediting a peer for the full
implementation of your assignment may well be honest, but clearly may not be worth any marks!). In
this question, re�ect brie�y on any assistance you made use of (e.g. Google, ChatGPT, workshop peer
discussion, assignment consultations, Ed discussion, teamwork, prior workshop solutions). In
particular, if you found yourself without this kind of assistance in the future, let us know if you think
you would be able to complete a project with similar challenges. If you like, also let us know what
you think is reasonable (i.e. even compiler feedback could be seen as a form of assistance - one form
which you may not have access to in an exam situation).
Did you submit your code and README.md for marking by using the Mark button on the
"Assignment Submission" slide?
Yes
No
Submission Certi�cation
Question 1
Question 2
In this form you will con�rm & certify your submission against the COMP20003 Honor Code and
academic integrity of your submission.
COMP20003 Honor Code
We’re committed to the integrity of your work on the COMP20003 course. To do so, every learner-
student should:
Submit their own original work
Do not share code (solution) with other students
Did you enjoy the assignment project?
(This question is for us to understand the usefulness of this project assignment for the future)
Yes, a lot!
Yes
More or less
Not that much
No, I didn't
I don't want to participate in this question
Do you feel you learn with this assignment project?
(This question is for us to understand the usefulness of this project assignment for the future)
Question 3
No response
Question 4
No response
Yes, I learnt quite a lot!
Yes, I learnt some things
I learnt some, but not much
I learnt almost nothing
I don't want to participate in this question
Feel free to share any feedback here
We are interested in any constructive negative or positive feedback, both are helpful to re�ect what
may need to change and what is working. Good humor and politeness are always welcome! ;-)
Thanks!
I certify that this was all our original work. If we took any parts from
elsewhere, then they were non-essential parts of the project, and they
are clearly attributed at the top of the �le and in a separate report. I will
show I agree to this honor code by typing "Yes":
This declaration is the same as the one in Khan Academy. We trust you all to submit your own work
only; please don't let us down. If you do, we will pursue the strongest consequences available to us.
You are always better o� getting a very bad mark (even zero) than risking to go that path, as the
consequences are serious for students.
The project will not be marked unless this question is answered correctly and exactly with "Yes" as required.
Programming Style
Below is a style guide which assignments are evaluated against. For this subject, the 80 character
limit is a guideline rather than a rule - if your code exceeds this limit, you should consider whether
your code would be more readable if you instead rearranged it.
/** ***********************
* C Programming Style for Engineering Computation
* Created by Aidan Nagorcka-Smith (aidann@student.unimelb.edu.au) 13/03/2011
* Definitions and includes
* Definitions are in UPPER_CASE
* Includes go before definitions
* Space between includes, definitions and the main function.
* Use definitions for any constants in your program, do not just write them
* in.
*
* Tabs may be set to 4-spaces or 8-spaces, depending on your editor. The code
* Below is ``gnu'' style. If your editor has ``bsd'' it will follow the 8-space
* style. Both are very standard.
*/
/**
* GOOD:
*/
#include
#include
#define MAX_STRING_SIZE 1000
#define DEBUG 0
int main(int argc, char **argv) {
...
/**
* BAD:
*/
/* Definitions and includes are mixed up */
#include
#define MAX_STING_SIZE 1000
/* Definitions are given names like variables */
#define debug 0
#include
/* No spacing between includes, definitions and main function*/
int main(int argc, char **argv) {
...
/** *****************************
* Variables
* Give them useful lower_case names or camelCase. Either is fine,
* as long as you are consistent and apply always the same style.
* Initialise them to something that makes sense.
*/
/**
* GOOD: lower_case
*/
int main(int argc, char **argv) {
int i = 0;
int num_fifties = 0;
int num_twenties = 0;
int num_tens = 0;
...
/**
* GOOD: camelCase
*/
int main(int argc, char **argv) {
int i = 0;
int numFifties = 0;
int numTwenties = 0;
int numTens = 0;
...
/**
* BAD:
*/
int main(int argc, char **argv) {
/* Variable not initialised - causes a bug because we didn't remember to
* set it before the loop */
int i;
/* Variable in all caps - we'll get confused between this and constants
*/
int NUM_FIFTIES = 0;
/* Overly abbreviated variable names make things hard. */
int nt = 0

while (i < 10) {
...
i++;
}
...
/** ********************
* Spacing:
* Space intelligently, vertically to group blocks of code that are doing a
* specific operation, or to separate variable declarations from other code.
* One tab of indentation within either a function or a loop.
* Spaces after commas.
* Space between ) and {.
* No space between the ** and the argv in the definition of the main
* function.
* When declaring a pointer variable or argument, you may place the asterisk
* adjacent to either the type or to the variable name.
* Lines at most 80 characters long.
* Closing brace goes on its own line
*/
/**
* GOOD:
*/
int main(int argc, char **argv) {
int i = 0;
for(i = 100; i >= 0; i--) {
if (i > 0) {
printf("%d bottles of beer, take one down and pass it around,"
" %d bottles of beer.\n", i, i - 1);
} else {
printf("%d bottles of beer, take one down and pass it around."
" We're empty.\n", i);
}
}
return 0;
}
/**
* BAD:
*/
/* No space after commas
* Space between the ** and argv in the main function definition
* No space between the ) and { at the start of a function */
int main(int argc,char ** argv){
int i = 0;
/* No space between variable declarations and the rest of the function.
* No spaces around the boolean operators */
for(i=100;i>=0;i--) {
/* No indentation */
if (i > 0) {
/* Line too long */
printf("%d bottles of beer, take one down and pass it around, %d
bottles of beer.\n", i, i - 1);
} else {
/* Spacing for no good reason. */
printf("%d bottles of beer, take one down and pass it around."
" We're empty.\n", i);
}
}
/* Closing brace not on its own line */
return 0;}
/** ****************
* Braces:
* Opening braces go on the same line as the loop or function name
* Closing braces go on their own line
* Closing braces go at the same indentation level as the thing they are
* closing
*/
/**
* GOOD:
*/
int main(int argc, char **argv) {
...

for(...) {
...
}
return 0;
}
/**
* BAD:
*/
int main(int argc, char **argv) {
...
/* Opening brace on a different line to the for loop open */
for(...)
{
...
/* Closing brace at a different indentation to the thing it's
closing
*/
}
/* Closing brace not on its own line. */
return 0;}
/** **************
* Commenting:
* Each program should have a comment explaining what it does and who created
* it.
* Also comment how to run the program, including optional command line
* parameters.
* Any interesting code should have a comment to explain itself.
* We should not comment obvious things - write code that documents itself
*/
/**
* GOOD:
*/
/* change.c
*
* Created by Aidan Nagorcka-Smith (aidann@student.unimelb.edu.au)
13/03/2011
*
* Print the number of each coin that would be needed to make up some
change
* that is input by the user
*
* To run the program type:
* ./coins --num_coins 5 --shape_coins trapezoid --output blabla.txt
*
* To see all the input parameters, type:
* ./coins --help
* Options::
* --help Show help message
* --num_coins arg Input number of coins
* --shape_coins arg Input coins shape
* --bound arg (=1) Max bound on xxx, default value 1
* --output arg Output solution file
*
*/
int main(int argc, char **argv) {
int input_change = 0;

printf("Please input the value of the change (0-99 cents
inclusive):\n");
scanf("%d", &input_change);
printf("\n");

// Valid change values are 0-99 inclusive.
if(input_change < 0 || input_change > 99) {
printf("Input not in the range 0-99.\n")
}

...

/**
* BAD:
*/
/* No explanation of what the program is doing */
int main(int argc, char **argv) {
/* Commenting obvious things */
/* Create a int variable called input_change to store the input from
the
* user. */
int input_change;
...
/** ****************
* Code structure:
* Fail fast - input checks should happen first, then do the computation.
* Structure the code so that all error handling happens in an easy to read
* location
*/
/**
* GOOD:
*/
if (input_is_bad) {
printf("Error: Input was not valid. Exiting.\n");
exit(EXIT_FAILURE);
}
/* Do computations here */
...
/**
* BAD:
*/
if (input_is_good) {
/* lots of computation here, pushing the else part off the screen.
*/
...
} else {
fprintf(stderr, "Error: Input was not valid. Exiting.\n");
exit(EXIT_FAILURE);
}
Some automatic evaluations of your code style may be performed where they are reliable. As
determining whether these style-related issues are occurring sometimes involves non-trivial (and
sometimes even undecidable) calculations, a simpler and more error-prone (but highly successful)
solution is used. You may need to add a comment to identify these cases, so check any failing test
outputs for instructions on how to resolve incorrectly �agged issues.
Plagiarism
This is an individual assignment. The work must be your own.
While you may discuss your program development, coding problems and experimentation with your
classmates, you must not share �les, as this is considered plagiarism.
If you refer to published work in the discussion of your experiments, be sure to include a
citation to the publication or the web link.
“Borrowing” of someone else’s code without acknowledgment is plagiarism. Plagiarism is considered
a serious o�ense at the University of Melbourne. You should read the University code on Academic
integrity and details on plagiarism. Make sure you are not plagiarizing, intentionally or
unintentionally.
You are also advised that there will be a C programming component (on paper, not on a computer) in
the �nal examination. Students who do not program their own assignments will be at a disadvantage
for this part of the examination.
Late Policy
The late penalty is 10% of the available marks for that project for each day (or part thereof) overdue.
Requests for extensions on medical grounds will need to be supported by a medical certi�cate. Any
request received less than 48 hours before the assessment date (or after the date!) will generally not
be accepted except in the most extreme circumstances. In general, extensions will not be granted if
the interruption covers less than 10% of the project duration. Remember that departmental servers
are often heavily loaded near project deadlines, and unexpected outages can occur; these will not be
considered as grounds for an extension.
Students who experience di�culties due to personal circumstances are encouraged to make use of
the appropriate University student support services, and to contact the lecturer, at the earliest
opportunity.
Finally, we are here to help! There is information about getting help in this subject on the LMS.
Frequently asked questions about the project will be answered on Ed.
Additional Support
Your tutors will be available to help with your assignment during the scheduled workshop times.
Questions related to the assignment may be posted on the Ed discussion forum, using the folder tag
Assignments for new posts. You should feel free to answer other students’ questions if you are
con�dent of your skills.
A tutor will check the discussion forum regularly, and answer some questions, but be aware that for
some questions you will just need to use your judgment and document your thinking. For example, a
question like, “How much data should I use for the experiments?”, will not be answered; you must try
out di�erent data and see what makes sense.
If you have questions about your code speci�cally which you feel would reveal too much of the
assignment, feel free to post a private question on the discussion forum.
Have fun!
essay、essay代写