In the
last post we were left with a cliffhanger. We had used a series of given scripts to take our sprite for a walk and used imported, downloaded or self created backgrounds to provide a context or place for this to take place. Some of the students had also experimented within scenes, changing sprites or adding additional characters and objects. The questions being raised as we worked reflected how the students wanted something different to happen when their sprites met, we weren't quite sure what but we knew that when characters and objects meet or "touch in a "real" computer game something usually happens.
This week we began again with an empty stage, and a session outcome to develop or create a small scale project where one object (or Sprite) within the environment would be programmed to interact with others. Building on student queries, I thought it would be a nice idea to build a simple game. I decided to borrow from a Phase 3 task and to build a version of the arcade game "breakout," but that I would limit the outcome to using only the paddle and ball sections of the game building a "keepy uppy game." Keeping the idea as simple as possible I hoped would allow me to build on student excitement from the previous session, and allow discussion of events and outcomes as procedures were added to the game.
With the world cup coming up there may be some interest in this fairly straight forward set of scripts, and the editing and extension possibilities they afford for adaptation of the initial idea. Theming the game from its origins into something soccer like, using existing scripts as the basis, and including a spoonful or two of creative playfulness by the students could make for some wonderful ideas. This however is an extension idea to come back to at the end of this post. Needless to say the game of "keepy uppy" is one of those things we probably use as teachers a lot in skills practice during PE, or have played as children ourselves in the garden, with a tennis racket and ball or a football. What I think students will enjoy about this as a creative starting point is that essentially it uses two sprites and a background. Both sprites are fairly simple in their purpose, while changes and careful choice of background gives us a visual backstory or context for our game.
To introduce the session I began at the end... modelling through a prepared design what we would be looking for if we were successful in making our game. The students were asked if their game needed to look like this in order for it to be a successful design? There are many games that work in similar ways but that look very different. What could we change before we begin creating and building the code?
The stage I used contained a star field, a rectangular space ship for a bat and an asteroidish type ball. Pressing the green flag set the asteroid in motion, while moving the mouse dragged the bat back and forth across the bottom of the stage (the x axis of movement). When the asteroid hit the bat it bounced off until it hit the upper sides or top edge of the stage when it bounced and changed direction. If we missed the asteroid and it made contact with the bottom of the screen then the game stopped running and was over. This process was described to the students in pretty much this way as the model was demonstrated. Why? As well as following instructions I want the students to be able to see and begin evaluating step by step what was intended to happen as the program runs. Describing the intended actions in this way, I hoped would encourage the students to begin reasoning aloud and visualising what the code blocks they would later be building were intended to do. In turn helping us to focus on particular blocks and what might be happening if the project did not work as expected.
The students were asked where else the game could take place?
- In a cave
- in the snow
- on the moon
- outer space
- under the sea
- in the kitchen
- In the classroom
were among suggestions made.
What might be falling/moving or flying in these spaces?
- fish
- meteorites
- planets
- bowls or cups
- food
- snowballs
What might be used to hit, catch, bounce or keep up these objects
- pans
- polar bears
- spaceships
- hands
The students had some really interesting ideas, many possible "right" answers, but to begin the activity, and inorder to ensure our code blocks did as intended I added the initial design stage proviso, that the part of the bat that meets the ball must be flat. The reason for this being that during the opening part of the software based activity I wanted the students to edit and alter the sprites that they chose to use.
The students began with their stage and the game background,
- either importing a background from collection that matched the idea they had
- searching for a background on the web they could download, import and use to set the scene for the game.
- or creating a background of their own
To the lower edge of the background a coloured line was added from one side to the other. The reason for which will become clear later.
The students then deleted the default sprite to create their "ball." This was imported from the collection and edited to work with and be in keeping with their background and so the game's backstory
Finally the students created or added a new sprite that would be their bat. This was
- either a sprite from collection edited to include a flat surface
- or a new sprite painted from scratch and designed to fit with the backstory.
With the background added and sprites created we were ready to code our game. The students were provided with support sheets, to guide them through the addition of code blocks to control the ball and bat sprites. We began with the bat or paddle. This object needed simply to be able to move across the screen from left to right, following the motion of the mouse. This was achieved by clicking on our bat/paddle sprite, then the script tab and dragging the following code blocks into the space.
The students were then encouraged to test the procedure, clicking the green flag header block, and observing the onscreen effect, and sharing their ideas about what was happening with each other.
With the bat/paddle/ working correctly we moved on to add scripts to the "ball" sprite, using the following script blocks.
I have included comments in this image, the yellow caption blocks, to demonstrate a feature of Scratch shown to me by one of the students this week. I didn't realise this function was available, but right clicking in the script area reveals a context menu, from which a comment block can be added, and descriptions of a code block or procedure and its function added. Dragging the comment to a particular section of the code visually links it. Thanks to J, this tool has now been added to my session plans for phase 3 next week, when students will be asked to create screen shots of their game projects and to annotate them to support our APP process. Loving this...never too old to learn something new.
The challenge in creating these procedures lies in the fact that some code blocks, require combining blocks from different areas eg using a control block with a sensing block, to create the forever if touching shuttle command, or combining a motion block with an operator to construct the point in direction or turn clockwise something degrees command.
The students were really excited about the outcomes, and enjoyed playing each other's games and adding the score variable made a real difference to the feel of what they had created.
The possible extension I mentioned earlier relates to the Soccer World Cup coming up in South Africa. It could be fun with the scripting now done to import photographs of players to scratch and then edit these to include as the "bat" sprite. How many times can "Rooney" keep up the ball. Perhaps the head only of the character could be added to a painted sprite with feet and head, allowing use of both to be used in the game? What might a keepy up game look like if it were an animal or intergalactic cup? What might be used for a ball? What if our favourite players were practicing in the kitchen or our school classroom before a match? What might they use to play keepy uppy with.
Hope this is useful. Have fun. If you use this with your students or any other creative ideas inspire you around this post please share these through comments. Thank you for reading.
