> I'm scared, but I would probably fiddle about with the
> timing mechanism within the World and pray that I could get > everything to
> line up right.

As I say, a useful model for me is to define the game state as a function of a parameter (t).  Then I ask to be interrupted (stepped) frequently enough to be able, on average to meet my frame rate hopes.

The step function does the following:

	"compute the time that has passed since our last step"
	"advance the state by delta t"
	"display me at the present time"

The trick is defining the model adequately, either in terms of delta t or absolute time.  Of course, this assumes that you can make some reasonable continuity assumptions during most likely step intervals, or tolerate approximations made to simplify the computation.

In practice, I haven't found this hard.  Frankly, its how I've always coded video games I have written, except that I have to worry in those products about all kinds of hardware discontinuities as well.

> BTW, a real time game in Squeak sounds real challenging to > begin with. On
> every game I've ever worked on, I've ended up with coding some of the
> critical bits in assembler ( or recently C )  just to get the > thing to run
> fast enough to play.

This depends much how you define "real time."  The key problems in my experience so far have all been simple IO issues, primarily in keyboard access (for which a straightforward plugin seems to solve the problem).