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

On 2009-11-27 20:13, Bert Freudenberg wrote:

On 27.11.2009, at 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.

Great!

...

I've been writing a space-invaders clone

Yay! :)

Looks like the "overlaps any" is buggy - there is some offset in the overlap test:

There was a bug in Morph>>overlapShadowForm:bounds: Suggested fix attached.

Karl

...

(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.)

Indeed, that would be useful. But we don't really have collision detection yet. The canonical way is to do color tests.

...

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.

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.

...

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.

You could upload it to the squeakland showcase:

http://squeakland.org/showcase/

• Bert -

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!

On Tuesday 01 December 2009 04:12:58 am Carl Cravens 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. :)

You have to make sure that your son is at a stage where he can handle thoughts like "If I were a bullet what would I do....?". Etoys can then enable him to translate those "whens" and "ifs" into a script. The goal here is not so much to create a full-fledged game but to motivate, enable and strengthen such ways of thinking. The output may look crude to people used to flashy (pun intended :-)) games but its author would have learnt many concepts in the process. Etoys is like dumbbells for brain cells.

In this particular case, create a uniquely colored marker morph (normally hidden) and have the bullet "show" it at a hit spot when collision is detected. Other objects can detect overlap with marker's color, hide it and then trigger an 'explosion' script.

Tip: do not use the test "overlaps color" directly in all scripts to detect collisions. Use a separate script "collision" for the test block and then call it from other scripts. When you decide to change the colors, only one script needs to be changed. A good opportunity to introduce the concept of "hiding implementations".

Subbu