There are many reasons why Shaun the Sheep on Scratch is appealing to students and to teachers, but as an IT professional the thing that stands out to me is the use of design patterns (the structure of the code) that haven’t been widely evident in the Scratch teaching resources I’ve looked at. It appears to me that the structuring of code is less well covered in exam specifications than logical control processes, and if that’s true, then we are missing an opportunity to create elegant, efficient code.
So what’s so significant about the code structure in the Aardman Shaun projects?
| Shaun by Aardman | Typical Scratch Project |
|---|---|
| Shaun has an invisible sprite called ‘Game’, which has only two roles: to initialise the game, and to sequence events; the only ‘when green flag clicked’ appears in Game’s scripts. | Every sprite is initiated with a green flag, and actions are sequenced independently: this can cause unexpected interactions between sprites. |
| All movement and physics is applied to an invisible sprite called ‘Character’; all animation is held in separate sprites for standing, running and jumping; sensors are anchored to the invisible Character sprite. | Movement, sensing and costumes are managed within a single, complex script |
The structure applied by Aardman demonstrates features of a software design pattern that I’ve used coding PHP under the Zend Framework, the Model-View-Controller or MVC pattern. MVC separates data and rules (the ‘Model’), presentation (the ‘View’) and management of changes to these (the ‘Controller’).
- Model: The data consists of variables recording key information about the Character (touching left, touching right, touching foot, direction it’s facing, whether it’s moving/jumping/idle), as well as parameters such as the strength of a jump and of gravity; rules such as calculating the rate of ascent in a jump, what to do if the sensor touches the colour red, etc etc, are also part of the model.
- View: The presentation of Shaun is completely separate from the game mechanics, and is entirely dependent on the ‘state’ variable (idle/run/jump). With this pattern, it’s straightforward to modify the animation without worrying about damaging how the game works.
- Controller: The ‘Game’ sprite is used as the central controller that defines what happens, in which order, by broadcasting events – to which the code in each sprite responds. So, for example, it’s clear that collision detection will always happen before movement (setting a variable to indicate whether a sensor is touching something), then movement will be decided (for Character, then sensors), then the appropriate animation will be played (depending on which movement state the Character sprite is in).
Why does this matter? In short, control of complex logic, maintenance and enhancement. Let’s imagine adding a moving baddie into the game. Now, step by step, you can go through the controller events that might apply to the baddie’s interaction with Shaun, and create the logic needed to decide what happens if the baddie touches him. It’ll move with the moveLevelItems event, you’ll need to detect whether it’s touched any of the sensors and set an appropriate state variable with the collisionDetect event, you’ll need to decide how that modifies the character’s movement (via the Character sprite’s ‘when I receive moveCharacter’ block), and then decide what animation to play.
Those interactions aren’t necessarily straightforward, and might need new variables to implement, but you have a logical structure for applying them and managing the changes, and it’s very clear what each element is doing. In my view, such a modular approach to programming is essential and should at least be encouraged within a computing course. How fantastic to have Scratch, an easy-to-use resource that’ll help teach such theory in an accessible way.
Does secondary teaching cover design patterns such as this? Having read through various exam board specifications it doesn’t seem to be explicit. Perhaps you can correct me.
Whether or not it’s required, it’s a great mindset to get into when programming: separate program control, data, logic and presentation. I’ve used this mental approach on a variety of applications and it works well. So, for example, in Microsoft Excel, it’s difficult to apply the controller pattern because the calculations aren’t sequential in the way they are with a programming language, but my workbooks generally have separate sheets for data, parameters, calculations, inputs and outputs; whilst there can be a little blurring of roles because, for example, you sometimes need to do calculations on the data sheet to derive further columns, I still try to keep the 3 conceptual elements of data, calculations and presentation as separate as possible, and it certainly helps in managing the analysis. Whilst not true MVC, it at least attempts to replicate the benefits of this pattern.
In my view, every student coming out of a computing course should have been trained to abstract software design patterns such as these – we’ll end up with better programmers and better code.
For more information on adding new features into the pattern, see www.shaunsgameacademy.co.uk.