GUI design in simulation: or MVC pattern usefulness?

So, I'm working on a project that I've done a few times before. A port
of an existing "game" called AT-Robots. The base description is a
simulation of a few virtual machines, along with the virtual robots that
they control. The robots can interact with the "Arena" by firing
missile, laying mines, moving, and scanning in various ways.

The original program was written in Pascal on DOS using BGI graphics.
It was written in a very procedural manor, and all of the graphics code
is interspersed with the rest of the code. Obviously, this is
something we'd want to avoid in the OO version of the project.

So, down to my concern. The simulation itself isn't very interactive.
Basically, the user can create/start/stop the simulation. There may be
a time when I add a debugger to the simulation, but that'll be a
different case that I'm not worried about currently.

Given all this. I'm not sure that the MVC is the appropriate pattern, or
if it is, I'm not sure how to separate each component.

The model itself is all of the objects in the simulation, and it is
constantly in flux (which presents a concurrency dilemma as well, but I
think that's one I can handle). The only thing that I could think of as
useful for the controller would be the code that basically says "new
Arena().start()"

The view, on the other hand, would have to know how to render so many
different things (robots, missiles, scan representations, mines,
explosions, etc...). I would either have to make a visual peer for each
of these objects, or have the objects themselves know how to render
themselves. Of course, this gets even more complicated if I want to
support "remote" rendering (shared Arenas over a network).

So, I'm curious how others might attack this problem at a OOA/D level.
I'm just using an iterative approach, so I'll solve the problems when I
get to them.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>