Sign in to follow this  
null;

Multiple bullets?

Recommended Posts

So, I've been asking a lot of questions on the forum recently, but those really payed off. So far, I've implemented a fair amount of features into my game (i.e grenades, health bars, attack system, etc.). Next, I intend to add guns basically attached to my player. I know HOW to do that, but I have a slight problem.

 

How would I have multiple bullets on the screen? What I usually do is, I wait for the bullet to exit the screen, then it becomes null, then the player can shoot again. The only problem is, I can't render more than 1 at a time (Note: I still haven't even implemented the gun, but that's just usually how it is in most of my other smaller games).

 

How would I go about doing this?

 

Thanks to whomever replies! :D

Share this post


Link to post
Share on other sites

How do you handle timing in your game?  You can fire a bullet once every x unit of time.

 

or 

 

You can fire another bullet once the current one is done firing.  This can be accomplished with flags or a ticks based timer with potentially a FSM.

 

edit - rereading your post, glportal's advice seems prudent.

Edited by Infinisearch

Share this post


Link to post
Share on other sites

then it becomes null

 

heh.

 

Anyway, look into "std::vector".

 

 

You could just make a variable like this:

std::vector<Bullet> myBullets;

then use it like this:

myBullets.push_back(Bullet(x, y)); // or however your constructor goes, if any. You can probably do myBullets.push_back({ x, y }); as well

If you have update and draw functions in your bullet class, then you can do this to call those:

for (auto& i : myBullets) { // Loop through all the elements in "myBullet" and let "i" be a reference to the current element. 
    i.update();  // or i.draw();
}

Hope that helps in any way.

Edited by irbaboon

Share this post


Link to post
Share on other sites

One standard approach (as always, there isn't a single approach which is [i]the[/i] approach in virtually all cases) is to use a factory function to instantiate bullet objects as needed. Usually this has two requirements: 1.) the player presses a "fire" button, and 2.) game rules determine that it is valid to fire again (something like a time delay between shots, the player has enough ammunition, whatever).

 

It sounds to me like your program has a variable instance of bullet, and you assign fresh values to it when a player fires, and then that variable is "taken" until the bullet goes off screen, so no new bullets can be fired until the values are nulled once the bullet goes off screen. Is that right? If so, glportal's suggestion is a good one. If you have a list of objects in the current scene, whether its a list for bullets alone, a list for all objects in the scene, or something in between, you can add and remove bullets from that list however you like. Each bullet is still an object and so will still have its own fields like position, velocity, etc.

Share this post


Link to post
Share on other sites

You treat the bullet as an entity. When you fire a bullet, you spawn a new entity, give it a constant velocity, and give it some special logic to do bullet things. When it collide's it's life is over and needs to destroy it's self.

Share this post


Link to post
Share on other sites

Don't know if this is of any relevance for you...

 

What others said, but: at least if you are using Unity as your game engine, or your engine/framework has a similar weakness with instantiating/destroying gameobjects/whatever-it-is-called-in-your-framework, OR your own "engine" you write for your game there will end up having similar weaknesses, never EVER instantiate/destroy while running the game!

 

Always instatiate at scene load, manage as a pool during the game, and destroy at the end of the scene.

 

Why? Would you believe me that at least in case of Unity, the engine was able to handle hundreds and thousands of gameobjects with a renderer and physics (not all of them had their physics components active at the same time though) on a pretty up to date intel CPU and a high midrange GPU while keeping >30FPS as long as I was using a pool to "re use" the objects, but dropped to around 20 or less FPS while I was still using instantiate/destroy instead of managing the gameobjects with the pool?

Just so my usecase gets a little bit clearer, I was creating an automatic weapon at the time, that shot bullets with a renderer and physics rigidbody attached, and ejecting spent cartridges, again with a renderer and physics rigidbody attached. Madness? So I thought too, until I actually profiled the slow running scene and found the problem was neither rendering nor physics, but the obscene overhead of instantiate/destroy of a gameobject. Amplified by about 30-60 of both going on per second. Seems Unity and a midrange PC can pretty much handle the use case, as long as you optimize a little bit (for example use object pools).

 

 

Now, this might totally not affect you. But then, using a pool instead of instantiate/destroy doesn't cost much more time to implement, and will safeguard against such scenarios where instantiating and destroying an "object" (in case of unity, a gameobject comes with a multitude of components, its more like a whole mess of objects) costs more performance than anything else.

Just instantiate at startup (making a good assumption on how many bullets you are gonna need on the screen at any time), keep in a managed pool (reuse bullets that left the screen or impacted with something, move them back to the gun and reset their trajectory... if you need more bullets, instantiate more and add them to the pool, but never destroy them yet), and destroy them when the level is over (and you have a second or so anyway to dispose the rest of the level, and do not need to render anything on screen with a stable framerate).

Edited by Gian-Reto

Share this post


Link to post
Share on other sites

As previously stated, the simplest way to handle multiple bullets is to store them all in an ArrayList, and remove them when they collide with something or leave the screen.

Although Gian-Retro's advice is the optimal practice, it requires a bit of experience to implement properly, and might not apply as well to your case as it did to his. I would just use ArrayList unless you notice a performance issue. :)

Share this post


Link to post
Share on other sites

As previously stated, the simplest way to handle multiple bullets is to store them all in an ArrayList, and remove them when they collide with something or leave the screen.

Although Gian-Retro's advice is the optimal practice, it requires a bit of experience to implement properly, and might not apply as well to your case as it did to his. I would just use ArrayList unless you notice a performance issue. :)

 

True, as given the project is less taxing on hardware resources, and the "objects" being instantiated and destroyed are less resource intensive (2D Sprites, no Physics components for example), as well as the underlying engine/framework being better at handling instantiation and destroying of objects at runtime, the difference might not be measurable.

 

 

Just wanted to give a heads-up on a good practice I would have liked to know about sooner myself :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this