collision between two area's(2d) happens too late.

Question

I have two area's(2D) one is a bullet the other a spaceship. I set up a collision signal via the area_entered signal. Everything works perfectly except that the collision only happens when the bullet is already halfway through the spaceship which causes some unnatural feeling gameplay

This is the bullet and it's collision area

This is the spaceship and it's collision area

and this is the moment the bullet hits the spaceship. The bullet would disappear the frame after this one.
I don't know why the bullet doesn't register a hit the moment it's collision area touches the spaceship's collision area. If you do know why please let me know because I don't want to resort to just making the collision area bigger

here is some code that might cause the problem:

func _on_Yellow_shoot():
if len(Ybullets) != 0:
    $YellowReload.start()
    Ybullets.remove(0)
    var bullet_pos = Vector2($Yellow.position.x+40,$Yellow.position.y)
    var bullet = yBullets_Scene.instance()
    bullet.position = bullet_pos
    add_child(bullet)

This bit of code is how I add the bullet to my main scene. The plus 40 on the x position is to make sure the bullet comes out of the barrel of the spaceship and not the middle.

Answer 1

I assume this is related to the speed of the bullet. That is, you're moving the bullet at some predefined speed and, to maintain said speed, the bullet needs to move some distance per each frame. Faster speeds require the bullet to move larger distances between frames.

Specifically, I'd guess that in the previous frame, the bullet has not yet collided. Now, it moves "X" pixels to maintain its speed. Now, in the next frame, it is colliding, but it's now visually inside the boundary of the target.

If your target is "thin" enough, this phenomenon can even cause a hit to not register at all since the bullet is on one side of the target in frameX and on the other side in frameX+1.

One possible fix would be to track the average distance the bullet moves between frames. Based on that, you could cast a ray (of that distance) ahead of the bullet. If that ray collides with your target, that basically means that you will hit the target in the next frame. Based on that you could start the "destroy stuff" workflow.

Comments

Thanks for the explanation. I didn't know the movement worked like that.

---

You could verify the above by (temporarily) slowing the bullet down. If my explanation is the issue here, it should be improved as the bullet is slowed down...