Erlang hints from an CO junkie

[Eric Merritt]

On Wed, 11 Aug 2004 08:58:06 -0500, James Hague <jamesh@REDACTED> wrote:
> This can be tricky, in that there's faux concurrency in many problems.  That
> is, things may appear dynamic, but in reality they're static.  For example,
> in a video game, it is tempting to model each critter in the game as a
> process.  In a single-player video game, though, there is no true
> concurrency.  Each object moves in a lock-step fashion, once per frame.  You
> could still use processes, but it's more a method of organization than a way
> to handle concurrent activities.  Once you make this a multiplayer networked
> game, then all of a sudden real concurrency jumps into the picture, in that
> sending and receiving network packets can happen at the same time as other
> processing.

 I think you may be missing the point (or perhaps I am). It matters 
not how the critter is displayed  or  the  fact that  it is  moved
once per frame. What matters is that in real  life the critter would
be concurrent, so it makes allot of sense to model the critter as a
concurrent process in the system. This would, perhaps, have
implementation considerations in updating the screen. However, that
has little or  no meaning  as far as modeling the critter goes.