You know why my aim is so rubbish in all those demo videos I’ve been posting of my game? Subtlties of cursor-following rotation and dual wielding, that’s what.
A bad workman always blames his tools, yes, but I programmed this… so I have the right to complain — and the right to fix it.
The Vagaries of Control
So my central control system is that, as in Nox, the player character is always rotated to face the mouse cursor. Clicking the left button uses the primary attack, while holding the right causes the character to walk towards the cursor. It’s the top-down system I always coveted but could not create for myself in Warcraft III.
It seems simple enough; take the position of the cursor and rotate towards it, right?
It begins with a deal old Ray, a line drawn from the cursor’s positon on screen and into the 3D game world. We don’t just let it go wild, though — we conjure up a plane for it to intersect with, a plane level with the character’s feet. The point where the ray cast into the world hits that plane is a world point that we will face.
It all looked fine at first. The character did, indeed, appear to rotate towards the cursor. However, a creeping sense of something wrong soon emerged. My primary mechanic is attack, of shooting and slashing. You might have noticed that my Delta’s cannons do not, in fact, reside at its feet. Any aiming, therefore, would be off by some degree depending on how far away the cursor was from the character, and what angle it was at.
The solution was easy — shift the plane up to cannon height and we now definitely look and shoot at the cursor. Huzzah!
General aim was not the only issue with my mouse control, though.
Nox allows characters to both walk and run. Holding the mouse further from the centre of the screen means running; holding it close means walking. It’s a nice little feature, and you might have noticed in the earlier videos that I have also had this working for a while. (Even more recently, I added a different run animation.)
However, when you’re dealing with screen coordinates, you might be generally aware that most screens aren’t square. When trying to normalise my coordinates to a number between 0 and 1 (actually 0.5 because I suck at maths) that indicates distance from the centre of the screen, you actually had to move the cursor further to the sides than to the top to engage running.
That’s no good, of course, and it took me a while to realise that was why my run/walk boundary felt so awkward: I wasn’t measuring on a circle, I was measuring on an oval.
The solution is simple enough — normalise the distance against a square with sides the size of the shortest dimension, rather than the raw width and height. In most cases, that’ll be the height of the monitor (though I remain adaptable for those crazy portrait screen people). Thus the mechanism is based on a circle that fits the middle of the screen rather than a wonky oval.
The final vagary is one that is, alas completely self-inflicted rather than stemming from a lack of experience.
You might have noticed that my test unit, the basic Delta mech, has two cannons. To scale, they’re roughly… two metres apart. Not so far that it’s impossible to get both shells to hit another Delta, but far enough that it’s a little bit annoying. That’s an annoyance I’m not sure I’ll be comfortable with when I finally get around to adding ammunition… and smaller enemies.
There is another problem of a similar ilk, though one that’s not manifested itself quite yet — how to shoot enemies above or below the plane of control. These mechs have pivots, they are physically designed to be able to shoot up at Cliff Racers and down at tiny Spiderbots, so the same solution will need to work in both circumstances.
So I am becoming the thing I despise the most and adding a modicum of auto-aim. When the cursor hovers over an enemy, the guns pivot to face the target. It’s a small thing, a little tilt inwards and maybe a little up or down; you’re already broadly facing the target because it’s under the cursor, but it adds the extra assurance that when you’re targeting an enemy with two cannons, both shots are going to count.
And then, of course, I start to think about adding dazzle camouflage that makes your guns pivot to the wrong point and shoot wide. You’ll have to aim at those enemies “manually”. (Hell, a cannon that’s visibly pointing the wrong way is much better than a spurious percent chance to miss, right?)
2 thoughts on “Blog 606: The Vagaries of Control”
Hey, I have just been dealing with the exact same problems you have with mouse controlled aiming from an isometric perspective 🙂
Funnily enough, I had exactly the same problems, and ended up doing the exact same solutions.
There is one suggestion that maybe I could help with? I did the same trick you did when it came to aiming at enemies above or below you at first, but have since converted to a slightly different technique. The aforementioned method where you set it to aim straight at the enemy under the cursor creates a horrible ‘sticky’ effect where your shots will only ever aim at the same part of the enemy. As you said, it feels like ‘auto-aim’.
Now I do this:
When the cursor hovers over an enemy, that enemy projects a plane VERTICALLY, with flat side always pointing at the player. You then simply aim at the collision point of that plane (as you do in the normal horizontal plane). The benefit of this method is you can actually do things like aiming at the enemy’s feet or head 🙂
I hope that makes sense!
Hmmmm! That’s a very interesting idea. I’m still struggling with getting the angles on the pivots constrained (vector and quaternion maths not being my strong point) so the pivots don’t go wild and clip through everything, but I’ll deffo take a look into that once I’ve got the basics solid.