Re: GUI design in simulation: or MVC pattern usefulness?
Daniel T. wrote:
Daniel Pitts <newsgroup.spamfilter@virtualinfinity.net> wrote:
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.
I've always loved those kinds of games. My friends and I would spend
hours trying to find the perfect algorithm to defeat someone else's
latest creation. We gave it up when we realized that the programs were
circular. A beats B which beats C which beats A. When we started we
thought we would end up with the "perfect robot" for the environment,
then we found there was no such thing. :-(
<nostalgia>
On the original AT-Robots, someone used a genetic algorithm to find a
robot that won most of the times. I was able to dethrone her only by
finding and exploiting a bug in the code :-) The original author posted
just a snipit of the structure used to represent a robot. I noticed that
the internal stack was relative to the armor/health value. I (correctly)
assumed that the author only did partial bounds checking, and I could
push values to a "negative" stack pointer, thereby giving my robot
immortality :-).
My opponent (FiFi Laroo if I remember) was impressed. Her robot was one
of the bests within the advertised constraints of the simulation. Mine
was *the* unbeatable one because it explored external dimensions. Of
course, as soon as the original author (Bones from necrobones.com) saw
what he'd missed, my robot became useless. I suppose if he didn't fix
that bug, the game could have gone into a combination corewars/AT-Robots
:-).
</nostalgia>
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.
If you want to detach the visual representation of the battle from the
logic of the game, then you should follow the same tact you would use if
there visual representation was being managed by a different machine or
program than the one that tracks the state of battle.
I agree on that part. I think that the local visual client should use
the same interface as the remote one. When I consider that
"requirement", then I think that creating a "visual peer" along with a
"state snapshot" is the best approach.
As for the controller, you have more than one. The person watching the
battle unfold is a controller (but as you say, all he can do is
start/stop the battle,) and you have the robot logic that manipulates
the robot representations that exist in the model. The Robot Controller
modifies the Robot Model while the Robot Graphic represents the Robot
Model's state.
I hadn't thought of it that way, but in reality the robot model manages
its own state, as any good business object should. However, the
controller can be responsible for the creating of the model, and the
wiring of the view to the model.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>