Following a tutorial in a paper-back book to learn to make a basic game in Snap.
A crab sprite, which follows the mouse-pointer has to run away from some endlessly generating octapodes/octapuses/octopi, which follow the crab.
The game is meant to end when any of the octopus sprites touch the players crab sprite.
There seems to be a bug in that sometimes it works fine and other times, it ends the game even when the sprites are not touching. This can occur anywhere from within a few seconds to a couple of minutes.
Hello, VeganPete. I have had this problem, and I believe it has to do with the game crashing. If you have too many clones in your stage, then snap! won't be able to keep up with all the clones' information. I suggest maybe having a death timer for the octopus and giving them a random spawn point. This may lead to octopuses spawning on the crab, but you can simply add a few blocks to prevent that.
I hope this was helpful!
@scratchdude17 Snap! can handle quite a lot of clones, thousands of them on a modern computer. And you'd notice an overall slowdown, e.g. jerky motion of the sprites, before you'd see incorrect behavior due to overload.
@veganpete I looked at your code and it seems fine to me. I have a suggestion for debugging: Replace the BROADCAST [END SIM] with PAUSE ALL, so that when the game ends you can see what's touching what. And maybe uncheck Draggable for the two sprites. I couldn't get it to fail, but I'm only an adult so I never get past three octopodes. Sometimes I hit one even with only two of them onstage.
Maybe it's race condition. Zorg sprite starts as visible at full size then shrinks to 50%. Try swap "show" and "set size" instructions or even move booth before sprite collision loop to ensure ordered execution.
I'm an absolutely shiny noob with snap!; the first chapter in The Coding Book has been my intro, so I wasn't even aware of PAUSE ALL but I came at it from a different angle by stepping through the code instead.
I noticed that clones of Zorg seemed to first spawn at co-ordinates 0,0, i.e. on top of and therefore colliding with the initial position of Agent X, before THEN being re-drawn at x: -200, y: -140.
I eventually worked around the issue by initialising Agent X well away from the centre of the arena, in the diagonally opposite corner at x: 200, y: 140.
Is there an undocumented 'feature' in the underlying code that initialises a sprite at 0,0, before the user's instruction 'go to x: -200 y: -140' can be obeyed? Is it possible that a revision to the underlying code has introduced such an undocumented feature since the book was written?
What I find curious is how this got through testing before being incorporated into the book, but this rings a bell from my old system testing days.
As a complete snap! noob, I have nothing on my machine that could affect the execution of the code, but I've seen code that has passed all tests on a developer's machine, only for the code to fail on a fresh box.
Is it possible that the code (as presented in the book) is relying on something that's (only) in a library on a typical developer's box?
So, going back to what I saw on step-through, that still leaves us with no explanation as to how clones of Zorg seem to first spawn at co-ordinates 0,0, i.e. on top of and therefore colliding with the initial position of Agent X, before THEN being re-drawn at x: -200, y: -140.
(0,0) is center of the stage.
"Master" (the one to be cloned) Zorg sprite is not at (0,0)?
There are checkboxes "x position", "y position" on Motion tab to verify sprite position.
Yep, agreed that 0,0 is the centre of the stage. As given on page 23, final version at the bottom of panel 4 of The Code Book, the block for Zorg should look like this:
when I start as a clone
show
go to x: -200 y: -140
set size to 50%
The expected result should be that Zorg spawns at x: -200 y: -140.
The actual result (when stepping through) is that Zorg unexpectedly spawns at x: 0 y: 0 and THEN spawns at x: -200 y : -140.
So the question remains: what is causing Zorg to FIRST spawn at the 0,0 centre of the stage (when the code (as read) specifically does not specify that behaviour) before THEN executing the appearance at -200, -140 as coded ?
The entirely laudable goal of this book is supposed to be a gentle introduction to coding for kids and I do note the workarounds above where the show and set size instructions have been swapped around, but these kids should expect the code to behave as specified. As it stands, it's serving as a less-than-gentle introduction to bug-hunting.
No, that's not what this code says should happen at all!
Clones are created at the exact position of their parent. If you would like the clone to first appear at a different location that's fine if the parent is hidden, because then the clone will be hidden, too. Hidden sprites can themselves sense collision with other clones but cannot be sensed to collide by other sprites.
BUT once you SHOW the clone, which in your example code happens BEFORE you move it elsewhere, it can and will collide with whatever is at the original (i.e. the parent's) position,.
BUT once you SHOW the clone, which in your example code happens BEFORE you move it elsewhere, it can and will collide with whatever is at the original (i.e. the parent's) position.
Then you've just proved my argument; it's not MY code but the code as given in the book, which SHOWs the clone before moving it elsewhere.
Can we agree therefore that the book is in error? And if so, how did it get through testing? What's at issue here is that any snap! noob, and especially the target audience of kids coming to coding for the first time won't be aware of the SHOW behaviour which you've outlined above.
That said, though, I do appreciate and thank you for your very helpful explanation - I can see now how the sprite is protected while still hidden.
Thank you.