> > You can set the step rate to whatever gives you the most usable
> > animation speed.
> 
> Nathanael already did that for the turtle with animation that I have.
> But this is really complex.
> I'm amazed to see how difficult it is to simply do a stupid small 
> program in Squeak that requires animation (ok I do not use step).
> Still.

Hm ... sounds almost like "I'm amazed to see how difficult it is to do a
stupid small program in Squeak which requires object orientation (ok, I
don't use objects)" ;-)))

For your example, you should actually come up with a model of what it is
your bots are doing. As you are talking about animation, you are also
talking about time. In other words - if you don't tell your bot how fast it
can do its work, then you're just assuming that it's infinitely fast and, of
course, you will not see any progress during the simulation. The best way to
handle this is by assocating time with the object directly so it can evolve
over time (not surprisingly, this is exactly what TeaTime in Croquet is
about) and effectively have the system visualize its state "as often as it
can" rather than explicitly.

Given that this is not exactly trivial (but noone said that graphics is
trivial, eh?!) you may want to have a more discrete model of what your bots
are doing (for example: "a bot can #go once per frame"). Given only a single
bot, then #displayWorld or similar in the right places will work perfectly
fine (and are utterly trivial). If you don't - e.g., you want users to be
able to interact with your objects, or have many of them - then you simply
have to be concurrent or how else would your objects _actively_ control what
is going on? So that, by the end of the day, your problem can only be solved
in a "good object-oriented way" if you realize that it is an intrinsically
concurrent task.

Cheers,
  - Andreas