[squeakland] Collision detection, only one object detects the collision

[Karl Ramberg]

On 2009-11-27 06:59, Carl Cravens wrote:
> 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!
>
Hi,
there are some issues with the 'overlap any foo' test.
There is a case where both 'bullet' and 'target' were the same class 
like sketch it would not exclude 'bullet'  from collision detection, it 
would always be true.
The detection is done by making one bit images of both bullet and target 
and combining the two with rule 'and', any pixels in resulting image 
being 1 is a collision.

You can always look at the source code by bringing up the World menu 
with alt-shift-w and open/browser etc.

Karl