I'm just a little confused at the moment. I'm making a 2d space shooter with SDL and C++. Whats the general process for making the enemies on screen shoot? How should I go about creating bullets for them?

What I mean is how do I create and store bullets? I got the player to shoot perfectly. For the player I just used a vector to store the bullets. But now I'm dealing with numerous enemies so how would I go about it?

Is it siimilar to:

Loop through enemy

enemy.createBullet();

I have something like this but it doesnt really work.

What I do is I have a bullet system that owns all of this stuff and the enemies and player just ask it to create one for it and they get a handle to this object. This allows me to reuse old bullets for new ones so I have less memory allocation.

That: make sure you never ever create new instances if you can reuse old ones. Easy rookie mistake to avoid (and you won't end up asking yourself why its starting to lag after a while...)

Megallion, you should post some of your code so that we can see where the problem is. Right now, it sounds vague. There are a gazillion ways to make bullets, and chances are, what you might be doing isn't one of them...\\

Here are a question to ask yourself:

When do enemies shoot? Is it after a predetermined set of interval, e.g. every 2 seconds, 1 second, 10 seconds? or is it triggered by a specific event in the game, e.g. player happens to be in the line of sight? Or perhaps a specific frame in an animation? Just like the player shoots after the player presses the shoot button, enemies need their own triggers too. The only difference is that instead of having the human player initiates the trigger (pressing a button), the trigger for the enemies must come from within the game code itself.

Once you have determined the trigger, then it's a matter of calling that createBullet() function from that trigger.

If you have organized your game objects such that the player and enemies share a common interface to shoot bullets, then having the enemies shoot is just the same as having the player shoots.

if (shootButton.pressed()) {
    playerShip.createBullet();
}

if (enemyTrigger.shoot()) {
    enemyShip.createBullet();
}

Since it looks like we're doing this piecemeal, some additional tidbits.

While you are unlikely to stress the computer with the style of game you described, you can get into somewhat good habits of being cache friendly. Don't obsess overmuch about these, but as you reach a larger scale they become important.

For small temporary objects like this it is generally good to work with pools, activating and deactivating objects as needed. Allocations take a relatively large amount of time, and if you are creating and destroying thousands of bullet objects every second, that is wasted time. Instead maintain object pools that have a live/dead or active/inactive or similar state. Depending on the situation it might make sense to keep them partitioned so all the live items come first then you can stop processing, or it might make sense to traverse the entire collection of both live and dead items every step.

Pools as organization can be very effective for bulk processing, especially for processing particle-like objects such as bullets. Can each side's bullet have friendly fire? If every bullet can hit everything then a single pool of bullets might work well. If there are friendly fire rules the pools can accomodate that as they are processed. Perhaps have an "AI bad guys" pool and a general "all players" pool if there is no friendly fire between players. Or perhaps an array of pools for each player if they can friendly fire other players but not friendly fire themselves.

As you process the pools, be cache friendly. The cost of loading data is expensive. Crossing the boundaries is roughly an exponential performance penalty. There are all kinds of good books and descriptions and studies, but here's a quick and fun little toy that demonstrates it rather clearly. If you are working with larger data sets there are very clear performance steps as you exceed the various cache size boundaries.

Ensure that these little particles are small and well-aligned. Cache lines are typically 64 bytes these days, so if you're processing them linearly it can work great as the processor can detect when you are nearing the end of your cache and prefetch more data. For a 2D space shooter you likely can store 2 16-bit numbers for position and 1 or 2 8-bit numbers for direction, if each structure is 8 bytes you can have an array of tens of thousands of bullets, something like a bullet storm.

So if you have a non-swept collision you might have a loop over every bullet, test the active/inactive flag, read the direction and speed it travels, then adjust its velocity, test the new position bounding box against the player sprite bounding box, potentially queue up if the bullet needs extra processing for a collision, and advance to the next bullet.

Of course, considering that the modern L1 data cache is around 32K, and the L2 cache is around 256K, assuming you are letting your video card do all the rendering work and your audio card do the audio work, your memory caches will have plenty of free space for your 2D simulation even if you are very sloppy about it.