A method for simulating bullet drop with straight lines


Today I will sort out the drop of those rays. I have two options for the actual implementation:

  1. Draw a single ray at a slightly downwards angle to simulate bullet drop without doing any actual maths.
  2. Draw multiple rays that conform to an equation of ballistic drop.

The second option would be nicer for an actual simulation, but drawing multiple segments of a single ray and checking for collisions with each may be expensive.


Breakthrough! Why should I mess around with making equations of rays, when I can do it better in a more improvised fashion? Consider:

  • Guns fire bullets in a slight upwards arc.
  • A skeet shotgun is zeroed at 19m. Pellets must be able to hit the point of aim at 19m.
    • The arc is a parabola, which means that its apex will be halfway between the muzzle and the Zero point.
  • The pellets steadily fall to the ground after the Zero point.

Therefore, I only need to draw three rays, and I can do it very simply!

The final series of lines is divided into three segments. From left to right:

  1. Muzzle to apex of ballistic curve. The apex is located halfway between the muzzle and the Zero point at 9.5m (38wu), and is 5cm (0.2wu) above the point of aim. A climb of 5cm at the halfway point is equal to a rise of 0.5cm every 1m, which seems legit.
  2. Apex to Zero point. The ‘bullet’ falls back down and crosses the sights a second time at the zero range of 19m (76wu).
  3. Zero point to termination. From the Zero point, the bullet falls linearly until it hits the ground at its maximum flat-ground range of 60m (242wu). Since this is going to be implemented as a ray, it will have an unlimited length.

Compare this to a simple linear implementation of bullet drop towards the ground at maximum range:

The bullet completely misses the zero point in a simple linear implementation. The problem I face is that rays are infinite in length, so it’s not gonna come out so neat: there will be many collisions at each segment. There are two possible fixes:

  1. For the nearest collision at each ray, determine whether it is within the allowed length for that segment. If it is, count that as a collision, stop making segments, and calculate the results.
  2. Use line geometries for the first two segments, and a ray for the drop-off segment.

1 looks like a good solution.


After coming back from a SNES break, it seems that the ray solution may not be the best because it’s an instantaneous system. If I can hook it up to the tpf I can make the rays draw over time, but if not (or if this is costly and awkward), then I’ll have to go back to physics. Of course, since we’re using shotguns it could be concluded that the range of a gunfight (even in FPS Roguelike) is so short that it simply won’t be necessary to have this kind of fidelity, although having pellets as physics objects would mean that we’d be able to use them for things like ricochets.


Big problem with physics-based bullets. I found how to make the physics update in real-time for fast-moving objects so that they stop going through solids, which meant that I could now have ricocheting pellets! And boy are they computationally expensive. I was detaching them from the node as fast as I could, but after launching a couple hundred of them (500 seems the magic number) it really slowed the game down.

I need to learn how to put pellets in a separate collision group so that they don’t collide with each other (cheaper to fire more of them at once), and how to garbage-collect before the physics space gets filled up.

It also seems that I was using the wrong listener to find rigidbody collisions.




Nike Air Max classic Nike Free Run sale Nike Air Max kopen Nike Air Max shop Nike Air Max classic goedkoop Nike Air Max 90 goedkoop Nike Air Max 1 kopen Nike Air Max sale Nike Air Max 90 sale Nike Air Max kopen online