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 gf clicked repeat (10) go to (random position v) create clone of [myself v] end go to x: (0) y: (0) when [space v] key pressed say [Hello!] for (2) secs
When the space key is pressed in the example, all the clones and original sprite say "Hello!". This is because they all respond to the key press hat and run the script connected to it. Often this isn't desired, for example, imagine that pressing space created a new clone. The number of clones would grow exponentially as each clone clones itself.
Local variables store values unique to each clone or sprite so can be used to uniquely identify them or give them unique behavior.
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 local variable
This small bit of data saved in the variable "instance" simply shows that the sprite is a sprite. "Instance" must be a local 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 [fade away v] if <(instance) = [clone]> then // check if this script is running in a clone 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 local 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.
