Now that I have time – for a missile, I think the trick is to make it move really, really fast. Seeking should be more “perfect” the faster the seeking object moves. It’s natural for it to miss when going too slowly, in fact, it’s a feature in a lot of games.
As for the turret, well, it’s way easier with pictures.
Let’s have a cannon facing down the Y axis:
The plane behind it is our “ship”.
Now let’s move it 90 degrees around the “Y-axis”
As you can see, nothing happens. It’s still perpendicular to the ship. (Okay, it moved a little, but that’s because I didn’t have it snapped to the Y-axis properly, in principle it won’t move).
Now we’ll rotate it about the X-axis:
Everything is as expected. Now let’s do it about the Z-axis:
It works normally. These two rotations don’t affect each other. In fact, I did the rotation again in Blender and made a picture, but it didn’t look any different so I scrapped it.
What have we learned from this? If your cannon is facing down a given axis, the rotation is simple: keep track of its rotations in the two other axes and clamp them, individually, to 90 and -90 degrees. If you use Euler angles this is equivalent to (pseudocode):
// Where z and x are some input angles you want to clamp
zAngle = clamp(-90,90, z);
xAngle = clamp(-90,90,x);
myRotation = Quaternion.Euler(0,0,zAngle) * Quaternion.Euler(xAngle, 0, 0);
Apologies if this isn’t perfect Unity, I don’t use Unity, but I think those are the functions it uses. Except clamp, which is just the function:
float Clamp(min float, max float, input float) {
if (input < min) {
return min;
} else if (input > max) {
return max;
} else {
return input;
}
}
Remember, it doesn’t matter which order the x and z rotations are in for this example.
Now for the second type of cannon you might mean, what I would call the “turret cannon”.
This is the type of cannon you’d see on towers, where it’s a “swivel” sort of cannon, where the turret swivels around and then you adjust the exact firing angle for range.
Let’s say we want to fire 45 degrees (max distance), swiveled to 90 degrees to the right of where we’re currently shooting.
Well, let’s swivel the dome first:
So far so good. Now let’s rotate the cannon be 90 degrees along the z-axis and then do the x rotation!
Succe… er… oops. Remember, rotating along the axis the cannon is already pointing towards does nothing. This introduces us to a nice fact: Euler angles are order dependent. However, in the first example, it didn’t matter due to mathy properties we don’t need to get into.
Let’s rotate the other way around, 45 degrees about x, THEN 90 degrees about y:
Success!
In this case, we only need to clamp rotation in one direction: the x direction. We just have to make sure to compose our rotation in the right order.
zRotation = Quaternion.Euler(0,0,zAngle);
domeRotation = zRotation;
xAngle = clamp(x);
xRotation = Quaternion.Euler(xAngle,0,0);
cannon.Rotation = zRotation * xRotation;
There is one tricky part here: didn’t I say to do x first? Well, vector math is a bit silly, the thing on the righthand-most side is applied first. So x is done first in this example, despite it intuitively being opposite.
Now you might say “that’s great, but this cannon is part of my ship, how do I get it there? Right now it’s just at some central axis, not very helpful” The answer is: the steps above work fine. Just do them FIRST. You may or may not have heard about the “model view projection” (or MVP) model. In this model, you move everything into the world, then transform it with respect to the camera, then warp it so it looks right. Unity will take care of the V and P part for you, so you’re only worrying about M.
Normally, M is just one thing “I have a ship with some heading at some location” and you simply rotate and translate accordingly. However, if we introduce something called a scenegraph we can make everything really simple.
The idea is that we split the “model” into several steps: the object transformation, the “owner” transformation, and then the world (“model”) transformation.
The object transformation is what we did above. We’ll call this objectTransform. The owner transform is what we do to get it to the right place as if the model was at 0,0 facing its default direction. So if you were at the ship’s center, the cannon was rotated 90 degrees around the z axis and at the coordinates (5,5,0), the owner transform would be:
rotation = Quaternion.Euler(0,0,90);
translation = Translate(5,5,0); // Don't know what the unity for a translation matrix is
cannon.Position = translation * cannon.Position;
cannon.Rotation = rotation * cannon.Rotation;
That’s it!
Now what about the model transform? That’s just whatever you were already doing for the “owner”. If the ship is at (0,12,15), and facing at 30 degrees in the Y direction;
translation = Translate(0,12,15);
rotation = Quaternion.Euler(0,30,0);
cannon.Position = translation * cannon.Position;
cannon.Rotation = rotation * cannon.Rotation;
Which is exactly identical to the above! 
In fact, with this sort of hierarchy, you can model an arbitrary number of ownership properties. Want that ship docked in a moving carrier? Transform the cannon with the ship and the ship with the carrier. Want that carrier orbiting a planet? Then transform that mess with the planet. Just do it in order. In fact, the design is harder than the math. Figuring out exactly which component or object to apply this intermediate transformations from is much harder than the transformations themselves, but that’s ultimately up to whatever is most comfortable for you.
I hope that helped, I’m happy to clarify anything.
The thing is, when you implement it as is in Unity, you get a horrible jittery camera I don’t know why. My guess is frame rates (since on the SNES presumably frame rates were locked) but I don’t know…
or not… cause then it would be work and not fun.