Directions at bottom.

How Was This Programmed?

Well, let's start with how it works: Before proceeding, click the FLOWER 15 or more times, then the STAR. Just watch for a bit,
then click the BOMB.
The 576 balls in the square are programmed to act like they are connected to their neighbors
by springs (neighboring balls are top, bottom, left, right, and diagonals). A spring
stretched an amount x exerts a force
F = ma = -kx
on the objects to which it is attached (if one of the objects has a mass m, then
then it experiences a resulting acceleration a, if that's the only force).
k is the spring constant, a proportionality constant that relates the force linearly to
the amount of stretch (or compression - the negative sign indicates that the spring always
pushes in the direction opposite the compression or stretch).
Well, let's face it, this is a virtual world. The balls on the screen don't have a real
mass, so we can set it equal to anything we want. Same thing for k. So we'll
set m = 1, and k = 1 (we won't worry about units).
Ok, so the equation above reduces to:
-x = a = dv/dt.
Acceleration is the rate of change in the velocity, which is dv/dt. So,
dv = -x dt.
An assumption lying behind these equations is that space and time are continuous
not discrete (the set of all integers is a discrete subset of the continuous set of all
real numbers - each set is infinite, but the infinity of real numbers is provably bigger
than the infinity of integers).
The balls in this simulation will move if they have a velocity (a vector quantity).
This will arise initially from an unbalanced force producing an acceleration.
Let's look at a single ball somewhere in the middle. It has to be told by the computer
to move. The computer makes a computation for the new position of the ball (and all the
others), moves them, then based on the changes that have occured, it makes a new
computation, moves everything again, etc. The basic cycle is: There is a big difference between the computer simulation of physics and the physical
thing being simulated: as far as we know space and time are continuous; but a computer
screen consists of discrete points, and finitely many; and time too is discrete on
the computer, a cycle through the computation being the shortest interval for this
simulation. So we don't have infinitesimals like dx and dt. The best we
can do is set dt = one computational cycle. In calculus terms:
x(t + dt) = x(t) + v(t)dt.
What's done here is:
setAt vx, n3, (getAt(vx,n3)) + t*(netX)
setAt vy, n3, (getAt(vy,n3)) + t*(netY)

setAt x, n3, (1.0*getAt(xo,n3)) + ((getAt(vx,n3))*t)
setAt y, n3, (1.0*getAt(yo,n3)) + ((getAt(vy,n3))*t)
These are vector equations. The first two update the x- and y-components of the velocity
with netX and netY (acceleration components). So they're an attempt to simulate:
v(t + dt) = v(t) + a(t)dt.
The second two are an attempt to simulate:
x(t + dt) = x(t) + v(t)dt.
(The computer language is Lingo, part of the Director software.)
You may notice that I've thrown in a factor t. This can be adjusted to make
the simulation closer to reality, but at the cost of slowing down the program.
It is set at a value that made things run well on my machine (Mac G3).
What about the SQUARE button? That reverses the order of the computer equations above.
This makes it a worse simulation, but gives rise to very neat patterns (push the SQUARE
to the "in" position, push the FLOWER once, then push the STAR; then watch).

Finally, as time passes the simulation will look less and less physically accurate.
Things blow up, and I've seen very weird foldings in the pattern of 576 balls - a kind of
topological collapse. This is a consequence of the discreteness of the variables.
Physical reality presumably carries a great deal more accuracy from moment to moment
than is possible here. A great deal more could be said, but I doubt anyone has even read to this point.

Mathematical Ideas in Science.