GUI design in simulation: or MVC pattern usefulness?

[Daniel Pitts]

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.

 

[Jeff Higgins]

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.

A quick web search using "object oriented game" reveals a surprising
number of articles on the subject. One article puts forth the use of object
of types: Entity Action Form State Space.

Jh

 

[Daniel T.]

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. :-(

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.

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.

 

[Daniel Pitts]

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
.

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.

 

[Joshua Cranmer]

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.

"A project that I've done a few times before." Sounds like something I
would say: I have two projects that I've started a few times but realize
in the middle that the entire plan is wrong and start over from scratch
again.

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).

My general preference for graphics is closest to a Visitor pattern (?):
display function:
....
map.display(this);

[ map class: ]
void display(Display d) {
// ... draw map ...
for (DisplayableObject o : objects)
o.display(d);
}

[ random displayable object: ]
void display(Display d) {
d.draw(x, y, z, theta, phi, this.getDrawingObject());
// or
d.draw(x, y, heading, this.getDrawingObject());
}

The drawing objects might be something like a 3D-model representing a
missile or a 2D-image that can be rotated depending on its heading.

The reason I like this model is because it is (relatively) easily to
extend to new types of objects, and it works well with my preference for
using data files to specify various objects as opposed to very large
class trees. In addition, it means you can use different types of
display: one display for drawing to a screen, another for sending data
across a network, and a third for having debugging console output.


[ Note: theta and phi represent the two needed angles for three
dimensions, if that wasn't made clear enough. ]


[OT for this thread:]
I just thought of how writing a game can be a good introduction to Java
for programmers: it's a good example of where inheritance trees can be
deep instead of broad; several of the collections are going to be used;
it would handle both network and file I/O; if properly planned out,
multithreading would be used; and all games need some sort of GUI worked
out. Hm, I should try recommending this as a course somewhere.
[/OT]

 

[Piotr Kobzda]

[OT for this thread:]
I just thought of how writing a game can be a good introduction to Java
for programmers: it's a good example of where inheritance trees can be
deep instead of broad; several of the collections are going to be used;
it would handle both network and file I/O; if properly planned out,
multithreading would be used; and all games need some sort of GUI worked
out.

Sure, writing a games is very good opportunity to learn Java.

Hm, I should try recommending this as a course somewhere.

You may also suggest writing a *key part* of an existing game (in fact,
interesting not only for beginners...).

[/OT]

piotr

 

[Martin Gregorie]

[OT for this thread:]
I just thought of how writing a game can be a good introduction to Java
for programmers: it's a good example of where inheritance trees can be
deep instead of broad; several of the collections are going to be used;
it would handle both network and file I/O; if properly planned out,
multithreading would be used; and all games need some sort of GUI worked
out. Hm, I should try recommending this as a course somewhere.
[/OT]

Agreed. Games programming is often looked down by "serious" folks, but
it manages to pull a lot of programming and design skills into a
deceptively simple task: interface design and implementation, data
representation, dialogue management and (maybe database design and/or
file i/o.

Even re-implementing something as simple as the old Star trek game in
Java would teach the implementor a lot, and if you want a role playing
game engine plus game editor package that's capable of building and
running games like Colossal Cavern or Zork then that's not trivial at all.

 

[H. S. Lahman]

Responding to Pitts...

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.

You don't need OO for this; it is basic application partitioning.
Encapsulate the UI and DB access in subsystems with generic interfaces.

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.

MVC would probably be fine for the old DOS game that evidently wasn't
too complicated. MVC nicely separates presentation (UI) from data
storage. But those kinds of simplistic layered models only work well
when the mapping between UI artifacts and DB artifacts is very close to
1:1 (i.e., the "business" layer doesn't have a lot to do except
construct DB queries.). But...

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()"

As soon as you are out of the realm of converting UI forms to DB tables
or vice versa, you are out of the MVC world. That's because you probably
need to view the world differently for simulation than for either the UI
or the DB. IOW, things may not map 1:1 across the boundaries anymore.
Then the canned infrastructures for moving between layers tend to break
down. If you are getting into situations where you need to explicitly
deal with concurrency or things are "constantly in flux", I would give
good odds you are well out of the MVC comfort zone.

I think you should think of the simulation logic as running the whole
show and using DB access and UI subsystems as low level supporting
services. IOW, the layered model becomes:

[Game Simulation]
/ \
/ \
[UI Rendering] [DB access]

where [UI Rendering] and [DB Access] are peer services whose interfaces
represent the simulation's need for data and instructions. IOW, those
service subsystems exist to convert the simulation's needs into the UI
or DB access paradigm de jour.

That encapsulation allows you to deal with three separate problems.
That, in turn, allows you to abstract the invariants of each paradigm
within the various subsystems. In theory that's what MVC allows, but
this tends to be more versatile. For example,...

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).

Note that one advantage of the architecture above is that things like
rendering can become arbitrarily complex. That is, the simulation
doesn't care if the robot is represented on a character screen or as
some high end 3D extravaganza. So you can add subsystems if the
rendering complexity gets out of hand (e.g., a Physics subsystem to deal
with colliding objects and sprays of debris) without touching the
[Simulation] subsystem that actually runs the game.

Similarly, you can add complexity to the [Simulation] by delegating
other subsystems for its activities, such as a debugger facility. Again,
you can do that without touching the rendering or DB access.

This sort of application partitioning relies on three things: subject
matter definition, levels of abstraction, and requirements flows. Each
subsystem represents a readily identifiable functionality and
perspective on the game that can be easily encapsulated. Subsystems are
also localized with respect to the level of abstraction. Thus the
[Simulation] subsystem thinks about moving robots around and whatnot at
the megathinker level without worrying about how the details are
presented on the screen (character, GUI pane, browser, etc.) or in the
DB (an RDB, flat files, clay tablets, or whatever). Finally, flows of
requirements organize the subsystems into a directed, acyclic graph of
clients and services. [You may find the category on "Application
Partitioning" in my blog of interest for this.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
(e-mail address removed)
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
(e-mail address removed) for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH