Welcome to Core Interaction Programming, the first course in the Unity Certified Programmer Specialization from Unity Technologies. This course will help you prepare for the Unity Certified Programmer exam, the professional certification for entry to mid-level Unity programmers. Unity is used to create real-time 3D applications for many industries, including video games, automotive, film, training, and more. In this course, you will be challenged to solve realistic Unity programming problems that are aligned to topics covered on the exam. Throughout the first course, you will build the foundation for a 2D action video game: AsteraX. In doing so, you will practice many of the skills covered in the exam, including evaluating scripting needs from a project requirements document, implementing the three "C's" of an interactive applications (Character, Controls, Camera), providing user feedback through basic UI elements, and applying professional programming practices like developer testing. This is an intermediate course, intended for people who are ready for their first paying roles as Unity programmers, or enthusiasts who would like to verify their skills against a professional standard. To succeed, you should have at least 1-2 years of experience programming interactive applications in Unity. You should be proficient at programming in the C# language and familiar with Unity's scripting APIs. You should have experience in the full product development lifecycle, from concept to launch (and beyond). And you should understand multi-platform development, including deploying applications to XR (AR and VR) platforms.
Solution 2C | Screen Wrap
Loading...
來自 Unity 的課程
Core Interaction Programming
1 個評分
從本節課中
Basic User Input and Object Management
This week, we'll begin implementing the basic application functionality that we planned the previous week. We'll give the user control over the ship, enable the firing of projectiles, and handle the tricky screen-wrap requirement. But first, we'll look at the importance of version control in professional projects, and Unity's version control solution, Collaborate.
與講師見面
Jeremy Gibson Bond
Unity Technologies
[MUSIC]
Hi, everyone, I'm Jeremy Gibson Bond, and
welcome back to the Unity Certified Programmer Exam Preparation Course.
This video is the third part of our solution
to your first programming challenge, the player ship movement and firing challenge.
And in this video, we're going to be focusing on what allows us
to loop things around the screen when they reach the screen edge.
And it's going to be comprised of two main components.
One is the ScreenBounds, which is a box collider trigger that lets us know when
things have left it, and it is perfectly sized to frame the entire play area.
The second is the OffScreenWrapper,
which is a single script that causes everything to wrap in this game.
That includes the player's ship, and the bullets, and
the asteroids, all wrap because of this single OffScreenWrapper script.
So let's go ahead and take a look in Unity.
So here in Unity, we're going to take a look at the main camera and
a child of main camera is ScreenBounds and
you can see here that ScreenBounds, it's just a cube.
It's just a box collider in the shape of a cube of size of one.
But it has the screen bound script on it and if you watch what the script does when
I hit play, is it sizes the ScreenBounds to the size of the play area.
So now if I switch out of my perspective view to an orthographic view and
then switch to here,
you can see that the bounds of the box collider here are exactly the bounds
of the play area with a little bit of leeway in the z-direction.
because I didn't want to, having to wrap z, that just doesn't make sense.
So that's what we're going to look at now, we're going to take a look at
actually using this, and how we set it up to match the camera bounds.
So again, make sure that in your solution, you have your camera set to 10 ADP or
I guess your game pane set to 10 ADP which is 1920x1080 pixel resolution.
And of course, your camera has to be set up orthographic with the size of 9 which
we did before the challenge.
So this is already pre-setup for you.
So let's take a look at this screen balance script here.
Up here, we have a required component of BoxCollider,
you have to have a BoxCollider for this to work, and just like we said for
the other things which require component because we've required it,
we don't need to double check whether it's null or not.
We have a static, private, singleton,
it being private means nobody other than these screen bounds instances
of the screen bounds class can access this singleton.
And so as a singleton,
the only part that we're using here is the part that says only one can exist.
It is not protected, so it doesn't have that property that it had before
where it alerts me if I'm trying to set a second one.
But for something like this, I'm okay with that.
The zScale is really just setting how big we
make this box in z-direction, everything, else is set automatically.
And so we got a camera BoxCollider and a cachedOrthographicSize and a cachedAspect.
Again, I like caching things that might be slow to calculate.
And then cachedCamScale is just the scale that we expect it to be.
So here in start, I say s is equal to this and the camera is camera.main so
it's the main and if the camera is not orthographic, I am going to log in error.
I'm going to tell you that it has to be orthographic.
And then I have got the BoxCollider, I get component, and
then I set the size of the BoxCollider to the Vector3.one,
which is a Vector3 1, 1, 1, it sets scale to 1 or its size to 1.
And that just makes the rest of the calculations work out properly.
I set the position of this game object to the origin Vector3.zero.
And that just moves it from where it was centered around the camera to being at
the origin of the game, and then I call scale self.
And scale self is called every update, but I call it now first, and
it just says hey, if the orthographic size
of the camera is different from the cached orthographic size that we have,
which initially would be zero because we didn't set this to anything.
Or if the aspect ratio of the camera is different, then calculate scale.
And what this allows us to do is while the game is running,
we can actually change the aspect ratio of the game window and
it will rescale this collider and calculate scale.
I pull in the orthographic size from the camera, and the aspect ratio of
the camera, and the scale from the camera, I put those all into my cached versions.
Then I cached version, then I create a scale desired Vector3, and
then this is just what size do I want this box collider to be.
I get the z-scale directly from the private variable, and
then I multiply the orthographic size by two, and then I multiply
the scale desired y, which I just created, by the aspect ratio,
so orthographic size is in the y direction, that gives me the x direction.
And then, I've got this cool thing that is an extension method for Vector3s.
And I'm going to get into this, but what I do is I
scaleDesired.ComponentDivide the cachedCamScale, and
what this ends up doing is it sets the scale of the collider
to the desired scale divided by the local scale of the camera.
So if for some reason, the camera has like
a scale of two in the y-direction which I don't know why you do that, but
just in case I use this to overcome that local scaling factor.
So that's what that is.
And what component divide does is it says, take the x of one vector and
divide it by the x of the other.
The y of one and divide it by the y of the other and the z of one and
divide it by the z of the other.
And the first vector is scale desired here.
And the second one is cachedCamScale and I'm going to show you how
that extension method works, I think extension methods are super cool.
Then I got a couple more things here that I'm not using yet, but
random on-screen local just returns a random point that we will be on-screen for
sure, bounds is just returning the bounds of the box collider.
And then I've got this OOB stuff and that is out of bounds.
So there's several different versions of this.
But I'm just asking, if I give you a vector 3, is it out of bounds?
Is it outside of this trigger collider that we have?
And then I have 3 more, is it outside in x-direction,
is it outside in the y-direction, is it outside in the z-direction.
And then finally, I have a number I can pass in and the way that this works,
if we are in the local coordinates of this transform for
this box collider here, then if a number is
over 0.5 or under -0.5, then it's out of bounds.
And it's used by all the other ones, this take those numbers and
it turns them into a one if you are out of bounds in the positive direction,
negative one if you are out of bounds in the negative direction and
zero if you are not out of bounds.
And you can see here that I have on 137 and 142 and
147 this transform.InverseTransformPoint(wordPos).
And what this does is it takes a world position point and
puts it into the local coordinates of this transform to scale the BoxCollider.
And that's what makes it such that, if I'm above 0.5, I'm out of bounds.
So you can look at that yourself,
I wanted to show you this awesome, Vector3 extension method.
So I have a new class called Vector3Extensions.
And you can see that this one does not extend modal behavior,
which is totally fine.
95% of the stuff I do extends modal behavior but this one doesn't.
because there's no need to and it would break it.
So Microsoft has documentation that you can see on line 8 there.
Just follow that and take a look at it to learn about extension methods.
But the basic idea is if you have a static class and
a static method in that static class,
you can then create an extension method for an existing class.
So vector three is an existing class.
I can't touch that code but by creating an extension method, I can create a way for
it to look like I've added methods to vector three, and effectively I have.
So you saw before that I add a Vector3.CcomponentDivide as if
this were part of the vector3 class.
And you do that by saying static public vector3 because it's returning a vector3,
you could have return whatever you want.
But proponent divide is the name of that method and then this vector3V0 means
that instead of passing that in as the first parameter after the parentheses and
ComponentDivide, you actually pass that in at the beginning as a vector and
then dot and ComponentDivide.
And then the first thing you pass in in the parenthesis actually becomes v1 here.
And you can see that I've got the math to divide things.
The yellow underline there is that VisualStudio gets annoyed when you try and
compare two floating point values with just equals or
not equals because it's like floating points are inaccurate.
Well, they are, but for zero, they're pretty accurate, and
they're entirely accurate for zero.
And they're entirely accurate for any integer up to about 16 million,
I think, but they are wholly inaccurate for things like one-tenth,
or one-third, because they have to, they're only accurate for
powers of two, going into fractional things.
So that's factor three extensions.
The last thing that we're looking at, finally, is the off-screen wrapper.
You can see, it is on the player's ship, and
it is also on the bullet prefab, so let's take a look at that script.
And that's the last thing for this video.
Here we are, off screen wrapper.
This is another modal behavior.
And I've added this update method because if there is an update method,
then back in Unity, you get this checkbox here that
sets the enabled value of the game object to true or false.
If there is no update method, then you'll see
that checkbox will go away, as soon as Unity recompiles these scripts.
So and enabled only sets update and other things.
On trigger exit still happens even when enabled is unchecked,
so that's why here on line 21 I say if not enabled, return.
So I'm manually making use of that enabled value, but
I have to have an update method in my ModalBehaviour script in order for
that enabled checkbox to show up.
So here again, pretty straight forward, OnTriggerExit whenever this game object,
or really whenever a collider that is an element of this GameObject exits
the trigger the that could be our ScreenBounds trigger.
It says hey, get the component ScreenBounds on that other collider
that we exited and if it is ScreenBounds, the bounds will not be null.
So if it's null, just return but if it is not null,
then we're going to screen wrap at the bounds.
And here's the ScreenWrap code.
So for ScreenWrap, we figure out the relative location so
we take the BoundsTransform, so this is the transform of the screen bounds.
And we do that InverseTransformPoint like I talked about before.
And we find the relative position of this thing that has just gone off screen
to the screen bounds rect.
And if it is in the x-direction that we've on off screen,
then we just set x to be the negative of x.
If it's the y-direction that we've gone out screen,
then we just set y to be negative of y, and if it's both, we set both.
And that's it, so then we transform that point with Transform.TransformPoint,
we return from relative location to a world point location and
we just set that to our position and that's it.
So that's it for video 8C.
I hope you like the solution and the explanation here and
I look forward to seeing you in the next video.
Thank you.
[MUSIC]
