Setting Up

With your default scene open, let’s set a few things up before we get rolling on the code.

Create a Plane. Name it Stage. This is the floor. Keep its position set to (0, 0, 0) and set its scale to (7, 1, 20). There. We’ve designed our level, and it only took us mere seconds. We sure are talented.

Now let’s set up the camera. The camera that comes with the scene by default will work. We’ll rename it to “Player Camera.” We’ll have it positioned over the level, pointing down at it with a slight upward angle so it’s not pointing straight down. A Y position of 54 by default will work just fine. We’ll use an X rotation of 70. A rotation of 90 will point straight down, so we just skew it 20 degrees off to give it that little tilt we want.

Those default settings will work for us, but we’ll have them exposed in the Inspector in case we want to change them at some point. Save the changes to the script, go to the script component on the camera GameObject, and set that Transform reference to the Transform of the same GameObject. Remember, that’s just a slightly faster means of referencing our own Transform, as opposed to using the “.transform” member that all scripts have. We’d more than likely be fine if we didn’t do this, but it’s a good habit to get used to.

We’ll start by defining the methods we’ll be calling to make things work. We’ll use Start and Update, and we’ll have some private methods that are called in Update. Just like with our Player in the first project, we’ll be doing this simply to split the code up into neat blocks, keeping things clean and neatly separated.

Arrow Key Movement

To implement the arrow key movement, we’ll write a simpler take on the code we wrote for the player movement of our first project. We use the Input.GetKey method to check if a key is pressed and apply movement directly to the targetPosition if it is.

First, we need to declare some variables. We still don’t have a targetPosition variable, after all. While we’re at it, we’ll declare a variable for the sensitivity of mouse drag movement, which will come into play a bit later, as well as a variable for the amount of smoothing applied to the camera movement.

The tooltips pretty much explain the variables. We’re using a new attribute, Range, for our movementSmoothing variable. This attribute is used to make sure a number variable is clamped between certain values in the Inspector. It also adds a handy little slider control to the variable in the Inspector to make setting it easier. We use it to make sure the smoothing is clamped between 0 and .99f. The smoothing variable will be used when we Lerp the camera toward the target position. It’s the third parameter in the Lerp call – the fraction. We’ll use all that stuff later, though – and we’ll talk about why we want the maximum value to be .99f instead of 1.

This makes it so that whatever position we place the Player Camera at in the scene is the position it will start at.

That’ll do it. The targetPosition will have the arrow key movement applied to it, using arrowKeySpeed multiplied by Time.deltaTime to ensure it’s “per second” instead of “per frame.”

The movement won’t actually apply yet, though. Let’s remedy that so we can test our features as we implement them.

Applying Movement

To apply the movement, we’ll simply clamp each axis of our target position (X, Y, and Z) between the minimum and maximum values and then Lerp the camera position toward the target position.

We set each axis of our targetPosition vector individually, calling Mathf.Clamp for each one. This results in three pretty repetitive lines of code, the only difference in each one being the axis we refer to throughout: the letter X, Y, or Z. When you type this out, make sure you’re getting it right – don’t copy-paste and change only some of the Xs into Ys or Zs. That can cause some pretty confusing behavior!

Moving on, the movement is only applied if the camera (trans.position) is not (!=) already where it needs to be (targetPosition). When moving, we set the position to the result of our Lerp call. That call will move the camera toward the target position.

You’ll notice the fraction we pass in as our third parameter in the Lerp call isn’t just the movementSmoothing variable given as is. Rather, we give it “1 – movementSmoothing”.

This is just so the variable makes more sense when you read its name and decide what value to give it. You would expect it to be smoother if the value is higher, right? A maximum movementSmoothing value should be the smoothest, while a minimum value should be the least smooth. If we gave the fraction as is, it would be quite the opposite. Remember, this fraction given to the Lerp call is “How much of the distance between the two positions will we move?” If it’s a higher value, we move more. That means the camera will be snappy, getting where it’s going more quickly. A value of 1 will simply apply no smoothing at all. A low value like .05f will move much less per frame and, thus, the smoothing will be more noticeable.

By doing “1 – movementSmoothing”, we ensure that, if the smoothing is something like .8f, we get 1 – .8f. That’s .2f – a low value, resulting in more smoothing. In other words, we’re pretty much “flipping” the value around when we pass it to the Lerp call.

At this point, you can probably see why our Range attribute was set to keep the smoothing value at a maximum of .99f instead of 1. If the smoothing were allowed to be 1, then we would simply be giving “1 – 1” as the fraction, resulting in 0. This would mean the camera would never move at all! By giving it a maximum value of .99f, we ensure that we never accidentally break the movement that way. If you can predict some situation where your code keels over and breaks, you should probably not trust yourself to remember that it’s possible and avoid it in the future – because you probably won’t remember it. And then some months later, you’ll break it. And then you’ll spend two hours and a few pulled-out tufts of hair trying to figure out what went wrong. And kick yourself when you realize what caused the problem.

Anyway, you should now be able to test our arrow key movement in-game. Try playing with the smoothing value through the Inspector and note the difference when it’s lower or higher. A very high value makes the movement very slow and slippery, while a very low value makes it snappy at the risk of being somewhat unpleasantly jarring. I’ve set the default value to .75f because I feel it’s a comfortable middle ground – not so smooth that it’s clunky, but still smooth enough to notice it.

Mouse Dragging

Let’s get a move on. The next step is implementing camera movement.

This will return true while the right mouse button is held down and false while it is not.

We then declare a local Vector3 named movement. We use another new Input method here: GetAxis. This is a more general means of reading input, where you provide a string as the means of identifying which kind of input you’re after. In our case, we use “Mouse X” and “Mouse Y.” These return what we call the “delta” for the mouse position, which means “how much it’s moved from its last position.” For example, if the user didn’t move the mouse left or right on this frame, Mouse X returns 0. If they did, it returns some fraction representing how much they moved the mouse.

If we apply it directly to the target position movement, we get an awkward result where the camera movement follows the direction of the mouse cursor. That’s opposite to how you normally expect it to work when you drag your camera around in games like this. It sort of goes against the idea of “dragging.”

That’s why we have the “–” sign before each Input.GetAxis call. It flips the returned values around: if the delta was positive, it becomes negative, and vice versa. In other words, if the mouse cursor moves right, the camera moves left, and so on for the other directions. If you don’t get this, take those “–” symbols out and try it yourself. You’ll probably feel all sorts of wrong trying to move your camera with the mouse.

The Vector3 we create is also correctly mapping the mouse axes to the actual 3D direction we want to move our camera. Remember, we’re operating on world direction here, not a direction local to the camera. The Mouse Y isn’t actually “up and down” in-game, since the camera is pointing down. To go “up” from the perspective of the camera, we really need to go forward in world directions. Thus, the mouse Y movement needs to correspond to the Z axis when we move the camera, so we provide it as the Z axis when we create the vector, and we leave the Y axis at 0 so that no movement occurs there.

After the vector is created, we multiply it by our mouseDragSensitivity variable, giving us an easy way to adjust the amount of movement the mouse generates for the camera. Since it’s tied to a variable like this, we could later implement a way for the player to set this themselves, such as through an options menu in-game.

After this, all that’s left to do is apply the movement to targetPosition, assuming there was any movement.

That’s all we need to make this feature work. You can test it out if you like. Note how changing the sensitivity variable affects the movement.

Zooming

To implement the zooming, we need to detect mouse scrolling. We can do this with a new member of Input by the name of mouseScrollDelta. This is a Vector2, which is just like a Vector3 except that it only has X and Y axes – no Z. The X axis corresponds to the mouse wheel being pressed left or right, which some mice support (but not all of them). It’ll be –1 if the wheel was ticked left or 1 if the wheel was ticked right. But we don’t need that function. The Y axis is what we’re after: it measures how much the wheel has been scrolled up (positive) or down (negative) this frame.

Like with the mouse dragging, that value doesn’t correspond to the movement we want. We want to go down toward the stage whenever the mouse wheel is scrolled up, which means we need to decrease our Y position. We want to go up when the wheel is scrolled down, increasing our Y position. The way it is by default, we’ll do the opposite. Again, we can just fix this by inverting, or “flipping,” the Y value with a “–” sign.

As is usually the case with operator stuff, we could accomplish the same “flipping” effect if we subtracted from the Y axis, changing that “+=” into a “-=”. It doesn’t really make a difference how we do it, just so long as we make sure it gets done!

With that in place, we now have all of our movement options up and running: arrow keys, right-click mouse dragging, and scroll wheel to zoom in and out. It’s all clamped with our bounds variables, keeping the player within view of the stage at all times, and we use some configurable smoothing to add that feeling of luxury.

Summary

With that out of the way, we can focus on the core mechanics of towers, projectiles, and enemies in our next chapter.