Correctly map a Mount&Blade style aiming rectangle to the projectiles flying direction?

Question

So I implemented a game mechanic where drawing a bow will display a shrinking rectangle that should represent the shooting accuracy. The rectangle is smallest after about 1.5 seconds of drawing the bow.

Now the question is, how do i correctly map the size of the rectangle to the projectiles flying direction?

My first though is to give the projectile a random angle deviation and the aiming rectangle is the max angle deviation, but I guess I somehow have to take the FoV angle into consideration somehow? Furthermore, is the FoV Angle uniformly distributed across a 2D screen or is the change of angle greater at the edges of the screen?

With a uniform distribution I guess it comes down to a very simple calulation.

• FoV = 70°
• Max Yaw and Pitch deviation at 1.5 seconds = 10°
• Screen resolution: 1920x1680

Size of aiming rectangle:

• width: 10/70 * 1920 ~= 274 pixels
• height: 1680/1920 * 274 ~= 239pixels

Is that correct?

For clarity here is a screenshot of that aiming rectangle that shrinks over time: https://www.vintagestory.at/uploads/monthly_2017_07/2017-07-22_22-48-10.png.86e757f209fde73b769726e7c12aaeb1.png

Answer 1

I would suggest to think of this square more like a fictive crosshair, like on a rifle, that hovers in front of the view. Let's assume, your square is 10 meters infront of the character and it's there about 1m x 1m when zoomed in, then you can create 3 vectors to calculate your next shooting vector.

q1 to one of the side edges, q2 to a topside edge and t to the center of this square. Now everything you shoot, calculate q1 and q2 in addition to t. Then calculate the arrows flying vector a, like this for example:

x*q1 + y*q2 + t = A

While x and y are random numbers between -1 and 1. You may want to have a function that is more biased to t, so less deviation.

I have two reasons not two fiddle with the pixels

1. As your other question suggests, if you want the FoV adjustable, things like the gui should scale with that, while the crosshair is gameplay related and should only get thicker for visual purpose.
2. With the vector approach you can project the square on solid walls, so the square gets sheered to reflect w possible angled shooting vector.

And the thing with angles is, that calculating cos, sin and their respective inverts is, that they demand a lot of time. Doing this every frame could be a problem. Alternatively you can set the width and height of the square to reflect the angle, so for my 10m example that would be sin(10 Degree) * 10m ~ 1.73 m. Double that for the width of the square.

To the FoV question, it should be stretched equally across the screen, although it can be done otherwise, I have no idea what it would do as a factor for motion sickness.