Hello Fellow Scratchers: Paper Minecraft, Scratchnapped, Epic Ninja, Geometry Dash and
Appel – What have these all got in common, apart from being Scratch games by griffpatch?
Give up? Well, they are all Tile Based Scrolling Games. That is, games that have their levels
constructed from a regular grid of tiled sprites. Creating levels in this manor has been an
extremely common technique in video game creation for decades, and one that I myself have used
over and over again. With the aid of this video, we are going to
be building together the basis for such a game engine. What is exciting about this technique
is that, it not only can speed up your projects, but it makes challenges like having offscreen
enemies far easier to manage, as well as many otherwise tricky things like built in level
designers and level saving systems. You are of course absolutely free to create
all your own costumes for this project, but if you want a quick start, take a look in
the notes under this video for a link to a starter project. You’ll find it already
setup with a number of pre-configured sprite costumes from a familiar Mario game. Simply
remix it, and off we go:
So, if you remixed my starter project, you’ll have 3 sprites. The first named Mario contains
a simple Mario sprite which is hidden for the time being.
The middle sprite is called “Tiles”. If we look at its costumes you can see the first
two are interesting. One named “BIG”, containing a large square – the purpose
of this I will explain later. The second is a blank costume, useful for blank areas of
our level. All the rest of the sprites are cool level tiles, and if you look at their
size, they are all 16x16 pixels. If you do draw your own, then make sure to keep to this
size too. If we look closely at one of these costumes
you can see how it is precisely lined up with Scratch’s checkboard grid. It’s super
useful to know that the squares in this grid are exactly 4 by 4 pixels in size. So, if
our costume lines up with this then we are all good. Also, the costumes are perfectly
centred in the costume editor (A tip for checking this is to press Ctrl + A to select the costume,
and then drag it – it will snap back to the centre by itself showing that it’s already
in the right place). If you design your own costumes, just make sure they too are aligned
and sized just like this! Ok, let’s talk about creating our tile grid
– I’ll select the Block-Gold costume because it’s a nicely outlined shape. Now click
into the Coding tab. Notice how small out 16x16 sprite looks on
the stage, Let’s double its size. Add it when flag clicked hat block and under that
“set size to 200” block. For good measure add in a go to x y position to x: 0 y: 0.
Now run the project so our tile becomes 32x32 pixels instead of the old 16x16.
Pull out a “create clone of myself” block into some free space and attach to it to a
new “change y position by 32” block. Now this is cool, click the clone and move
block script and notice how a new clone of the tile is created, while our original sprite
skips up to perfectly sit above it. Smash that script a few more times with your mouse
and we can generate a very handsome looking column indeed!
Right! We can easily automate the process of cloning a whole column of tiles. Hit the
green flag button to reset our project, and then
Add a new repeat block around the create clone & change y position blocks. Set it to repeat
5 times and click the script to run it. Perfect, told you that would be easy.
But hold on a minute – were you expecting 6 tiles in our column? Afterall we asked for
5 didn’t we? Don’t worry this is not a bug, remember, when our project starts we
already have 1 tile on the stage, so after creating 5 more clones we do indeed expect
there to be 6 sprites in total. So let’s move on, we can improve our code
by replacing the number 5 with new variable. Create a new one now named “CLONE COUNT
Y”, leaving it set to “for all sprites”. Set it to 5 under the green flag and drag
the variable into the repeat loop replacing the number 5.
Now is a good time to click the green flag again to make sure that variable gets set
before we do any more testing! And click our repeat loop to ensure it draws our column
still. Now, wouldn’t it be nice to move this column a little further down the screen
perhaps so that it was cantered? We just introduce a “set y position to”
block from the motion category before our repeat loop and set it to “CLONE COUNT Y”
* -16. Why -16, well 16 is half a tile, and minus means backwards. Click the code to test
it – Good work! So, we have a column of tiles, how do we make
this into an awesome grid? Well, obviously we need to move a tile to the right to begin
the next column, so stick a change x by 32 at the end of our script. Now when we run
this script you’ll notice the extra sprite at the top has hoped to the right. So, click
the script again… and again… yep, mash away!! Looking really good.
To automate this start by creating a new variable named “CLONE COUNT X” and we’ll also
set it to 5. Bringing in a new repeat block around our cloning script and set to [CLONE
COUNT X]. Then before this add a “set x position to [CLONE COUNT X] * -16”.
Wow so cool – a repeat loop within a repeat! Let’s run this updated script and see what
happens. Click the green flag to reset our project, and then click the cloning scripts.
That’s real nice, do you agree? Hold on, have you noticed that we still have
one left over sprite up at the top right of our grid? Let’s just tidy that up by adding
a hide block to the bottom of our script, and of course a show block to the top to ensure
we still see the ones we want. Green flag, and run the scripts, that did it - Great!
We can make things look a little more interesting by switching costumes for each tile. Just
move the switch costume block down before the create clone block and drop in a “pick
random” from 3 to 19 (If we look in the costumes from this sprite you can see that
3 to 19 is our full tile set at the moment. Reset the project and run our scripts again
to see a different pattern of costumes appear each time.
Ok, it’s nice to see the clones appearing like this, but I’m ready for it to run quicker
- from the “my blocks” category, Make a Block and name it “setup”, ticking “run
without screen refresh”. Now drag all our cloning loop scripts under the new define
block, and then drag the new setup block itself to the bottom of the green flag script.
Simply run the project now and the grid of tiles should appear instantly. Love the power
of that “run without screen refresh” right? Now you’d be right if you were thinking
that this 5 by 5 grid is not very impressive – and if you’ve resisted the urge to stuff
in some larger values already, then you’ve been very well behaved – ha! But for now,
this smaller size will help us ensure we pick up on any problems with your tile engine as
we introduce more scripts. before we can move on, we have a small problem
to address – to be able to keep track of scrolling tiles, we are much better off switching
from using scratch’s built in sprite position x and y variables, and replacing them with
our own tile x & y variables. This is especially important as we begin to want to move sprites
off-screen. Create two new variables named “tile x”
& “tile y” and make sure to create them for “this sprite only.
Now I am going through the “setup” script replacing all references to position x & y
with my variable x & y (this includes any set or change blocks. Make sure do double
check your script after doing this with mine on the screen now as it’s easy to make a
mistake! Now because we are no longer setting the sprite’s
positions, our code is no longer going to work – try it and we find it’s completely
broken! But don’t worry, although the clones are now all appearing a single heap in the
middle of the stage, the good news is that their positions can be restored very quickly
now by adding a new “when I receive” block with a new event of “position tiles”.
Within this add a go to x: y: and position it using the sprite’s tile x & tile y variables.
Then we broadcast to this event after our call to the “setup” custom block. This
needs to be a broadcast, not a custom block, because we want to notify every single one
of the cloned tiles to position themselves all at once, and a broadcast will do that.
Run the project and hey presto, things are working again, phew!
So what about that scrolling? Add with me 2 new global variables named “CAMERA X”
(for all sprites) & “CAMERA Y” (for all sprites). These are to track the position
of the camera as it tracks around the level. Now right click the CAMERA X & Y variable
reporters in turn and change them to sliders. Then right click them again and change the
range to 0 to 500 for them both. Update the when I receive “position tiles”
script to subtract the camera x from the tile x, and the camera y from the tile y.
And finally add a forever loop around the broadcast “position tiles” block so that
the positions stay up-to-date as the project in running.
Run the project again, and we can play with the camera x & y sliders to watch the game
tiles scrolling left and right, up & down. And now comes an unfortunate Scratch limitation,
the 300 clones limit. You might be hoping to simply expand out the number of tiles to
generate your entire level from tile clones, but no no no, we can’t do this – It will
take over 200 tiles just to create one single screen of the level, so that only leaves 100
more before we run out… and we will need more close for other parts of the game like
collectables, or enemies. So, what to do! The solution is to only use clones for the
tiles that are actually in view, and tiles that are offscreen we’ll not create a clone
for yet. To demonstrate this, let us pretend that our games view port is actually only
4 tiles wide and high, I will draw a dark border around the current stage to demonstrate
this (here’s one I prepared earlier). This is our view-port (the area of the game that
we can see at one time). Now I scroll the level using CAMERA X and things look good
as tiles scroll off the left of the viewport, but things are not so good on the right where
we have run out of level clones! The solution to this problem can be referred
to as looped scrolling – [show by scrolling and dragging a sprite] As a tile clone moves
out of the current viewport like this, we recycle it by quickly move it over to the
right hand side of the viewport ready to scroll back into view on the other side filling the
gap. To do this, Within the “position tiles”
receiver, add an “if” condition checking whether the position of the tile (tile x – CAMERA
X) < the left side of the viewport (CLONE COUNT X * -16)”. If it is, then we change
tile x by the width of the viewport, that is CLONE COUNT X * 32.
Now slide camera x to 0, and then run the project. We can now scroll it to the right…
Success!!! Look how the tiles are jumping to the right hand side when they move out
of the viewport. But not so when scrolling back to the left
- Let’s update the script to fix that. We could write out the full script again,
but instead let’s do something a little more clever. Insert the maths operator “abs
of” around the “tile x-camera x”. Switch the < for a >, and change the -16 to positive
16. The abs function changes any negative values to positive ones, so we are now effectively
looking for when the tile moves out of the viewport both to the left or the right.
Then add an if else conditional block within, and check whether tile x < CAMERA X, if it
is, then the tile has moved off the left side of the viewport and we need to move the tile
to the right hand side of the viewport, otherwise we want to move it to the left (by multiplying
by -32 instead) Let’s give that a quick test. Ok, Looking
really good. We can make short work of implementing the
same scripts for scrolling up and down too. Just duplicate the IF condition, and make
sure to switch all the tile x’s for tile y’s and the CAMERA X’s for CAMERA Y’s.
Ok, finally let’s expand out our viewport to fill the entire screen. Scroll to our green
flag script and change the CLONE TILES variables from 5’s to 10’s. Run the project – Boy
that was easy! :D But exactly how big should be make these values
to fill the entire screen? We can do a quick bit of maths to work it out precisely. Scratch’s
stage is 480 pixels wide. Since our tiles are 32 pixels wide we divide 480 by 32 and
get exactly 15 tiles wide, we can fill that in. The height of the scratch stage is 360
pixels, 360 / 32 is 11 and a quarter. Hmm, well we always have to round up otherwise
there will be a gap, so that’s 12 tiles high. I’ll enter that value into CLONE TILES
Y. Now if we run that we can see that things are looking really good, but it’s not quite
there, see a gap on the left and right? The reason for this is that we calculated how
many tiles we needed to fill the screen width and height, but we didn’t factor in that
a tile can be half off the screen on either side. So, we simply need to add 1 more tile
to the width and height. That makes the viewport 16 by 13 tiles. And now, we have a very full
screen of tiles! Wonderful. But hold on, are you seeing what I’m seeing?
The tiles at the edge of the screen are getting stuck and not scrolling off the screen nicely
at all. We simply have to fix this; This is obviously happening because of Scratch’s
sprite fencing rules designed to stop us losing our sprites by moving them offscreen … sadly,
there are plenty of times when we do want to be able to move them offscreen – and
this is one of them. My favoured one right now is to switch the
costume of our sprite just before we position it, to the costume named “BIG”. Remember
that costume? I told you we’d come back to that. So this costume is larger than any
of our tiles, and scratch will allow this tile to be moved further off the edge of the
screen than a smaller tile. Then once we’ve moved it to where we want it, we switch back
to the correct smaller costume… ah… We don’t actually know what that was, So let’s
Add a new variable named “tile”, ticking for “this sprite only” and use this as
the new costume identifier. Then in the define “setup” custom block, replace the switch
costume block with a set “tile” variable to and replace with the random number.
And we run the project again – look at that, so good. We have a full screen of very well
behaved scrolling tiles. Well, if you got this far then congratulations,
you should be very pleased with yourselves. Look at how smoothly those tiles scroll on
and off the screen. This is the fabulous beginnings of ‘so many exciting’ Scratch projects
‘just-waiting to happen’! I don’t know about you, but I am really
looking forward to what lies ahead in part 2 of this tutorial – if you are excited
then let me know in the comments below! I hope you have enjoyed this video, please
smash that like button and subscribe to the channel if you want to see more griffpatch
tutorials like this one! Thanks for watching, and Scratch on!