Hi there!
I'm a professional developer, and recently discovered Etoys while looking for a language/environment suitable for my 9-year-old son to learn to code in. (These kids raised on Flash games don't seem to want to write programs with boring text-based interfaces.) Scratch is really cool, but it quickly became too limiting. Etoys, while a little less inviting than Scratch, has a lot of power hidden under the hood once you manage to find it. Many thanks to those who have made it happen... I've been having a lot of fun with it.
I've been writing a space-invaders clone (one of my first video games; I'm 41), and it's going pretty well... I've got dynamically created siblings for the invaders, and they change costumes (for the "marching" animation and the explosion) selected from a Holder, the "bullets" are dynamically created siblings. The shields are stamped onto the playfield, and when a bullet collides with one, an "explosion" the same color as the playfield is stamped onto the bullet's location to erase part of the shield. All of that is working very nicely.
But I'm having a problem with collision detection between the bullets and the invaders. The invaders don't actively watch for collisions. Each bullet does collision detection on each move, and I'm using the "bullet overlaps any invader" test. When it collides with an invader, it fires the "am I hit?" script on all invader siblings, so each invader checks to see if it's the one that's been hit. (I can't figure out how to find a handle for the object I've collided with so I can send it a message directly. That would be useful.)
But here's the problem:
My invaders are shaped like an 'M'... if the bullet hits them in the center, it detects a collision well before it touches any of the invader's non-transparent pixels, parallel with the lowest visible pixels. That is, if I draw an invisible box around the invader, the bullet detects "I overlap with" when it crosses the invisible line, not just when it collides with the visible pixels.
But, none of the invaders detect this hit. They only detect it if the bullet hits the leg of the 'M', so that the bullet is touching visible pixels of the invader. (To be clear on that, my code is working just fine if the pixels actually overlap.)
So at first I'm thinking that collision detection is "any of my pixels overlaps an invisible box drawn around the 'target'". Except I've done a lot of experiments... setting up an invader and bullet object with scripts that update a "I'm colliding" variable, so I can watch their status. The weird thing is, I can put the bullet between the legs of the 'M' so that it's not touching any invader pixels, but it's well past the line at which it normally registers a collision. In this little experiment, I can't get either to register a collision (using "I overlap with any foo") unless they actually have overlapping visible pixels. So that contradicts my "invisible box" theory. (Unless somehow the scripted "move and check" is different from the check happening when I use the mouse to move the bullet around. I wouldn't think so, but obviously something is different between the two situations.)
I'm sure I could switch to testing "I'm over color", but I'd like to be able to use more artistic invaders... I don't want them to be a uniform color. And I could redraw my invaders so that they don't present such a large "opening". Or I could give the invaders a background color that matches the playfield instead of a transparent background.
But it seems to me that something isn't working right (collisions should always be mutual, not one-sided), and I'd like to understand why it's not acting as expected, and why "move 5 and test" gives different results than manually placing the objects. And if what I'm having trouble with is "normal" behavior, I'd like to know that so I can quit beating my head against this wall and implement a workaround instead of searching for the "correct" solution.
(Yeah, I prefer an "elegant" solution. But if it's clear that I have to work around a known behavior, then I have to work around it. I just don't want to write a kludge if there's a known best-practice that solves the problem properly.)
I'm not sure what the standard is for sharing code... I can post the project if looking at it would be helpful. Just tell me where and how.
Thanks!
--
Carl D Cravens (raven(a)phoenyx.net)
A conclusion is the place where you got tired of thinking.
