As I first began to experiment with the StarLogo sample projects, the first
thing that struck me was the length of the code for each project-I could not
believe that such complex situations could arise out of such simple a simple-and
short-set of rules. But then again, this is part of the value of StarLogo. I
began by simply exploring the sample projects, particularly the ones in the
biology section. I was particularly interested in the epidemic simulation. When
I first ran the simulation, everyone was 
quickly
infected. Not too exciting. But as I changed the slider that determined how
long it took to recover from the disease, I found that if it was possible to
recover at all, then some equilibrium was quickly established-but I was unable
to achieve less that about 60% infection rate. This seemed unrealistic, as it
is rare that 60% of the population has any disease. I spent quite a while playing
with the settings until it occurred to me to modify the number of people in
the simulation. With much fewer people in the simulation, the disease was transferred
much less often and thus the exponential rate of increase was greatly slowed.
Instead, the equilibrium was established at 10-20% infection rate. It occurred
to me that I had inadvertently came upon the generally-given explanation for
why people get the common cold when it's cold out: because they're huddled together
inside, and thus have a greater chance of spreading the disease.
After spending some time with the sample projects, I followed the tutorial
on creating the termites project. I was again impressed by the simplicity of
the individual actions which led to the seemingly complex behavior of forming
piles. After finishing the simulation and watching with satisfaction as the
multitude of bugs made their piles, I tried to make what I thought would be
a simple modification: I wanted to sprinkle two kinds of wood chips and have
the termites make two 
kinds
of piles. I modified the setup routine to make two kinds of chips and changed
the turtles' program so that they would drop chips only next to chips of that
color. I expected this to lead to a few large piles of chips of the same color,
but instead I got the pattern to the left. At first I thought I had made an
error, and I created two types of turtles: one which would only pick up blue
patches and one which would only pick up yellow patches. However, after attaining
a similar pattern with this strategy, I decided something else had to be going
on. I finally realized that this pattern was emerging because the turtles could
only build on the edges of the piles. Thus the colors became intertwined but
did not separate into different piles. This gives rise to the interesting pattern
I found, in which the blue and yellow chips form strands and masses within each
larger pile. One might even speculate that StarLogo could be an interesting
artistic medium.
As a computational tool built around the idea of a distributed simulation, StarLogo seems very successful in several areas. First, it overcomes Starr's objections to the use of SimCity's simulation. We need not worry that a user would be overly trusting of a StarLogo simulation because he or she can easily look at the source code and determine exactly what's going on in the simulation. Nothing goes on "behind your back" as the simulation runs (well, nothing with regard to the observable simulation anyway.) Even better, the user will likely have built many of the simulations that he or she observes, making them intimately familiar with just how their simulation relates to reality and what its strengths and limitations are. In this case, we need not worry about whether the user will be deceived by the simulation-instead, the ways in which the simulation differs from reality can be easily examined, and would probably be among the first things considered upon observing an unexpected result. It is often the case that these differences are particularly interesting-for example, real termites almost certainly use sight and smell to locate wood chips instead of moving randomly. However, it is very instructive to note that, armed only with the sense of touch, they could still build their piles.
One obvious limitation of StarLogo is that it takes place on the computer screen. Although the user defines their behavior, it is difficult to interact meaningfully with individual turtles or determine their state as the simulation is running. Furthermore, though the graphics available in the MCL version of StarLogo add an extra dimension of realism to the simulation, it is difficult to form a personal attachment to on-screen turtles when you can create a thousand of them by pressing nine keys.
The concept of participatory simulations is an interesting extension to the
concept of modeling systems. In the simulation, 
each
participant assumes the role of a "turtle" in StarLogo, interacting with other
participants according to predefined rules (in the case of our activity in class,
this involved the interactions between predatory and prey fish in an ecosystem.)
This solves many of the limitations of StarLogo-during our activity is was clear
that we developed personal attachments to the simulation by being actors in
it. Furthermore, the activity took on a social context for us as participants-we
could each decide what strategy to pursue. During the second round of the simulation,
we decided strategy as a group (perhaps not unlike programming all the turtles
at once in StarLogo.)
It is interesting to consider deciding on our behavior as a group as a means of programming. In one sense, this style of simulation falls prey to the questions that Starr raises about SimCity's simulation; during the "big fish-little fish" simulation, we were unable to alter, say, the rate at which schools of little fish increase in size. This seems to have more of the character of SimCity-such variables are set by the designers of the experience in order to maximize the educational and fun value. However, there is much more individual leeway in the participatory simulation so that individual styles can become a factor, making the experience enjoyable for the participants. It is also worth noting that this style of "programming" needs no formal introduction, unlike the complex grammar of StarLogo; participants certainly already know how to interact with each other. Only a minimal introduction to using the badges is needed-and during the simulation, participants simply need to wear the badges.
Finally, we should consider the different experiences of a dynamic, distributed
system provided by StarLogo and the participatory simulations. In StarLogo,
the user has control over everything that occurs in the simulation, and thus
in theory can grasp all the interactions that occur in the StarLogo universe.
After all, he or she could well have designed these interactions. Furthermore,
StarLogo is designed to operate quickly so that long-term effects of the rules
can be observed, and also to increase the 
iterativity
of designing and modifying the parameters of a StarLogo simulation. In contrast,
during a participatory simulation, the action proceeds much more slowly, and
the simulation is viewed from a first-person perspective. This makes individual
interactions perfectly clear to the participant, since they are performing each
one. But it can make understanding the system as a whole more difficult, as
the combined experiences of the group are necessary to fully describe what occurred
during each simulation. Using a graph of data stored by the badges is an interesting
approach, allowing the entire simulation to be viewed at a glance and taking
into account all the participants' individual perspectives. Yet most of the
knowledge that is crucially important to understanding the simulation comes
from the aggregation of interactions between individuals. The challenge of keeping
the entire ecosystem alive is excellent for this purpose-it requires the participants
to work together to consider workings of the entire system, not just their individual
role.
Both StarLogo and participatory simulations are valuable for gaining an understanding of complex, distributed systems and for overcoming the mindset of centralized control of any large system. The two styles of simulation together seem like a good way to experience and come to understand a variety of decentralized systems.