Which approach would you take?

K

krugen

Guest
Having work with GMS2 for a month now, I notice a little something.

You have two objects, obj_a and obj_b

obj_a created obj_b

obj_b can be created and destroyed anytime obj_a wishes so

The process to create obj_b occurs in obj_a's step code

Whatever happens to ob_b will not impact the decision of obj_a to destroy obj_b

Here is my question:

To destroy obj_b, which approach would you take?
a) Destroy obj_b directly using its id directly from obj_a
b) Set the value of a check variable in obj_b such that when obj_b read the condition during its step time, it will destroy itself
c) Have obj_b checks the status of a variable in obj_a using the id of obj_a, depending on its status, obj_b will destroy itself. This is the same as (b) except instead of setting obj_b's variable, you are setting your own variable.
 

tagwolf

Member
My answer is, it depends but sometimes BOTH makes sense. For example in my rocket jump game, I spawn obj_rocket from the player and because of the way I read collisions, I destroy it from the player using instance nearest in the event of a rocket jump because I need to read variables from the rocket BEFORE it is destroyed.

But if the rocket hits a wall or expires, I destroy it form the rocket using alarms and collision events on itself. If I was spawning bullets though, I would put the destroy logic in the bullet itself probably in alarm and collision events. Though I might have an enemy object destroy the bullet if I needed it to read things from the bullet first.

You'll figure out naturally where it makes the most sense to put it based on the game you are making and where the logic works best (with the least amount of code and referencing "other" object) and where you need to read variables from and when.

In general, it's best to manage things in as few places as possible provided it doesn't make your code a nightmare. It's always a balancing act between object management and code management. And try to avoid passing variables back and forth (double writing them) if they are already stored in an existing object.

The extreme edge of the spectrum is to have a game manager object and put ALL logic in it. I wouldn't recommend this outside of managing game state.

If you have a specific context example I might be able to offer better advice. But I hope some of this helps a little bit.
 
Last edited:

Binsk

Member
Its all preference so I'll just give you my opinion of how I personally prefer to do it.

I would choose depending on why the object is being destroyed. If it is something related to obj_b, such as the object colliding with an enemy or something like that, then I'd let obj_b handle the destruction.

Let's say obj_a was a controller and counts down to the destruction of all obj_bs or something like that then I would let obj_a call the destruction.

Essentially I usually have the cause bring about the effect. The reason for this is because that is just how my brain thinks when I'm programming. Because that's what feels natural in my head that means that it will be easy to find the code when I need to later because it is where I will think to look first.
 
Top