Scratch

Man, that gives me the creeps!  Too many bugs! 


What are the rules regarding spider combat? 

The only thing I see that is going to cause a problem is the reproduction.  Scratch, as you know, can't make sprites on the fly so you will have to create all sprites that are ever going to be needed.  If the reproduction occurs too often, you are going to run out of sprites.

Paddle2See wrote:

Man, that gives me the creeps!  Too many bugs! 


What are the rules regarding spider combat? 

The only thing I see that is going to cause a problem is the reproduction.  Scratch, as you know, can't make sprites on the fly so you will have to create all sprites that are ever going to be needed.  If the reproduction occurs too often, you are going to run out of sprites.

The world is initially populated with 77 live spiders.  Originally, I had a lot more but because of space limitations, I cut it back to 77 so they wouldn't be bunched too closely together at the beginning.

When you click Run, every spider goes off in its own direction.  When two spiders collide, they do a little battle dance and then either they separate and both go off on their way or one dies and the other goes off on its way.  The probability of death for each spider at each encounter is 0.05.

Dead spiders lay where they died and are subsequently ignored by live spiders.

Every time you click the world with the mouse, every live spider reproduces, producing one offspring each.  Therefore, if you click the world a few times shortly after clicking the Run button, the world becomes a seething mass with hundreds and possibly even thousands of spiders, with most of them being still alive and moving around.  Once the number of live spiders exceeds about 800, my computer bogs down and starts running the animation rather jerkily.

I don't think that this is the same as Scratch stamping as someone suggested.  As far as I know, stamped sprites in Scratch are not alive and can't move.  I may be wrong, but I believe that they are simply fixed images that are superimposed on the background.

Last edited by dbal (2008-07-04 21:04:26)

Paddle2See wrote:

You could use Stamping...by using Stamp animation where you clear the screen then redraw.  However, you would have to keep track of the state of all the spiders so they could be redrawn at the right position, direction and so on.  This would require a lot of variables.  Also, the animation would be jerky. 

Stamping can be used to render the dead spiders though.  Couple that with my "Rock Recycling System" (it becomes a Spider Recycling System) that I developed for Scratchoids and I think you could make a pretty good version of the game.

In Scratchoids (an Asteroids rip-off), I designed a Rock Sprite that responded to rock creation requests made by a controlling script.  As rocks were "destroyed" in the game, they would return to the rock pool and wait for another rock request.  This would work well for spiders too.  You might have to build a Spider Request Queue however, to handle the large number of spider requests that are likely to occur nearly simultaneously, due to the strange reproductive behavior of this Spiderus Dbalus species...

Having been very favorably impressed by some of your earlier work, I'm convinced that if anyone could find a way to force Scratch to accomplish this, you could.

I'm sure that you already know this but others may not.  Only about 70 Java statements were required to write this program and that number, consisting mainly of control code, is largely independent of the number of spiders.  Increasing the number of spiders to hundreds or even thousands would not increase the size of the Java version of the program.  However, keeping track of the state (x, y, orientation, and life) of each of the 77 individual spiders using variables would probably require at least 308 variables, so not even counting control code, the Scratch program would be more than four times the size of the Java program for only 77 spiders.  Beyond that, the size of the Scratch program would be roughly proportional to the number of spiders.  This begs for the addition of some sort of data structure capability (such as Jen's list) in Scratch to help students begin to learn about scalability.

I would be interested in seeing an implementation and comparison between two Scratch versions of the program.  Perhaps one with ten spiders and one with 20 spiders to illustrate what happens as the volume of data expands for a Scratch program.  Both versions should also include the reproduction feature.  Some scratchers seem to be fond of writing tutorial projects in Scratch.  Maybe one of them would be willing to take this on as a way to educate the less-capable scratchers regarding the strengths and weaknesses of Scratch as compared to other programming languages.

dbal wrote:

...Maybe one of them would be willing to take this on as a way to educate the less-capable scratchers regarding the strengths and weaknesses of Scratch as compared to other programming languages.

Hi Dick. I'd love to see something like this. I've been looking around for some discussion of how to minimize bad software engineering practices with Scratch, such as duplicate code and lack of modularity. I see student code with the same sprite duplicated tens of times, and many other code smells.

I've been using broadcast just to get some modularity and self-documentation. At least I can name a section of code.

Something else that I would be interested in is some sort of external sprite editor. Perhaps a Netbeans or Eclipse plugin for editing Scratch sprites, maybe even with some refactoring support.

Dave Briccetti
http://www.davebsoft.com

Paddle2See wrote:

Here is my attempt.  Note that I am using color sensing for the spiders to tell when they contact each other as Scratch has no generic "when touching any sprite" sense.  So dead spiders are now gray to keep them from triggering the sensing.  I made fighting spiders have red bodies because I thought it would look better. 


http://scratch.mit.edu/projects/Paddle2SeeFixIt/206878

The version online has a 51 spider pool and starts off with 36 spiders.  I suggest you let the spider populationo get pretty low (below 26) before sending a Reproduce command.

As you have pointed out, Scratch is not the ideal language for this application primarily because it doesn't support runtime creation of sprites.  However, I was able to build this application without any typing or syntax errors due to the drag-and-drop interface and the results are resonable for a language that was intentionally slowed down for educational purposes.

Very good!  I'm impressed with the results.  Of course as a computer science professor, I would prefer to see a lot less redundancy, but I certainly can't quarrel with the results.

As time goes on, just for fun, I may post additional challenges.  Thanks for responding.

Last edited by dbal (2008-07-06 10:22:59)

Paddle2See wrote:

Thank goodness for the Shift Copy and the Shift Cut commands (allowing mulitple Copy and Cut operations without having to reselect the Copy or Cut tools)!

what is that function it sounds useful.  for my last project i copied about 15 star sprites twice using the copy tool.

Paddle2See wrote:

dbal wrote:

Very good!  I'm impressed with the results.  Of course as a computer science professor, I would prefer to see a lot less redundancy, but I certainly can't quarrel with the results.

As an experienced computer programmer, I have to agree with you...redundancy is a bad thing...but you work with what you have.  When I build a project like this, I work with one master sprite and rough out what it is supposed to do.  Then, I debug with a small number of copies of the master sprite.  Finally, I copy the master up to the full number of sprites I want the project to have.  Still, I probably ended up deleting and rebuilding the sprite copies 20 times.  Thank goodness for the Shift Copy and the Shift Cut commands (allowing mulitple Copy and Cut operations without having to reselect the Copy or Cut tools)!

And thank you, Dbal, for the interesting challenge.

As neither a computer programmer nor a computer science professor, my humble opinion is that Paddle2See's version is pretty impressive! It even has state-dependent color. I'd like to see a Greenfoot implementation of _his_ program 

chalkmarrow wrote:

Paddle2See wrote:

dbal wrote:

Very good!  I'm impressed with the results.  Of course as a computer science professor, I would prefer to see a lot less redundancy, but I certainly can't quarrel with the results.

As an experienced computer programmer, I have to agree with you...redundancy is a bad thing...but you work with what you have.  When I build a project like this, I work with one master sprite and rough out what it is supposed to do.  Then, I debug with a small number of copies of the master sprite.  Finally, I copy the master up to the full number of sprites I want the project to have.  Still, I probably ended up deleting and rebuilding the sprite copies 20 times.  Thank goodness for the Shift Copy and the Shift Cut commands (allowing mulitple Copy and Cut operations without having to reselect the Copy or Cut tools)!

And thank you, Dbal, for the interesting challenge.

As neither a computer programmer nor a computer science professor, my humble opinion is that Paddle2See's version is pretty impressive! It even has state-dependent color. I'd like to see a Greenfoot implementation of _his_ program 

The thing that is impressive about Paddle2See's implementation is that he was able to accomplish it (with a severe limitation on the number of spiders, a huge amount of code redundancy, and a severe restriction on dynamic reproductive behavior) in Scratch.  (Code redundancy is not something that we should be teaching the next generation of computer scientists.)  But a famous football coach once said something like "You dance with who brung you." and Paddle2See had to work with the tools that he had available.  Given those tools, he did an outstanding job.

The state-dependent color is interesting and does produce an interesting effect.  I may give that a try once I figure out how to create a red spider image.

dbal wrote:

chalkmarrow wrote:

Paddle2See wrote:

As an experienced computer programmer, I have to agree with you...redundancy is a bad thing...but you work with what you have.  When I build a project like this, I work with one master sprite and rough out what it is supposed to do.  Then, I debug with a small number of copies of the master sprite.  Finally, I copy the master up to the full number of sprites I want the project to have.  Still, I probably ended up deleting and rebuilding the sprite copies 20 times.  Thank goodness for the Shift Copy and the Shift Cut commands (allowing mulitple Copy and Cut operations without having to reselect the Copy or Cut tools)!

And thank you, Dbal, for the interesting challenge.

As neither a computer programmer nor a computer science professor, my humble opinion is that Paddle2See's version is pretty impressive! It even has state-dependent color. I'd like to see a Greenfoot implementation of _his_ program 

The thing that is impressive about Paddle2See's implementation is that he was able to accomplish it (with a severe limitation on the number of spiders, a huge amount of code redundancy, and a severe restriction on dynamic reproductive behavior) in Scratch.  (Code redundancy is not something that we should be teaching the next generation of computer scientists.)  But a famous football coach once said something like "You dance with who brung you." and Paddle2See had to work with the tools that he had available.  Given those tools, he did an outstanding job.

The state-dependent color is interesting and does produce an interesting effect.  I may give that a try once I figure out how to create a red spider image.

State-dependent color adds a nice touch.  (Wish I had thought of that)    I updated my version to cause the spiders to turn red while engaged in combat and to turn green (fertilizer) when they die. 

Other features in the new version are:

1.  The live spiders now have the ability to hide underneath a pile of dead spiders in order to ambush other unsuspecting spiders as they come by.  (Similar to a real-life "trapdoor spider".)

2.  When in combat, red spiders puff themselves up in an attempt to look larger as many animals are prone to do.  They also expose a pair of ugly blue fangs.  (If you can't see them when the program is running, click the Pause button.)

3.  Dead spiders curl their legs underneath themselves as dead spiders are prone to do.

Just to emphasize the issues of scalability and redundancy, I also increased the size of the playing field in the newly-published version relative to the original version (I had actually already done that in an update to the original version), increased the initial number of spiders from 77 to 400 and caused each live spider to produce three offspring (instead of a single offspring) each time it is asked to reproduce.

I also created and tested an experimental version in which the initial number of spiders was set to 900.  However, the spiders were so close together in that case that it was difficult to separate them visually, so I didn't publish that version.  My computer animated the world pretty well with 900 initial spiders but tended to slow down when I increased the number of spiders beyond about 900.

And here is the most important point of all, which was the motivation behind the original challenge as Padde2See recognized immediately     This increase in the size of the playing field and the number of spiders only required changing literal values in a couple of statements with no additional code and produced absolutely no code redundancy.  Had I made those factors input variables in the original version, no changes at all would have been required to accommodate the increases.

The new version is published at:

http://greenfootgallery.org/scenarios/181

Take a look at it.

Last edited by dbal (2008-07-08 16:12:21)

By the way, if you use ChrisCrouch's Dynamic Sprite duplication hack, which is available for download from this link. Even though the hack was designed by ChrisCrouch, it is implemented in that link by s_federici. You can actually make a working, dynamic version of this!