Artificial Intelligence Coursework (COMS30084)
Boiler-plate · Coursework Brief · GridWorld Library · Part 1 · Part 2 · Part 3 · Part 4 · Marking Scheme
This document provides an overview of and guidelines for the coursework assessment (COMS30084) on the 3rd year Artificial Intelligence (AI) unit in the 2025-6 academic year. After outlining the standard boiler-plate text (Section 1) this document provides a general coursework brief (Section 2), followed by an introduction of the relevant features of the GridWorld library (Section 3), a breakdown of the four individual parts that you will need to submit (Section 4 - Section 7), and a summary of the marking scheme (Section 8).
1 Boiler-plate
Value: This coursework is for unit COMS30084 AI and is worth 70% of 20 (=14) credit points.
Mode: This coursework is individual work and you must not discuss this task with anyone else (including your current classmates, former students, third parties, discussion forums, etc). Any collaboration will be considered cheating and will be treated as such, if detected.
Timing: The coursework will be released on Thursday 13th November (Week 8) at 1pm and must be submitted by Thursday 4th December (Week 11) at 1pm. The intention is that you submit by 12pm and keep the last hour as an emergency reserve for e.g. technical problems. In case of problems with your submission, e-mail [email protected] before the 1pm final deadline to avoid your work being counted as late.
Submission: You must submit the coursework on the Blackboard page for the assessment unit COMS30084 (not the teaching unit COMS30014). On the assessment unit, go to the menu item “Assessment, Submission and Feedback” and follow the instructions there.
Commitment: You are expected to work on both your courseworks in the 3-week period from Week 9 to Week 11 as if it were a working week in a regular job, that is 5 days a week for no more than 8 hours a day. It is up to you how you distribute your time and workload between the two units within those constraints. You are strongly advised not to try and work excessive hours during the coursework period: this is more likely to make your health worse than to make your marks better. If you need further pastoral/mental health support, please talk to your personal tutor, a senior tutor, or the university wellbeing service.
Support: For this unit COMS30084, the following support is available during the coursework period: we will continue running the lab as an optional drop-in clinic on Thursdays at 9am- 11am in Queens 1.80. Note that the purpose if the drop-in session is to provide an opportunity for you to clarify what is expected of you in the coursework and also to provide an opportunity to ask general questions about Prolog or discuss general skills (that you can transfer to the coursework). You will also be able to ask questions about any part the unit (whether you are doing the major or minor assessments); and you may also continue posting questions to the Discussion Forum on the Teaching Unit (COMS30014).
Marking: A summary of the marking scheme for this coursework is included in Section 8 of this document.
2 Coursework Brief
This coursework comprises 4 equally weighted parts that are briefly outlined below (and explained in more detail in subsequent sections of this document):
Part 1 (25%) involves you extending Lab Search with an A* algorithm in order to more efficiently find shortest paths from an agent's position to specified cells or objects without running out of energy in grids containing walls, oracles and charging stations;
Part 2 (25%) involves you extending Part 1 with the ability to plan more complex routes that enable your agent to visit as many oracles as possible, refuelling as necessary along the way, in order to find the identity of a secret film actor by asking each oracle to provide you with a single link from that actor's Wikipedia page;
Part 3 (25%) involves you coordinating the movement of multiple agents in order to explore and solve an initially hidden maze by guiding each agent from an “entrance” point near the top left to an “exit” point at the bottom right;
Part 4 (25%) is a more open-ended exercise that involves writing a short report where you consider (at a conceptual level rather than an implementation level) potential extensions of and reflections upon your solutions to the above tasks.
The following table provides a brief overview of the three coding Parts 1-3 showing the submission predicates and files (where 12345 stands for your student number - which should actually be 7 digits long) along with the associated grid configurations, a quick-start guide to running the code, and the relevant marking criteria:
Table 1: Quick-start Guide for Parts 1-3.
† Please note that you MUST hit "run" in the GridWorld browser window that will open (or nothing will happen until you do)! See later in this document for alternative ways of running the code in Linux and Windows
Remember to rename the default skeleton submission files above by replacing the number 12345 with your actual student number (a 7-digit number that is not the same as your candidate number or your user id)! Note that failure to use your student number will disrupt the loader and lead to seemingly obscure errors.
You are advised to tackle the parts in the order they are listed above as the level of guidance deliberately decreases as you progress through Parts 1-4. Moreover, Parts 2 and 3 both build upon the insights and code you develop in Part 1; and Part 4 will benefit from your experiences all the other Parts 1-3.
As there is no dependency between Parts 2&3, you may start work on either or both of these after you've made some progress on (but not necessarily completed) Part 1. Similarly, you may begin working on Part 4 after making some progress on (but not necessarily completing) Parts 1-3.
This coursework assumes you have a running version of SWI Prolog and a working knowledge of logic programs obtained by working through Chapters 1-6 & 10-11 of the recommended Learn Prolog Now! tutorial. You should have studied the content of the Prolog lectures along with SWI toolchain and debugging slides and worked through all three Prolog labs (in weeks 1,2 and 3) including reflecting on the example solutions. You should be comfortable editing and running programs in SWIPL as well as using the online manual and the built-in debugger.
It has been noticed that some computers (particularly Lenovo machines running the latest SWI on Windows 10) may experience slow performance when interacting with cells adjacent to oracles (so that setup may take minutes instead of seconds). If your machine is affected, please try downgrading your SWI installation to SWI 8.4.3-1 — which is the version running on the lab machines (in MVB 2.11 and QB 1.80) that you may also use. Also, make sure t0 see the lab tips at the end of lecture 12!
Note that, in this documentation, predicates are often annotated with their respective arities (name/arity) and arguments are often annotated with their intended modes (+In, -Out or ?Any). These arity and mode decorations should not be typed in any actual code - there are included in the documentation to show how the predicates should be used. As explained in the SWI manual:
an input argument (+) must be instantiated to a correctly typed term when the predicate is called,
an output argument (-) will become instantiated (if it wasn't already) when the predicate succeeds,
and partial arguments (?) may be variable, ground or partially instantiated when the predicate is called and/or succeeds.
Please note that (SWI built-in and GridWorld library) predicates are only guaranteed to work properly (or even at all) when used in the correct way!
You should treat this coursework as a individual take-home open-book time-limited extended-exam. You should work by yourself and without assistance from each other or TAs. But (as detailed above) we will continue running the lab as an optional drop-in Clinic; and you may also post questions to the discussion forum on the Teaching Unit (COMS30014).
Please note that staff will be able to help clarify expectations and discuss general issues but will not be able to explicitly help you write coursework solutions.
Answers should be submitted in Blackboard before the deadline by uploading exactly 4 files (corresponding to the four respective parts) named as follows: cw_12345.pl, cw_wp_12345.pl, cw_maze_12345.pl and cw_report_12345.pdf (where 12345 should be replaced by your 7 digit student number). Note that you may overwrite your files until the deadline - at which point standard Faculty late penalties will apply (to the submission as a whole). The relevant submission point should be available at least a week before the deadline.
Academic offences (including submission of work that is not your own, falsification of data/evidence or the use of materials without appropriate referencing) are all taken very seriously by the University. Suspected offences will be dealt with in accordance with the University’s policies and procedures. If an academic offence is suspected in your work, you will be asked to attend an interview with senior members of the school, where you will be given the opportunity to defend your work. The plagiarism panel are able to apply a range of penalties, depending the severity of the offence. These include: requirement to resubmit work, capping of grades and the award of no mark for an element of assessment.
If the completion of your assignment issignificantly disrupted by serious health conditions, personal problems, or other similar issues, you may be able to apply for consideration of extenuating circumstances (in accordance with the normal university policy and processes).
3 GridWorld Library
A Zip file containing the GridWorld library files and skeleton submission files should be downloaded from Blackboard and unzipped on your working machine. These files extend and supersede the library code from the earlier Prolog labs (which means that many of the exported predicates should already be familiar to you). The following diagram provides an overview of the key dependencies between Parts 1-4 of the coursework, the user predicates they'll need to define, the library predicates they'll need to call, and the files where everything is or needs to be located. Note that:
plain rectangles show library modules (with the exported predicates you may use);
round rectangles show parts of the assignment (along with their weighting);
semi-round rectangles show the files (and predicates) you'll need to modify.
In this coursework, you will not need to look at the library code or understand how it works - although you are welcome to look inside the given files if you wish!
Remember that 12345 should be replaced by your (7-digit) student number.
Figure 1: Overview of part/file/predicate dependencies and grid configurations
The above dependencies are set up by a file loader ailp.pl that allows you to run the different parts of the assignment from the command line. After moving to the library root folder (containing ailp.pl file) you should run the following command:
on a Linux machine type ./ailp.pl cw part in a bash terminal (if necessary, after first making the file executable with the command chmod +x ailp.pl)
on a Windows machine type swipl ailp.pl cw part or swipl-win ailp.pl cw part in a cmd or powershell terminal; or double click on aipl.pl in an explorer window and type cw part at the Prolog prompt
When running the above commands, remember to replace the symbol by the actual digit (1, 2 or 3) representing the required part number:
To enable interaction with the user, the GridWorld provides the additional commands, shown below, to open and close a session. The commands in the top table allow the user to set up a local web-server, display the grid in a browser window, add one or more agents to the game, (re-)initialise the grid, and start the game running. This setup must be completed before the GridWorld library predicates can be called; The commands in the bottom table allow the user to remove agents from the game (one-by-one) and stop the web-server. These commands must be executed, at the Prolog prompt, in the order shown below:
The extra " ." after the "start." command can be optionally used to accept the dialog box which asks the user whether to “open in browser window (y/n)"
Remember to hit “run” in the browser window after starting the web-server (or nothing else will happen until you do)!
Don't forget to use make and reset_game after you make changes to your code (and you may also need to refresh your browser window).
Table 2: commands to start (top) and end (bottom) a GridWorld session.
In order to further facilitate user interaction during a session, the GridWorld also provides an interactive user shell that can be invoked with the following command that allows the user to run the set of macros listed below (which are especially useful for Parts 1 and 2):
Note that, while you are not required to use the shell in this coursework, the following macros can significantly reduce the amount of typing required and will also print some helpful messages (to the Prolog console and GridWorld window):
Table 3: Possible shell macros.
Note how the shell prompt "?" omits the dash in the standard Prolog prompt "?-".
Notice how some of these macros refer to the user predicates solve_task/2, find_identity/1 and solve_maze/0 that you'll need to (re)define in Parts 1, 2 and 3 - so you can use the shell to help you test the behaviour of your code.
Note that the above commands and macros should not themselves be used in any code you submit as they are only there to help you run and test that code!
The easiest way to get a feel for how the GridWorld works is to run the Part1 demo from the library command shell, which will take you step by step through a preprogrammed use case involving the following sequence of main operations:
1. reset the game and execute a path to oracle 1;
2. ask oracle 1 “What is the meaning of life, the universe and everything?”;
3. execute a path to position 7,7;
4. execute a path to position 19,9;
5. verify that the agent is adjacent to charge station 3;
6. top up the agent's energy;
7. execute a path to position 10,10 (default code fails!).
As you can see from the following figure, because your agent has a limited supply of energy which gets used up as it moves around and queries oracles, and because it only comes with a naive depth-first search algorithm, by default the agent runs out of energy on this last task — which is an outcome that you'll need to change as you work through this coursework!
Terminal output GridWorld output
Figure 2: Result of running Part 1 Demo with Skeleton Code
The simplest way to run the demo is with the following sequence of commands which will allow you to easily step through the complete command sequence by just repeatedly pressing the <enter> key after each sub-task completes (or using <ctrl>-c followed by a and <enter> if there is a problem with your code and you need to abort out of the shell):
?- start. .
?- shell.
? setup.
? demo.
Various other ways of running the demo are illustrated below - using either the built-in demo macro (centre), or running the constituent shell macros individually (left), or calling their corresponding GridWorld library expansions (right):
The vertical alignment and extent of each box is intended to show the correspondence between the macros and their constituents or expansions:
Figure 3: Some different ways the user can run the GridWorld demo
You can enter and leave the user shell at any time; and you can run non-shell commands from within the shell by wrapping them up as an argument to a call macro - which will implicitly find all solutions of the specified goal. If you want to make your head hurt, try running call(shell) from within the shell!
The dotted lines show some ways you can add more agents to the game (applicable in Part 3 which is not restricted to one agent). To do this when the game has started (after a call to start_game or one of the macros setup, reset or demo), you'll need to run a precise sequence of commands comprising a reset_game, one or more join_game, another reset_game and a start_game. The first reset_game is needed to stop the game before more agents can be added (or you'll get an error). To do this from the shell you'll need to explicitly run call(reset_game) as the macro reset also calls start_game which sets the game running again.
Make sure the game is not paused in the browser when you call reset_game or the server may hang due to feature (or bug) in the way http responses may be sequenced.
Although you won't need to exploit this fact in the coursework, the library allows multiple clients to interact with the server over http via an internal predicate query_world/2 that enables one or more Prolog threads running on your machine to join agents to a game, move them around and query the grid. The only thing you need to know is that, because this all happens over http, calls that involve looking up the contents of a cell or moving an agent will have a significant time overhead as compared to standard Prolog queries.
During program development, you are welcome to use SWI built-ins from the statistics library such as statistics(Key,Value) with the Key cputime to run some empirical tests on the execution time of various GridWorld queries.
You may also look at http interactions in your browser by looking in the networking tab of the dev menu for your web browser. This can usually be opened using F12.
An example of the requests made to the web browser at a given timestep is shown below:
Figure [request]: Example http request for agent 1 (blue) to moving to p(1,3)
Parts 1-3 of this coursework all involve you navigating one or more agents around square grids of various sizes and configurations in order to solve different tasks (illustrated in Figure 1). In all of these tasks, agents may move one step at a time to any empty adjacent (on-grid) cell immediately to the South, East, North or West of the current position (with multiple possibilities being returned in that order). The location of each cell in the grid is represented by a Prolog term p(X,Y) where X and Y are natural numbers denoting the horizontal and vertical offsets (rightwards and downwards) from the top left corner. The contents of each cell in the grid is represented by exactly one of the following Prolog terms (where N is an integer identifier of the corresponding object):
Note that represents the Prolog ceiling function which can be used within an is to round its argument up to the nearest integer (i.e. towards positive infinity).
Although the GridWorld library supports the random movement of walls, oracles and charge stations, Parts 1-3 will all be restricted to static grids where only agents will be allowed to move. Moreover, in order to help you test your code and get a realistic estimate of its performance, Parts 1-3 will all impose strict restrictions on the number of various objects in grid and will ask you to define specific predicates to solve different tasks, as detailed in the following sections. Of course, you are welcome to consider alternative static and dynamic variations of these task definitions and grid configurations in Part 4.
The marking of Parts 1-3 will be mainly carried out by an auto-tester that will take into account several marking criteria specified in the following sections. For each criterion, you will gain from 1 mark for a basic solution (that provides some slight improvement over any baseline code) up to 5 marks for (near-) optimal solutions. In cases where there might be a potential trade-off between two or more of the objectives, their respective priorities will be stated in order of importance (primary, secondary, etc); and your mark for any higher priority criteria will serve as an upper bound on your mark for any lower priority criteria (as well helping to adjust the expected performance).
To avoid losing marks, you should take care not to over-optimise low priorities at the expense of high priorities. Before submission, you should also double check that any auto-tested predicate definition is in the correct file with the correct name and arity. While you are free to write any helper predicates you like (with names and arities of your choosing) you should ensure all of your code only make calls standard SWI built-ins or explicitly exported library predicates (as any attempt to modify or expose other library definitions won't work on the auto-marker).
As good coding practice is part of the marking scheme you are strongly advised to: comment your code to explain the meaning of each argument and the behaviour of each predicate; format your code to make the logical flow clear (using informative variable and predicate names); test your code to make sure it compiles without errors and that predicates terminate properly which means that wherever possible they should be (semi-)deterministic in the sense that they should terminate after succeeding once (or failing). You should especially try to avoid non-termination and run-time exceptions or predicates that return duplicate solutions or leave unnecessary choice points.
Note that you won't get any marks for solutions that don't compile or are half finished. You will get marks for improving on the default working skeleton code you have been given.