[Intro] Hello fellow Scratchers, I’m Griffpatch and I love all kinds of Scratch Projects, especially Platformers, but until now I’ve not covered the traditional bread and butter of Scratch, the “Classic Scratch Platformer”… There may be no scrolling or complex lists here, but we have great expectations, because we are laying solid foundations to build up to something more like this! Wow doesn’t that look great – Why not drop me a message in the comments below to share what you are most excited to learn about! There’s a lot to see, from the solid platforming, to wall sliding. Scratch cat’s feet matching the slope he is standing on, did you see that? Moving platforms, and lava, Wall jumping and level navigation. Oh wow… This is all classic Scratch coding, there’s no complex lists or grids to worry about, just Scratch at its best using simple level costumes drawn within the scratch costume editor, and thus it’s going to be a breeze for you to take what we create together, and in no time at all, make your very own style of game with it! Oh yeah, so excited! But we have to start somewhere, and to ensure we get things right, we’ll be starting simple and our concern will be with player movement and collision detection – and for those who’ve done this all before, no - you may not have done it quite like this before – So stay with us! As with my other tutorials, if you want to begin this project by remixing by starter project then there is a link under this video. This project contains all the costumes needed to get Scratch Cat animating in later episodes. If you are not interested in following this tutorial exactly, then don’t worry about using these, but even though we are not using these costumes today, we will soon, and it might be easier if you have them in your project right from the start. I’m just going to remix the project and we’re ready to go! So, check out these costumes! Loads-o-cats! Man yeah, they took me some time to draw, and no, I didn’t do them in Scratch. I painstakingly drew them out in adobe illustrator. But as I said, today, we’ll make a ‘new costume’ for the player… Why are we doing this? Well because simple platforming scripts work best with simple costumes. So, using mostly rectangles I can quickly draw a ‘’completely original’ square protagonist! Just please, please ensure you have him completely centred. You know, by dragging the big square towards the middle of the drawing canvas until you see it snap into place. Oh yeah… Gotta love ‘em – All I can say is. You see this guy and you know exactly what game you’re about to play lol. I’m going to christen him ‘Guy’ – There, job done. You know, we should rename this sprite as “Player”, so we know what it’s for. [backdrop] Now for the level. Some people prefer to use backdrops, some people prefer to use sprites for some very good reasons… In these tutorials I’m going to teach both! But today, it’s backdrops, so click with me into the stage backdrop. Ensure you select the rectangle tool so that we draw a perfectly straight line, and make a nice floor for our first screen. Next we can make a few new rectangles to act as stairs. And finally, I’ll add a little floating platform to test our skills! That’ll do nicely, click back into the player sprite and we can begin to code! [Gravity] Begin as so often we do with a When green flag clicked block, and then set the player’s position x to -150, and y to 50. How do we get the player to fall to the ground, simple, a forever loop, and change y by, say -1. Negative numbers move us downwards. Run that, and yeah – we at least can see he does drop downwards, but very uninspiringly. The problem here is that objects do not fall to the ground at a constant speed, nope, the longer they fall, the faster they travel right? To keep track of our players speed we’ll need to make a new variable, naming it “speed y”, for this sprite only (because it’s this players speed, no one else’s). We’ll set speed y to 0 when the project starts, and then change speed y by -1 each loop, and finally then change y by speed y. So now, every time the player is moved down, they move a little faster than they did the time before. Let’s give that a test. Splendid – That’s far more convincing don’t you think. Our next goal is to actually stop when we hit the ground. [Ground Collisions] So, after we’ve moved down with the change y by speed y, add in a IF, and (for the time being) we’ll check for touching color, and use the colour picker to select the colour of your level. Now for all of you worrying about using the colour sensing blocks, don’t fret, this is just for the time being as it makes things easier to explain. Right, drop in a “stop all” block within that IF and we can confirm that we are detecting the collisions. Run the project and now everything comes to a halt as soon as the player is touching the level. It’s worth noting here what touching actually means. Unlike in the real world where you’d say you were touching something if you were pressed up against it, in Scratch the objects need to be overlapping to be counted as touching. And this, this is overlapping – check! Goal number 3 then is to get our player back out of the ground again now that we have collided. Well, if we weren’t colliding last frame, we could just move back to where we were before? To do that, we change y again, but this time by negative speed y (that is 0 – speed y). Run that again – Hmm, as soon as we collided, we quickly have been taken back to just before the collision occurred… That actually looks pretty good, but notice the small gap under our player? That happened to be a rather lucky fall, things can look a lot worse. Let me adjust our starting y position to 55 and run the test again. Oh no – That is no good at all, we’ve moved way too far. This strategy of just moving back out the floor by the same amount we moved in doesn’t work. Instead we need to carefully move our player back up only a single step at a time, until we finally reach the point where they are no longer colliding. Then we can be sure they are not floating off the ground after the collision, and the world will be set to rights. We’ll do this by repeating until we’re NOT touching color. And in this repeat loop we change y by 1. That is, we move them up 1 screen pixel. We don’t need the stop all block any longer… If we run that, we can now see after a collision we are raised back up to the surface, but then suddenly we plunge back down into the ground again! Why is that? Ok, simple… after an impact with the ground, we need to reset our speed y to 0 since the impact should take all the speed out of our fall. Great – Gone is the glitch, but I’m not dead keen on the way the player is seen to glide up out of the ground. Luckily this can be easily fixed using our friend the custom block. So, make a new block, naming it “Fix Overlap” – and here’s the important thing, we click “Run without screen refresh”. This means everything we place inside this block will no longer animate, but will finish running before the screen refreshes. This is perfect for getting the player out of the ground without us having to see it happen. Move the entire repeat until block under the new define Fix Overlap block, replacing it with the “Fix Overlap” block itself. Let’s see that in action. Oh yeah, smooth. The player now looks to be falling and landing flush with the ground, no visible penetration, and no floating or unwanted bouncing around. Perfect. Ok, now before we move on, what if we wanted to change the speed at which the player falls to the ground? Well, that we be a change in the force of gravity right, that’s our -1 value here. What we will do is create a constant variable specifically for this. Make a new variable, naming it GRAVITY, for all sprites. And we’ll set it to negative 1 right at the start. Then simply replace the change speed y by -1 with the new GRAVITY variable. That makes it easier to remember how to change the force of gravity at any time later on. Feel free to play with different values and have some fun! [Jumping] Talking of gravity, how better to show it off than to add in the ability to jump! And this is surprisingly easy! Right at the top of our forever loop add a new IF, checking whether the up arrow key is pressed. Then we set speed y to a positive number, say 12. And, just run the project… Tap the up key – And up we go! Our speed keeps us travelling up for a moment, and then gravity naturally returns us back to the ground – That’s excellent. Of course, there’s nothing to stop us holding down the up key and flying off! So it’s more of a rocket jump at present, but not to worry, we’ll fix that later. [Walking] Let’s add in the left and right movement. IF left arrow key pressed, then… Ah, we need a new variable for our x speed. Name it “speed x”, again for this sprite only. Now when the left key is pressed, we can ‘change’, yes don’t set this time, change speed x by negative 1.5. We’ll do the same for the right key, changing speed x by positive 1.5. That takes care of our player’s acceleration, but doesn’t actually move them, that we will do down here, just above the “change y by”, we add a “change x by, speed x”. Run the project! And we are off, I can now press an arrow key and the player begins moving in that direction… however I have to stress, they don’t then slow down, but keep moving very fast in that direction, that is until I press the opposite arrow key again. Oh man, that’s hard to control. What we need is some resistance, that is friction with the floor to slow us down and stop us moving. Not a problem, just before we change speed y, add in a SET speed x to, speed x * a value between 0 and 1, I’m going to pick 0.8. The closer to 1 this number is the more slippy the floor will feel. Play testing again… and that’s quite a transformation – This is feeling much more like a platformer already. [Rethink and Innovate!] The next step , no pun intended, would obviously be, to stop us colliding with this right hand step (or wall) by detecting the collision and backing our player sideways carefully out of it, just like we did for gravity… however… I’m going to stop us right there, and take a short breather! Why? Because I want to try something a bit different. What I love about coding is that there’s always space to innovate – To try doing things a little differently to see if you can improve things! We yet have many problems ahead of us that we will need to address, some easy to work around, others more problematic, for example, like the player getting caught on the irregular pixels of steep inclines, the very pixels that make up our bitmap level – man that’s a real doozey. What I am going to propose is that, rather than moving the player in large steps until they collide, and then using small steps to get out of the collision. We instead use small steps at all times while moving the player. This allows us to detect collisions as soon as they occur, and also allows us to handle the movement and collisions in far more detail going forward. Shall we give it a go? We’ll begin by replacing just the change y and collision script here. Make a new custom block named “Move – in steps” with a numeric input of “steps”. Make it run without screen refresh. As usual, drop in this new block where we took the original scripts from. We’ll leave the steps input empty for a moment. So, we want to move by speed y as before, but split up over a number of smaller steps. We’ll start by repeating for the given number of steps. It’ll be useful to remember the last position we were in before the move. Make a new variable naming it “last value”, for this sprite only. Set last value to the current “y position” of the player. And now we “change y by”. But how much? Well, we need to divide the total distance we want to travel (speed y) by the number of steps we are going to take (That is, ‘steps’). We can then put back the collison check, removing the fix overlap. Since moving by small increments can no longer leave us deeply overlapping the ground on collision, all we need to do is restore the player to their last position before the collision, so set y position to the “last value” we recorded. Now bring back the old fix overlap script, did we forget anything, yes – we need to borrow the set speed y to 0 to ensure our player is slowed down after the collision. Super! No looking back now, throw away the old “fix overlap” scripts. Finally, looking back to where we make use of the “move in steps” block. We need do decide on how many steps to split this movement up into to ensure it’s accurate enough. Well, we could plum for a number, say 100! Perhaps a bit overkill, but let’s just give that a test and see if it is working? That seemed ok, let me try moving around… and even dare I bump my head, yeah, now that didn’t work before . So, was 100 a good number of steps then? Well, not really, No. Because performing a hundred checks every frame is far more than is required when we might generally only be moving a few steps at a time max. Luckily we know how far we are moving. It’s told to us by the value of ‘speed y’, only we just have to be careful because it’s often negative, so how about we put the maths operator abs in here around the speed y. Then it will switch it to always be a positive number, and the perfect number of steps to take to move by 1 pixel at a time. Run the project again. And it feels identical… but will be performing far far less collision checks, which is good news. [Horizontal Collisions] This then is the perfect time to consider the horizontal movement, and the resolving of their collisions too. The scripts required are a simple transformation of the scripts that move us in the y direction. I’ll temporarily move them over to the right so we can compare them as we code. Set last value to the x position. Then change x by speed x / steps. Then check for the collision again with an IF touching color. If we did collide, then set x back to the last value, and finally set speed x to 0 to stop us moving any further in that direction. Great, so we can return the y moving scripts, but put them underneath the x moving scripts, careful to keep them within the repeat loop. Finally, just scroll up and we can remove the old change x by speed x here as this is now covered by our changes to the move in steps block! Oh hold on, one more thing to consider. The move in steps block is only working out the number of steps to move based on the speed y. Well, now we also have a speed x to consider. This does complicate matters, but to make life easy, we can just add the two speeds together. Just make sure to add the abs of speed x to the abs of speed y like so. And it’s testing time again! I’ll literally dash over to this first step… And celebration, we have contact! There’s no passing through this one now. Everything is feeling really solid… which is brilliant news… [Fix Jumping] So where does that leave us? One last thing I’d like to just address before the next episode is the jumping mechanic – At present I can still fly around by holding up – Let’s limit that to a simple jump. For this I like to make use of a new variable, named “falling”, for this sprite only. This wants to increase all the time we are in the air… We can put a change falling by 1 at the top of the defione “move in steps” script. Then, to reset it to 0 when we touch the ground, set falling to 0 when we set speed y to 0 after a vertical collision. If we run the project it’s easy to see this at work. Falling is 0 while we are sitting on the ground, and then quickly starts counting up when we leave the ground. This makes it easy to now limit our jumping to points of ground contact. Scroll to the if up arrow pressed, and we can surround the set speed y with a IF, checking for a “falling” value less than, say 3. Hmm, so why 3? Well, this trick let’s the player still jump 2 frames after they ran off the end of a platform. It’s often known as a coyote jump, and helps to keep your game feeling less frustrating. Ok, how does that feel – Hm, pretty good. I’m feeling much more grounded… [Stuck to ceiling bug] Hey up, did you see that, Oh no! Right we still have one bug – I was able to stick to the ceiling by holding the jump key. Luckily I’ve seen that many times before and know exactly what it is. Find the “define move in steps” script, and scroll down to the set falling to 0. Ok, so this collision triggers both when hitting the ground, and ‘also’ when hitting the ceiling! We don’t want to say we’ve stopped falling just because we’ve touched the ceiling, so place an IF around the set falling to 0. Make sure to move it above the set speed y to 0, and then check whether speed y < 0. That is we were travelling downwards when we collided. If this is the case, then this was a floor collision, and we are ok to set falling to 0. Run the project again… That’s it! We are solid and everything is feeling just right, and no sticking here. [Mess around with the Physics] We are all but done for episode 1, What I’d just like to do before we finish is make sure you know how to customise the feel of the movement. Perhaps to make it feel a little less floaty would be nice. Come right up to the top of the script. We started everything with this GRAVITY variable. You know about this one, just change it to a larger negative value, say negative 1.5 to cause the player to be pulled faster back to the ground. This looks better, but of course, has the effect that we can’t now jump as high as before. Well, let’s add a new variable to adjust how high we jump. I’ll name it “JUMP FORCE” for all sprites. Set it initially to 12. And I’ll drop it in to the set speed y here where it was previously already set to 12. So no change there, but what if I change it to 20? Give that a run and woo-hoo, now I can spring really high into the air, that’s cool :D But… I’m pretty sure 12 is good for me right now. That leaves us with how fast the player walks and slows back down. Make a new variable “ACCELERATION” for all sprites, and set it to 1.5, again up at the top of the project. We can replace the right arrow change speed x with ACCELERATION right off. But, the move left requires a negative change, so bring in a subtract block and we’ll change x by 0 subtract ACCELERATION like so. That just leaves this 0.8 here, this slows us down, so make a new variable named RESISTANCE, for all sprites, and put it right there. Scroll to the top and set RESISTANCE to the same value, 0.8. Good good good! – We can play around with these new variables to find values that make our platformer behave and feel just the way we want, and this may change over time as we continue to build up this exciting platforming engine. [Outro] There’s something really satisfying about a functioning platforming engine that feels really solid. And it’s important that we have this firm foundation to build upon, because we have great aspirations for where we are going! Next episode we will open up our level map to include multiple screens, and explore the benefits of sprite vs colour collisions, and perhaps we’ll look at navigating up sloping inclines? But, there’s so many more exciting things to come! I can’t wait to add wall jumps and moving platforms But that is the it for this episode, If you’ve enjoyed watching please smash the like button. Don’t forget to subscribe to ensure you don’t miss the next episode the moment it comes out – If you want to support this channel further, then don’t forget you can join the channel to become a channel member – There’s all sorts of awesome perks including early access to videos, priority comments with custom emoji, and even access to the scratch projects themselves. This channel wouldn’t be here without your support, so thank you so much! So, until next time, have a great week ahead, and Scratch On guys!