1. Assignment guidance

In this assignment, you will be creating four assets:

-    A test plan

-    Test data

-    Skeleton code based around this module plan

You are not expected to produce a working implementation of the program described below, and no marks or feedback will be given for implementing the program.

You should produce your plans and skeleton code based on the brief given below.

Maze Game

You are creating a basic game, where players navigate through a maze.

./maze <filename> <width> <height>

The maze will be loaded from a file, the filename for which is passed as a command line argument. Mazes are made up of four characters:

A maze has a height and a width, with a maximum of 100 and a minimum of 5 .

The height and width do not have to be equal – as long as both are within the accepted range.

Within a maze, each ‘row’ and ‘column’ should be the same length – the maze should be a rectangle.

When the game loads, the player will start at the starting point ‘S’ and can move through the maze using WASD movement:

Note: I do not expect you to make this keypress triggered.

The player can move freely through path spaces (‘ ‘) but cannot move through walls or off the edge of the map. If they try and do so, they should receive some message telling them not to do this.

The map should not be shown to the player every time they make a move, but they can enter ‘M’/’m’ to view an image of the map, with their current location shown by an ‘X’ .

When the user reached the exit point ‘E’, the game is over and will close. The player should be given some message stating that they have won.

2. Assessment tasks

Test Plan

Note: this is the section which has been adapted for your resit attempt – in the mark scheme this will appear as ‘test script’ and you will be assessed against the same criteria, but as a plan rather than as a working script. You may implement a test script if you prefer this.

You will produce a test plan which can be used to test this code. You will need to consider the range of potential errors which could occur in the program, paying particular attention to places where data is being inputted.

You should also think about potential mistakes which you might make in programming, and how you will ensure that your code is working successfully – for example, if a player walks into a wall, how will this be handled and how can you test for this. You should test for success as well as failure.

Each test should have:

-    A name/description of what you are testing for

-    The terminal command you would use, including piping in inputs where necessary

-    The expected outcome which you would see in the terminal

Here is an example which you can adapt:

There are no ‘correct’ prints – you should decide what you will print out and be consistent. These should be specific and clear.

Test Data

You should create some test data which you can use with your plan (should be referenced by filename within your plan).

This should include:

-    A variety of maze text files which you will use in your testing (valid and invalid)

-    Some input files to navigate through your test mazes / check for errors when using your program

Not only will these help you to think about the kinds of errors which you should be testing for in your

script, this will also make testing your code easier when you come to implement it later in the semester.

Skeleton Code

Based on the provided brief, produce a skeleton for your code. This should include:

-    Struct definitions

-    Function/procedure definitions

-    A basic outline for your main written using comments.

You do not need to write any of the functionality, and there are no marks available for the ‘ real ’ code. You should outline a plan of what you are going to do using comments.

3. General guidance and study support

You should refer to the previous lab exercises and lecture notes to support you.

4. Assessment criteria and marking process

Your test script will be manually checked in order to look at your handling of:

-    system errors

-    bad user inputs

-    common logic errors

Your test data will be checked in order to make sure that it is used in your test script.

Your code skeleton will be checked for:

-    Modular breakdown

-    Struct design

-    Basic structuring of your program

A full breakdown is available in section 8.

5. Presentation and referencing

You will submit your work to Gradescope. You should organise this appropriately, for example

putting all test data inside a subdirectory in order to make it easier to find and mark your test plan and skeleton code.

Referencing:

It is expected and required for you to reference any pieces of code which you adapt/borrow from.

This is particularly important for academic integrity: if two students submit very similar code, this will be detected by Gradescope and flagged to me- if this code is similar because you both used the same webpage, documentation or generative AI prompt, then I can ignore this! If there is no reference, then you may be returned a mark of 0 and be required to attend an academic integrity meeting.

This is also part of being a good academic; if you are building on someone else’s work, they deserve some credit.

If you do need to reference any resources use a simple comment, for example:

// This test is adapted from an example provided on: https://byby.dev/bash-exit-codes // This test is adapted from chatGPT’s response to the prompt ‘How do I write an if statement to check the output of a C program using Bash?’

You should not be directly copying any code from external resources, even with a reference.

6. Submission requirements

Submit via Gradescope.

7. Academic misconduct and plagiarism

Leeds students are part of an academic community that shares ideas and develops new ones.

You need to learn how to work with others, how to interpret and present other people's ideas, and how to produce your own independent academic work. It is essential that you can distinguish between other people's work and your own, and correctly acknowledge other people's work.

All students new to the University are expected to complete an online Academic Integrity tutorial and test, and all Leeds students should ensure that they are aware of the principles of Academic integrity.

When you submit work for assessment it is expected that it will meet the University’sacademic integrity standards.

If you do not understand what these standards are, or how they apply to your work, then please ask the module teaching staff for further guidance.

By submitting this assignment, you are confirming that the work is a true expression of your own work and ideas and that you have given credit to others where their work has contributed to yours.

Some simple rules to avoid academic integrity issues:

-    Your final submission should onlyinclude code which you have written, and template code provided by module staff.

-    Don’t share your code with other students, allow other students to seeyour code, or release your code publically online until you have received your final grade and feedback.

-    Look after your code- lock your computer if you are going for a break, and if you share your laptop with another student on the module then make sure your assessment code is protected.

-    Always put a reference if you adapt code from online, and if you use generative AI such as ChatGPT make sure you include the prompt or series of prompts which you used.

-    Never copy code from online into your own code – always adapt it to fit your style and the rest of the code

-    If a friend is struggling, guide them to helpful resources or the module staff- showing them your code, writing their code for them, or sending them your code for them to copy are all forms of collusion and both of you will receive a penalty inline with the academic integrity policy.