[From Bill Powers (920808.2000)]
My system has temporarily lost Kermit, so this will be sent late.
penni sibun 920807 --
i've seen the crowd demo (thanks to avery) and i've seen sonja (pengi's
daughter). quite frankly, you know, they're both just demos, and one >can
look at them, or even play with them, and assume they're video >games that
aren't trying to demonstrate any particular theory of >activity. if you
read the accompanying text and/or the code, you may >or may not speculate
about whether or how the demos support the models.
Yep, that's the problem with just looking at behavior.
The crowd model could be set up with a single active person seeking a goal
across the screen, and one stationary person in the way. When the moving
person got close to the stationary one, the path would curve around the
stationary person and head on to the goal. There are lots of ways to
accomplish this result.
One way would be to write a program that says "Draw a line from the start
position to within 20 pixels of the obstacle position, then decribe a
semicircle centered on the obstacle, then continue the line to the position
of the goal." That would be pretty trivial.
Another way would be to say "Move toward the goal position. If an obstacle
appears within 20 pixels of the moving object's position, turn the path
left and keep the obstacle 20 pixels away until you are again on a line
between the starting position and the goal. Then move toward the goal
position again until it's reached. Then stop." This is slightly better, but
you still have to inform the model of its own position, the obstacle
position, and the goal position by providing this data from outside the
program. You also have to tell the model what "toward" means. You also have
to tell it to stop when its distance from the goal is zero. You have to
program into it the meaning of "turn left" and you have to provide a
computation that will keep it 20 pixels from the obstacle. The BEHAVIOR of
this model would be just like that of the first one, but it's not the
behavior that we're interested in. It's how that behavior is created by the
combination of the programmer and the running model. There's a little more
going on inside this second model than inside the first one.
My way of programming an individual in the crowd program was done in still
a different way. I told it which object was the goal and which were
obstacles. I told it to use an avoidance control system for obstacles and a
seeking control system for the goal. The avoidance control system had two
sensors, one detecting the sum of all proximities to obstacles on the left,
the other the sum of all proximities of obstacles to the right (weighted to
reduce the effect of objects toward the rear). Proximity was defined as
k/r^2, where r was the radial distance to a given obstacle. This created a
perception similar to that of visual area subtended by an object at a
distance r.
The avoidance system used both the sum and difference of left and right
proximities of all obstacles. The error signal from the control system
caused the direction of movement to curve to the left or right, curving
faster as total proximity increased and simultaneously slowing the
velocity. The destination-seeking system used the difference in left and
right proximities of the goal-object; its error signal also made the path
curve left or right, velocity increasing with error.
As a result, a person would start out toward the goal, veer left or right
when it got near the obstacle and describe a path around it, then go on
toward the goal in a straight line from the point where its avoidance path
was aimed at the goal again. When it got to the goal it would slow down and
stop. If you looked only at the BEHAVIOR, this model would look much like
the first and second ones mentioned above.