微信客服：xiaoxionga100
微信客服：ITCS521
processing代写-TFT00018C
时间：2021-03-09
Page 1 of 6
Department of Theatre, Film, Television and Interactive Media
Assessment Brief
MODULE: Computational Thinking, TFT00018C
ASSESSMENT TITLE: Summative Assessment 1
ASSESSMENT DATES:
SET: Week 5, Spring Term
HAND-IN: Week 10 Spring term, 12:00 noon (GMT), Thursday 18th March 2021
THE TASK
For this assessment, you must implement a top down maze game in Processing.
You must also write a 1,000 word report describing and reflecting on your application.
This assessment is worth 30% of the total marks for this module.
GUIDANCE: TECHNICAL COMPONENT - TOP DOWN MAZE GAME
This assessment is about structured programming and your ability to implement a
standalone application entirely from scratch in Processing. You should demonstrate
knowledge of data structures, object-oriented programming and event-based
programming. You should also use graphical user interfaces and algorithms where
they are necessary for the implementation of the desired behaviour.
A top down maze game is a game in which the entire playing field is a maze, and is
viewed from the top. Examples of top down maze games include Mouse trap, Binary
Maze and Pacman.
Page 2 of 6
Department of Theatre, Film, Television and Interactive Media
Mouse Trap game on the left and Binary Maze on the right
Features you may wish to include in your game (in order of increasing complexity):
• Using an appropriate data structure to hold the maze and other elements within
the maze.
• Drawing the maze using efficient code.
• Controlling the character in the maze using keyboard.
• Stopping the character moving through the walls.
• Letting the character collect objects in the maze, such as points, food or keys.
• Making some of the object have different functions in the game, e.g. a key might
open doors, or a power pill might affect enemies.
• Adding other elements to make the game more challenging, such as a time
limit.
• Adding game UI elements, such as a title screen, score, game over and lives.
• Making the maze more complex. For example, it could be an irregular shape,
or include teleports and trapdoors for the character to find or avoid.
• Adding enemies which have simple predefined movement.
• Adding enemies which have more complex AI-defined movement, for example
they could chase the player.
• Adding more levels.
• Adding sound effects to events happening in the game (e.g. character moving
around the maze, collecting objects, enemies interaction, winning a level, and
more)
• Making the maze move around the player rather than the player move around
the maze.
• Dynamically generate the maze, so that each time the game is launched, the
maze would be randomly generated.
Please note that the list above is for inspiration, you are not expected to implement
all of these features, or follow this order, or be limited to this list. These features are
provided as examples of how you might add depth to your project.
Page 3 of 6
Department of Theatre, Film, Television and Interactive Media
GUIDANCE: REPORT
The report should contain:
• A description of the implemented functionality (like a user manual) – you can
and are advised to use screenshots for this. You should also describe the major
features and behaviours, along with how a human user interacts with the system.
• A description of how the code implements the behaviour described above,
including clear descriptions and diagrammatic representations of classes, global
variables, and functions, and of their interdependencies. You do not have to
describe everything – you may and are advised to describe only the most
challenging aspects and/or most elegant solutions of your implementation.
• A reflective section in which you report existing bugs, limitations and possible
improvements – i.e. aspects of the code that do not work well, behaviour that you
would have liked to implement but did not know how and things you could have
done differently.
All sources should be cited using the Harvard referencing system format. You may
refer to this guide from the University of York. This guide from the Anglia Ruskin
University Library may also be helpful, particularly for finding out the correct format for
citing non-standard sources (e.g. computer games).
You must meet the target number of words as stated on this brief. You are
allowed a 10% leeway either way (i.e. 100 words over or under is acceptable). This
length limit excludes any appendices and all diagrams, screenshots and fragments of
code. The word count must be stated clearly at the end of the report.
You should note that over- or under-writing beyond the limits of the leeway may incur
mark deductions with respect to the comprehensiveness and clarity of your work per
the assessment and feedback criteria.
Plagiarism and collusion, for both the technical component and the report, are
unacceptable under any circumstances. They are serious academic offences.
Please refer to your academic integrity tutorial and other references for guidelines on
plagiarism and on how to make proper citations.
ETHICS
Students ARE NOT permitted to conduct any work that raises ethical concerns.
Full details about this are available on the Ethics VLE, and you may be penalised if
you do not follow these guidelines.
Page 4 of 6
Department of Theatre, Film, Television and Interactive Media
SUBMISSION REQUIREMENTS
Your submission must include the following two components:
Component Submission Procedure
1,000 word report, with a cover
sheet, in PDF format
Worth 20% of the total mark
Submit the report via the VLE Submission
Point.
Your PDF file should be name in the format:
EXAMNUMBER_CT1.pdf (e.g.
Y123456_CT1.pdf)
ZIP file containing all the
processing files required to build
and run the application, including
source, data files (images, etc).
Worth 80% of the total mark
Submit the ZIP file via the Storage drive.
Instructions for how to submit via Storage are
provided in Assessment Submission Area of
the VLE.
Your ZIP file should be named in the format:
EXAMNUMBER_CT1.zip (e.g.
Y123456_CT1.zip).
IMPORTANT: You are very strongly advised to read the Very Important Points To Note
for the Submission of All Assessments (which includes important information on the
appropriate time to start submission; how to check your files; what to do if there are
problems with submission etc). Please access the information document linked above
using your University of York account.
You are welcome, and encouraged, to submit your work in advanced.
PENALTIES
Note the assessment penalties as described in the handbook and on this Intranet
page.
In particular:
• Your report MUST be submitted as a PDF file. Please ensure that you have
uploaded the correct file AND in the correct file format. Standard late penalties may
apply until the assessment is received in its correct file and correct file format.
Page 5 of 6
Department of Theatre, Film, Television and Interactive Media
ASSESSMENT AND FEEDBACK CRITERIA
Mark breakdown and feedback pro-forma:
TOTAL:
Implementation (80%)
Technical Implementation
Comprehensiveness of the
Application and Overall Behaviour (35%)
How complex the implemented features are
and how easy it is to use them
Code Design (25%)
How appropriate the implementation is,
including appropriately defined classes, data
structures and variables; appropriately
chosen algorithms; effective algorithm
implementations (code extendibility is a
criterion which will be considered in the
award of high marks)
Code Structure and Readability (10%)
How clear and organised the code is,
including appropriately named variables and
functions/methods, clear indentations, clear
comments
Code Robustness (10%)
How stable, responsive and robust the
implementation is, including how well it
avoids crashing and deals with errors and
edge cases
/100
/100
/100
/100
Note: The complexity of the implementation is taken into account during the marking.
This means that a more ambitious implementation that is not perfectly executed in
terms of code efficiency and elegance may achieve a higher mark in the technical
quality mark categories than a game that perfectly makes use of trivial techniques.
To achieve an Exceptional or Outstanding mark for the technical quality categories,
your game must go beyond expectations from a technical complexity perspective
and the code must be both elegant and efficient.
Page 6 of 6
Department of Theatre, Film, Television and Interactive Media
Report (20%)
Description and Justification (10%)
Implemented functionality (5%)
How clearly and comprehensively the
report describes the overall application.
Code Design (5%)
How clearly and comprehensively the
report describes the code design
/100
/100
Critical Reflection (10%)
How clearly and comprehensively the
report identifies and discusses existing
bugs and limitations, and possible
extensions.
/100
This assessment will be marked using “stepped” or “fixed point” marking.
学霸联盟
Department of Theatre, Film, Television and Interactive Media
Assessment Brief
MODULE: Computational Thinking, TFT00018C
ASSESSMENT TITLE: Summative Assessment 1
ASSESSMENT DATES:
SET: Week 5, Spring Term
HAND-IN: Week 10 Spring term, 12:00 noon (GMT), Thursday 18th March 2021
THE TASK
For this assessment, you must implement a top down maze game in Processing.
You must also write a 1,000 word report describing and reflecting on your application.
This assessment is worth 30% of the total marks for this module.
GUIDANCE: TECHNICAL COMPONENT - TOP DOWN MAZE GAME
This assessment is about structured programming and your ability to implement a
standalone application entirely from scratch in Processing. You should demonstrate
knowledge of data structures, object-oriented programming and event-based
programming. You should also use graphical user interfaces and algorithms where
they are necessary for the implementation of the desired behaviour.
A top down maze game is a game in which the entire playing field is a maze, and is
viewed from the top. Examples of top down maze games include Mouse trap, Binary
Maze and Pacman.
Page 2 of 6
Department of Theatre, Film, Television and Interactive Media
Mouse Trap game on the left and Binary Maze on the right
Features you may wish to include in your game (in order of increasing complexity):
• Using an appropriate data structure to hold the maze and other elements within
the maze.
• Drawing the maze using efficient code.
• Controlling the character in the maze using keyboard.
• Stopping the character moving through the walls.
• Letting the character collect objects in the maze, such as points, food or keys.
• Making some of the object have different functions in the game, e.g. a key might
open doors, or a power pill might affect enemies.
• Adding other elements to make the game more challenging, such as a time
limit.
• Adding game UI elements, such as a title screen, score, game over and lives.
• Making the maze more complex. For example, it could be an irregular shape,
or include teleports and trapdoors for the character to find or avoid.
• Adding enemies which have simple predefined movement.
• Adding enemies which have more complex AI-defined movement, for example
they could chase the player.
• Adding more levels.
• Adding sound effects to events happening in the game (e.g. character moving
around the maze, collecting objects, enemies interaction, winning a level, and
more)
• Making the maze move around the player rather than the player move around
the maze.
• Dynamically generate the maze, so that each time the game is launched, the
maze would be randomly generated.
Please note that the list above is for inspiration, you are not expected to implement
all of these features, or follow this order, or be limited to this list. These features are
provided as examples of how you might add depth to your project.
Page 3 of 6
Department of Theatre, Film, Television and Interactive Media
GUIDANCE: REPORT
The report should contain:
• A description of the implemented functionality (like a user manual) – you can
and are advised to use screenshots for this. You should also describe the major
features and behaviours, along with how a human user interacts with the system.
• A description of how the code implements the behaviour described above,
including clear descriptions and diagrammatic representations of classes, global
variables, and functions, and of their interdependencies. You do not have to
describe everything – you may and are advised to describe only the most
challenging aspects and/or most elegant solutions of your implementation.
• A reflective section in which you report existing bugs, limitations and possible
improvements – i.e. aspects of the code that do not work well, behaviour that you
would have liked to implement but did not know how and things you could have
done differently.
All sources should be cited using the Harvard referencing system format. You may
refer to this guide from the University of York. This guide from the Anglia Ruskin
University Library may also be helpful, particularly for finding out the correct format for
citing non-standard sources (e.g. computer games).
You must meet the target number of words as stated on this brief. You are
allowed a 10% leeway either way (i.e. 100 words over or under is acceptable). This
length limit excludes any appendices and all diagrams, screenshots and fragments of
code. The word count must be stated clearly at the end of the report.
You should note that over- or under-writing beyond the limits of the leeway may incur
mark deductions with respect to the comprehensiveness and clarity of your work per
the assessment and feedback criteria.
Plagiarism and collusion, for both the technical component and the report, are
unacceptable under any circumstances. They are serious academic offences.
Please refer to your academic integrity tutorial and other references for guidelines on
plagiarism and on how to make proper citations.
ETHICS
Students ARE NOT permitted to conduct any work that raises ethical concerns.
Full details about this are available on the Ethics VLE, and you may be penalised if
you do not follow these guidelines.
Page 4 of 6
Department of Theatre, Film, Television and Interactive Media
SUBMISSION REQUIREMENTS
Your submission must include the following two components:
Component Submission Procedure
1,000 word report, with a cover
sheet, in PDF format
Worth 20% of the total mark
Submit the report via the VLE Submission
Point.
Your PDF file should be name in the format:
EXAMNUMBER_CT1.pdf (e.g.
Y123456_CT1.pdf)
ZIP file containing all the
processing files required to build
and run the application, including
source, data files (images, etc).
Worth 80% of the total mark
Submit the ZIP file via the Storage drive.
Instructions for how to submit via Storage are
provided in Assessment Submission Area of
the VLE.
Your ZIP file should be named in the format:
EXAMNUMBER_CT1.zip (e.g.
Y123456_CT1.zip).
IMPORTANT: You are very strongly advised to read the Very Important Points To Note
for the Submission of All Assessments (which includes important information on the
appropriate time to start submission; how to check your files; what to do if there are
problems with submission etc). Please access the information document linked above
using your University of York account.
You are welcome, and encouraged, to submit your work in advanced.
PENALTIES
Note the assessment penalties as described in the handbook and on this Intranet
page.
In particular:
• Your report MUST be submitted as a PDF file. Please ensure that you have
uploaded the correct file AND in the correct file format. Standard late penalties may
apply until the assessment is received in its correct file and correct file format.
Page 5 of 6
Department of Theatre, Film, Television and Interactive Media
ASSESSMENT AND FEEDBACK CRITERIA
Mark breakdown and feedback pro-forma:
TOTAL:
Implementation (80%)
Technical Implementation
Comprehensiveness of the
Application and Overall Behaviour (35%)
How complex the implemented features are
and how easy it is to use them
Code Design (25%)
How appropriate the implementation is,
including appropriately defined classes, data
structures and variables; appropriately
chosen algorithms; effective algorithm
implementations (code extendibility is a
criterion which will be considered in the
award of high marks)
Code Structure and Readability (10%)
How clear and organised the code is,
including appropriately named variables and
functions/methods, clear indentations, clear
comments
Code Robustness (10%)
How stable, responsive and robust the
implementation is, including how well it
avoids crashing and deals with errors and
edge cases
/100
/100
/100
/100
Note: The complexity of the implementation is taken into account during the marking.
This means that a more ambitious implementation that is not perfectly executed in
terms of code efficiency and elegance may achieve a higher mark in the technical
quality mark categories than a game that perfectly makes use of trivial techniques.
To achieve an Exceptional or Outstanding mark for the technical quality categories,
your game must go beyond expectations from a technical complexity perspective
and the code must be both elegant and efficient.
Page 6 of 6
Department of Theatre, Film, Television and Interactive Media
Report (20%)
Description and Justification (10%)
Implemented functionality (5%)
How clearly and comprehensively the
report describes the overall application.
Code Design (5%)
How clearly and comprehensively the
report describes the code design
/100
/100
Critical Reflection (10%)
How clearly and comprehensively the
report identifies and discusses existing
bugs and limitations, and possible
extensions.
/100
This assessment will be marked using “stepped” or “fixed point” marking.
学霸联盟
