I'm designing a 2d fighting game in which characters can shoot out some projectiles like arrows, ninja knives, Hadouken (like the one in Street Fighter), etc...

My current character design is actually in a component based manner, however, I've no idea about how to model these projectiles. I've thought about treating each single projectile as a single object, but I'm afraid that there will be performance problem as long as I keep creating these projectiles in the game.

I've read this question also, but it seems that it's to quite suitable to my situation

Bullets and projectiles in component based entity systems

Any comments would be appreciated! :)

  • \$\begingroup\$ A good start would be to explain WHY the other question isn't quite suitable for your situation. And why "not quite" suitable, in which way is it suitable? What have you tried so far, and did you actually encounter performance issues, and did you track the issues down to the way you model projectiles? Show relevant code, how you call it, and which language you're using if it's not obvious. \$\endgroup\$
    – Hackworth
    Commented Nov 25, 2013 at 15:33
  • \$\begingroup\$ What I do when I have very very huge number of projectiles or object to update on a low power CPU, I update them once every two frame or more, for the less acurate operations. Collision check is still done every frame. You could skip some collision check if your frame are dropping \$\endgroup\$ Commented Nov 25, 2013 at 15:52

1 Answer 1


I have seen this accomplished in a number of ways. One in particular that I favor is creating a "pool" of projectiles, or a set -concrete number of objects that the game can never exceed. This will solve a number of issues,

  • Performance: You will always be able to test what happens when the max allowed projectiles are in game.
  • Memory: Hopefully you are taking measures to make sure your textures are only being used once (persistent/static). IE, the same texture memory address is being referenced by all the projectiles of type knife. From a memory standpoint -especially if you are working with a physics engine, having a set number of objects in a pool will keep your engine from having to consistently allocate and deallocate vectors.

Typically starting with a core layer projectile class that all projectiles inherit you will need the ability to determine if the projectile is currently being used or if it is inactive and hidden from view of the user. From there I would create a projectile management class that allows you to queue projectiles. The management class will simply not create anymore projectiles if the pool is empty.

From a performance standpoint I would then run a routine at 1/6 the frequency of the game updating engine -or even slower- to cleanup and detect stray projectiles (knives and hatchets that have flown off screen) -which will replenish your pool. At this point the projectile management class will mark the object as inactive in the physics engine and make the object invisible. Also great from a testing standpoint, by mashing on your fire button and using up all the projectiles in the pool -does the pool fill all the way back up with free projectiles when you stop firing? If you have a memory profiler -do you have a memory leak when all the projectiles are fired and restored to an inactive state?

Hope this helps!


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .