COMP1921代写、Java/Python/c++编程语言代做

项目预算：开发周期：发布时间：要求地区：

School of Computing: Assessment brief
Module title Programming Project
Module code COMP1921
Assignment title Resit Assessment
Assignment type and
description
You will produce code to meet a given specification.
Rationale This assessment gives you an opportunity to develop a small working
game using professional techniques such a modularizing code and
defensive design. You will work to create code which meets a client
brief, whilst also ensuring that the code meets basic standards of
structure, documentation and memory management.
Word limit and
guidance
You should spend 20-25 hours working on this assessment.
Weighting 100%
Submission deadline 9
th
August 2024 @ 23:59
Late submission is not permitted.
Submission method Gradescope
Feedback provision Marked rubric, Autograder output & in-code comments via Gradescope.
Learning outcomes
assessed
- apply professional programming practices to programming projects.
- explain the importance of applying professional programming practices
to programming projects.
- design, implement, debug and test a modular programming solution to
a real-world problem.
Module lead Amy Brereton (@scsabr)

1. Assignment guidance
You are tasked with creating a basic treasure hunt game in C, where players navigate a map to find
hidden treasures using command-line inputs.
You should design your code to be defensive and handle a range of errors in a graceful way,
without crashing unexpectedly. Consider the full range of mistakes which a user could make when
trying to run the program.
Treasure Island Game
The game loads a map file, which is provided on the command line in the format:
./island
A map file can contain:
And is always a square with the width and height dimension which is also provided on the
command line.
The game involves the player moving around the island looking for hidden treasure. The player can
move using the WASD keys (w/W = up, a/A = left, s/S = down, d/D = right) or display a map using
the m/M key.
The locations of the hidden treasure and the starting point should not be shown by the map, these
should be showed by blank spaces ‘ ‘.
When the player finds the hidden treasure, they should receive some message telling them how
many they have found such as ‘You have found 1 out of 3 hidden treasures’.
When the player has found all 3 hidden treasures, they have won and the game ends successfully.
There is no exit or quit option, so the only way to complete the game is to find all treasures.

Symbol Meaning
‘ ‘ (space) Land which the player can move across.
‘w’ (lower case w) Water – this surrounds the island and the player cannot move through
it. There must be only water in the first and last row and column.
‘T’ (upper case t) Palm trees which block the player from moving on land.
3 x ‘H’ (upper case h) Hidden treasures which the player is searching for.
1 x ‘S’ (upper case s) The starting point, where your player will be placed when you start the
game. Return codes and Outputs to the User
Any outputs such as error messages can be any text you like, as the grader does not read them.
However, there are certain return codes which you have to use:
0 = success (the game was able to run correctly)
1 = argument error (bad number of arguments, or bad dimension)
2 = file error (the file cannot be read – doesn’t exist or no read permissions)
3 = data error (the file is not a valid map)
Where an error could fall into multiple categories, the autograder will accept either – or you can ask
me via Teams.

Map Files
Map files are text files containing a ‘map’ for the game. They have some rules:
- The map should always have a border of water (‘w’s) around the edges (i.e. every first and
last character of a row and column should be a ‘w’).
- A map is always a square (width and height equal), and should match the dimension given on
the command line.
- There is exactly one start point marked by ‘S’.
- There are exactly 3 treasures marked by ‘H’.
- The map only contains characters ‘w’,’T’,’ ‘, ‘H’ and ‘S’.
- The size is a minimum of 5x5 and a maximum of 100x100.
- They may end with a trailing newline character (a ‘\n’ as the final character).
A selection of map files have been provided to help you test your code – note that these will not be
the final files used to test your code, so it’s important for you to ensure that your code works on a
variety of different files.
These example files also do not contain every possible error – try and think of other ways in
which a map file could be wrong, and make some of your own to test your code.
You do not need to check whether there is a valid route between the start and the 3 treasures
– you can assume there always is. Additional Task – Map Generator – 30 marks
This task is optional and should not be attempted if you are sitting a capped resit – this is
only for those with uncapped marks who are aiming for higher marks and may take
significantly longer than the suggested time for this assignment.
The developer wants to procedurally generate a range of different maps to build up a website of
maps which people can download and use with the game. They would like you to create a script
which is able to generate these maps.
You may use C, Python, or Java for this extension.
You will produce a program which can generate maps with a given filename and size. For example:
./islandGenerator new_island.txt 40
Would create a random, solvable 40x40 map and save it into new_island.txt.
Note: as other languages are permitted, please provide running instructions in a readme.md
file.
Your islands need to be valid by the rules given in the ‘Map Files’ section above, and it is
recommended that you try and ensure that around 60% of your map is covered by island (rather
than having a lot of water around small islands) to make your islands more interesting and varied.
Your islands must also be solvable – it must be possible to start at the starting point and reach all 3
treasures.
You will develop an algorithm to produce these more complex maps. You may use existing research
to help you to do this, but you should also experiment with how changing existing algorithms affects
the maps you produce. You should be writing all code yourself, and citing any research you use.
Aim to create an algorithm which produces visually interesting and challenging maps, and which
produces an interesting range of shapes and styles of island.
You will produce a short report which explains how you developed your island-generating algorithm,
focusing on how you iteratively developed and improved your code, justifying changes you made
and explaining the impact of these. You can include screenshots, code snippets and images to
demonstrate this
You should also include a reflective conclusion discussing:
- The limitations of your solution
- What you found challenging in designing the algorithm
- Future improvements you would like to make
I recommend writing no more than 10 pages (including images and code snippets) but there is no
page or word limit.
You should ensure that you cite any sources using Leeds Harvard referencing.
Please upload your report as a PDF.
2. Assessment tasks
You should develop a C program to fulfil the brief given above. You will submit your source code,
and if you attempt the map generator challenge task you will also submit a short report.
Your code should be:
- Defensively designed
- Sensibly structured
- Modular
- Memory efficient
And you should ensure that you test your code throughout development. On submission, you will
receive feedback for some tests which should help you to ensure that you are meeting the
requirements of the specification such as correct exit codes.
If tests are failing and you are not sure why, you can contact me via Teams/email for
additional feedback.

3. General guidance and study support
You should refer to the previous lab exercises and lecture notes to support you. Procedural
Programming covered the basic C code needed so you should refer back to this module’s notes.

4. Assessment criteria and marking process
50 marks will be calculated by an autograder which runs your code through a number of scenarios
testing invalid inputs, files, and some integration tests ensuring your code can navigate a full game.
You will see the result of a small number of these tests on upload, but the majority are hidden.
20 marks for code quality will be manually assessed by code inspection.
30 marks for the extension task will be manually assessed from your report and running your code.
A full breakdown is available in section 8.

5. Presentation and referencing
In your report, you should use Leeds Harvard referencing which you can learn more about:
https://library.leeds.ac.uk/info/1402/referencing
The quality of written English will be assessed in this work. As a minimum, you must ensure:
- Paragraphs are used
- There are links between and within paragraphs although these may be ineffective at times
- There are (at least) attempts at referencing
- Word choice and grammar do not seriously undermine the meaning and comprehensibility of
the argument
- Word choice and grammar are generally appropriate to an academic text
Referencing of Code
Two simple rules:
1. You should not be directly copying any code from external resources, even with a reference.
2. Use of generative AI needs to be referenced with a link/copy of the conversation.

If any code is adapted from examples found online, provide a basic comment with the URL on the
line above the adapted line/section:
// This test is adapted from an example provided on: https://byby.dev/bash-exit-codes

Generative AI
In ChatGPT, you can generate a link to the full conversation:

And provide the reference as follows:
// Lines 1 – 7 were adapted from code provided by the following conversation
with chatGPT: https://chat.openai.com/share/c356221d-fb88-4970-b39e-d00c87ae1e0b

In Copilot, you will need to export the conversation as a text file:

Save this with a filename including the date and 2-3 word summary of what the conversation was
about (’11-03 inputs in C.txt’) and ensure this is submitted with your work.
You can reference this in your code:
// Lines 1 – 7 were adapted from code provided by the CoPilot conversation
recorded in ’11-03 inputs in C.txt’
If you are using a different Generative AI model, these instructions may differ – you must still
provide a link to or copy of the full conversation and reference in the same manner above.

Use of Generative AI in this Assessment
This assessment is rated ‘amber’ according to the university guidelines around generative AI. This
means that you can use genAI models such as ChatGPT or CoPilot to explain concepts which may
be useful in this assessment, but you must not use any code it generates or give it any part of
this specification.
Here are some examples of reasonable things to ask a generative AI model:
- Explain how to use the fgets function to read a file in C
- How do I create a struct in C?
- How do I allocate a 2D array in C?

These are asking for help with concepts, and not with the assignment itself and are therefore
acceptable – although you must reference your use of generative AI with a full transcript of the
conversation, as shown in the section above.

If it is suspected that you have used generative AI without reference, the standard academic
integrity process for plagiarism will be followed.

6. Submission requirements
Submit via Gradescope.
Main task:
Submit your code and a makefile to Gradescope along with any referenced generative AI
conversations. Your code should not be inside any subfolders, and must compile on Linux.
This is an example of a correct upload – you can see that my files do not have a folder name before
them, and there is a makefile provided.
The autograder will show the result of 4 different tests, one from each section (arg errors, file
errors, map errors and success tests). Use these to ensure your code is returning the correct value.

Extension task:
Submit your code, report, and any instructions for running your program to the ‘Resit – Extension’
assignment on 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’s academic
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.

8. Assessment/ marking criteria grid

Category 1
st 2:1 / 2:2 3
rd
/ Pass Fail
Island Game (70)
Functionality
50
AUTOGRADED
Game works with
very few/no errors.
Game works
relatively well
with some
issues.
Game semifunctional
with
significant errors.
Severe
functionality
issues; game
unplayable or nonfunctional.

Code Structure
10
Code is readable
and well
structured. It has
been documented
clearly with doc
comments and
some in-code
comments.
Code is generally
easy to follow,
with a good
attempt at clearly
documenting
code with
comments.
There has been
some attempt to
make code
readable, with
sensible comments
used.
Code is poorly
structured and
lacks
documentation.
Memory
Management
5
Dynamic memory
allocation used
appropriately, with
memory freed
before all exits.
Dynamic
allocation used,
with frees before
the majority of
exits.
Dynamic allocation
attempted although
may be
inconsistent.
No attempt at
dynamic
allocation.
Modularity
5
Code has been
split into sensible
modules (files)
with good
functional
breakdown.
There is at least
one additional
module (file) and
reasonable
functional
breakdown.
Code may all be in
one file, but
functional
breakdown is
acceptable.
Code all in one
function, or
functional
breakdown is very
poor.
Island Generator (30)
Functionality
10
Generates
interesting maps
which meet the
criteria and are
varied and
consistently
playable.
Mostly generates
good maps, but
may have some
limitations which
do not prevent the
game from being
playable.
Generates maps
with significant
limitations which
may impact
playability.
Fails to generate
valid or interesting
maps.
Algorithm design
10
It is clear how the
algorithm was
developed and the
changes made to
improve it. There
are sensible
justifications for
changes made.
It is clear how the
algorithm was
developed,
although there
may be limited
iterations or little
justification for
changes.
Not fully clear how
the algorithm was
developed, but
there is some
narrative.
Unclear how
algorithm was
developed, or lack
of explanation of
changes.
Reflection
10
There is a clear
understanding of
the current
solution and any
limitations, with a
good critical
analysis provided.
Reflects on the
iterative process
but may lack
critical analysis.
Limited reflection
on the process,
limitations, or
improvements.
Minimal or absent
reflection.