views:

115

answers:

2

I've been starting to get into game development; I've done some tutorials and read lots of articles but one thing I'm not sure about is what is the best way to manage large numbers of temporary objects, e.g. bullets.

Should each entity manage its own bullets, should I have a global bullet manager or should I create each bullet as a new full-blown individual object (that seems pretty inefficient though)?

Also, when using a component pattern what should I do about properties that seems generic, e.g. position, velocity, etc..? Some stuff I've read seem to think that everything should be in some kind of component while others seem to think that generic properties that will be commonly accessed by a variety of components should be a member of the entity class itself.

Forgive me, these are probably simple but I want to make sure I'm thinking in the right direction.

Thank you very much!

+3  A: 

Creating each bullet as a "fully blown object" shouldn't be too inefficient - have a look at the Object pool pattern, which outlines a way to speed up these object creations.

As for your question re: components and generic properties, it depends on how strictly you wish to follow the component architecture. If you want to be really strict with the component architecture, every property should be in a component and different components should talk to each other. Otherwise, for efficiency reasons, share some properties in the main object. For more information, have a look at this page on the component behavioural pattern.

a_m0d
Thank you, I never thought of using an object pool for bullets.Good thing Stack Overflow exists, otherwise we'd miss out on all kinds of clever solutions.If anybody else has anything to add I'd like to hear it and learn.
JamesK89
+2  A: 

The original Quake uses a fixed-size pool for entities (which are also sometimes called edicts). Anything whose existence persists between frames is an entity. This includes "shaped physical" things like the world and doors, rectangular physical things like monsters, players, and nails, movetype-transparent things like weapons, invisible but touchable rectangular things like trigger fields, and entirely-nonphysical things like delay events.

I think the limit in Quake is something like 700 edicts; the game will crash if the limit is exceeded. I think edicts are simply stored in an array, since every property which exists for any edict exists for all of them.

supercat