Pages

Showing posts with label scratch. Show all posts
Showing posts with label scratch. Show all posts

6.4.13

Educaplay: Flash and HTML 5 Interactivity creation.

Have you tried Educaplay?  This is a fantastic site where you can create interactive content for use on  your VLE.Blogs and Web Sites for free, simply register, create and share..

Below is an example of what they call an interactive map.  I will be beginning work with Scratch this term with my phase three students  I want them to become familiar with the Interface and where to find unfamiliar items.  This map based quiz will hopefully help consilidate their understanding of where to find things in the program.




We will also need to become familiar with keywords and vocabulary.  So how about a Wordsearch as a starter, before moving on to define and use these terms in learning diaries and such.



Other great tasks available include "word jumbles," "sentence jumbles," "matching" and "crossword" interactivities.

These can be saved in your account space and then embed codes generated for the tasks copied and pasted into html view in you pages or tasks that can be shared with students either in the VLE or through provision of shared shortcuts to specific pages online you have created.

Oh and did I mention that the site is free!

Enjoy..... :o)

23.7.11

Digital Music Boxes: Random Music Or Simple Synthesizers Using Scratch

Last term we worked with our phase three students to Design and Make computer games using Scratch.  One of the Focussed Practical tasks I used emerged from a music session I taught with some of our younger students exploring pitch and composing musical phrases using the pentatonic scale. 

I knew that Scratch could be used to create music, and had used the pentatonic scale during impovisation and composition activities with students in my primary classes to great effect.  I wondered how it would pan out if I involved my Phase 3 students in programming a simple random music generator.

To begin two sprites were created.
  • A Musical Note: that was programmed to bounce around the screen randomlyish!
  • The second a musician sprite programmed as above but also to play a single musical note from the chosen scale, when it touched the note.

The Musical Note.
This was created using the paint a new sprite tool, and in my case looked like this.

Behind the musical note sprite I added the following pair of scripts.








When we set up the task the "when green flag is clicked" header block was was added from the control block to both scripts.  However before running the program the header block from one of the scripts was removed.

The first script, Script one in the image, allows some user control, with the musical note following the mouse pointer, in effect allowing the user to play notes in the order they choose.  A simple musical instrument or synthesiser.

The second script in the image. Script two has a very different effect setting the note moving under its own steam, when the gren flag is clicked, playing any note it comes into contact with in the order it meets it...  But not quite yet, as we don't have any musician sprites.


Musician Sprites
The first musician sprite and its scripts were created by choosing a character through the "insert sprite from file" option. and then adding the following script.  The musical elements of this coming in the form of elements from the "sound" blocks.


Completing My Digital Musical Box
So far I have one musical note and one musician.  I need 5 musicians and each need to be tuned to play one note from the pentatonic scale.  To achieve this I created 4 duplicates of my first musician sprite, by right clicking and selecting duplicate from the menu.

Next I changed the Sound script elements of each sprite.  I kept the instrument and duration or beat the same in each case but changed the note value, and renamed the sprite accordingly so

Musician Sprite 1 was renamed playc        Plays note number 60
Musician Sprite 2 was renamed playd        Plays note number 62
Musician Sprite 3 was renamed playe        Plays note number 64

Musician Sprite 4 was renamed playg        Plays note number 67
Musician Sprite 5 was renamed playa        Plays note number 69

Each Musician Sprite was also given a change of costume to uniquely identify them onscreen

Now on pressing the green flag each of the musician sprites begin moving randomlyish around the screen, as does the musical note.  Each time a musician meets the note it contributes its sound to the tune.

I have to say at this point each individual student loved this a lot more than those around them.  With the programming in place, I found now that the learning began through play and creativity.  The students extended this task for themselves, experimenting and asking what would happen if they
  • added more musical notes?
  • changed the speed of the sprites?
  • Altered the instruments being played?
What I like about this activity is that from very simple programing we have two possible outcomes.
  1. The random music generator
  2. A very simple synthesiser
The random music generator, digital windchime or music box, allowed the students space to experiment and explore the effects of editing scripts on output.  The Synthesiser option provided a possible extension opportunity, where using static musician sprites and mouse control they could create a simple game or activity to help younger students create music, with additional outcomes being possible use of graphical scoring.  I intend to use this activity again myself perhaps as part of our moving on moving up week with new intake students, or in involving our students in preparing sessions to work with younger students on the campus.  I would be interested to hear from anyone who tries out this task with students and what they made of it too. :o)

23.5.10

Making and Playing Computer Games With Scratch: Episode 2 A keepy Uppy Paddle and Ball Game

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.

      22.5.10

      Making and playing Computer Games With Scratch: Embedding Games to Share

      This post is jumping ahead slightly, since most of my students are still involved in the design and make stages of the process, however one or two have begun to ask, how they can share their games when finished.

      After a search around I came across this solution in the Scratch Forums, and as I talk my way through the process for myself I hope that the content here will be useful for others.  One of my main reasons for looking into this was the evaluation process, within AF1 of phase 3 units of work, and wanting to make available outcomes created by students for peer assessment and review.  The obvious thing to do was to place finished games on the VLE or to encourage students to upload content to a wiki, and use commenting as a way of feeding back.

      The VLE with the above solution has been a no go, even with absolute link locations copied and pasted to seperately uploaded html pages, the VLE (Fronter) seems unable to deliver the content. Perhaps this ia an issue with the way files are stored or access rights managed within the platform, either way the html pages will open, but the same error message appears afterward, about being unable to locate the file, regardless of attempts to redirect file locations and so on.  I'm sure someone will be able to help, and I would be grateful for any comments that lead me toward resolving this.  I guess I also need to contact my colleagues at Fronter, to get their take on this, and to discuss this with our Primary VLE colleagues at ITs Learning, when we meet this week.

      SO! to the work around!

      For the time being I have opted instead to create a web folder on our web server, to add the game files and applets to this space and then to use hyperlinks from within the VLE or from the school website to enable access to and sharing of these outcomes of learning.  So how did this work?

      First of all on my local machine/school laptop I created a folder called "scratch_games" and into this have copied completed student game (scratch) files.  These have been renamed to exclude capital lettersextraneous characters - the students for some reason insist on adding - and spaces.  They have been reduced to a common format eg si_pacman.sb

      • where si is the student's name
      • pacman is the game
      • .sb is the scratch file extension.
      Into this folder I have also placed one copy of each of the java applets downloaded from the site above

      • ScratchApplet.jar
      • soundbank.gm
      For each game a separate html file has also been created, also using the naming convention above but saved with a file extension .htm eg si_packman.htm

      The html files were created using this file template using code copied from the above site to a notepad document, that was then edited as follows.


      Using save as, selecting all files from the file type drop down, these were then saved in the file convention outlined above eg si_gamename.htm

      A home page or index file is the next step, created within the Pacman Project folder with individual hyperlinks to each game.  Though I will probably play with this idea a little if the embed code works here so that each game is accessible within a single project page.

      The "Pacman" folder containing all scratch files, java applets and html files were then uploaded to the school's web server clicking the following hyperlinks will allow you to see examples of how the games currently appear in individual html files.  Clcikcing the green flag will start the games, and use of the arrow keys will allow the games to be played.

      Unfortunately, for the time being at least, I am unable to embed the applet to run directly in my blog, but this is my next challenge.  I am sure there is tweak out there somewhere, something I am missing, and am hopeful that either another "blogger" user can help and leap to my rescue with this particular platform, or that some of my other more experienced visitors can help overcome the wider issue.  I hope this makes sense is useful.  I look forward to any comments, and thoughts from visitors.  Thank you in advance. :o)

      An Additional line of thought from a colleague

      After Posting at the weekend, I was contacted through comments about an additional means I could try to run the student's scratch games.  The above process still applies and is required for this idea and tool to work.  Having created the folder, added the scratch files themselves and created an html page for each file using the code above, these are then uploaded to the host web space as outlined above. Next an iframe within the new page.  Here is the code that I used in blogger...


      The file linked to above should be saved as is, and maintained as a text file, however changing the url and then saving the file makes it a template to be copied and pasted with minor editing needed to point the frame at what you want inside it.  Eg in the case of my iframe above the individual student games and so, all I needed to edit after copying and pasting was the html file name, in blue above.

      As of yet I have not tried this out in the VLE, but this is something to move onto next. Have a play and see how you get on.

      Scratch Embed Trial

      This is a trial space as I explore embedding some of my student's Scratch Games into web spaces for sharing.  Currently the scratch Applet is running fine within individual pages created for each game and placed on the school web server  These can be accessed via the hyperlinks if you'd like a look.


      The Applet itself is opening in my blog using the same embed code, but can't currently access the game files to run them.  Pondering whether this might be a firewall issue as files hosted on LA web Space!?  Any thoughts?






      Thanks in advance! :0)

      Building on comments from Sam R I have added an iframe linked to J's Frog Eating Thing.  This seems to have done the trick on Blogger as you can see below. The iframe links back to the holding page uploaded to the school web server, perhaps this is the solution to my other problems, will check this out, and update blog later with process.  Thanks to Sam R for all your help with this :o)

      28.4.10

      Making and Playing Computer Games With Scratch Episode 1

      A while back I found myself downloading and playing with scratch, considering it as a possible tool to complement work I was already doing with Phase 2 students around Shape and Space and LOGO.  With a move to work with Phase 3 students I have been "encouraged" into the slightly steeper learning curve of using Scratch as a programming platform in its wider sense, resulting this term in a series of sessions exploring arcade games and working with students to use the tool as a basis for designing, making and evaluating one or two of our own.  I have decided however, as an offshoot of this and to support my personal professional learning to use some of the materials from Phase 3 sessions with my phase 2 ICT club as well, and to see how they got on.  Our first session worked really well, and I was impressed at how creative some of the younger students were with the basic scripts in hand.

      The first Session involved students familiarising themselves with the layout of the tool's interface.  Following given instructions and scripts to bring about increasingly complex animation effects. Within the session students used the default "sprite" initially and blocks from the control, motion and looks scripts areas only to bring about 3 different types of animation.
      • Activity one bringing about movement as a flip in position using an on mouse click event.
      • Activity two bringing about continuous movement of the sprite from one side of the stage to another, with an image swap to add interest to the sprite's actions and a change of direction when it reached the edge of the screen.
      • Activity 3 using four separate scripts, that on click or use of a keystroke would allow user control of the sprite to move it around the stage using the up, down, left and right keys on the keyboard.
       Within the session the following scripts were were provided for students to use.

      Activity 1
      As the students worked with the above script they discovered that the sprite didn't simply flip, but rather rotated as it changed direction.  The students were encouraged therefore to explore what would happen if... they changed the settings of the motion buttons highlighted in the image above.  Could they
      • make the sprite mirror as it turned
      • stand on its head 
      • step forward and back?

      Activity 2

      Running this script, the sprite walks back and forward across the stage when the green flag is clicked, its moevement repeated because of the forever loop until the red stop button is pressed.  Again in running this script students were asked to explore the effects of changing the position of the motion buttons, but in addition to explore what would happen if we altered some of the variables in the motion blocks.
      • Could we slow down the sprite?  
      • Could we speed it up?  
      • Could we make the sprite's speed vary so during some parts of the routine the sprite seemed to be moving faster than at others?  
      • How did our changes effect the way he/she looked as they moved?  

      What would happen if...

      we changed the green flag header block for the

      "when [something] key pressed,"

      or "when sprite clicked"

      header blocks.



      Activity 3

      Here students were encouraged to recreate a script that would enable them to control the sprite using the arrow keys, so that for example when the right arrow key is pressed and held down the sprite walks towards the right side of the stage. This example with the addition of a cap block will bring about movement towards the bottom of the stage by the sprite when the down arrow key is pressed.


      Having completed one of the scripts the students were shown how to duplicate it and then how to edit the values according to given models values in the images below.  The addition of green flag caps to the procedures, meant that on clicking the green flag the program would run, allowing the students to control the sprite's movement across the stage in the up. down, left and right directions.  In effect they could take the sprite for a walk.

      These were then tested to ensure that they worked, and then further edited if need be to correct them.


      To engage the students in evaluating this Focussed Practical Task, they were asked...  If we were making a computer game of our own...
      How might this set of procedures be useful
      Where might we use them, and what might be happening in our game?
      Following discussion several familiar gaming type scenarios arose
      • Perhaps we might want to move our character around a room, perhaps colecting things.
      • Perhaps we might want to move our character around a maze.
      What seemed to excite the students most however was that they now had a working model that they could explore and play with, and this lead to our extension activity... 


      Extension


      Having copied the scripts and set a scene where the sprite could be moved with the keyboard the students now wanted to play with what they had done..
      • Could they change the sprite or character they were animating?
      • Could they set a scene for the character or sprites actions to happen in?
      With the model in place the students 
        • explored importing new sprites to replace the cat. 
        • investigating how they could get their new sprite to follow the instructions they created for the cat.
        • Adding an extra sprite and having it move using one of our earlier scripts at the same time as the original sprite.
        • Editing, recolouring and changing the sprites they had imported.
        • Importing image backgrounds from collection or from the web as well as creating background images  providing context to the action.
        The session created a great deal of excitement and raised towards the end an important question we need to address if we are to make a game of our own such as.. 
        • How do we get the characters to do things when they meet or bump into each other?  
        • How do we get sprites to interact with each other?..

        This seems right now a good place to stop.. As it was with the students... Leaving them with a cliff hanger and waning more next time, when I have promised them with this as the prerequisite scene setter, that during our next set of activities involving the use of "sensing blocks,"  we wil be creating a very simple game a "keepy uppy type" game.  This will involve creating a "paddle" and "bouncing ball" the first steps in creating our own versions of "breakout."  Hope you drop by for our next installment.

        23.3.08

        Scratch and

        I was desparate to call this post "Scratch and Sniff," as really that is all it is, a tip of the iceberg set of statements and a momentary expression of appreciation about a tool I have been pointed to a number of times through blog posts, feeds and del.icio.us. Until a recent post and a thumb's up on mrstucke's Masterplan I didn't realise just what I had missed out on by not actually installing the download I had made or looking further than the handful of videos on the tool I had watched. Installing the application, taking a spot of time to aclimatise and familiarise myself with the environment and its visual tool box, it has been really cool to watch kitty boogy his way through a set of routines I had previously scripted for my turtle in LOGO.


        Can feel a few posts of my own coming in the future. Thanks Daniel. Interested in having a play for yourself, you can download a copy of Scratch from here.