[Slick2D] Inconsistent collision because of frame rate dependency.

I’m currently working on remaking a game I made a few years ago, and it didn’t occur to me until recently that the new code is very framerate dependent, in that the speeds of various game entities vary depending on what framerate you’re getting. I’m making the new version of the game using Slick2D.

I modified the calculations that “move” the projectile to take deltaTime into account, and this has got me some better results with various frame rates, but now I’m running into another issue. Specifically, the accuracy of my projectile collision detection varies depending on the frame rate. The faster the frame rate, the more accurate it is. I can understand why this is, as with a slower frame rate, the projectiles will be moving further along their path, meaning they could skip right past the enemy collision radius; so I’m trying to think of how I could modify the existing system to give me better results that would be consistent regardless of frame rate.

I’ve thought about using raycasting to decide whether the projectile hits. I was about to start writing the code so that the raycasting would be done when the weapon fires, so it would determine then if there is a collision, and then just fire the projectile really fast so it gets there before the enemy can move away from it.

I realize that this is not a good approach, because this means the enemy will take damage before the projectile actually arrives, which would result in some… interesting visuals. So would it be feasible to have the projectile simply raycast along its own trajectory and if it’s within the enemy’s collision radius, then it hits?

Currently, the collision detection is:

But as mentioned before, the varying frame rate can cause particles to completely miss just because of lag. So my new idea is…

I feel like I’m confusing myself every time I try to reason this out. Can anyone offer advice?

My current code base is available at: https://github.com/packetpirate/Generic-Zombie-Shooter-Redux

Relevant Files:

I’m also open to any suggestions about the rest of my code, specifically any design patterns I could use to make things easier to modify or anything that I could do differently.

Use fixed step instead of variable step.

I’m not the best guy to answer (i’m all in 3d) but your idea is right, it’s the widely used discrete detection : when a move risks to fail to hit something, divide it in several steps and test each one.
To fix permanently the problem you might use continuous detection which tests collision not on a fixed position but on the move, but it’s more complex (and i can’t talk of it seriously in 2D…).

Ok, that seems better. I went with a fixed timestep (target frame rate of 60), and things seem consistent now (will have to confirm this by testing more). However, specifically, my Flamethrower weapon generates a lot of little particles, and most of them seem to pass right through the collision radius for the enemy, and I see them die off a little bit after they pass the zombie.

I’ve attached a screenshot in case it helps. Can anyone tell why it might be failing for that particular weapon, but not the basic weapons (Pistol, Assault Rifle, Shotgun)?

In the screenshot, you can see the flame particles mostly missing the zombie (the collision radius is noted by the red circle).

https://imgur.com/lePSE1U

[quote]Can anyone tell why it might be failing for that particular weapon, but not the basic weapons (Pistol, Assault Rifle, Shotgun)?
[/quote]
Yes, your other guns projectiles must be bigger, if your particle takes 1 pixel you must test it pixel by pixel on its trajectory !

Like @N_I_C_S said, use a “continuous” (or “swept”) circle/circle collision detection algorithm.
Much more accurate and requires no iterative approach.
See: https://www.gamasutra.com/view/feature/131424/pool_hall_lessons_fast_accurate_.php (page 2 for working code)