Well ...
Perhaps what should happen is that when you drag the "bounce" tile line to the desktop it should show its meaning as an Etoy script.
Bounce is more or less writable directly in Etoys so it would be easy for a user to see just what it does and how. Interesting question would be what to expose about "forward" in order to make this happen. Probably the Snell's law way of looking at things is the most intuitive for end-users.
It could also be renamed to avoid bad guesses about what it might do (but simply showing an Etoy version of it would be good).
The simplest thing to do would be for this scriptor to resist editing and just tell the user so -- or, it could even allow itself to be edited (with the modifications running much slower than the internal def of bounce did).
Cheers,
Alan
At 06:06 AM 1/9/2007, Scott Wallace wrote:
Hi, Bob,
Short answer: The "bounce" of etoys doesn't do what you, or any reasonable person, might expect it to. So yes, you are best off computing coordinates directly in your own scripts, rather than trying to use "bounce".
Within its limited range of ability, "bounce" can be useful for keeping moving objects onscreen without too much effort.
Beyond that, however, "bounce" is a pretty strange beast, best avoided.
However, for anyone still interested, read on...
When I tell a ball "Ball forward by 10" I expect to see it move forward, and it does. When I tell a ball "Ball bounce croak", I might well expect to see and hear something happen, some sort of reversal of direction, some sort of froggy sound, but instead it doesn't seem to do anything. Why is that?
It's because Squeak's "bounce" has a very narrow and less-than- obvious meaning, something along the lines of: "If I've just crossed the edge of my container, then change my direction and position to make me appear to have just bounced off the edge and returned to the interior."
Unless scripts affecting the position of your object have just made it cross the edge of its container (from a position previously wholly within the container,) telling it to "bounce" will appear to have no effect. Unlike any other etoy command, it has its own implicit, built-in "conditional" or "Test" having to do with the motion brought about by currently-running scripts, relative to where the edges of the container are. This bit of magic can be used to nice effect in some demos, but in practice it's pretty strange if you try to harness it for anything interesting.
To meet the beast head-on, paint a Frog, rotate it slightly, drop it into a Playfield, then build the script:
Frog forward by 5 Frog bounce croakWhen you set this script to ticking, the Frog repeatedly goes forward by 5 units, but it does not repeatedly "bounce", by any reasonable interpretation of the word "bounce", nor does it croak -- in fact the bounce request doesn't seem to do anything at all.
Until... the Frog approaches the boundary of its container. When it reaches or crosses such an edge, because of the "bounce" command, it magically gets its heading, its x, and its y adjusted to give the appearance of "bouncing off the edge of the container". And only then is the croak heard.
This is all that "bounce" can do. You don't get to choose what the object is to bounce off *of* (if the bounce does happen, it will always bounce off of whatever edge of its container it has just crossed,) nor by how *much* it should bounce (that is computed based on its imputed speed, which is based on where it was before and where it would be without the bounce afterward) -- nor even *when* the bounce will take place (that is based on the "just-reached-edge-of- container" test implicitly built into the "bounce" command.)
So to summarize... because of the above limitations, and because or the maddening fact that when you tell an object to bounce it usually does nothing, I do not recommend using "bounce" for anything except for those familiar, simple "forward by/bounce" scripts.
It would be interesting to hear some suggestions and discussion on this list regarding possible improvements to the set of commands in the standard etoy vocabulary.
Cheers,
-- Scott
On Jan 5, 2007, at 4:00 PM, Bob Irving wrote:
Hi all,
I've been doing some searching on this topic and haven't been able to find answers to my questions. So....
I'm trying to use the bounce command in games (like Pong). Can anyone explain to me -
- Does bounce require a playfield to bounce off? I've tried
testing to see if a ball's color see the color of a wall, and then bouncing if it does. But that doesn't seem to work. I know the ball's color can see the wall's color, because I've also had it croak if it sees the wall. The ball croaks and keeps on going through the wall.
- Exactly how is the bounce calculated? When I put the ball in a
playfield, then make a colored box the same size as the playfield, it will bounce and most of the time the bounce is "true". Every so often the bounce is the opposite of what you expect. Does anyone know why this is? Would I be better off to use a variable for the heading and calculate it, thus inducing the correct "bounce"?
I hope these questions are clear.
Thanks in advance,
Bob Irving Middle School Technology Facilitator Lancaster Country Day School Lancaster, PA Blog: http://cougar.e-lcds.org/wordpress/ "In times of change, learners inherit the earth, while the Learned find themselves equipped to deal with a world that no longer exists." Eric Hoffer _______________________________________________ Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland