How to handle bullets in a FPS?

Blitz3D Forums/Blitz3D Programming/How to handle bullets in a FPS?

vibe37(Posted 2004) [#1]
How would you handle all the shooting-related stuff in a first person shooter? Would you create actual bullet entities that collide with the enemies or would you prefer commands like LinePick (which I found pretty slow..)?
I'm looking forward to your ideas!

Kungfista


Gabriel(Posted 2004) [#2]
I'd use linepicks. Faster and safer. I'm not sure why you're finding them so slow. I found them pretty decent. Not blistering, but fast enough you could get away with a good few.


N(Posted 2004) [#3]
I use the former method you proposed. Create a pivot, give it a small-ish radius, and then move it. When it collides with an object, I free it and then do whatever else I want to do with the collision point and entity afterwards.

Sybixsus: He might be using them over a great distance...


Shambler(Posted 2004) [#4]
Depends if its a slow moving visible projectile or a fast moving projectile as to whether I'd use a moving pivot or a linepick.


ChrML(Posted 2004) [#5]
You could move a little cube or something with MoveEntity, and use EntityCollided to detect what it collided with.


_PJ_(Posted 2004) [#6]
I use the former method you proposed. Create a pivot, give it a small-ish radius, and then move it. When it collides with an object, I free it and then do whatever else I want to do with the collision point and entity afterwards.

I'd rather use linepick than a pivot, because using a pivot means scaling down to a small float which doesn't always work well with Blitz collisions


Rob(Posted 2004) [#7]
It's simple: you do one perminant linepick. The linepick is used to determine where rockets will be fired and where machine gun bullets will end up.

The performance hit of one linepick never hurt anyone. If you're doing one linepick per bullet then thats faulty logic as you'll realise you don't need to do this. Bullets are nearly instantaneous, and you only need to add an artificial (fake) delay based on distance.


jfk EO-11110(Posted 2004) [#8]
I do both. When a bullet from a conventional firearm such as a pistol or rifle is shot, there is no mesh in the air, it's only a linepick and the impact happens immediately. If the Weapon was some kind of Fire thrower or rocket lauchncher or whatever, it will generate an opject that will travel trough space until it hits something or until it's out of sight. So there's a collision check.

I have some flags for each gun which decides how to handle the usage of the weapon. One of those flags is the HasMesh flag. An other one is Speed and a third might be Destruction etc...
The weapons settings are stored in an external file together with the weapons file-paths and further settings such as path to individual sound files, accessibility, Description String etc.


vibe37(Posted 2004) [#9]
If you're doing one linepick per bullet then thats faulty logic as you'll realise you don't need to do this

ROFL, that's exactly what I did... You're right, I need only one LinePick per cycle :)
I guess I'll use both methods, depending on the gun.
Thanks to everyone for their advice!


jfk EO-11110(Posted 2004) [#10]
You could save that linepick if you would only do it when the player presses fire. But since most games want a target-sensitive crosshair with some tech-looking info scrolling across the screen, you might require to do that linepick every loop.

It's the sum of long range linepicks that makes a game slower.