7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
FREELessons: 22Length: 2.6 hours

Next lesson playing in 5 seconds

Cancel
  • Overview
  • Transcript

3.10 Adding Custom Movement

Now it's time to make a couple of slight modifications to our game just to kinda make it look a little bit better and introduce the concept of the game loop. Cuz to this point, we've really just been relying on the setup of the physics world and the bodies that we place within the world. To actually take care of the movement of things and the interaction of these bodies. So we're gonna kind of introduce a new concept in this lesson as well that's going to give you a little bit more control over where things move. And how quickly they move and things of that nature. So first we're gonna make a slight modification to what we've been doing so far. And that's going to be for the layout of the blocks here. I'm gonna modify this just a little bit, just so that it looks a little bit more aesthetically pleasing. So I'm gonna to give this a kind of an offset from the left of the screen of 300 and I'm gonna space these out a bit more. We're gonna space them out to 40 then we'll go ahead and save that and I think for the time being that should do us. Let's go ahead and run it just to see things should get spaced out just a little bit more, a little bit more centered. There we go, that's a little bit better I think. Now what we also wanna do is to introduce the concept of the game loop and really what that means is, if you remember from earlier lessons when it. We had the lines in here that were showing you the frames per second and the node counts. So if I uncomment frames per second and save that and go ahead run again. You're once again gonna see this show up on the bottom of the screen to see, you know, how many frames per second we're running at. And by default we're gonna be running at about 60 frames per second. Now depending on how many things you have on your screen and how much interaction and things like that you have going on that number will change. But how does that matter to you? Well in this concept of a game loop every frame, every time a frame is executed or something is changed you have an opportunity to update something on the screen. You have an opportunity to adjust where things are on the screen, so you have very fine-grained access to everything that's going on for every rendering or every frame that's executing on the screen. So do you think when this ball is moving around it's actually moving around and being drawn or redrawn in a different position 60 times per second. Now it may not look that way but that's really what's going on behind the scene. So let's see how we can tap into that and maybe introduce some movement of our own that's kind of done in a calculated fashion. So the first thing that we're going to do and I'm actually going to save you watching me write some of this. I'm actually going to paste in a little block of code here and then we'll talk about it. So after our positioning of the original four blocks I'm gonna come down after that for loop and I'm gonna paste in a block of code here. Now it's gonna be extremely similar to what we've done so far in the past where I'm creating this concept of a moving block now. Which is an s case sprite node and I'm gonna color it yellow just so it's a little bit different. Then it's gonna have the same size as the other blocks, 150 by 40. And then we're just gonna set the default position which will initially be 250. And that's just kind of an arbitrary number, you can set it to really be anything you want. And we're going to space these things out a little bit so what I wanna do is I gonna change the height of the original blocks. So let's just bump that up a little bit to say about 90% of the height and that way this new moving block, this yellow block is gonna be at 75% of the height. And then we're going to create that physics body, just like we've done before. We're gonna set all the same characteristics as we've done before. And we're actually gonna use the same bit mask because there's no reason for us to use anything else to this point. And then finally we are going to proactively or programmatically give this a name. So we can reference it later on in our code and we are gonna give this a name of moving. So I can use that nice little built in function later on to get a hold of that actual node using the child node with name function. So now that we have all that set up, I'm gonna go ahead an add this new movie block to our scene. And then I'm going to increment the block count again so we have the original 4 plus an additional 1 which is 5. So we're gonna have a total of five blocks and once we've made those changes, if I go ahead and save. And run what you should see now is we're going to have an additional block that's gonna be yellow and it's gonna be placed underneath those green ones. So now we can start to move around and it's gonna interact just like the other ones have, where it's going to get hit and disappear. So nothing out of the ordinary and in order to win the game you actually have to hit all five blocks which may or may not happen in the short term here. But once you do, you will still get the same you win scene transition as we've done before. Now what I wanna do is I actually want to have that block move hence the name moving block but how do I do that programmatically. Well I could sit here and write some complicated logic and have something run in the background. And all that sort of good stuff to calculate it's position but that wouldn't be taking advantage of the built in capabilities of sprite kit. So if you go all the way down to the bottom, we've kind of glossed over this concept but we haven't touched it yet. This is this update function as you can see here, it says that this function is called before each frame is rendered. So that means this function is going to be called 60 times per second. Now that's very frequent so we have this wonderful opportunity to be able to do some additional calculations quite often throughout this game running. To change the position of certain objects or move things around or place things on the screen at random intervals or things like that, which is ultimately what we want to do in this case. So one other thing that we're going to want to do is figure out how we want this block to move. Well, all I want this block to do is moved from left to right and maybe have it stop once it hits about 250. That same offset that we placed it from the left, whether it gets 250 spaces from the left or from the right that's when I want it to stop and change direction and start going back and forth. So it's gonna get this, kind of, bouncing back and forth, kinda, feel to it. So one thing that we're going to need to do is we're gonna come up here and we're gonna define a couple variables or properties in our GameScene class. So we're gonna have a movingBlockDiff, this is how far it's going to move each time we want it to move. So in this case, you know, we can default it to 10 depending on how, how fast you want it to move. If you want it to move a little bit slower, we could drop it down to 5, so let's start with 5 just to see what that looks like. And then we have a simple property here that's gonna check whether or not it actually exists. And you're gonna see why we're gonna need that in just a moment. So let's go ahead and go down to our update function here and what I'm gonna do is I'm going to paste in another block of code here. So this is what we're going to do, we're going to try to get access to this moving block via our child node with name, casting it as a sprite node. And what's going to happen here since this is like an if let block. If this child node exists and we can cast it to a sprite node and if this moving block has a value, then we will enter into this if block. If it does not, meaning this node does not exist any more and this moving block is an optional null value then we will not enter into this block. So it's just kind of a way to check ourselves so that we don't fall into a null reference exception type situation. And then all we're gonna do at that point is do a little basic calculation. So we're gonna calculate where the next exposition of that moving block is gonna be and I'm just gonna use the movingblock.position.x property. And I'm gonna add to it the diff of how far I want it to move. So where is the next exposition that this block is going to be? And then I just do a couple checks, so if my movingBlockDiff is currently positive, which means it's moving to the right. If that's moving to the right, and that x position subtracted from the width of screen is less than 250 which means it's moved a little too close to the right side of the screen. Then I'm going to multiply the movingBlockDiff by negative 1, so that's gonna force it to go in the other direction. And the same thing if the moving block is currently negative and the exposition is less that 250 which means its gotten too far of the left of the screen. Then I wanna once again multiply the moving block dif by negative 1 so I can switch it's directions. And then I'm just going to do a simple incrementation of my exposition Of my moving block based on that differential value. So I'll go ahead and save it, so now you're gonna see something very interesting. When I run this, is we're gonna have this yellow block actually movea and it's gonna move left to right on the screen. So you see there, now it's, we have a moving target that we have to try to hit as well. So this is another interesting way that you can add some additional functionality dynamically through code on your screens and actually have different things move. So you have options when it comes to a sprite kit. You can have everything be physics driven like we did in the beginning and have that dictate the movements of the different nodes or bodies within the world or you can progrommatically inject some things into it. So that you can get finer control and have more dynamic movement, based on certain calculations that you wanna do. So at the end of the day, the options are completely up to you and it's even nice to kind of mix those things up a little bit. And add some kind of dynamicness to it, based on some calculations you're doing with encode, that always kinda tends to spice things up a little bit and give you a little bit more control. So, now that we're pretty much coming to the end, one of the final things that I'd like to do is to crate a, getting started scene or at least a, a start screen. So that we can [UNKNOWN], not just jump right into the game but maybe display a scene to the user. To say tap to begin to play or something along those lines. And they we're gonna have a fairly well-rounded game that you can then play and extend at your convenience. So in the next lesson we're gonna add that start scene.

Back to the top