Strategy Game Camera: Unity'southward New Input Arrangement

/ Jeremy Wolf

I was working on a paradigm for a potential new project and I needed a camera controller. I was also using Unity'due south "new" input system. And I idea, hey, that could exist a good tutorial…

In that location'southward also a written mail on the New Input System. Check the navigation to the right.

The goal here is to build a camera controller that could be used in a broad variety of strategy games. And to do information technology using Unity'south "New" Input Organisation.

The camera controller will include:

  • Horizontal motion

  • Rotation

  • Zoom/drag mechanic

  • Dragging the world with the mouse

  • Moving when the mouse is most the screen edge

Since I'll be using the New Input System, you'll want to be familiar with that before diving likewise deep into this photographic camera controller. Check either the video or the written blog mail.

If you're just hither for the code or want to copy and paste, y'all can get the code along with the Input Action Asset on GitHub.

Build the Rig

Photographic camera rig Hierarchy

The first step to getting the photographic camera working is to build the photographic camera rig. For my purposes, I choose to proceed it simple with an empty base object that will translate and rotate in the horizontal plane plus a child photographic camera object that will motion vertically while also zooming in and out.

I'd too recommend adding in something like a sphere or cube (remove its collider) at the same position as the empty base object. This gives united states an idea of what the camera tin can see and how and where to position the photographic camera object. It's just piece of cake debugging and in one case y'all're happy with the camera you lot tin delete the extra object.

Camera object transform settings

For my setup, my base object is positioned on the origin with no rotation or scaling. I've placed the camera object at (0, eight.3, -8.8) with no rotation (we'll have the camera "wait at" the target in the code).

For your project, you'll want to play with the location to help melody the feel of your camera.

Input Settings

Input Action Asset for the Camera Controller

For the camera controller, I used a mix of events and directly polling inputs. Sometimes one is easier to use than another. For many of these inputs, I defined them in an Input Action Asset. For some mouse events, I just polled the buttons straight. If that doesn't brand sense hopefully it volition.

In the Input Activeness Asset, I created an action map for the camera and three actions - movement, rotate, and elevate. For the movement action I created ii bindings to allow the WASD keys and arrows keys to be used. It'south easy, and so why not? Also important, both rotate and elevate have their activity type set to Vector2.

Importantly the rotate activeness is using the delta of the mouse position non the actual position. This allows for smooth movement and avoids the camera snapping around in a weird way.

We'll be making use of the C# events. So brand sure to save or accept automobile-save enabled. We besides need to generate the C# code. To practise this select the Input Action Asset in your project folders so in the inspector click the "generate C# grade" toggle and printing utilise.

Variables and More than Variables!

Next, we need to create a camera controller script and attach it to the base object of our camera rig. Then inside of a camera controller class nosotros need to create our variables. And at that place'southward a poop ton of them.

The starting time two variables volition be used to cache references for employ with the input organization.

The camera transform variable will cache a reference to the transform with the camera object - as opposed to the empty object that this class volition be attached to.

All of the variables with the BoxGroup attribute will exist used to tune the motility of the camera. Rather than going through them one past i… I'k hoping the name of the group and the proper noun of the variable clarifies their approximate purpose.

The camera settings I'g using

The last four variables are all used to track various values betwixt functions. Meaning i function might change a value and a second role volition brand utilize of that value. None of these need to have their value set outside of the class.

A couple of other bits: Discover that I've besides added the UnityEngine.InputSystem namespace. Also, I'm using Odin Inspector to brand my inspector a bit prettier and proceed it organized. If you don't have Odin, you should, just you lot can just delete or ignore the BoxGroup attributes.

Horizontal Movement

I'm going to effort and build the controller in chunks with each chunk calculation a new mechanic or piece of functionality. This as well (roughly) means you can add or not add together whatsoever of the chunks and the camera controller won't interruption.

The first chunk is horizontal motion. It'due south also the piece that takes the most setup… So bear with me.

Offset, we demand to set upward our Awake, OnEnable, and OnDisable functions.

In the Awake function, we demand to create an instance of our CameraControls input action asset. While nosotros're at information technology we can also grab a reference to the transform of our photographic camera object.

In the OnEnable function, we first demand to make sure our camera is looking in the right direction - we can practice this with the LookAt part directed towards the photographic camera rig base object (the same object the code is attached to).

Then we can save the current position to our concluding position variable - this value will get used to assist create smooth motion.

Side by side, we'll enshroud a reference to our MoveCamera activeness - we'll be direct polling the values for movement. We also demand to phone call Enable on the Camera action map.

In OnDisable we'll call Disable on the photographic camera action map to avoid issues and errors in instance this object or component gets turned off.

Helper functions to go camera relative directions

Next, we need to create two helper functions. These will render camera relative directions. In particular, we'll be getting the frontward and correct directions. These are all we'll need since the camera rig base will only move in the horizontal plane, we'll as well squash the y value of these vectors to zero for the aforementioned reason.

Kind of yucky. But gets the job done.

Admittedly I don't love the next function. It feels a fleck clumsy, simply since I'm not using a rigidbody and I want the camera to smoothly speed up and slow down I need a way to calculate and track the velocity (in the horizontal plane). So thus the Update Velocity function.

Aught also special in the role other than over again squashing the y dimension of the velocity to naught. After calculating the velocity we update the value of the last position for the adjacent frame. This ensures we are computing the velocity for the frame and non from the start.

The next function is the poorly named Go Keyboard Movement role. This function polls the Camera Movement action to then prepare the target position.

In order to translate the input into the movement we want we need to be a flake careful. We'll take the x component of the input and multiply it past the Camera Right function and add that to the y component of the input multiplied by the Camera Forward function. This ensures that the movement is in the horizontal plane and relative to the photographic camera.

We and so normalize the resulting vector to go along a compatible length so that the speed will be constant even if multiple keys are pressed (up and correct for example).

The concluding pace is to check if the input value's square magnitude is above a threshold, if it is we add our input value to our target position.

Note that we are Not moving the object here since eventually at that place will be multiple ways to motility the camera base, we are instead adding the input to a target position vector and our NEXT function volition use this target position to actually move the camera base of operations.

If we were okay with herky-jerky motility the next role would be much simpler. If we were using the physics engine (rigidbody) to move the camera it would also be simpler. Only I want smooth motility AND I don't want to tune a rigidbody. So to create smoothen ramping up and down of speed we demand to do some piece of work. This work will all happen in the Update Base Position function.

Get-go, we'll check if the square magnitude of the target position is greater than a threshold value. If it is this means the player is trying to get the camera to movement. If that'due south the instance nosotros'll lerp our current speed upwardly to the max speed. Notation that we're also multiplying Time Delta Time by our acceleration. The acceleration allows us to melody how speedily our camera gets up to speed.

The use of the threshold value is for ii reasons. I so we aren't comparing a bladder to zero, i.east. request if a float equals nil tin exist problematic. 2, if we were using a game controller joystick even if it's at rest the input value may non be null.

Testing the Code then far - Smoothen Horizontal Motion

Nosotros so add to the transform'south position an corporeality equal to the target position multiplied by the current camera speed and time delta time.

While they might expect unlike these 2 lines of code are closely related to the Kinematic equations you may have learned in loftier school physics.

If the actor is not trying to go the camera to move we want the camera to smoothly come to a stop. To do this we want to lerp our horizontal velocity (calculated constantly by the previous function) downwards to zero. Note rather than using our acceleration to control the rate of the tiresome down, I've used a dissimilar variable (damping) to allow separate command.

With the horizontal velocity lerping information technology's style towards null, we then add to the transform's position a value equal to the horizontal velocity multiplied past time delta time.

The final step is to set the target position to zero to reset for the next frame's input.

Our concluding step before we can test our code is to add together our last 3 functions into the update part.

Camera Rotation

Okay. The hardest parts are over. Now we can add functionality reasonably rapidly!

And so allow's add the ability to rotate the camera. The rotation will be based on the delta or alter in the mouse position and will just occur when the center mouse button is pressed.

Nosotros'll be using an event to trigger our rotation, so our first addition to our code is in our OnEnable and OnDisable functions. Here we'll subscribe and unsubscribe the (before long to exist created) Rotate Photographic camera role to the performed event for the rotate camera activity.

If you're new to the input arrangement, you'll notice that the Rotate Photographic camera function takes in a Callback Context object. This contains all the information almost the action.

Rotating the photographic camera should now be a matter!

Inside the role, nosotros'll beginning check if the middle mouse button is pressed. This ensures that the rotation doesn't occur constantly but only when the button is pressed. For readability more than functionality, nosotros'll store the x value of the mouse delta and use it in the side by side line of code.

The terminal piece is to set the rotation of the transform (base object) and only on the y-axis. This is done using the x value of the mouse delta multiplied by the max rotation speed all added to the current y rotation.

And that's it. With the event getting invoked there'due south no need to add the function to our update function. Nice and like shooting fish in a barrel.

Vertical Photographic camera Motion

With horizontal and rotational move working it would be nice to move the camera upward and down to let the player run across more or less of the globe. For controlling the "zooming" nosotros'll be using the mouse scroll wheel.

This motion, I institute to be 1 of the more complicated as there were several $.25 I wanted to include. I wanted there to be a min and max height for the camera - this keeps the player from zooming also far out or zooming down to pettiness - also while going up and down information technology feels a bit more natural if the photographic camera gets closer or farther away from what it's looking at.

This zoom motion is some other good use of events then we need need to make a couple of additions to the OnEnable and OnDisable. Merely like we did with the rotation we need to subscribe and unsubscribe to the performed event for the zoom photographic camera activeness. Nosotros also need to fix the value of zoom peak equal to the local y position of the photographic camera - this gives an initial value and prevents the camera from doing wacky things.

Then within the Zoom Camera function, nosotros'll cache a reference to the y component of the curl wheel input and carve up by 100 - this scales the value to something more useful (in my stance).

If the absolute value of the input value is greater than a threshold, meaning the actor has moved the coil wheel, nosotros'll gear up the zoom height to the local y position plus the input value multiplied past the step size. We then compare the predicted peak to the min and max elevation. If the target height is outside of the allowed limits we set our height to the min or max height respectively.

Again this function isn't doing the bodily moving information technology'south just setting a target of sorts. The Update Camera Position function volition do the actual moving of the camera.

The get-go pace to move the camera is to use the value of the zoom height variable to create a Vector3 target for the camera to move towards.

Zooming in activity

The next line is admittedly a bit confusing and is my endeavor to create a zoom frontward/backward movement while going up and downward. Here nosotros decrease a vector from our target location. The subtracted vector is a product of our zoom speed and the difference between the current summit and the target height All of which is multiplied by the vector (0, 0, 1). This creates a vector proportional to how much we are moving vertically, just in the camera's local forward/backward direction.

Our final steps are to lerp the camera's position from its electric current position to the target location. We use our zoom damping variable to control the speed of the lerp.

Finally, nosotros as well have the camera look at the base to ensure we are however looking in the correct management.

Earlier our zoom volition work we need to add both functions to our update function.

If you are having weird zooming beliefs information technology'due south worth double-checking the initial position of the photographic camera object. My values are shown at the top of the page. In my testing if the ten position is not zero, some odd twisting motion occurs.

Mouse at Screen Edges

At this signal, we have a pretty functional camera, simply there's notwithstanding a bit more polish we can add. Many games permit the player to move the camera when the mouse is nigh the edges of the screen. Personally, I like this when playing games, but I do notice information technology frustrating when working in Unity as the "screen edges" are defined by the game view…

To create this motility with the mouse all we need to practise is check if the mouse is near the edge of the screen.

We practise this by using Mouse.current.position.ReadValue(). This is very similar to the "erstwhile" input system where nosotros could just call Input.MousePosition.

We also need a vector to rails the motion that should occur - this allows the mouse to be in the corner and accept the camera move in a diagonal direction.

Screen edge motion

Next, we simply check if the mouse x and y positions are less than or bully than threshold values. The border tolerance variable allows fine tuning of how close to the border the cursor needs to be - in my case I'm using 0.05.

The mouse position is given to us in pixels not in screenspace coordinates so information technology'southward important that we multiply by the screen width and acme respectively. Detect that we are again making utilise of the GetCameraRight and GetCameraForward functions.

The last step inside the function is to add together our move direction vector to the target position.

Since we are non using events this function too needs to get added to our update function.

Dragging the World

I stole and adjusted the drag functionality from Game Dev Guide.

The last slice of smoothen I'm adding is the ability to click and drag the world. This makes for very fast motion and mostly feels skilful. However, a note of caution when implementing this. Since we are using a mouse push button to drag this can quickly interfere with other player deportment such equally placing units or buildings. For this reason, I've chosen to use the correct mouse push button for dragging. If y'all want to use the left mouse button you lot'll demand to check if you Tin can or SHOULD drag - i.east. are you placing an object or doing something else with your left mouse button. In the past I have used a drag handler… and so maybe that'due south a better route, but information technology'southward non the management I choose to go at this point.

I should too admit that I stole and adapted much of the dragging code from a Game Dev Guide video which used the old input system.

Since dragging is an every frame type of thing, I'one thousand once again going to directly poll to decide whether the right mouse push is downwardly and to go the current position of the mouse…

This could probably be downwardly with events, just that seems contrived and I'm not certain I really see the benefit. Mayhap I'm incorrect.

Within the Elevate Camera part, we tin outset check if the right push button is pressed. If information technology's non we don't want to go any farther.

If the push button is pressed, we're going to create a airplane (I learned almost this in the Game Dev Guide video) and a ray from the camera to the mouse cursor. The plane is aligned with the world XZ plane and is facing upward. When creating the plane the first parameter defines the normal and the second defines a indicate on the plane - which for the not-math nerds is all you need.

Next, we'll raycast to the plane. Then cool. I totally didn't know this was a matter!

The out variable of distance tells us how far the ray went before information technology striking the plane, assuming it hit the plane. If information technology did hit the airplane nosotros're going to do ii different things - depending on whether we just started dragging or if nosotros are continuing to drag.

Dragging the world

If the right mouse button was pressed this frame (learned about this thanks to a YouTube annotate) we'll cache the bespeak on the aeroplane that we hit. And we get that point, by using the Go Indicate function on our ray.

If the correct mouse push button wasn't pressed this frame, pregnant we are actively dragging, we can update the target position variable with the vector from where dragging started to where it currently is.

The concluding step is to add together the drag function to our update part.

That's It!

There you go. The basics of a strategy camera for Unity using the New Input Arrangement. Hopefully, this gives you a jumping off betoken to refine and maybe add features to your own camera controller.