A simple game in Scratch

Scratch is a great tool for helping teach programming concepts in an easily understandable way. I’ve cause to give a small taster of Scratch to a group of children, and put together the following as a simple example of something to get started.

I’m working on the assumption that folks can sign up and reach the editor — our starting point is a new Project.

Screen Shot 2017-05-03 at 15.35.41

Scenario — a race!

The scenario is a running race between two characters, with the winner of the race getting bragging rights at the end. Two players make their character move each by pressing a different pair of keys for back and forward. The idea is to demonstrate that very quickly and easily a game with a competitive element can be made, and then built upon later.

Setting the scene

First thing we need is a fitting backdrop. Handily Scratch comes with a bunch of them already uploaded, including an athletics track. First, click the picture icon (the leftmost) under the New backdrop: caption.

Screen Shot 2017-05-03 at 15.37.02

You’ll see a dialog box appear with a wide variety of different backdrops to choose from. Drill down to the Sports category, select track and then OK.

Screen Shot 2017-05-03 at 15.37.47

You should now see the track as the background for the Project.

Screen Shot 2017-05-03 at 15.38.31

The track background comes with a start line but no finish line. Create one by clicking the paintbrush icon.

Screen Shot 2017-05-03 at 15.39.06

A blank canvas appears on the right.

Screen Shot 2017-05-03 at 15.39.33

Select the Line tool.

Screen Shot 2017-05-03 at 15.40.11

By default the line will be black, so select white from the colour picker at the bottom.

Screen Shot 2017-05-03 at 15.40.53

You’ll notice you can adjust the width of the line as well. Create a vertical line by holding down the shift key (to lock to vertical) dragging vertically on the canvas:

Screen Shot 2017-05-03 at 15.41.29

You may notice that the line has appeared on the Stage on the left hand side — you can drag it into roughly the right place for a finish line.

Screen Shot 2017-05-03 at 15.42.16

Setting up the contestants

We’ve already got our friendly cat as one contestant, so let’s find them an opponent. Click  the face icon to open up a palette of predefined sprites to choose from.

Screen Shot 2017-05-03 at 15.43.08

Now of course it’s a free choice what you wish to choose to race the cat. For tradition’s sake, I’ve selected the dog. Click OK once again to accept your choice.

Screen Shot 2017-05-03 at 15.43.47

You’ll now see the second sprite has been added to the Stage:

Screen Shot 2017-05-03 at 15.44.19

Position the contestants on the start line by simply using drag and drop.

Screen Shot 2017-05-03 at 15.44.57

Making the contestants run

I’ll show how we can make one of the sprites “run” in response to a keyboard control, the same logic applies to both, albeit with different keys. In Scratch, each sprite has an associated set of scripts that do things in particular circumstances. The scripts are formed of interlocking pieces which are dragged into place from a palette. The palette organises the script fragments into logical groupings depending on their type.

Screen Shot 2017-05-03 at 15.46.00

I’ve selected the dog to set up scripts for the dog sprite:

Screen Shot 2017-05-03 at 15.47.28

I’ve set up a utility script to restore the dog to its starting position — in Scratch, when a sprite has been moved, it stays in its new location until you move it back, or write some code to do so. My script puts together an Event (the green flag being clicked) with a Motion script to move to particular x and y coordinates. Handily, the x and y coordinates of the Motion script default to the current x and y coordinates, so assuming we haven’t moved the sprites around since we put them on the start line, we don’t need to change anything.

Screen Shot 2017-05-03 at 15.48.24

You can repeat this exact process for the cat as well, so that when the green flag is clicked, they both move back to their starting position.

To make the dog move to the right (i.e. towards the finish line), we create another Event and Motion script — this time a directional movement in response to a key press. I’m going to select w to move it right.

Screen Shot 2017-05-03 at 15.52.05

Now we need to create the rightward motion. We can do this easily by simply moving the sprite 10 pixels to the right. We do this using a Motion script.

Screen Shot 2017-05-03 at 15.51.06

Note that a positive value for the change in x is a movement to the right. We can now set up the leftward motion by simply selecting a leftward key (I’m using q) and a negative change, giving:

Screen Shot 2017-05-03 at 15.53.38

The dog now moves left and right! You can apply the same logic to the other sprite by selecting it from the Sprites panel and repeating the above with different keys.

Knowing who’s won

There’s a simple way of knowing who has reached the finish line first, and that’s to add some control logic to the rightward motion of each sprite to sense when it is in contact with the finishing line sprite we created earlier. For this we use a combination of a Control script and a Sensing script:

Screen Shot 2017-05-03 at 15.55.10

The if script provides a mechanism to test if the sprite has reached the line after a rightward move. The condition is provided by a touching Sensing script — we simply specify the name of the sprite we’re interested in touching. In this case, the white line is imaginatively titled “Sprite2”! Having detected the condition, we now need to make the sprite actually do something. We can accomplish this using a Looks script to simply make the sprite “say” something:

Screen Shot 2017-05-03 at 15.56.45

Which has the following effect:

Screen Shot 2017-05-03 at 15.57.56

So for the game in its simplest form, by creating matching logic for each sprite, we now have ourselves a workable competition. Try it and see who shouts first!

Making the loser answer back

In Scratch, we can make sprites communicate by broadcasting messages. On Events, we have broadcast scripts that emit a named message that can be received by other sprites. In this case, I’m going to broadcast a message when each contestant wins. To do so, I can create a new broadcast script, and specify a new message type (which is literally just a name), for example:

Screen Shot 2017-05-03 at 15.59.11


Screen Shot 2017-05-03 at 15.59.53

That then gives us a message we can broadcast. In the following case, the dogwin message will be broadcast as well as the dog celebrating:

Screen Shot 2017-05-03 at 16.00.24

Now having broadcast the message, it’s not much fun unless we have someone do something with it. We can use an Event script to respond to the message when broadcast. The following script when added to the cat’s scripts makes it express its disappointment when it realises the dog has won:

Screen Shot 2017-05-03 at 16.02.02

This means when the dog wins, the following now happens:

Screen Shot 2017-05-03 at 16.02.59

Again, by making sure both contestants emit a “winning” event, both can respond in kind if they lose!

Lots more can be done

Now of course the above is very basic and there are many gaps in the logic we could plug — for example stopping the competitors running once there’s a winner, having different pacing for sprites, obstacles etc. But as a guide to how quickly we can create a two player game in Scratch, with practice this little exercise can be accomplished in less than five minutes.

I hope this is useful, I’ve shared my basic version on Scratch for you to look at.

IoT reference architecture for the edge domain

During my talk at Thingmonk last week, I showed the snippet of an IoT reference architecture that I developed covering the edge gateway domain.

Since I’ve yet to find amongst the many published IoT reference architectures any that decompose the edge and because several people asked for a copy, I thought I’d share it here for people to reuse. It’s simple but hopefully useful, and provides a starting point for proper design of solutions that exploit the edge.

Architecture overview diagram


Explanation of capabilities

The reference architecture shown above describes the key set of technology and organisational capabilities required in the deployment of edge applications.


  • Physical security mitigates the risk of tampering when devices are deployed in the field.
  • Device platform security protects the software platform, application code and data from unauthorised access.
  • The Device provides the hardware platform for application code and logic deployed at the edge.
  • Analytics models describe deployed analytics logic consumed by analytics runtimes in the edge software platform.
  • A Local Area Network provides the mechanism for the device to communicate with locally deployed applications, sensors and actuators, e.g. Bluetooth Low Energy, Zigbee etc.
  • Local Monitoring and Management tools enable administration and break/fix by local technicians servicing the installed hardware and software.
  • A Remote Monitoring and Management agent on the device enables diagnostics, monitoring and control of edge devices from the centre. This would be the preferred mode of operation since it does not require physical access to the deployed system.
  • Sensors and Actuators provide the link between the assets themselves and the device.
  • Assets monitored and controlled by the edge installation — i.e. the “things”.
  • Local applications support business operations conducted in the field.
  • An Application Runtime provides the programming environment for application logic deployed at the edge, e.g. NodeRED.
  • Control code is application logic deployed in the Application Runtime to orchestrate interactions with sensors and centre.
  • Sensor SDKs (Software Development Kit) facilitate development of sensor-driven applications to run at the edge by providing developer-friendly programmatic access to the sensor hardware.
  • Back-end SDKs facilitate communication with the centre by providing developer-friendly programmatic access to services at the centre and/or provided by third-parties.
  • A Wide Area Network connects the device to the data centre, for example via a cellular network or via wifi to the corporate network.


  • Device and asset management is the central service management capability that deals with the ongoing monitoring and support for the hardware and software installation in the field.
  • Device installation and maintenance is the field-based service that installs and maintains the physical device, sensors and assets deployed in the field.

Brownfield IoT in manufacturing – new blog post

Following on from Thingmonk last week, I’ve just published a blog post on the IBM Watson IoT blog about one of the growing focus areas within the manufacturing industry.

Let me know what you think.

Thingmonk 2016

I had great fun at Thingmonk 2016 yesterday over in Shoreditch. Even better, I had the chance to present a talk, so if you’re interested, I’ve put it up on Slideshare.



Been a little while…but then not!

I realised the other day that it’s been a little while since I wrote here on this, my personal blog. Regular readers will remember my  last post was a personal one, about the sad demise of my running mojo. That story is long overdue an update, and I will write one (in case anyone’s interested how that ended up).

I haven’t, however, stopped putting my thoughts out there and whilst this blog has been relatively quiet recently, I’ve been quoted and writing elsewhere. It felt a bit grandiose creating a Press page, but I thought it’d be a good way of not losing what I’d been doing, and sharing for anyone who is interested.