Sorry your browser is not supported!

Well I want to have lots of objects firing bullets and was wondering how exactly this could be done?? I need a relativly simple way to handle all the bullets that are gonna be flying about. Anyone got any ideas.....

well im doing this in my game and what i have is in my code is a section where it creates a bullet which is just a plain and it makes it 'bulletno'. bulletno starts off as 20 and all the numbers less then 20 are used for objects in the game. of course you can just adjust this number for your game. when the bullet is created 'bulletno = bulletno + 1'. then after the bullet has been created and also pointed in the right direction you do a for loop each loop. make the loop something like....


for move = moveplus to bulletno
if object exist(move)=1
move object move,movespeed
if [condition of bullet 'death']
delete object move
moveplus = moveplus + 1
endif
endif
next move


where moveplus starts of as 20 or whatever number you want

I'm not quite sure about how I will make the objects still

Ok ive got a simple bullet life system now but I was wondering how to get lots of bullets coming out one after each other...and how do you have more than one object that can fire bullets shooting at the same time.

start the code with

dim bullets(200)
for i=1 to 200
make object cube i,0.1
position object i,outofsightx,outofsighty,outofsightz
next i

then when ever someone fires a bullet,(you need to do this for all the people/players that shoot), you find a free bullet and set it too the players position and direction (or you could set it to the guns position etc), the rest of the code later on will worry about moveing all the bullets wherever they are pointed, this gives the player/npc a free bullet and sets it to their position and direction, you would need to make up something like a weapon jam routine if all the bullets where used up when you tried to fire.

for freebullets=1 to 200
if bullets(freebullets)=0
bulletx#=playerx#
bullety#=playery#
set object to object orientation freebullets,playerobjnum
bullets(freebullets)=max_life_of_bullet
move object freebullets,distance to clear player
endif
next freebullets

and to move the bullets in the world (in the main loop)

for shot=1 to 200
if bullets(shot)>0
move object shot,bulletspeed
dec bullets(shot)
endif
if bullets(shot)=0
position object shot,outofsightx,outofsighty,outofsightz
endif
next shot

and when a bullet dies (hits a player or something) get the objectnumber and do

position object objectnumber,outofsightx,outofsighty,outofsightz
bullets(objectnumber)=0

to stop it moveing and hide it, the outofsight variables are somwhere you can`t see the bullets, you could put them miles away or inside a wall or something, I find stretched cubes work well, just move them at the same speed they are long, textured orange and they look like machine gun tracer, or you could use instant bullets with the intersect object command and do the check when the bullet is fired, but if you want visible fire in the world then this is an easy way to get it, I just typed this direct into the forum so beware typos/minor logic errors, but it does work, since I have used it myself, if you want more bullets in the world then increase the size of the array and the loops to match, don`t try to optimise by keeping an index to the last bullet fired since several could "die" while one is still in motion and the overhead wastes more time than running the loops ,cheers.

Mentor.

Thanks ill try this out...hope it works well.

instead of possitioning the bullet off the screen cant you just:



then when you need the bullet unhide it, then position it where you want it to be.

but hidden bullets still report collision, so you could be killed by walking into one that you couldn`t see, this way you don`t have to keep track of their status and code to ignore hits from hidden bullets, I use hidden objects a lot for menu selections too, most usefull ,cheers.

Mentor

cant you just have it so when you shoot it creates the bullets?

creating objects in the main loop takes time and slows the game down, more so if you have lots of bullets being fired/created at once, keep the object creation out of the main loop at all costs, you must have noticed the amount of time it takes to initialise code with plentifull objects in it, just imagine that order of speed reduction in the main loop, you would be down to 2fps before you know it.

Mentor.

I haven't tried to implement this yet (I'm only on my fourth day with DB), but I would use a system which only looks at active bullets. I would have a bullet counter, an array which holds the object number of active bullets and an array that acts as a timer for each active bullet. When a bullet was fired, the bullet count would be incremented, it's object number would be placed in the next available bullet array element and its life expectancy would be placed in the corresponding timer array element. Each cycle through the main loop, only the active bullets would be compared for collisions and the timer array elements would each be decremented. When a bullet's timer reached zero or it hit something, the bullet count would be decremented and its entry in the bullet and timer arrays would be removed. All the remaining elements of the arrays would have to be moved down in the array.

The advantage is that the loop checking for collisions doesn't have to check for inactive bullets, (both a time savings and preventing inactive bullets from giving false hits). Having to move down elements all the time when bullets become inactive does seem a little awkward. Maybe it would be better to use a queue, since if all bullets have the same lifetime, the first bullets fired would be the first to time out, so a first-in first-out data structure would seem appropriate. If a bullet scored a hit before it timed out, its object number could be swapped with a flag (maybe a negative number) that would signal it was not to be checked for collisions. Then it could just be retired normally when it timed out.

sorting the bullets in realtime is a overhead you can do without, it is awkward and slows everything down, also you said the first bullet out would die first, not so, imagine you strafe across a wall in a open space, the bullets that hit the wall could die first, and you would find it easier to just place the bullets out of reach and update all the live ones in a fixed loop than start playing with flags and sorted arrays, remember it takes a lot of time to create a bullet inside the main loop, just sticking them at 0,-100000,0 will keep them out of harms way well below the floor in most games, no chance of false hits then and the code doesn`t need to keep track of "live" ammo, all you need is the one active bullet array, any number over zero means the bullet is in use, if its zero then hide it at some remote location, if it isn`t then decrease the number by one, simple, cheers.

Mentor.

Well, first of all, you don't sort them, you just place the next available bullet in the array. Shifting elements down when one is retired is awkward, but it isn't an O(N^2) operation like a sort. Which is why I mentioned the queue thing. I DIDN'T say bullets fired first would necessarily die out first, I said if all bullets had the same life expectancy, bullets fired first would time out first. I mentioned that if a bullet was retired early, you would replace it with a marker that tells you it isn't active. Then everything is just removed when it times out and you don't have the awkward problem of adjusting the array that the non-queue method has.

If you just have one matrix for active bullets, how do you know which element is associated with which bullet? Or is it a matrix for all bullets, but you know which is active by the timer count? And the object number is implicit in its array index? Hmm. Since I'm guessing the time associated with a comparison with 0 is pretty small in relation to a check for collisions (at least for DBPro), the overhead of iterating over all bullets isn't significant in any case. My initial thought was to not look at 200 bullets when only 5 were active or something like that. I'm also looking down the road to the game I'd like to make where you have a lot of different bullet types and a large total pool of bullets which are never all going to be active. I'd like a method where I can whittle that down to a small number which are likely to be active (those which have not timed out).

Floyd

Yeh i understand all this but what if i have like 20 or 30 or 100 guns firing at the same time?? how am i to do that? Does each gun have to have its own set of bullets or what this could get complicated.

Take a look in 20 line challenge forum for 'return to phobos' game. It is a full-on doom game with loads of aliens that each fire multiple bullets at you. You also fire multiple bullets at them.

Well my thoughts on this (which are constantly evolving) are that you just have a pool of bullets. I forget what DB calls user-defined types, but each bullet should be a user defined type with a timer and a vector which tells the bullet how its coordinates should be incremented each cycle. So every bullet is just fired and forgotten by the shooter. After it is fired the loop can consider the bullet independent of its shooter.

-Floyd

Aha and can someone explain how to make like 1000 objects with that for next loop thingy cause i cant seem to get it to make 1000 objects

since debate is good for development , I see what you mean but, (theres always a "but"), the array index refers to the object number, either directly or via an offset, the vector is inherent in the object if it is pointed in the correct direction all you have to do is move it each loop, the only remaining thing is to keep track of it`s lifespan and the variable indexed in the array does that, I did misunderstand your intent when you "move them down" I thought you where sorting them by lifespan as an attempt at optimisation, so sorry for that, thousands of bullets are a problem though (if you want them visible or not), how fast does this run on your machine?

for i=1 to 2000
make object plain i,1,1
position object i,rnd(50),rnd(50),rnd(50)
point object i,rnd(50),rnd(50),rnd(50)
next i
position camera 70,70,70
point camera 0,0,0
do
for i=1 to 2000
move object i,0.1
next i
text 200,0,"**"+str$(screen fps())+"**"
loop

on my machine I get a handsome 12fps, not exactly Quake framerates, and thats a pretty heavily optimised rendition of 2000 plains onscreen at once, no AI, scenery, collision or animation, change the plain command to cube and the framerate drops to 8fps, the moral of this is to use instant bullets if things are going to get busy, if you have pro it`s no more difficult than setting your position and a point in the world with pick screen and then using intersect object to check for a collision, or you could just use pick object at the crosshair position to tell you what you hit and intersect object for the bots, either way 2000 onscreen bullets is gonna kill the framerate dead, time for plan "B" LOL, cheers.

Mentor.

ps: 1000 objects is no harder than


for i=1 to 1000
make object cube i,1
next i

but when you come to moving them remember to make the loop for 1000 objects, otherwise 800 of them will be stood still, cheers.

cool there wont be that many on screen. Only 5-10 bullets maybe shot at anyone time from each shooting object so its not to greater deal. You say something about their life in an array is that required to have each object have a seperate life span??

Good, finally some numbers. So let's say you're firing a submachine gun at 10 rounds a second and bullets time out at 2 seconds (I think that would probably be too long, but just for an upper limit). So your first round is timing out when the 20th is fired, so one Tommy gun contributes at most 20 (or 21) rounds. So 10 weapons and 200 active rounds at once seems doable.

I trying to think back to Quake or Quake II, I can never think of a case where 100 players are all firing. I remember playing Quake levels that were made with level editors that had a lot of baddies and frame rates were terrible.

Oh well, I'll find out when I get there I suppose. By the way, Mentor, when you talk about the implicit vector, were you talking about one between the player and the bullet. Because in the FPS tutorial, the bullets are pretty slow and it appears to me if you dodge sideways, the bullet curves. I think it because they're using the vector between the current player position and bullet position, which changes when the player moves. I deactivated the monster so I could just try it in peace, and I don't think it's an optical illusion. That's why I thought of attaching a vector to the bullet when it was fired, so it would remain the same through each iteration.

the tutorial (if its the one I am thinking of) has a monster with homeing missiles, so they do curve (goblin on matrix with lots of brick pillars and a small hud IIRC), if you look at the code I did the direction that each object travels is set with...

point object objnum,x,y,z

then all you need to do is

move object objnum,dist

to move it for as long as it lives, the array location indexed by the object number holds the objects remaining life, and each time you move it the life gets reduced by 1 until it reaches zero and then you just put it out of sight and wait for it to get used again, in a busy scene the different bullets can be jumping in/out/in/out of the scene all at different times/positions and existing as a specific objects bullet for differing times, if you could see the array as (for example) a row of lights for each location, on for active and off for zero then you would see them flickering on and off apparently at random as the game ran, speedwise, allocating a slot to a bullet will take on average half the time it takes to scan x slots, where x is the number of bullets currently in motion, the code will stop the instant it finds a vacant slot and use that one, so if it found slot 1 free then the search would take 1 loop, likewise if you had twenty bullets active and they where all in the first twenty slots then you need to scan 21 slots to find a free location, the overhead on average will be 1/2 of the number of bullets active, as you would expect the more bullets active the slower things happen, I used simular code for a two player game with machine guns and the framerate was more affected by the scenery and animations than anything else, the bullets where no problem, you will also notice a "hill" with DB, what I mean by that is (this is just an example) you may have 60fps with 200 objects on screen and 40fps with 204 objects on screen, the limit has been raised with pro but you will notice a marked slowdown above a certain amount of objects.
the main object of my code is to reduce the number of logic decisions (if/then, case etc) in the main loop, you can do (relativley) a lot of loops and math for the price (timewise) of one logic decision, since logic slows code it`s best to try to keep it out of the main loop, for example

if object hit(4,3) then whatever
if object hit(4,8) then something else
if object hit(4,9) then something else again
etc.....

imagine it takes 1/100th of a second to make each decision (it doesn`t..pro is way faster than that, but bear with me), 10 decisions in the main loop will slow the game down to 10fps, but do this

collisionvalue=object hit(4,0)
if collisionvalue>0 then sort out the details

and you do 1 test per loop and the loss to gamespeed is 1/100th second, if an event does happen then the code takes 1/100th of a second to jump to the subroutine/function that handles the event, and 1/10th sec to sort out what happens, so when you die it takes 1/100th second longer for the event to happen and you have the advantage of the main loop running at 100fps rather than 10fps, a good tradeoff, the main thing is to try to keep decision logic out of the loop as much as possible, but this is digressing rather a lot, back to bullets, another option is to just use intersect object and show flashes (texured plains) across the collision positions when bullets hit walls etc, intersect object is way faster and in real life you don`t see the bullets coming anyway, the only time you need something that moves visibly is if you have a rocket launcher, otherwise, let math do the job and ignore fast moving objects like bullets, or you could compromise and have a small amount of ghosted cylinders hidden away and then just flash one up positioned between the player and the object intersection for four or five frames at the correct scale and then remove it again, that would look like a laser shot, or you could rapidly scroll a texture on a box postioned in the same way so that a "bullet" travels down the box from player to object hit and have the box transparent and the texture black apart from the bullet (but you will have to wait untill they sort the transparency properly for that), or any number of other ideas that I haven`t mentioned but may have just occured to you , it`s a matter of what works best for what you are trying to do, cheers.

Mentor.

ps: you have to keep track of them some way to make sure they don`t fly off into space and journey on forever, so counting down how long they still have to live is a good bet since they can`t travel too far before they get stopped and put on the list of objects free to be used, just make the lifespan such that they can travel as far as is reasonable before they get put back in the heap, normaly they will die before that from hitting walls/players etc, but it would be weird if they traveled off into space and you forgot about them and then half an hour later they suddenly started to rain down on you after the float values had rolled over and allowed them to re-enter the other side of the world-space and pass through the games location again

I think here you've probably outlined the best strategy for games in which a lot of bullets are shot. I was playing the game Battlefield 1942 a while back and trying to decide if I should lead aircraft when I was shooting at them or shoot straight at them. It appeared that triple A moved with finite speed, but machine gun or small arms fire was instantaneous. So for weapons which fire at a fairly low rate, like cannon or rockets, finite speed should be acceptable, but for small arms fire the instantaneous method is better. I think that will probably be the model I keep in mind from now on.

This code will not work as is, you must create the objects and misc other things. A link to a simple space shooter I created in DBC is below. In the code, you can specify the rate of fire, bullet speed, and the total number of bullets allowed on screen at one time. Just use these two sub routines. "NOB" stands for number of bullets. This is the total number of bullets you can shoot at a time. It's not commented, but should be pretty easy to understand. D/L is about 330k I believe.
http://angelfire.com/80s/phaelax/shootemup3d.zip



REM PLAYER CONTROLS
_player_controls:
if upkey()=1 or joystick up()=1 then inc py#,9.0+veloc#
if downkey()=1 or joystick down()=1 then dec py#,9.0+veloc#
if leftkey()=1 or joystick left()=1 then dec px#,10.0+veloc#
if rightkey()=1 or joystick right()=1 then inc px#,10.0+veloc#
if controlkey() = 1 or joystick fire a()=1
if bdelay >= waiting and ammo>0 then fireshot=1:bdelay=0
endif
if shiftkey()=1 or joystick fire b()=1 then lazer=1:show object 5000
return


REM HANDLE BULLETS
_handle_bullets:

if fireshot=1
for bt=1 to nob
if bullet(bt,1)=0 and found=0
dec ammo, 1
found=1
fireshot=0
firing=1
bullet(bt,1)=1
position object bullet(bt,2),px#,py#,0
show object bullet(bt,2)
play sound 2
shotz#=shotz#+1
endif
next t
found=0
endif

if firing=1
anything_alive=0
for bt=1 to nob
if bullet(bt,1)=1
bx#=object position x(bullet(bt,2))
by#=object position y(bullet(bt,2))
position object bullet(bt,2),bx#+bullet_speed#,by#,0
gosub _bullet_collision
endif
anything_alive=anything_alive+bullet(bt,1)
next t
endif

if anything_alive=0 then firing=0
return

How do you fire off bullets at regular intervals like a soon as one bullet has left the gun how do you have the next one come out as soon as first one has left gun but still have the bullet have a long life.

[Edited..]

??