using the delete operator to remove objects from a game? C++?

Question

I am having a game, it is a simple tile-based platform-shooter, and I was wondering about this. If I have a rendering loop, that draws all enemies using a for loop, but first checks whether they 'exist'. Would it be appropriate to use 'exist' in terms of memory (if (enemy[i]) to check existence, delete enemy[i] to remove them from gameplay) or to use 'exist' in terms of gameplay (declare a local variable inside the enemies, if (enemy[i]->exists) to check for existence, enemy[i]->exists = false; to remove them from gameplay). Considering the enemies won't be seen for the entire level again, wouldn't it be smart just to remove them from memory? BTW, at level start, they are dynamically allocated, when read from a map file.

Answer 1

Why *are* they dynamically allocated? Are they intended to outlive the owner (which is the level, in your case, I am guessing from the description)

Create a vector, or another suitable container, holding the enemies. Make the vector a member of Level. When the enemy is gone, erase it from the container (call vector::erase()). The for loop in the renderer will not need any sort of existence checks.

Answer 2

construction of objects take time, so does destruction. There is also a term called memory fragmentation, which pops to mind, reading your question. So, in case you have "sufficient" memory display objects if display flag is turned on and don't if not. Appropriate is NOT only, what is working. You as a programmer have to be able (in case the program is a group effort) to leave the logic of your program as transparent as possible so that other people can use your logic in order to implement changes, corrections, add features, etc. Now, depending on your code - introducing another flag may have far more implications than you outline. Most of the "bigger" games store their stats, user preferences, user results, etc in databases. So in case you introduced another flag, this could mean a database change. In this case the obvious argumentation to "just" introduce another flag may become obsolete or very work intensive, depending on the current stat or setup of your program. What is appropriate is a given (i.e. by projects management, senior programmer, etc).

Answer 3

It would be easier on your logic, I think. Remove them from the "visible enemies" list and then either delete immediately, or add them to a "dead enemies list" if you need their stats or something for later scorekeeping calculations...and then delete them when you delete the dead enemies list.



If you just want to have one list, and just one place where enemies are deleted, then you could have methods like:



private:

bool alive;

public:

bool isAlive() { return alive; }

void setAlive(bool alive) { this.alive = alive; };



Putting the method body in the .h class definition like this gives you the same performance as adding a data field (no actual function call on any decent compiler) but also keeps the OOP separation between interface and implementation.

Answer 4

Go with the destructor. Once the enemies are gone, they're gone, right? There's no need to have them taking up memory.



If there aren't many enemies (not enough to bog down a computer), you can just go with the enemy[i]->exist route.

Answer 5

nicely, you're able to do it in case you choose. purely make sure that if there are the different regulations around additionally pointing to that merchandise, they upward push as much as date to boot and/or is purely not used in an risky way. That pronounced, the technique as you somewhat have it set up there probably won't artwork, simply by fact the pointer is being handed in by using fee, not by using reference. putting the close by pointer to null is variety of pointless (no pun meant).