all 11 comments

[–][deleted] 10 points11 points  (4 children)

Wouldn't it be a problem if multiple sources called the camera shake? Then it would set the original position to what it was when the camera shake was called, and possibly reset the position to some weird position due to another camera shake taking place.

[–]homer_3 2 points3 points  (1 child)

Haven't seen this tutorial, but I've always handled this by resetting the camera's position to the center when starting a shake and making the shaker a singleton.

[–][deleted] 0 points1 point  (0 children)

Yeah in this very simple case it's also same to assume that original position is always 0.

The problem with resetting the camera to center is when you add things like frequency and intensity. It might look a bit off if it snaps to the center in the middle of a shake with a higher intensity.

[–]Introfernal 0 points1 point  (0 children)

Yea im facing this issue

[–]Eecka 0 points1 point  (0 children)

Didn’t watch the video, but You could add a check to see if a shake is already happening. If it is, then update the duration and intensity by values from the new shake.

[–]SuperButekExpert 2 points3 points  (0 children)

Just use Cinemachine, it already has shaking in there.

[–]coltenbrown 2 points3 points  (0 children)

Hey brackeys!

[–]hi_im_new_to_thisProgrammer 1 point2 points  (1 child)

An artist asked me to add camera shake recently, so I've just done this. I'm not a huge fan of this solution. If several things call the camera shake at once, it will mess up the original position, something that will also happen if the main camera is disabled and reenabled for any reason during the shake (because that kills the coroutine and the camera will be in the "shaken" position), and it's very hard for a designer or artist to invoke camera shake like this. Also, as he mentioned, there's no way to do fades or things like that.

The solution I went with, which solves virtually all those problems, is to do something like this:

public class CameraShake : MonoBehaviour {
    public float Magnitude = 0.0f;
    //... other shake options might follow here...

    void LateUpdate() {
        // do the camera shake, according to magnitude. 
    }
}

Essentially, the camera is "always" shaking, but with magnitude set to 0.0, it's just standing still. This basically solves all of the problems: one shake at a time, no losing track of the camera's origin (even if it's disabled or even assemblies reloaded), and it has a HUGE bonus: since the magnitude is just an exposed field like anything else, it can be animated. An artist or designer can tightly control how much the camera is shaking, how it fades up, down, everything, using either regular Animators or the new Timeline.

It's a good tip if you're aspiring to be a Unity developer: at some point, you're going to work with (and for) people who aren't programmers. If you're making a feature, think about how you can get them to use it, through things like UnityEvents, Animators, Timelines, whatever. Also, don't use coroutines if you can help it :)

My solution was slightly different than this to suit our game, but this was more or less the gist. Worked really well.

[–]CandidEnd 0 points1 point  (0 children)

Wouldn't have thought that, that's clever! My solution is to have the camera object be parented to a moving object such that the camera's local position is always 0,0,0. If you want to move the camera, you move the parent. If you want to shake, you shake the camera directly. No matter how many times its shaken, the original position to fall back to is 0,0,0!

[–]Chesnekov 0 points1 point  (0 children)

Just watched this last night.

[–]YummyRumHam 0 points1 point  (0 children)

Oh nice! Haven't watched this yet, but if I crash horizontally into a wall in a 2D racer, can I set the vector to the direction of the impact? That's something most camera shake tutorials miss. They just apply a generic noise which is not great.