Every death is a suicide.

Heh, I wonder if that title triggered any filter software on blogspot? Anyway, I'm referring to how one would "kill" game objects in the BGE, and how the "end object" actuator is a construct that ultimately contradicts common sense.

Let's say you have a missile object, tracking to your player object, and you want the missile to "kill" the player on contact, removing him from the game-space; How would you set that up? Well, there are different ways to do it (luckily), but the way that the logic-brick system was designed for, and that the current implementation promotes, is this:

• Set up a collision sensor on the player to detect the missile.
• Connect that with an "and controller".
• Connect the end of that controller to the Edit Object->End Object actuator.

Ok, that's not all that complicated, and my argument isn't based on the level of complexity involved here, but note that the logic for killing the player is on the player itself. Think about that for a minute; It doesn't matter what the situation, the only way for the player to die (using this method) is for the player to determine that he/she *should* be dead, and then essentially commit suicide. And it's here that we arrive at a somewhat philosophical conclusion regarding resource management in the BGE (from a users perspective):

Every death is a suicide.

Is that wrong? Well, I believe it is. Yes, it would be great if things worked like that in the real world, because then we could all just decide that every attempt on our life was a failure, be it an attempt of some specific enemy with a bazooka, or just of nature itself. But, in the BGE, I prefer my deaths to follow the cold hard logic of our current reality as closely as possible. The two primary reasons for my preference:

1. It makes "real-world" sense, which is important for humans who developed their logic in the real world, and who now want to use that base of understanding in game design.
2. It's better in an organizational sense.

#1 is obvious, but to elaborate on #2: The very nature of a missile is to destroy, so the fact that the details of that destruction (what collapses, who dies, etc) are contained within the missile keeps all the other objects uncluttered. I mean, having a whole set of conditions on the player object just to detect when something is "hurting you", and if and when you have to die........That may not seem like a lot of code, and depending on your game, it may be relatively little, but if you have more than one object that needs to die, you'll have to write those checks for all of them.

Isn't it better to just have one missile that would "know" how to kill multiple objects?

In BGE python, every game object comes with an endObject() method, which, when executed, removes that object from the game space. This was a recent change in the API (I think), and a very useful one, because now you can just set a collision sensor on the missile object, use the hitObject attribute to get the object involved in the collision, and then subsequently kill it, by calling collision_sen.hitObject.endObject().

That's the way I do things, and that's the method I recommend.