Collision detection, only one object detects the collision

> 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!
>

>
> Thanks for all the responses on this.
>
> Bert Freudenberg wrote:
>
>> What if the bullet does a "I'm not over the background" test?
>> But yes, in general Etoys is set up not to make things pretty but to
>> allow the principles to be applied directly.
>
> My nine-year-old likes "pretty".  He wants to write Flash games, but getting the tools set up on Linux to achieve "hello world" seems to be a monumental task. :)
>
> The bullet needs to detect collisions with four different kinds of things (invader, base shield, bonus saucer, and invader bomb).  In three cases, they're more or less the same thing... some other object with its own collision scripts.  In the case of the shield, that's just a stamp on the background, and I'm using "over color" there.
>
> I could use "not over background color" but I still have to get the right object to respond to the collision, which means signaling *everything* to check if it's been hit, and not just one "class" of object.  For now, seeing as I've uncovered a bug, I've switched to "over color" detection and that's working fine.  But "foo overlaps with any bar" seems to be the ideal tool for what I'm doing.  (Though I'm getting a hint here that it may not be as efficient as detecting simple color overlaps.)
>
> This is turning into a much more complicated project than I expected.  That's good... I've learned a lot about Etoys in a short time.  It's been a fun challenge, and I feel pretty prepared for my son's questions.
>
> Thanks!
> --
> Carl D Cravens ([hidden email])