Scratch Game Design Rubric Doc

Assessment Guidance

Data Representation: Information about objects (Sprites) tell the program about what to do with these objects to run properly. This includes information about a Sprite such as their position, direction, size and/or colour. Data is a fundamental consideration, as programs use data to operate. Students use data in programs when they tell a Sprite how to move around the program (e.g. how many steps a Sprite takes) and they can manipulate data in their program to have a different output (e.g. to change the number of steps a Sprite will take).

Students can also store data in their programs using variables. Variables are like containers and can hold data – such as keeping track of a score in a game.

Data for a Sprite

Variable in a program

Has the student adapted the attributes of their Sprite?
Can the student identify and classify the types of data in their program?
Can they identify the attributes of their Sprite?
Can students predict what will happen if they make a change to some data in their program?
Has the student used a variable in their program?

Sequence: The program will be made up of a sequence of steps (algorithm) arranged as blocks of code (our "script") that have a start and an end point. These blocks execute one after the other. Students will test that their code executes in the correct order. The blocks in the brown "Events" block group can be used to tell the computer how/when to execute a sequence of code. Dr Scratch measures this with "Flow Control" (awarded 0 points, as the starting point of their program development).

A more advanced version of sequences could be that students not only have one single script, but that multiple scripts, made up of a sequence of blocks, are executing at the same time. This is referred to as "parallel programming" and is measured in Dr Scratch as "Parallelism".

Sequences (logical order)

Parallelism (multiple scripts)

Is there a start-block for the sequence of blocks that indicate when the program should start? E.g. "When [green flag] clicked" or "when [space] key pressed".
Does the code execute in the intended order? Do events/actions happen in the program in the expected order? Are the blocks used organised in a logical order?
How many "scripts" of are present? Can the student add another script to run at the same time?
The most obvious starting point is when students have users click the green flag to start the program. Can they also consider other ways a script might be prompted to start by using alternative "event" blocks?

Iteration (repetition): As students form their sequential blocks, they can introduce the repeat/loop block to avoid repetition in code as a more advanced aspect of sequences. For example, instead of putting the same single blocks one after the other, we can wrap an iteration (repeat/loop) block around blocks they would like to repeat, to tell the computer to execute the code a certain number of times. This block is used to control our code and can be found in the yellow "control" block section of Scratch. Dr Scratch measures this as an extension of "Flow Control" (awarded 1 point or more).

Iteration

Has the student used iteration (repeat/loop) blocks in their script?
Are there existing blocks that are repetitive and could be replaced with an iteration (repeat/loop) block?
Can the student evaluate their program and think of ways to make their code more efficient?
Can the student identify code that is repetitive? Can they see a pattern in their code?

Branching/Conditions: We can use branching blocks (also referred to as "logical operators" or "decisions") to tell our computer what to execute based on a decision or condition in our code. Dr Scratch measures this as "Logic" (awarded 0 points for a simple "IF-THEN" combination and 1 point for an IF/ELSE combination. 2 points awarded for combining "branching blocks").

IF-THEN combination

IF- ELSE combination

User Input: Programs can be designed to engage the user by having them interact with the program – through some form of user input. For example, a user might click on a Sprite in a game or animation to have make it react in some way, or they could enter their name or a quiz answer when prompted. When we think of input and output, we can characterise the images on the screen and sound as output. Input is anything that provides some information to our program – such as a click of the mouse or a keyboard, or entered text. User input involves students considering the functional requirements of their program.

User input/interactivity

Is there any level of user interaction with the program beyond clicking the green flag?
What types of interaction are featured?
Can the student identify the functional requirements for how the user interacts with their program?

This is measured in Dr Scratch by "User Interactivity" (with 0 points starting with the "when [green flag] clicked" event block). Further points are awarded if the user is invited to engage in further interaction, such as enter their name, use the mouse or click on other Sprites. The highest level of interaction can occur when they use the microphone or webcam abilities to interact with the user. Interactivity blocks are found in the brown "Events", blue "Sensing" and pink "Sound" sections.

User interface design: This includes: what the user can see, how the user interacts with the program, the information provided to the user and the usability (functionality/ease of use) of the program. Students need to consider their user in their designs and ensure programs meet their needs and intended purposes. For example, it is not enough to make a program interactive, if the user does not know how to interact with the program. The student needs to provide information to the user that helps them to use their program. This could be through Scratch Instructions, an opening scene with information, or prompts throughout the program that help the user. It could even include a "Help" page if users need to be reminded or seek help. User interface design involves students considering the functional requirements of their program.

Does the user know how to use and interact with the program? E.g. Are instructions or prompts present for which keys to press?
Is the program usable? How could user engagement be improved?
Is the design visually engaging and appropriate? E.g. consider fonts, editing, colour contrasts.
Has the student completed a user-test of their program on their own or with a peer? What did they identify as needing to change?