Materials by Teachers in English - Primary
Planets (Nyssa Edlin)
Why I created a branching story
Having never worked with Scratch 1.4 nor indeed anything to do with computing, producing an interactive teaching tool seemed quite daunting. I decided to make an interactive presentation based on the great fire of London where pupils would type in responses covering the sequencing of events and the materials (and their flammable nature) from which the houses were made. It took hours of work to create a very short introduction where pupils typed in their responses.
After completing a 6 week placement in school I soon realised that what I had planned to cover was a whole terms worth of work and far too big a project. Moreover, pupils in year 1 are not secure in their typing skills, thus a drag and drop approach would be much more effective. Inspired by all the work the children in my class did on the topic of space and the solar system I decided to do a branching game which teachers could use during input or plenary to gain or consolidate knowledge covering the following areas:
- The names of the planets and their correct order.
- The types of planets: rock or gas.
An algorithm is simply a set of instructions. Applied to Scratch it is the assembling of the appropriate commands in the correct order to achieve your objective (small objective at a time!) Scratch is accessible to children and adults without computing experience alike because it groups this coding together for us in manageable, drag and drop blocks. It separates those instructions into the sub headings of motion, look, sound, pen, control, sensing, operating and variables. You don’t necessarily have to understand what they mean to get to know how to use them. I have done this through copying coding from similar examples and trial and error.
Generalisation (Re-using coding elsewhere)
Is what it implies, applying a general rule elsewhere.
- Both games have the same coding for the planet sprites and backgrounds so that it scores and celebrates, or scores and moves incorrect planets accordingly.
- I used ‘instructional sprites’ for the initial branching and then to instruct the user in both games as to which key to press to check their answers. The two used in the initial branching screen have the exact same coding.
- All ‘planet sprites’ have the same coding for the scoring system, I simply dragged and dropped and adjusted the variable accordingly.
Abstraction (ldea of hiding complexity and looking at a problem at the appropriate level of detail)
Abstraction is to hide the complexity of the problems that your intended project creates and to look at the bigger picture. Just as you would identify the key words in an exam question, when tackling a Scratch project you should formulate what your main intentions are and identify the key problems. In my case the biggest challenge was to solve (debug) the issue of how to code the game and it’s scoring. The introduction to both games, and the branching screen from which those introductions could be accessed, where secondary issues.
My original intention was to be able to use it on the interactive whiteboard where a child could drag and drop the sprite where it needed to be. A colleague had used coding like this where the system would know if the planet had been dropped in the right place by matching it to a given colour. It very quickly transpired that this did not work in full screen mode so I was forced to use a different method. To resolve this issue I copied coding that required the need to point the mouse to a given destination and press and hold down a given key on the keyboard. I could then use the colour recognition coding to score the game.
Abstraction at this initial stage was to create coding that would work, I used rudimentary backgrounds and shapes for sprites until the coding was developed and built everything else up from there. Below you will find a list of some of the problems I encountered and how I eventually resolved them. Debugging can take from 1 minute to days of exasperating trial and error, and the solution always seems obvious once you’ve found it!
Debug (Solving ‘how to’ issues)
- Keep planets from rotating: click on the sprite. Above the ‘script’ tab there is a miniature version of your sprite, move it around so that it is aligned how you would like it and press the – symbol (third one down) to save it.
- How do I code it so that a sprite can be dragged and dropped to a given destination? My aim was to be able to drag and drop the planets into the right place however this does not work in full screen. As an alternative to this I copied some coding which allowed the user to point the mouse to its destination and move it using a specified letter (in this case the first letter of the planet apart from Mars). Using the sensing and setting scores to 1 for variables, I was able to program it so that it would be recognised if the planet sprite was in the correct position. Using the same system but setting the score to 0, I was able to program it so that if the planet was in the wrong position it would move back to its starting position. This is not as user friendly as I wished it to be however with teacher support it is still accessible.
- How do I instruct the user to press ‘space’ to see if they got the answers right? The only way I could do it was to make a written sprite which I hid until the required background came up. I sued the same process to instruct the user to press the ‘up arrow’ to see if they got the answers right in the planet sorting game.
- Why are both branches playing simultaneously? After making the menu stage with the sprite and all of its instructions I couldn’t figure out why the sprite for the sorting game intro would not receive the instructions. For some reason it only worked if I clicked on and held down ‘When I receive Intro’. SOLUTION I had another stage with the same set of instructions so they were over riding each other and neither were playing. By deleting the instructions in the stage I didn’t need it resolved the problem
- Why are both branches playing simultaneously? When writing the script for the astronaut sprite for the second game on the sort planets stage it seemed to play both instructions for both games at the same time. SOLUTION: After approx. 10 hours of trying different instructions including creating a separate Sprite the solution was to use the Orange ‘When left arrow key pressed’, ‘When right arrow key pressed’. Then the coding as you see it. This seems obvious now that I have found the solution however it took me a long time to recognise that the branching options needed to start as two separate streams rather than coming at the end of the ‘Green flag’ instructions. (I had used the orange ‘if’ instruction inserted the blue sensing ‘left/right arrow pressed’ and then ‘broadcast’ either the intro or sort. This resulted in them both playing at the same time if you clicked right but not left strangely).
- How do I give a sprite an instruction to switch to a background? I duplicated the instructional sprite from the ‘Ordering planets game’ for the ‘Sorting planets game’ and changed the text. From here it wouldn’t allow me to change the background to anything but costume 1. I solved this by dragging and dropping the coding from the relevant stage background into the sprite script.
- How do I create a ‘play again’ button? A colleague was able to help me with this as she had already done this. I copied the coding. Please see pink and yellow arrow sprites for specifics.
- Why isn’t my sprite receiving and acting upon a broadcast? : I spent 8 hours trying to debug this problem and have given up.
Acting on advice I focused first on the game rather than the introduction, instructions and presentation. I solved problems in this order:
- Drag planet sprites into position and recognise to be correct by the colour on which it is placed
- Recognise when an answer is correct
- Keep score
- Move the planets that are incorrect
- Add the celebration sprite with timed speech
- Add an introductory scene with new stage and sprite with its own instructions
- Create a branching Menu stage with its own sprite and instructions
- Change all the prompts so that the menu stage is the first one that appears
- Make the branching option of choosing out of two games
- Change the prompts so that the menu flows into introduction of the planet ordering game
- Ensure the game flows from the introduction
- Tidy up all sprites and backgrounds so that they are aesthetically pleasing
- Create second branches introductory screen with correct timings
- Create second game
- Instruct the celebration sprite for the second game-realised I had programmed it for it to celebrate if any 1 of the 8 planets were correctly placed!
- Link it to its introductory screen
- Create instructional sprites
- Tidy up timings and aesthetics
- Add ‘play again’ sprites and broadcast planets to move back to original position
- Debug 2nd celebration sprite for ‘sort game’ (did not achieve at time of writing)
Scratch is infuriating, addictive and rewarding all at once and I strongly feel that it is a viable way to introduce children to computer programming. Its colour coding is attractive to visual learners and teachers can take a cross curricular approach to a Scratch project. Algorithms in the context of computing for example could be taught as an extension of instructional writing already in the literacy national curriculum. Also within literacy a child could write and script their Scratch story, in drama children could record voice over’s, in music instrumental loops can be recorded, in modern foreign languages scripts could be translated and recorded, not to mention maths.
The coding produced in this project is not what we could expect of KS1 children at this early stage in the dawn of computing in schools, however it is something that could certainly be aimed for and indeed exceeded by KS2 children. I have found that co-ordinating so many back grounds and sprites, all with corresponding instructions takes a high level of concentration and thinking skills, a skill that needs to be nurtured in our children in today’s throwaway culture.
By teaching computing, its concepts and vocabulary from an early age we will be creating young adults able to access the fast developing technological world with confidence. The concepts themselves, when explained simply will not be too difficult to grasp for a child. As for the vocabulary, today’s 6 years olds know what a split-digraph is, why couldn’t they learn the words abstraction, generalisation, decomposition and debug. Just as in maths children learn the vocabulary through continued modelling, why not in computing?
I came to this project as a complete beginner and by taking coding from other examples, trial and error and sharing information with colleagues I have produced an interactive resource of which I am proud. If I can do it, other teachers can and by working collaboratively with children without pretence of superior knowledge we can certainly take this forward. As mentioned above Scratch is addictive, and time consuming so Scratch after school clubs would be the perfect forum for progress and development.
Notes from the Course Tutor
These files are for use in the classroom. They can, of course, be adapted by teachers, with further resources, such as Sprites or Backgrounds, added by pupils.
I have included all the work of my teaching group here. There are many wonderful teaching ideas, and if we did not solve every coding problem effectively (none of us is an expert in Computing, including me!), the creativity of these young teachers more than makes up for it.
The teaching programme covered 30 hours of work at the computer, so if you start with one session of 60 minutes per week, you will become as proficient as they have been well before the end of your teaching year!
The key to success is to work with a partner, share ideas, and problem-solve together.