[MUSIC]
Hello again, it's great to be hanging out with you one more time.
I was just over on our community site having a look at all the incredible
sharing that people are doing with their game, with their screenshots,
with how things are coming along.
It's really cool to see.
So thank you if you've been sharing.
If you haven't shared yet, then something to consider.
The community loves to see it.
It's a really supportive community.
I think it's really cool.
Everyone wants to see everyone else succeeding, and
learning how to make cool games.
So we have a problem that we're gonna solve in this video, as we often do.
What's our problem?
What's our challenge?
And in this case,
the problem is we're getting situations where the ball ends up in this endless, or
near endless, loop where it's just bouncing from left to right of the screen,
and it's not increasing or decreasing at all with its height.
And it's just going left and right, left and right.
And we're sitting there saying, when will the ball ever reach the paddle?
We get it to a degree, sorry, on the x-axis as well, up and down.
But often we can chuck our paddle in the way, and
have it bounce off in a different direction.
We often get that if we're bouncing between an unbreakable block, just up and
down, and up and down.
So we're gonna resolve that.
And I want you to have a think for a moment about,
just put on your problem solving hat.
How could we solve that so we don't get in this endless loop, where it's just going
straight across the screen and straight back across the screen again?
How do you think we could approach that?
Well, one of the ways that we can do it is, say each time the ball collides,
this moment of collision, we add a little bit of y velocity, up or down.
And likewise, we can add a little bit of x velocity to the left or the right, so
that when we're in this situation the ball is bouncing a little bit.
So we'll get a situation where the ball kinda goes bounce, and
then doesn't exactly make an exact, perfect angle.
But it might bounce a little bit up that way, and a little bit straighter,
and little bit not exactly the way we expect.
A little of randomness is going to solve those situations of
repetition where the ball just can't get out of that loop.
Okay, so for this lecture, we're gonna be working in the ball script, ball.cs.
And up at the very start, what we'll be doing is moving my tablet out of the way,
cuz I'm not drawing any more.
Okay, but what are you gonna be doing?
First of all, we need a new parameter, which we will serialize.
So SerializeField, and this will be of type float.
This will be the randomness that we're adding to it.
So we'll call this random what, randomFactor,
just a random factor that we're putting onto the ball.
And we'll initialize that at 0.2f.
Okay, now we're looking at velocity of the ball.
So where is the velocity represented in terms of our components?
Where are we pushing the ball around?
It's in the Rigidbody.
So Rigidbody 2D the component on the ball
that is determining how the physics is affecting it.
And that's where we can say, push it a little bit this way or
a little bit that way.
So we're interested in the Rigidbody 2D component.
Now I have a challenge for you, which is to cache the reference,
as we've done with the AudioSource, cache the reference for our Rigidbody 2D.
So let me give you a challenge slide here, cache reference to RigidBody.
Similar to caching reference to the AudioScource,
cache a reference called myRigidBody.
Let's actually call it myRigidBody2D, just so it's nice and
clear that we're making a 2D game, just in case anyone forgot.
Okay, so there's the challenge.
Jump in, take that on now, and I'll see you back in a moment.
Okay, so there's two places that we are looking at this.
First of all, here is our reference.
This is the variable that will be of type Rigidbody2D.
I'm gonna call it myRigidBody2D.
RigidBody2D, okay, semicolon.
And within our Start method, similar to the above line where we're
doing this with the AudioSource, we're gonna say myRigidBody2D.
What does it equal?
Well, we want this to be storing within this variable.
We want to store the reference for getting the component,
of GetComponent of RigidBody2D,
open and close parentheses, and semicolon.
Okay, and there's one place already that we can go and
benefit from caching this reference, which is down under our LaunchOnMouseClick.
We're getting the component.
We can remove the GetComponent Rigidbody2D, and
instead just say myRigidBody2D, cuz we're already getting the component.
Generally, when we are doing something in more than one place,
that's when we want to start caching out components, our references.
Or if we're doing getting a lot, on every frame for
example, on a regular basis, we wanna cache it instead of constantly saying hey,
go find it, hey, go find it, hey, go find it.
It's better if we already know where it is, and
then we're just pointing to the specific place.
Next up, what we need to do is find our moment of collision where
the ball is bouncing, and we can push it in a different place.
Right at the very top of OnCollisionEnter2D,
we need to start by declaring a variable of type Vector2.
We'll call this velocity, what should we call it, velocityTweak.
Tweak, to show that we're tweaking the velocity, moving it a little bit.
And we need to construct this as new, so using the new keyword, Vector2.
And then Vector2 is gonna be looking for an x and y, so an x and
y coordinate in here, in terms of our new Vector2.
Each of these, we're going to do random.
And we're gonna do random between 0 and
our random factor, our random factor up here, our variable.
So if you want a mini challenge, take that on, to construct our new Vector2 that
is between Random.Range of 0 and our randomFactor for x and for y.
Okay, let's do this together now.
So Random.Range in the brackets, so ( 0f, randomFactor).
That's on the x, and then comma on the y.
And I can see a red, squiggly line I'll come back to in just a moment.
Random.Range, and this will be exactly the same, (0f, randomFactor),
okay, and semicolon at the end.
Now, again, I'll get to the random in just a moment.
But you can see this a huge line, it doesn't quite fit.
If you're zoomed in a little bit, it's not gonna fit on your line,
which is a bit annoying.
We can tidy this up by saying new Vector2.
Let's put the x value on one line, and then comma, the y value on another line.
So you can do that, you can move things around.
So long as the syntax, the code is written in a correct way, you can put in your
spaces and your returns however you want, so it fits on the page nice and neatly.
Now, Random's giving us an error.
If you mouse over it, it's saying,
Random is an ambiguous reference between UnityEngineRandom and SystemRandom.
And if we scroll up to the top, we're using System and UnityEngine.
This is one of those things that it's like, why bother with namespaces?
Well, there's multiple concepts of Random.
This System namespace has a concept of Random and
the UnityEngine has a concept of Random.
If we go and comment out these three lines, and I'm gonna do that by typing in
/*, that says everything after me is commented out.
And then at the end of my randomFactor here, I'll say */,
that's one way of commenting out a block of code if you like.
There's also some hotkeys, but
I thought I'd teach you this way cuz it's kind of neat.
So when we comment out or Random.Range, if we scroll all the way up out,
we can see that we're no longer using Unity System.
And what I think's going on here is the fact that these are the generic
lines of code that Unity's creating at the top of our script in Visual Studio,
that just gets created there by default.
We're not actually using any of those and we don't need them.
And we know that for this particular using, it's the UnityEngine, sorry.
For this particular Random, it's the UnityEngine Random that we need.
So I've deleted those other usings, those other namespaces,
we shouldn't have a conflict now.
So when I come down and remove my nifty asterisks comments,
and make sure that my indenting is all good, yep, that looks nice.
Then we can see that our error goes away.
We'll save that and make sure that it actually works,
before we celebrate too much.
We'll just finish off writing our codes.
So we've got our new Vector2, that's good.
And then I'll give myself a line here, so
I can just see there's a little bit of space.
So this is a block here, a chunk of code.
And then, if (hasStarted), well, what do we wanna do in here?
We want to allow the audio stuff to do the audio stuff.
So we're gonna say in here, myRigidBody2D.velocity, Actually,
we'll say += because we want to be adding to the velocity, be giving it a little bit
of extra tweak, as opposed to completely changing it to something different.
And that we +- velocity, if I can spell it correctly,
velocityTweak, which was the variable that we created just above.
Okay, so
just to recap on that, we're saying here's this new tweak to the velocity.
Let's add that tweak to the velocity once the game has started.
And this applies to the RigidBody, RigidBody.velocity.
We'll save that.
Just jump back into Unity, make sure this works.
You know what I'm going to do?
I'm going to be that guy.
We'll find ball, and scroll down to where we find the ball script.
And the random factor, I'm gonna put the random factor up to, say 1.
That should do something crazy.
We'll click on Play.
Hopefully, that's not too crazy.
And we'll launch the ball over to the side, and then boink.
Okay, a little bit tough to see whether the randomness is actually happening.
So let's go and dial our randomness up to something ridiculous.
Let's put this up to 100.
[LAUGH] So that should be adding 100 to the x or the y.
I think that should be fairly,
I assume it's probably gonna make the ball go really fast.
Whoa, it made it go stupid fast.
Okay, so this is part of something we're gonna be talking about in an upcoming
video is extreme tuning, but I'll try to make it a little bit more sensible.
We're adding 10 onto the ball.
Okay, yeah.
That is, wow, doing lots of really crazy, random stuff.
Which is kind of fun in a way.
That's, whoa, it keeps you on your toes, except when that happens.
Okay, so that's not so good when that kind of super slowness is going on.
So we'll put this back to, say 0.5.
It's gonna be something that we tune and play around with,
but we want to get generally in the ballpark.
I think 0.2 is fairly safe, but not overly dramatic.
Yeah, this seems pretty good.
It's not making the ball do anything really weird, and so
far we haven’t been stuck.
I'll probably have to play for a while to get that use case where we’ve got the loop
across the screen, but this feels pretty good.
It’s not ridiculous and I quite like it.
Okay, so we've introduced some randomness into our game.
We've also talked about using the namespaces and
what to do if you come across that problem with the conflict.
Our ball shouldn't be stuck so much.
If you want to be tuning it so
it doesn't get stuck, you can change the Random Factor.
Remember after you've played around with it, to apply it back to the prefab.
So that in all of our other scenes, we have this particular change to the ball.
So great work, and I'll see you again soon.