no plarigism and no copy from previous work

GPSIT 1101 IT Problem SolvingAssessment 3: Design and Build a
Minimal Viable Solution
Overview
This is an individual assignment that requires you to devise and attempt to implement a
game using block-based coding. You will design algorithms for your game, attempt to
implement the algorithms and then present an aspect of your work to your peers. There are
three separate parts to this assignment, coinciding with the stages of developing your
solution:
•
Part A: Design Documentation and Peer Review
•
Part B: Implementation Report
•
Part C: Presentation
Timelines and Expectations
Percentage Value of Task: 40%
•
Part A – 10%
•
Part B – 20%
•
Part C – 10%
Due:
•
Part A: Initial Design Documentation – 9th September 2024 @ 4:30pm
•
Part B: Implementation – 4th October 2024 @ 4:30pm
•
Part C: Presentation – Week 11 Lab
Minimum time expectation: 20 hours
Learning Outcomes Assessed
K2-5, S1-4, A1
Assignment Scenario
You are tasked with designing and creating a Scratch-based escape room game inspired by
Ballarat. The game should transport players into a virtual environment that reflects the city’s
history, culture, and/or landmarks. Your creativity in designing the game is encouraged, as
long as it can be realised using the Scratch programming platform.
CRICOS Provider No. 00103D | RTO Code 4909
Page 1 of 11
Part A: Initial Design Documentation and Peer Review
This stage requires you to create some initial draft documentation for your game. You will
create and document rules for your game, and develop algorithms for its implementation.
These rules and algorithms may continue to evolve throughout the course of the assignment,
so they do not need to be perfect, but you do need to try to make these as complete as
possible to get the best value out of the peer reviews and simplify the coding stage of the
assignment. Your documentation will continue to be updated as needed throughout the
assignment.
You will also peer review the designs of two other students in the course.
Game Design
You can select any game within the scope outlined in the Assignment Scenario.
Your game must:
•
Be challenging for you, so that you are able to demonstrate your problem solving
skills.
•
Require you to use a variety of problem solving strategies / techniques to complete.
•
Be creative. Fun is a huge element, so you want to select something that you will
enjoy.
•
Require you to code the behaviour using Scratch v3, and be within the capabilities of
Scratch v3.
You may not use any other programming environment for this assignment. Your game must
also not be something that you can solve by following previously created instructions (even
with minor modifications) or downloading existing programs. For example, you cannot find a
similar game on Scratch and copy it as your own, or use a Scratch tutorial to provide your
code. Looking at other examples and completing tutorials to help you learn is fine, but
copying other work is not counted as using problem solving skills. You need to think through
what your code requires for yourself.
Design Documentation
Once you have chosen your game design, you must create documentation that outlines the
rules and breaks down the logic of the gameplay into algorithms you can use to implement
your game. You may need to break your gameplay down into smaller sub-tasks to achieve
this, and should include statements that make the purpose of each task or subtask clear.
Your documentation must clearly describe an overview of your game, the game rules and
include algorithms and a UML model to represent the full functionality of the game you intend
to implement during the assignment. Your documentation must be saved in .pdf format.
Peer Reviews
After the submission date of the design documents your lecturer will print off your assignment
so that you can conduct a peer review on two other students’ design documentations. You
individually are to review these design documents.
Your task is to review the documentation allocated to you and to evaluate it against a set of
criteria provided in a marking rubric. You should consider how well the documentation
CRICOS Provider No. 00103D | RTO Code 4909
Page 2 of 11
defines the problem(s) under investigation, how clearly algorithms represent and address the
problems(s) and how effectively UML diagrams are documented to solve the problem(s).
You will also have the opportunity to provide your own comments, and should take care to
provide specific comments that highlight both the positive aspects and the potential issues of
the proposed solution(s) and documentation.
Note: Your mark will not be impacted by the feedback your peers provide on your
work. Your tutor will be marking your design documentation separately, and it is your
tutor’s mark that will contribute to your assessment. You will be marked based on
how well you complete your peer reviews.
All reviews must be completed in class, in readiness for the next stage of the assignment.
You should review the feedback you have received and incorporate the feedback you receive
into your design, as appropriate.
You shall continue to update your documentation throughout the assignment, based on your
experiences, and any additional ideas you obtain through seeing the designs completed by
other people (Note: this does not mean copying their work. It does mean that you can be
inspired by it, and make improvements to your own design based on what you’ve learned).
This revised document is submitted as part of Part B: Implementation.
Part B: Implementation Report
This part of the assignment requires you to discuss, analyse and reflect upon the problem
solving techniques you use during the assignment. This will occur through a work journal to
be documented in Microsoft Word or compatible text editing program (and saved as a .pdf
file for cross-system compatibility). This task is to be completed individually.
You will update and maintain your work journal on a frequent basis throughout the
assignment in dated journal entries, covering an overview of the work you have been
attempting, any challenges or problems you encounter, the output or results of your work and
screenshots of supporting documentation for your entry, e.g. the code you work on for each
entry, any diagrams / documentation you update, test cases and test results, tables you
create, etc.
Note: The supporting documentation you include throughout your Work Journal is really
important to demonstrate your progression through the assignment. It allows someone else
to review your progress and the changes that occur throughout the assignment, so including
screenshots as you progress provides a record of how your work evolves throughout the
assignment and enables other people to understand the context in which your journal entries
are made.
Throughout these journal entries, you will make and analyse connections between the work
you are performing and the course concepts reviewed throughout the semester. For
example, if you attempt to solve a problem using a graphical model, your entry would identify
the problem you were trying to solve, discuss the use of the graphical model and the reason
for its use and analyse how effective the graphical model was in helping you resolve the
problem. It would also include a screenshot of the graphical model you used.
CRICOS Provider No. 00103D | RTO Code 4909
Page 3 of 11
You will also reflect on your learning throughout the assignment. This includes reflecting on
course concepts that you now better understand as well as what you learn about yourself as
a problem solver.
The work journal does not need to document every single aspect of the work you perform
during the assignment, and does not need to address all of the marking criteria in every
entry. Rather, the journal entries as a whole need to provide insight into your experiences in
the assignment. An example of the format for a single journal entry is included below (yours
should include the actual images instead of just a list of the embedded images):
Supporting Documentation
Effective completion of your work journal will involve referencing documentation that you
have created for the assignment. Examples of this include UML models, tools for problem
solving, code, test cases and test results.
You are also required to submit an updated Design Documentation alongside your work
journal. You should clearly summarise the changes that you made as you progressed
through this assignment.
All code (in a .sb3 file) should be uploaded as a separate time. Models, test cases and test
results should be included as part of the Implementation Report.
Part C: Presentation
The last part of the assignment is a presentation. Each person must provide a short
individual presentation about their assignment experiences in their scheduled laboratory.
This presentation will:
•
provide a description and demonstration of the game you chose for the assignment.
•
identify a personally-significant moment experienced during the assignment and
discuss what made this significant. A significant moment may include events that
were challenging, particularly emotive (satisfying, frustrating, etc) or that had a large
impact on the work performed during the assignment.
CRICOS Provider No. 00103D | RTO Code 4909
Page 4 of 11
•
identify one problem you encountered during the assignment, and discuss the
problem solving techniques or strategies you used to address this problem and how
(and why) these were used.
•
reflect on personal learning and responses to challenges encountered during the
assignment, including understanding of course concepts, personal skills in problem
solving and the role of mindset.
Each presentation should not exceed 15 minutes. Any presentation aids readily available to
students may be used, but students are responsible for ensuring these will work in the labs
and having a backup available in the event of an issue.
Important Note Before You Begin
This assignment takes the form of a hackathon, meaning that you have a short period of time
in which to work on your idea and you may not have a finished product when it ends. This is
absolutely fine – you do not need to fully implement your game, but you do need to make
some progress towards your goal.
The key here is that you are applying problem solving skills to work on your game. Some of
you have never coded in your lives, while others have had quite a bit of experience. You are
not being assessed on how good your game is, or how complicated its design, or anything
else that assumes you already have a level of coding ability. Instead, the focus is on your
problem solving skills. When you encounter a challenge, how do you respond? What
strategies do you employ? How do you proceed when your first (or first several) attempts are
unsuccessful? For your assignment, this means two key things:
1. Even though you are able to freely see and access existing Scratch games, copying
someone else’s work does not provide you with any benefit. Copying existing code
does not allow you to practise your problem solving skills, and so you would not
receive high marks for the submitted work. It is what you, personally, achieve that
counts, not what you’re able to source from someone else.
2. The complexity of your game idea allows you to control the level of problem solving
you need to perform. If you are a novice coder, pick a simple idea, or an idea that
starts simply but can easily be expanded. Conversely, if you are an experienced
coder, your game will need to include some complexity. Only you know your current
capabilities, and so it is up to you to choose an idea that interests you and that
pushes you just beyond your current capabilities so that you have the opportunity to
demonstrate your problem solving skills. If, when you get to the coding activities, you
find that your choice was too simple, you can add further complexity. You will not be
penalised for submitting an incomplete implementation of your game, but you will be
penalised if you have chosen a task that does not provide you the opportunity to
problem solve appropriately.
Using Scratch v3
Scratch (https://scratch.mit.edu/) is available for both online and offline use. Download
Scratch from here: https://scratch.mit.edu/download. Save your work to your computer as
you go.
CRICOS Provider No. 00103D | RTO Code 4909
Page 5 of 11
Some interactive tutorials are available within Scratch; and others are available here:
https://projects.raspberrypi.org/en/codeclub/scratch-module-1 to help you learn how to use
the Scratch interface and create programs.
While you will be introduced to the Scratch programming environment in class,
developing your game will require independent learning. To successfully implement
your design, you will need to dedicate time outside of class to explore and master the
Scratch platform.
CRICOS Provider No. 00103D | RTO Code 4909
Page 6 of 11
Submission
There are two submissions associated with this Assignment:
Part A (Initial Design Documentation and Peer Review): Your initial design
documentation must be submitted in the link provided in Moodle, as a single .pdf file. Your
engagement in the peer review session is essential. This includes providing constructive
feedback to peers and actively participating. Your contribution to the peer review process will
be formally assessed in class.
Part B (Implementation Report): Your submission must include all associated
documentation: Implementation report (journal), Final Design Document (which has evolved
since original submission on Part A), code file (sb3) and be submitted in the assignment
submission link provided on Moodle.
Your presentation will be assessed during your scheduled lab class in week 11. The
presentation itself does not need to be submitted.
Feedback
Marks will be uploaded in fdlMarks, and a completed marking feedback sheet will be
uploaded in Moodle within 2 weeks of the assessment due date.
Plagiarism:
Plagiarism is the presentation of the expressed thought or work of another person as though
it is one’s own without properly acknowledging that person. You must not allow other
students to copy your work and must take care to safeguard against this happening. More
information about the plagiarism policy and procedure for the university can be found at
http://federation.edu.au/students/learning-and-study/online-help-with/plagiarism.
CRICOS Provider No. 00103D | RTO Code 4909
Page 7 of 11
Marking Criteria – Part A
Design
Documentation
Game objective and
rules developed
Complete Peer
Reviews x 2
Develop algorithms to
implement the
gameplay described.
Provide an
appropriate UML
model to represent
the proposed
gameplay
3
Algorithms are provided. These clearly
relate to the gameplay, are unambiguous,
clear, complete and logical. These
algorithms should successfully implement
the gameplay described.
A UML diagram is provided and is an
appropriate type of diagram for the
purpose it has been used. The diagram
appropriately reflects the gameplay.
Correct notation is used, and following
the diagram would lead to
implementation of appropriate solutions.
2
1
0
A statement of the game objective has
been provided, along with a detailed
description of the rules. These clearly
identify and describe the gameplay to be
implemented, enabling the development
of robust solutions.
A statement of the game objective has
been provided, along with a description of
the rules. These provide a reasonable
description of the game, but some further
clarification would be needed to develop
robust solutions.
Two peer reviews of design
documentation have been completed.
These both demonstrate critical analysis
of the design documentation and provide
meaningful feedback.
Two peer reviews have been completed.
The analysis and / or feedback lack
analysis.
OR One peer review has been completed.
This demonstrates critical analysis or the
design documentation and provides
meaningful feedback.
1
Algorithms are provided. These can be
related to the gameplay but are a) unclear
or ambiguous b) incomplete c) logically
incorrect.
No game objective has been provided OR
A game objective has been provided but
rules of the game have not been provided
OR The game objective and / or the rules
have been provided but these are
ambiguous or do not clearly describe the
gameplay.
Peer reviews not completed.
2
Algorithms are provided. These clearly
relate to the gameplay and mostly achieve
the required solution but contain a small
number of issues with clarity,
completeness or logic.
A UML diagram is provided and is an
appropriate type of diagram for the
purpose it has been used. The diagram
reflects the gameplay as appropriate.
There are some issues with clarity, or logic
that would cause the solutions to fail, OR
some of the notation used is incorrect.
A UML diagram is provided however the
choice of diagram type is not appropriate
for the way it has been used.
0
Algorithms not provided OR algorithms
are provided but the relationship between
these and the gameplay is unclear.
No UML diagram provided OR the UML
diagram does not clearly relate to the
gameplay described.
Page 8 of 11
Marking Criteria – Part B
Work Journal
Problem Solving
Techniques
Reflection
Challenges
encountered
Perseverance through
Challenges
Test Cases
5
A variety of problem solving techniques
are identified and discussed with explicit
connection to the related modelling
documentation, code and / or test cases.
Meaningful connections are analysed
between course concepts and the
application of these concepts to solve
problems experienced during the
assignment. Use of problem solving
techniques has led to significant progress
towards implementing a solution.
Thorough, on-going, frequent reflection is
evident throughout the journal and
includes in-depth analysis of how the
experiences contributed to student’s
understanding of course concepts.
3
Journal entries demonstrate that the
problem selected for the assignment
presented many challenges. This may
have been achieved by adapting the initial
problem to a more difficult standard.
3
Problem solving techniques are identified
and discussed with explicit connection to
the related modelling documentation,
code and / or test cases. Attempts to
relate course concepts with experiences
solving problems in the assignment are
made but these lack depth and / or
understanding. Use of problem solving
techniques has led to reasonable progress
towards implementing a solution.
1
A limited selection of problem-solving
techniques are identified and discussed.
0
Application of problem solving techniques
is not evident through the journal OR
Problem solving techniques are identified
and discussed but links are not made
between these techniques and how they
have been applied to specific modelling
documentation, code and / or test cases.
On-going, frequent reflection is evident
throughout the journal and includes
analysis of how the experiences
contributed to student’s understanding of
course concepts.
2
Journal entries demonstrate that the
problem selected for the assignment
presented several challenges. This may
have been achieved by adapting the initial
problem to a more difficult standard.
Few, or infrequent, attempts at reflection
have been included in the journal OR
analysis is either not provided or limited.
Reflection has not been attempted.
1
Journal entries demonstrate that the
problem selected for the assignment
presented few challenges.
0
Journal entries do not identify challenges
encountered during the assignment
Experiences resolving challenges are
discussed and demonstrate a thoughtful
approach to identifying and trialling
possible solutions. A strong willingness to
persist through difficulties and adapt
approaches when required is evident.
Experiences resolving challenges are
discussed. A willingness to persist
through difficulties and adapt approaches
when required is evident.
Experiences resolving challenges are
discussed. A limited willingness to persist
through difficulties and adapt approaches
when required is evident.
Journal entries identify challenges
encountered during the assignment but
do not provide details of how these were
approached and / or demonstrate
willingness to persist through difficulties.
A comprehensive selection of test cases is
provided to validate design (whether code
is fully implemented).
Completed test results are provided for a
comprehensive selection of test cases, in
Test cases are provided to validate most
of the design (whether code is fully
implemented). Additional test cases
would be required for confidence that the
code behaves as required.
Limited or no test cases are provided. OR
Limited or no testing completed.
CRICOS Provider No. 00103D | RTO Code 4909
Page 9 of 11
so far as code attempted. Errors may still
exist in the code.
Supporting
Documentation
Appropriate documentation is
incorporated in the journal in support of
the problem solving activities. This
design documentation is updated when /
if appropriate to reflect new learnings and
feedback
Test results are provided to validate most
code behaviour, in so far as code
attempted. Errors may still exist in the
code.
Appropriate documentation is
incorporated in the journal in support of
the problem solving activities.
Incomplete or no supporting
documentation is provided.
Marking Criteria – Part C
Presentation
Description and
Demonstration
3
Personally-Significant
Moment
Challenge Identified
Problem Solving
Techniques
Reflection
At least three key problem solving
techniques are identified and discussed in
relation to how and why they were used,
in the context of the unique challenge
identified. The appropriateness of these
techniques for this purpose is insightfully
analysed.
CRICOS Provider No. 00103D | RTO Code 4909
2
The game idea selected for the
assignment is clearly described and
demonstrated.
The presentation includes identification
and discussion of a personally-significant
moment during the assignment.
At least three key problem solving
techniques are identified and discussed in
relation to how and why they were used,
in the context of the unique challenge
identified. The appropriateness of these
techniques for this purpose is analysed
but this analysis lacks depth.
An insightful reflection analyses the
assignment experience and the student’s
personal responses to the challenges
encountered. The impact on learning,
understanding of course concepts and the
role of mindset are meaningfully
reviewed.
1
The game idea selected for the
assignment is described and/or
demonstrated.
Personally significant moment during the
assignment identified but limited
discussion of this event occurs.
A challenging problem encountered in the
assignment is identified and described.
One or two problem solving techniques
are identified and discussed in relation to
how and why they were used, in the
context of the unique challenge identified.
The appropriateness of these techniques
for this purpose is analysed.
0
The game idea selected for the
assignment is unclear..
A reflection analyses the assignment
experience and the student’s personal
responses to the challenges encountered.
The impact on learning, understanding of
course concepts and the role of mindset
are reviewed but this lacks depth.
No reflection is included OR A reflection is
included but does not make connections
to learning, understanding of the course
concepts and mindset.
A personally significant moment during
the assignment is not identified.
No challenging problem from the
assignment is identified.
Problem solving techniques are not
identified and discussed
OR
Problem solving techniques are identified
but not discussed as to how and why used
and / or not analysed.
Page 10 of 11
CRICOS Provider No. 00103D | RTO Code 4909
Page 11 of 11