Bullet collisions

I’m making an FPS game, that obviously uses bullets. The problem I’m having is that I don’t know whether to use the ray or the touch sensors to collide with an object (Ex. a wall). I want to be able to apply force if I need to (like push something on collision) and to change bullets into bullet holes. but if I make the bullet slow enough for the sensor to pick it up, then it won’t look realistic :confused: I don’t know how to change bullets into a hole if it goes as fast as I want it to go…plz help

a ray is the way to go, and then you can shoot a “fake” as well that dies on collision with anything,

So step 1 fire ray
Step 2 add object bullet

should look ok :smiley:

Need to do it in logic ?

If keypress fire---------------and----------------property GunDriver =1
if GunDriver=0-----------------/

Ray sensor-------------------
if GunDriver=1---------------Raycast python

if GunDriver=2---------------and-----------------add object bullet

if GunDriver min:1 max: (shoot animation length-1)–GunDriver add 1

if GunDriver = animation length----and------------GunDriver=0

if changed-----------------------------and-------------Action property based GunDriver

So this casts the ray, adds the bullet and manages the animation of the gun :smiley:

This is funny, because “realistic” you would never see a bullet. Because they are fast. That is the reason, why rays are a pretty good approximation.

A ray has two drawbacks:

A) it hits immediately, which is to fast, especially on large distances
B) it does not follow a ballistic curve

Therefore it as not that nice, that bullet (the physics engine can’t handle them well).

There is a solution but it is not easy:

You merge physics bullets with rays to workaround the collision problems.

This is the idea:

A bullet is not just a physics mesh. It consists of 2 parts:
A) the physics mesh (which might miss the collision because of it’s size)
B) a sensor that forward measures the path for possible hits. That can be a ray or a sensor object.

| mesh    > ------ sensor --------- | estimated future position.

The difficulty is to determine the length of the sensor. Obviously it’s minimal length should be the way the bullet will move within the next frame. The maximum length is the same as it should only hit objects within this two points (current and next).

If the speed changes you need to estimate the sensors range within each frame. If you assume a constant speed, you can calculate it once (even before game start).

So I should use the bullet mesh to sense the position and if collision, then end object? That doesn’t seem too bad…This actually might work!! Thanks a lot

To do pushing force (I don’t do python anymore so this isn’t “copy paste”-able, but this is a universal thing):

pushForce = (gunBarrel.position - hitPoint.position).normalized


You can use more than just force to move it though.

Normalized makes the vector numbers no greater than 1. Without normalized, the greater the distance the bigger the vector. So more force will be applied the father away you are from your target.

pushForce = (gunBarrel.position - hitPoint.position).normalized


Jedi Grab item!

Neat !

never thought of using python for this…pretty cool! i’ll give this a try…too bad I don’t program Python :frowning:


If you need some commented BGE code just ask,
I have examples of this and that laying around…

To precise the statement:

A normalized vector has the length of exactly 1.0.

This was meant to calculate the impulse (force) transferred from the colliding bullet to the hit object (e.g. a box which can be “shot away”).

With the “ray method” there is no bullet. The speed is assumed to be a constant the direction is assumed to be along the ray.

When using a travelling bullet you can ignore the length of the ray. You can assume that the current velocity (including its length = speed) is part of the impulse to be transferred [= no normalization]. As a very simple formula you can simply assign the bullets velocity as impulse to the hit object.

So you do not just

  • end the bullet,
  • you can apply a force to the hit object (only worth on dynamic objects), and
  • you might want to add a hit mark (bullet hole) as well.

These are three different things that can be triggered when you detect a hit.

for a FPS you can use mouseOverAny , is the way more easy , this ignore completely the speed of bullet.(or better manage it as he have a superspeed)

but at the same time give you all necessary :
object hitted (eventually to send some message)
direction of bullet (you can use applyForce() )
and also the hitPoint

(or eventually also applyImpulse()))

the bullet not exist :smiley:

Except you have no control over shooting mechanics and the most cursor does not stay centred

Sent from my Nexus 7 using Tapatalk 4

Ok, I tried the ray sense with bullet, and it works :slight_smile: problem solved, thanks everyone

i can understand as “design”, changing weapon change “automatically” also the bullet, and it follow the real sequence (player -> gun -> bullet)

but for the cursor not, or at least , to me seem that give just annoyng ,
ie : you want shoot where is the mouse at the end… (no matter where is the gun) :slight_smile:

Except the mouse more relative to screen centre. You would be better using a ray down from the camera

Sent from my Nexus 7 using Tapatalk 4