{"id":102,"date":"2022-06-08T19:31:12","date_gmt":"2022-06-08T23:31:12","guid":{"rendered":"https:\/\/courses.ideate.cmu.edu\/53-353\/m2022\/?p=102"},"modified":"2022-06-08T19:31:12","modified_gmt":"2022-06-08T23:31:12","slug":"day-17-camera-control-triggers","status":"publish","type":"post","link":"https:\/\/courses.ideate.cmu.edu\/53-353\/m2022\/?p=102","title":{"rendered":"Day 17: Camera Control & Triggers"},"content":{"rendered":"\n
Today we continued to develop our platform game by making our camera smoothly follow the player throughout the environment, implementing our ruleset for how the player can move through the environment (forward only, please!) and finally we added an enemy controller and gave it a patrolling “behavior” through the use of triggers (a special variation of colliders).<\/p>\n\n\n\n\n\n\n\n
Part 1: Camera Control<\/h2>\n\n\n\n
Now we have created a player object and let him run through our level, but very quickly the player runs out of view. There are a number of ways to address this. The simplest way to let the camera follow our player is to make the camera a child<\/em> of the player object. This way, any movement of the player was automatically reflected in the camera. The end result is that the player remains perfectly still as the rest of the world moves around it.<\/p>\n\n\n\n
This solution is OK, but does not really fit what we are going for. This should be a side scroller, meaning we move our camera to the side, and so we need a better solution.<\/p>\n\n\n\n
Our first step is to move the camera horizontally with the player, but not vertically. We accomplish this by placing a script on the Camera object that would mirror the X value of the player object, like so:<\/p>\n\n\n\n
IMPORTANT NOTE:<\/strong> Although our game is 2D, our transforms are still very much 3D. This means when working with position, we always need to use Vector3 rather than Vector2 structures.<\/p>\n\n\n\n
We set a public game object and assign the Player object to it in the Inspector.\u00a0 Then on each frame, we find the X position and match it.\u00a0 The result was just OK. The side motion worked but things feel a little jittery.\u00a0 We want to give our player a little room to move away from the center and have the camera catch up, as though it were controlled by some camera person trying to keep up with the action.\u00a0 To facilitate that, we used Mathf.SmoothDamp( )<\/strong>, a dampening function to create a gentle curve to the updating X values, giving the camera an eased, elastic feel.<\/p>\n\n\n\n
public GameObject player;\nprivate float xVelocity = 0.0f;\n\/\/ Update is called once per frame\nvoid Update () {\n Vector3 playerposition = player.transform.position;\n Vector3 cameraposition = transform.position;\n \n cameraposition.x = Mathf.SmoothDamp (cameraposition.x, playerposition.x, ref xVelocity, 0.5f);\n transform.position = cameraposition;\n}<\/pre>\n\n\n\n
SmoothDamp ( ) is part of the float math libraries, and takes 4 parameters \u2013 the start value, the end value, the current velocity (as a reference), and the time the smoothing should occur. Velocity here is tricky, as SmoothDamp ( ) will modify it each time it runs. In order to let that persist, we pass the velocity variable as a \u201cref\u201d, which is the closest we will get to pointers in this class. Normally when we call a method we say \u201chere is a value\u201d but in this case by declaring \u201cref\u201d we say \u201chere is access to the variable itself\u201d. SmoothDamp ( ) will update velocity each time it runs.<\/p>\n\n\n\n
Playing this again, this is getting better. My player runs away and the camera catches up again. Since I\u2019ve decided to use \u201cMario\u201d rules, I want to make sure that the player can only advance, not move backwards. I\u2019ll do that by defining two rules.<\/p>\n\n\n\n
Rule #1: <\/strong>Any time the player moves right of the midpoint on the screen, the camera will follow. Rule #2: <\/strong>The player can only move as far left as is currently visible on the screen.<\/p><\/blockquote>\n\n\n\n
Rule #1 is easy enough to implement.\u00a0 To do this, we set a condition around the SmoothDamp and transform position update that test to see if playerposition.x is greater than cameraposition.x and if so, it will let the camera follow.<\/p>\n\n\n\n
public GameObject player;\n\/\/ ref value for smoothDamp\nprivate float xVelocity = 0.0f;\n\/\/ Update is called once per frame\nvoid Update()\n{\n \/\/ match the player x position\n Vector3 playerposition = player.transform.position;\n Vector3 cameraposition = transform.position;\n if (playerposition.x > cameraposition.x) { \n \/\/ cameraposition.x = playerposition.x;\n cameraposition.x = Mathf.SmoothDamp(cameraposition.x, playerposition.x, ref xVelocity, 0.5f);\n transform.position = cameraposition;\n }\n}<\/pre>\n\n\n\n
Rule #2 is a little trickier, as we don\u2019t really know where the left edge is. We could do all kinds of math to figure this out, casting rays and such, but we are going to do this the lazy way.<\/p>\n\n\n\n
OPTION 1: (the complicated way) <\/strong> In a previous semester, we included a value called \u201cleftSideOffset<\/strong>\u201d that held the distance in x units that corresponded with the left edge of the screen from the center of the camera. Since the camera is always the same z-distance from the player, this number can be a constant. In our update loop, we then check the offset as a bounding x-value for the player, with the following code: <\/em><\/p>\n\n\n\n
OPTION 2: (the cheap way) <\/strong>For this class, I have implemented a much more rudimentary system. I create an object and assign it a BoxCollider 2D<\/strong>. I size this to span beyond the vertical length of my camera view, and move it to the very left of the camera. Finally, I make this object a child of the Main Camera, meaning that it will follow along wherever our camera goes. This prevents our player from being able to run beyond the edge of the screen. (Once we place enemy objects, you will want to adjust your Collision Matrix in the Physics 2D<\/strong> panel in your Project Settings<\/strong>, just like we did with our 3D collisions in Astral Attackers, so that your non-player objects can pass through unimpeded.)<\/p>\n\n\n
\nThat box on the left means there’s only one way you can go.<\/figcaption><\/figure><\/div>\n\n\n
Part 6 – Enemies and Triggers<\/h3>\n\n\n\n
Now that we\u2019re moving and jumping, let\u2019s create some enemy objects to interact with. We won\u2019t worry about colliding with them right now, but let\u2019s at least get them in the scene and behaving the way we expect them to behave (patrolling their platforms)!<\/p>\n\n\n\n
We created an object similar to our player but with our Enemy sprite. We added CharacterController2D, Circle Collider 2D, and Rigidbody 2D component to it, and gave it a simplified version of our script to automate its movement. We use a simple boolean<\/strong> in our script called “FaceLeft” which will indicate if our enemy is facing left or right, and uses that value to pass that direction into the CC2D move command.<\/p>\n\n\n\n
To create behaviors, we will use Triggers<\/strong> to give our Enemy the illusion of intelligently patrolling its platform. Triggers are a variation of colliders that don’t actually collide – they simply define a volume, and that volume will create a collison-like event when another object’s collider enters it.<\/p>\n\n\n\n
For our purposes, we are going to create a “turn around” box – a cube volume that our enemy will enter, register, and react by reversing direction. First, create an empty object, add a Box Collider 2D, and check the Is Trigger<\/strong> box. Create a tag called “TurnAround” and assign it to this box. Make this object a prefab so that we can place them throughout the level. Then we add this to the Enemy script:<\/p>\n\n\n\n
private void OnTriggerEnter2D(Collider2D collision)\n{\n if (collision.gameObject.tag == \"TurnAround\")\n {\n Debug.Log(\"Hit the Collider\");\n faceLeft = !faceLeft;\n }\n \n}<\/pre>\n\n\n\n
Once the Enemy object enters the trigger object, it checks for the \u201cTurnAround\u201d tag, and if it finds one, it will invert the \u201cfaceLeft\u201d value of the Enemy causing him to walk in the other direction. This will only fire when the enemy first enters the volume as OnTriggerEnter2D<\/strong> only occurs at the first point of overlap. You can use OnTriggerExit2D<\/strong> to register when the overlap has ended, or OnTriggerStay2D<\/strong> to confirm that an overlap is ongoing.<\/p>\n\n\n\n
NOTE: <\/strong>Trigger’s use the OnTrigger<\/strong> commands, as opposed to the OnCollision<\/strong> commands. Unity treats these differently, so they will only apply to the corresponding setting for isTrigger<\/strong>. Also, because this is 2D physics, note the 2D<\/strong> designation at the end of each of these. OnCollisionEnter<\/strong> and OnCollisionEnter2D<\/strong> use different physics systems and are not interchangeable, so if your collisions are not registering, check that you are using the proper command.<\/p>\n\n\n\n
Part 7: Pixel Perfect Camera<\/h2>\n\n\n\n
When working with pixel art, you may notice some tearing or flickering lines in your game. This is often due to the slight artifacts created by the camera sampling the artwork at an incorrect distance. Thankfully, Unity includes a package to help correct for this – the 2D Pixel Perfect Camera<\/strong>. Rather than run through all of the features here, check out the Unity Manual which does an excellent job breaking down exactly how this works.<\/p>\n\n\n\n
![\"\"](\"https:\/\/courses.ideate.cmu.edu\/53-353\/f2020\/wp-content\/uploads\/2020\/11\/image-22.png\")