The hierarchy of a sprite and its clones.

With the introduction of cloning in Scratch 2.0, projects have many efficient capabilities to perform tasks without creating an extensive number of sprites. Clones are instances of sprites, meaning they inherit the properties of the sprite but are separate objects. Clones commonly may have a slightly different task to perform than the parent sprite, but one barrier is that both clones and sprites respond to almost all of the event blocks (triggers). Therefore, a trigger specifically designed for a sprite will also be run by a clone when signaled.

Concept

One way to understand the concept is with the following simple script:

when this sprite clicked
go to x:(0) y:(pick random (-100) to (100))
repeat (10)
change x by (3)

Contrary to its name, if a clone of the sprite containing the above script was to be clicked, the clone itself would perform the script. If only the sprite and not its clones should respond to the script, customize which triggers are run by what class (i.e. parent sprite or child clone) through the use of a local variable. If a local variable is not used, all clones will share the same variable.

Creating a local variable.

Local variables store values for individual sprites and clones, although they have the same name. For example, three clones can have a variable named "x velocity", but each clone can have its own individual value of its variable. In a similar way, a sprite can have a variable set to a particular string while every clone has it set to a different value. This concept of different variable values between classes allows one to choose which scripts are run by the parent sprite or child clones.

Programming

When the green flag is clicked, all clones are immediately deleted but the parent sprite still exists. This is the correct time to set the sprite's variable to an indication of its class (position on the hierarchy).

Making clones behave differently to the parent sprite

when gf clicked
set [instance v] to [sprite] //"instance" must be a private variable

This small bit of data saved in the variable "instance" simply shows that the sprite is a sprite. "Instance" must be a Private Variable or else it will not work. Next, a script must be designated for assigning all clones a variable value that shows they are clones. The following script can accomplish this:

when I start as a clone //a sprite cannot run this script, only clones
set [instance v] to [clone]

The above script will not change the sprite's variable. Instead, each individual clone will have its own variable. Once this is done, the variable in conjunction with an if statement can properly designate triggers to only run for the sprite or its clones.

when I receive [fadeAway v] //This script only works for clones
if <(instance) = [clone]> then
repeat (10)
change [ghost v] effect by (10)
end

The above script will only work for the clones, because the sprite's variable is not set to "clone", and the sprite will not execute the blocks inside the statement. This variable method is an efficient way for debugging projects in which clones are causing trouble.

Making clones behave differently from each other

The following example shows how multiple clone types can be managed in a single sprite's scripts. Note that a value is assigned to the private variable "type" before each clone (or set of similar clones) is generated. If the parent sprite is to ignore a broadcast, its own unique value of "type" should be set after the clones have been generated but before the broadcast is expected.

when green flag clicked
set [type v] to [ghost] //"type" must be a private variable.
create clone of (myself v)
set [type v] to [egon]
create clone of (myself v)
set [type v] to [parent]
when I receive [send in the ghosts v] //This script only works for clones...
if <(type) = [ghost]> then //...but can differentiate between them.
start sound (spooky moan v)
else
if <(type) = [egon]> then
say [Don't cross the streams!]

The value of the private variable "type" is inherited by each clone from the parent sprite, which ignores the broadcast because its own value of "type" is different. This technique allows many different clone types to behave in unique ways.

See Also

Cookies help us deliver our services. By using our services, you agree to our use of cookies.