I currently have a structure where every object in the game that has the capability to shoot has an array of missile objects created within it, and it creates new missiles out of it''s own cache. But I''m wondering, is it better to have every object owning it''s own missiles (which all behave the same after they have been created - moving down the screen), or should I have a central missile storage area? This central storage area would be a class that simply creates a new missile when any object requests one. I would no longer have missiles managed in each object, but instead one central missile storage area. These missiles would be stored in a linked list, and created and deleted as needed. OR, is it too slow to keep creating and deleting missiles all the time? If that''s the case, I''ll have an allocated array of missile objects, and the linked list would refer to those created objects. Currently my particle system works like that. Particles are created in a linked list, but the actual particle objects are stored in an array, which the list refers to. I did this because I found that constantly having particles being created and deleted with "new" and "delete" lagged my game. Ideas? Thanks.

i use new and delete for all of my objects, including particles. I can have thousands going at once with no noticable impact on my game. I''ve tried it both ways. For technical reasons however, i''m sticking with dynamic allocation.

If you''re worried about a couple of missles, you have bigger things to worry about :-) Unless you have hundreds of thousands of these things, i wouldn''t worry about it.

Personally, i''d keep management seperate, just in case you end up developing different types of missiles. Now i can shoot BasicMissle, and another object can shoot HeatSeakingMissle, and so on...

Put them in a central storage area. And you''re right about new / deleting 100s of times a frame. Just have something like bIsActive and if its false, use that with new values. Only if all your missiles are active, should you add new ones.

Make sure you store a pointer to the entity that "owns" them though, like CBaseEntity *pOwner.

That way you can keep track of frags / kills and such (may not be as important to your game now but one day it probably will be).

You can also stop players from dying to their own missiles or whatever effects you want, by storing the owner.

I''d recommend that you do object management the same for all types of object, including missiles.

Missiles should, as leiavoia said, keep track of who fired them for frags accounting / score (and also because you probably want to implicitly prevent missiles from killing their owner; they will probably start in contact with their owner.).

Also they may need to keep track of who they''re targetting if they are homing missiles.

Be careful you don''t end up with dangling pointers if the owner or target gets destroyed while the missile is still flying.

Mark

That shouldn''t be a problem at this point. I''m making just a basic shooter game (2D), and all the missiles do is go forward until they hit something or go off the screen. They have no notion of targets. All they know is that when the collision detection engine says they are hit, they die. :-)

*pffff*

No fun :-)

Haha. Don''t worry, all I have to do is add entries for "ownership" and "target" to the missile class, and with very little work it''s done. :-P

Ok, the restructuring is done, and the improvements are significant!

Before I had 30 aliens, each with an array of 20 missiles, one hero with 100 missiles, and a boss alien with 120 missiles. That''s 820 missiles.

NOW, I dynamically create missiles on the fly by contacting a missile management class. This class handles creating and destroying missiles automatically. It''s awesome. And I use maybe 40 missiles at a time. That''s it! Let''s do some math:

40/820 = 4.9%

That means I''ve decreased the bloat by 95%! I like! :-D