Creators – Week 16

This week, we worked to make the “Gem Found” prefab that we created last week actually appear when we found a gem, and disappear after it’s played it’s animation.

A Script for Our ‘Gem Found’ Prefab

We want a simple script, called GemFoundMessage.cs, that will set the message on the prefab’s canvas to match the gem we just found:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using TMPro;

public class GemFoundMessage : MonoBehaviour
    public TMP_Text Text;
    public Transform GemHolder;

    public void SetGemDefinition(GemDefinition gd)
        string message = string.Format("You found a {0} spirit gem!",
        Text.text = message;

We attach this to the root of of our prefab. This script contains a single function we can call to set the text based on the gem definition and a couple of properties. One property is the text we need to update, the other is the location where we’re going to spawn a gem model to have it animate.

Making the GemFound Prefab Clean Itself Up

We already have a SelfDestruct script. We add it to our GemFound Prefab and give it a time of 4 seconds; this is enough time for our animation to finish.

Updating PlayerDig

We now need to update PlayerDig.cs. There are a few things to do:

  1. After spawning our digging animation, we want to wait three seconds and then check to see if we’ve found a gem.
  2. We look to see if the nearest gem is within a certain distance (the larger we make this the less precise the player will need to be)
  3. Assuming there is a gem there, find out what type of a gem it is
  4. Add it to our inventory [We’ll need to wait to do this, as we don’t have our inventory written yet]
  5. Create a GemFound prefab
    • Inform it what gem type we have
    • Create a gem as part of the GemFound

First we add the line Invoke(“DigResult”, 3); this to the OnDig() function as shown:

        if (Physics.Raycast(rayPos, Vector3.down, out hitInfo, 10.0f, lm))
            Instantiate(DiggingPrefab, hitInfo.point,
            Invoke("DigResult", 3);

We then add the DigResult() function:

    private void DigResult()
        float distToNearest = (ItemScatterer.nearestItem.transform.position -

        if (distToNearest > MaxDistToItem)

        // Capture the gem definition
        RandomGem rg = ItemScatterer.nearestItem.GetComponent<RandomGem>();
        GemDefinition gd = rg.GemDefinition;

        // Remove the item from ItemScatterer
        ItemScatterer.nearestItem = null;

        // TODO: Add to our inventory

        // Spawn the Gem Found Prefab to let the player know what they found
        GameObject gfb = Instantiate(GemFoundPrefab, GemFoundLocation);
        GemFoundMessage gfm = gfb.GetComponent<GemFoundMessage>();
        GameObject gem = Instantiate(gd.Prefab, gfm.GemHolder);

This does everything we talked about above.

Basic UI

We took a short look at simple UI layout options as preparation for building the UI next session.

Code Download

The code for this week’s project is on our GitHub, as always. 

Modellers – Week 16

We continued with our tank. In this session we:

  1. Used an array to generate multiple track segments (treads)
  2. Uses a curve modifier to fit these around our curve
  3. Used a negative scale to mirror some objects
  4. Created a simple terrain with a cloud texture and a displace modifier
  5. Generated a procedural texture for generating camouflage

Which was a lot!

Here are the video notes:

The updated tank model can be found here.

Creators: Shootah Part 6 – Enemy Shooting Back


This week we did our last iteration on Shootah and added a Bomb to be dropped by the enemy to try to hit the player.

Bomb Class

We copied the existing Bullet class and called it Bomb instead. The main changes we had to make were:

  1. Changing the speed to a negative number so that it moved down instead of moving up (as the Bullet does)
  2. Changed the check for the top of the screen to one for the bottom of the screen instead (to account for the fact it moves down)
  3. Changed the check in its hit() function so that the Bomb doesn’t interact with the Enemy when it’s dropped, but will be marked as inactive it if hits anything else.
  4. Changed the colour of the bomb to red

Manages Bombs

It happened that the code we had already written to manage bullets was already perfect for managing bombs as well.

We used Visual Studio Code’s built-in capability to automatically rename symbols to:

  1. Rename the bullets array to projectiles
  2. Rename the manageBullets() function to manageProjectiles()

This was enough to have bombs move, draw and be removed when it becomes inactive.

Dropping Bombs

We added a new function to Ememy called shoot(). In that function we generated a random number from one to two hundred. We then dropped a bomb every time that number was less than five (we tuned this small number to get a good rate of bomb drops). This meant that the enemy dropped a bomb at random intervals, to make it impossible for the player to anticipate.


The files for this week can be found on our GitHub repository.

Intermediate Scratch – Challenge 15 – Create a Rock-Paper-Scissors Game for 1 or 2 Players!

CDA-S2-Challenge15-RockPaperScissorsThis week’s challenge is to create a game of Rock-Paper-Scissors.

This week, you can choose to either create a 2-player networked game with a friend, or if you don’t feel like doing networking, you can write a 1-player version where you play against the computer. It’s up to you!

This challenge makes use of the networking ideas that we have covered in recent weeks, when writing a network Chat program and when writing 2-player Pong.

The big ideas behind today’s challenge are:

  1. How to design a 1-player or 2-player program
  2. Using variables  for exchange of data between computers and to pick random numbers
  3. Using broadcasts to sync parts of the game

Here are the presentation slides from the day, in PDF format: CDA-S2-Challenge15-RockPaperScissors.pdf

Next time, we will help ninjas to work on their own games.

If you would like me to send you these slides in PowerPoint format, feel free to get in touch on Twitter or via the comments!

Scratch Advanced – Week 16 – Stop Motion Animation

We are going to revisit one of the topics we did earlier in the year. Do you remember The Movies, where we had the spinning wheel looking like it was going backwards?

Well we are going to do something similar over the next couple of weeks, where we will investigate and use Stop Motion, this is the same movie making technique that the Wallace and Grommet Movies are made with.

So what are we going to learn, well, we are going ot use a lot of techniques we have used before, so it is more a case of what are we going to re-learn.

  • Broadcasts – to make our code smaller and neater
  • Variables to simplify the code, specifically local variables.
  • Speech Bubbles.
  • Program Flow, there are a lot of things that need to happen and we need them to happen in the right order.

We are going to animate The Three Little Pigs and the Big Bad Wolf.

As you know this is a little story and in stories, things happen one after the other, so that is what we need our code to do as well, there is not much point having everything running from a Green Flag, we need some way to control the flow of the Program.

First we are going to need some Sprites though.

  1. A Wolf
  2. Pig One
  3. Pig Two
  4. Pig Three
  5. Straw House
  6. Wood House
  7. Brick House

As you know my drawing skills are excellent, so I have come up with the following:


Nice aren’t they. I’m sure you can do better.

When the Story starts there is only the Wolf, One Pig and the Straw house visible, so all the others need some code under a Green Flag to get them ready, backstage, ready for when it is their turn in the story.

The Wood House for example has just a HIDE under the Green Flag, you will need to determine what each Sprite will need under a Green Flag control. Basically anything to get it ready for the story.

On to the Stop Motion Animation.

Stop Motion is where something is moved a small bit and then a picture taken and then moved another small bit and another picture taken, until the figure has moved to where it needs to be.

We are going to do something similar, where we will set up the x and y position of the Sprite in local variables and then get another piece of code to do the actual moving, this helps to make the code a little easier to read as it splits it into smaller sections.

Here is the code for example that one of Pigs uses to move to the next House


You can see how I have split it into smaller pieces and that I have used local Variables to set the x and y positions.

You will need to figure out where on the screen you want the Sprites to go and how fast you want them to go there, that will determine the numbers that you need to use when you are SETting the xPosition and yPosition variables.

As the Wolf is kind of the main Character in the Story, we control everything from his Sprite. We do one thing after another and if we need to wait for something else to happen we use a Broadcast and Wait, this will control how the code flows from the top to the Bottom.

Here is all the code for the Wolf Sprite


Now, my code is very scrappy, there are a number of BUGs that need to be sorted out, for example when Pig One moves to the Wood House and the Wolf comes over, the Speech Bubble covers the Pig, this should be changed really.

At the end of the day, you can make your Story as simple or as complex as you like, one thing that I can tell you though, is that the more time you spend on the project the better it will end up.

You can also do real Stop Motion with a Camera and Lego, you can then import the different pictures into Scratch as either Stages or Sprites.

I did one as Stages which is up on the Scratch Web Site and here is one of the Stages from it.