Sunday, October 28, 2007

Kedama: a GUI-tile scriptable massively-parallel particle system

Kedama is the StarLogo approach imported to etoys. ie.
... a programmable modeling environment for exploring the workings of decentralized systems -- systems that are organized without an organizer, coordinated without a coordinator ... you can model (and gain insights into) many real-life phenomena, such as bird flocks, traffic jams, ant colonies, and market economies
I've been arguing on the Victorian teachers list recently that this is the sort of thing that computers ought to be used for in schools, to add something unique and valuable to the curriculum

Kedama comes with etoys (squeak). It was developed by Yoshiki Ohshima, who is a member of Alan Kay's Viewpoints Research Institute team

There is a wonderfully clear tutorial Linda Kao, with detailed explanations, on the squeakland site.

Visualise kedama as consisting of 3 layers:
  • Kedama world layer
  • Patches layer 100x100 grid (each patch might consists of just 2x2 pixels) and each cell can be assigned an integer value
  • Turtle breeds (particles). A breed is a group of turtles. Turtle breeds are scripted as a group. You can also have multiple breeds for more complex simulations
The turtles can alter their behaviour by interacting with the patch variables. For example, if a patch has a value of 1, then any turtle entering that patch could be programmed to change colour

So, for an epidemic simulation:
  • Create hundreds of turtles (one breed)
  • Infect one of the turtles, show this by displaying that turtle in a different colour
  • Use an infected turtle to infect a patch
  • If any other turtle enters an infected patch then it becomes infected
  • Run the simulation, see how fast the infection spreads

I include some screenshots of three scripts and the developing epidemic:











Some things I learnt:

If I pull out the third line of the infect script and then run the setup script then all turtles immediately become infected

Looking behind the scenes I see that Squeak has a doSequentialCommand: keyword method which somehow carries out the commands to the turtles in each breed one by one. Hence the setup script stops at the point of infecting a single turtle

If I pull out the "patch clear" line of the spread script then the infection spreads much more quickly. This is equivalent to infected surfaces continuing to remain infectious. This illustrates the potential of the patch approach, much more versatile than programming collisions.

spread script pseudocode:
  1. move all turtles
  2. clear all patches
  3. If turtle is infected then infect the immediate patch
  4. If another turtle which is NOT infected enters that patch then infect that turtle

7 comments:

mithro said...

That is quite cool. It kind of reminds me of the old "game of life" program.

As you pointed out, this has quite a huge potential for learning how complicated systems work. A course at University used a similar system to show some powerful results. One example was how segregated communities can occur from amazingly innocent rules, like the wish to have a neighbour who has a similar trait. It is pretty amazing to imagine the type of things students could discover if they had the time to play with this in High School.

It has applications in many subjects not just S&E, for example in English you could look at how the usage of words could throughout a community, in Maths you could study economics using similar ideas.

It is sad that there is such a huge resistance to using tools like this.

Unknown said...

I wrote a disease simulation in Game Maker:
disease simulation
http://schoolgamemaker.rupert.id.au/samples3/
disease.gm6

It took me 60 seconds to write in GM.
How long would it take in in Etoys/Kedama ?

Is Etoys really good enough for kids yet?

Bill Kerr said...

hi tony,

Your program does illustrate the concept of exponential growth of disease, so it is good.

However, systems like kedama or starlogo can do more as I indicated in the article:

"If I pull out the "patch clear" line of the spread script then the infection spreads much more quickly. This is equivalent to infected surfaces continuing to remain infectious. This illustrates the potential of the patch approach, much more versatile than programming collisions"

Because it has both patches and turtle breeds kedama is more complex to program but it is also more powerful.

Write a program in GameMaker of ants following scents left by other ants. That would be a fairer comparison IMO.

There is a series of online kedama projects available on this page . You need to have squeak installed to run them on line.

Unknown said...

Challenge accepted. Ant trail in GM at http://schoolgamemaker.rupert.id.au/samples3/scent.gm6

unfortunately it is not working properly but I have other work just now

Unknown said...

or
http://tinyurl.com/2cslrf

Unknown said...

New version that works at
http://tinyurl.com/22g7sz
it was difficult because GM does not give an easy way to detect which side the collision is on also can detect the presence of an object to the side but not its properties

Bill Kerr said...

hi tony,

You are a good programmer but as you say - not easy

I don't think it's easy in Kedama either. Here are some preliminary comparisons and observations about the on line Kedama ant colony simulation. So far I've just looked at the online version and tried to reverse engineer what is happening

I can see 4 turtle breeds:
ant
nest creator
nest
food creator

and 3 patches:
nest
food
pheronome

The ants wander around, look for food and for scent, leave scent when they pick up food and return it to the nest. Ants with food are shown in red, ants without food are shown in blue and the scent is shown in yellow

So far I just have a rough overview of how the turtle breeds and patches interact

Towards the end of the program the food disappears but the yellow scent remains for a while so blue ants still mill around in that area. Then gradually the scent fades away and the ants wander off in search of new food

In kedama, I can view and play around with this all of this live on the one screen, rather than having to inspect code, alter code and then run the code as a different action

I'm very impressed with this demo but it will take me more time to learn how to build my own version