Limit speed and boundaries
Last we left off, before taking a quick look at how variables work, we managed to get our player object moving across the screen. However, it would move just to the right, or left if we told it to go left, at blazing speeds. To remedy the speed of the object, we can simply put in “time.deltaTime”:
As for “time.deltaTime”, what it does is change the conversion rate of the speed from going at 60fps to 1fps. In unity, moving 1 frame is equivalent to moving 1 meter per second. It allows us to use real time, as it is the time in seconds to go from the last to the current frame.
Now, lets say we wanted to adjust the speed within the Unity editor, but not have to change it every time in the script. All we have to do is apply what we learned from our variables exercises and apply it to here.
We applied it as a private float, as for best practice, it is almost always best to apply your variables as private unless you need them to be public. However, if we kept it as just private, we wouldn’t be able to make our adjustments in the editor. So, instead, we put [SerializeField] above it to have it show up in our editor.
As we can see, it is also possible to adjust the value of our speed while game is playing, as well as going into a negative value to move to the left.
Applying user controls
Now that we have an idea of how to adjust the speed of our player, let’s apply some controls to it so that we can move it when we want to move it. First, we can go into our Unity editor and see what the different input commands are already set up, or make adjustments to them if we want to have something different.
As we can see, the defaults are set to our typical movements used in any game. From here, we can go into our player script and write in the code to set it up so that the player moves only when we tell it to.
As we can see, we created a float within the Void Update section for both horizontal and vertical movement. From here, we just added it to our line of code for right, and then created an up line of code and now we are able to control our player how we see fit.
Now, lets find out how to get some boundaries set up so that when we are playing, we can see the player within our camera view at all times. In order to create boundaries, we first need to search for the locations that we need to limit our object within.
As we can see, if the y axis base is set to -4, the object is still fully on the screen, so we will set that as our lower limit.
We will set our upper limit of y to 0, as we do not want to allow our player to move too far up into the playing field.
As for our x position, we will set the limits to 11.3 and -11.3, however with these ones, we can set up a loop effect so that when we pass those limits, we will have our player show up on the opposite side of the screen.
As for what type of variable code we should use, we have to figure out what is happening with our object. We are trying to have our object not be able to surpass certain points, so the best type of statements we should us would be if() statements. These will allow us to tell Unity that if our object reaches a certain point, then we want something specific to happen.
Now with these lines of code in place, we can now test it out in our game and see what happens.
As we can see, they values of the y do not go lower than -4, or higher than 0. As well, the moment we reach -11.3 or 11.3, we are switched to the other side of our playing field.
Now that we have our player movement portion of the script finished up, it’s time we cleaned up our script a little bit so that in the future, if any issues arise from movement, or if we want to make some small adjustments, we have made a reference to it to simplify our lives.
What we can see from above, is we created a new Void function and named it movement. Then, everything we just created we placed into that void and in our void update, all we now have to do is reference out Movement() method. This now lets us make reference to movement for our player to anything we want to in the future, or keep the code in tact so that if errors do arise, it is easier to search through a specific category rather than all of your lines of code. Now, any comments that we have left in, we can clear out if we know what everything means, as it is taking up space in our coding. Right now, it isn’t too bad, but if we have hundreds if not thousands of lines of code built into something, all the excess comments that are mainly just used as a reference for what our tasks are, are taking up a lot of unnecessary space.
Now that we have our boundaries and player movement set up, next we will get to have some fun in figuring out how to get some sort of shooting mechanism in place and not overload our games with infinite objects.