How to predict the player movement with vector math in a shmup?

Archive
1
:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By Leandro

Greetings from Brazil. I’m developing a 2D shoot’ em up game. In this game genre, is quite common to have enemies that shoot aiming at the player’s current position. Since in my code all positions and speed are represented with 2D vectors, the formula to calculate the desired enemy shot direction is quite simple: (playerx,playery)-(enemyx,enemyy).

However, I want to try a different twist. Instead of having enemies that aim at the player CURRENT position, I want to create enemies that instead aim at the player FUTURE position. Both player speed and enemy bullet speed are constant. Is there any vector formula that I can use to calculate the enemy bullet direction, so it’ll intercept the moving player? Thanks in advance!

enter image description here

2
:bust_in_silhouette: Reply From: DarrionOakenbow

Unless I’m missing something, this should be as simple as taking the current aim (vector from enemy to player in the enemy’s local space) and adding the player’s velocity vector. When I sketched it out quick it seemed to me that I was literally just drawing the old ‘tip-to-tail’ vector addition method, so it should work out just fine.

As long as you use the resulting vector as the projectile’s velocity, it should be directly on course to hit the player (assuming I didn’t mess up and they maintain their course).

All in all, should be something like this (pseudocode)

aimVector = (x,y) - (ex, ey)
aimVector += (vx, vy)

Sadly, you are missing something. And me as well, since I tried that before. :frowning:

I think the enemy bullet speed should also be considered in this equation. If it’s fast, it should reach the player near his original position. If it’s slow, it should reach the player much far away to intercept (with a totally different angle).

Leandro | 2019-05-31 20:51

I didn’t think about that. I guess my solution only works if you don’t care about giving each projectile type its own preset speed.

I don’t suppose you could just multiply by the ratio of the player’s speed and the bullet’s speed? I.e

scalar = (vx, vy).length() / (this projectile's max speed)
aimVector = (x,y) - (ex, ey)
aimVector += (vx, vy) * scalar

I think that should correct for the difference in speeds. If the bullet moves faster than the player, it would underaim (relative to my original answer), and if the player is faster it would overaim.

DarrionOakenbow | 2019-05-31 21:12

It SEEMS to be working. I cannot be sure because it gets buggy (as expected) when the player reaches the limits of the screen, and this funcion doesn’t consider the player will be forced to stop.

Anyway, it’s more accurate than before. :slight_smile:

Leandro | 2019-05-31 21:32

Update: no, it doesn’t, although it’s way more accurate.

Leandro | 2019-05-31 21:34

If the limits of the screen are constants (sx, sy), you could just clamp the x and y coordinates of the velocity to something like (sx, sy) - (x, y) on max and (0,0) on min (if that’s how you’re set up).

DarrionOakenbow | 2019-05-31 22:04