Scratch

In some scrollers people only use two sprites for the scrolling... Archknight's Adventure is a good example. Anyway, here's something by archmage.

archmage wrote:

For a demonstration of this method go to http://scratch.mit.edu/projects/archmage/82995

You should already be comfortable using the first scrolling method as this method is more difficult

You will need to create 3 different variables for this method

  <{  scrollX  }>    //This variables keeps track of how far the user has scrolled

  <{ terrainNum  }>  //This is used to let the terrain sprite know what terrain should be displayed
 
<{  xVelocity  }>  //For some reason I was unable to get linear movement to make the terrain sprite not flicker with this method. However when the scrolling variable is changed according to the xVelocity variable the scrolling works as it should and does not flicker.

*Place these scripts on the stage*

<when green flag clicked>
<forever>
<if>  <( (( <round( <{ scrollX }>  </> 480 )) <>> (( <{ scrollX }>  </> 480 )) )>
<set{ terrainNum }to( (( <round(  (( <{ scrollX }>  </> -480 )) <+> 1 ))
<else>
<set{ terrainNum }to( <round(  (( <{ scrollX }>  </> -480 ))

What this script does is it divides the scroll variable by the stage's width and then rounds it down to the nearest whole number.

<when green flag clicked>
<forever>
<if> <key[ right arrow ]pressed?>
<change{ xVelocity }by( -2
<end>
<if> <key[ left arrow ]pressed?>
<change{ xVelocity }by( 2
<end>
<set{ xVelocity }to(  (( <{ xVelocity }> <*> 0.9  ))
<change{ scrollX }by( <{ xVelocity }>
<end>

This is a basic movement code that uses the xVelocity variable to change the scrollX variable.


Now before we begin programming on the terrain sprites it is very important to remember that BOTH of the two terrain sprites must have exactly the same costumes in exactly the same order. Now doing this will result in weird changing of the terrain sprites to incorrect costumes.

Make sure you have created 2 terrain sprites called "terrain1" and "terrain2".

Now put this code on terrain1.

<when green flag clicked>
<forever>
<switch to costume[ <{ terrainNum }>
<set x to( (( <{ scrollX  }> <+>  (( 480 <*> (( <{ terrainNum }> <-> 1 )) ))))
<end>

What this script does is it sets it's costume according to the terrainNum variable and then it sets it's x position to scrollX+(480*(terrainNum-1)). When the terrainNum variable changes it makes the terrain scripts change costumes accordingly and move to the proper position.

Now put this code on terrain2.

<when green flag clicked>
<forever>
<switch to costume[ (( <{ terrainNum }> <+> 1 ))
<set x to( (( <{ scrollX  }> <+>  (( 480 <*> <{ terrainNum }> ))))
<end>

This script is similar to the script on the first terrain sprite but it has been altered to appear in front of the terrain1 sprite.

archmage wrote:

If you want to see examples of projects that feature scrolling go to this gallery.
http://scratch.mit.edu/galleries/view/8494

Last edited by Jonathanpb (2010-01-18 06:20:34)

try this....
http://scratch.mit.edu/projects/Locomule/707613

details...
press the "4" button to change the background images to see the scrolling better
it uses 4 sprites
uses the arrow keys to control direction
auto-scrolls but you can adjust direction and scroll speed with keys "1" and "0"
features a central sprite as well as a sprite that scrolls around and off the stage

You can see in my project notes my plans to use this to link together maps into a really big map. I based this on Archmage's stuff.
  I have other uploaded scrollers that include a random dungeon generator, an Astroids type scroller, a race car with a track that scrolls and is 4 screens large, and a Dragon game scroller that is still in early development. I plan to keep its background simple, but to create a 'world' of objects by reusing sprites to draw world objects as they scroll across the stage (trees, houses, wagons, etc.)

Btw, the problem with linking really big maps is not the scrolling, it is the file size of the combined map images and consequently being able to upload your game to Scratch. What is the size limit, like 9 megs? I squeeze my graphics down to nothing by reducing them to as few colors as possible but even then, say to do a RPG type game, between sprites, items, effects/animations, gui components, etc etc you eat up your total file size 'real estate' really quickly.  My random dungeon generator is an interesting solution because as is, you could have a simple hack and slash that went on till you got sick of it. Add saving via Save Codes, replace the simple walled random dungeon with a map that could be drawn via a hand full of repeated dungeon floor/wall maps tiled together from Listed codes... then you have a dungeon that is NOT random but could still be made huge, freeing up as much memory as possible for sprite animations, game objects, etc. But I digress, sorry