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.

The importance of starting small.

It's hard to convince new BGE users that they should try to replicate the mechanics of some very simple 2D games before doing anything more complex. They try a few logic bricks, they snag a few working scripts, they see all this complex behavior just work, and they think: "If I were to make a whole game, it would only be slightly more complex than this.".

The BGE is a great tool, but it can trick the unsuspecting user into thinking that game development is easy. Well, it's not; game development is still software engineering, and software engineering is hard. I mean, even with something like break-out, the details behind such a seemingly simple game are quite challenging, especially for someone who is unfamiliar with the BGE.

So, while I'm sure that your FPS-MMORPG uber game is "awesome", and that you are indeed capable of learning everything required to make it work "as you go along", I think you should start by re-creating a simple game of break-out first.

Not only will you learn a lot about how the BGE works, but you'll also get a sense of what you're able to do, and what exactly defines a *realistic* project for a single developer with your particular skills. It's an important perspective to have, because otherwise, you'll probably start on some overly ambitious project, spend a year on it, and then realize that you don't really understand any of the scripts you're using, and that everything in your game is a jumbled mess of things that can't be changed without essentially redoing the whole project.

Now, some will say that even overly-ambitious projects are ultimately a learning experience, and that, as such, they should be encouraged. This is partially right: yes, everything is a "learning experience" (this includes failure), but there is a difference in how many lessons are learned, and how long it took to learn them.

Also, there is something to be said about the difference between failure, and *graceful* failure.

With an overly ambitious project, which becomes abandoned after something like a year (or maybe even a few months), the lessons learned are few:

1. You bit off more than you could chew.
2. Using other people's code without understanding it first was a mistake.
   
3. The people on BA didn't want to make your game for you.
4. Game development is hard, even with the BGE.

Ok, so you probably learned a few technical details about the game engine as well, but my point is simply that you could have learned *a lot* more, in a significantly shorter period of time, by pursuing more realistic goals.

And, as an added bonus, you would actually have a complete game that your friends/family could play.

Yes, this is a BGE blog.

In my 5 years of using Blender, and, more specifically, the BGE (Blender Game Engine), I have seen my share of BGE related blogs.

Here's why most of them suck:

1. They're written by people who know very little, if anything, about the BGE, or the BGE community.
2. They don't have a cool blog name, accompanied by a thoroughly awesome banner.
3. They're written by people who are just down-right boring, and who should just spare us the 497th update relating to some unrealistic project that we all know they're never going to finish.

I'm not promising that this blog won't suck, but if it does, it won't be for any of the reasons listed above.

I'll basically use this space as a soap-box to talk about my thoughts relating to the BGE (obviously), the people who use it, the games they (try to) make, tips, tricks, quips, my anger when someone posts a 10 MB .blend and asks: "What's wrong with this?"....and so on.

Right now, I plan for one entry per week, which should be just enough time to absorb something new and interesting on the forums, and then put it all in perspective here, at "The Blend With No Name".