GUI design in simulation: or MVC pattern usefulness?

Discussion in 'Java' started by Daniel Pitts, Oct 28, 2007.

  1. Daniel Pitts

    Daniel Pitts Guest

    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

    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, Oct 28, 2007
    1. Advertisements

  2. Daniel Pitts

    Jeff Higgins Guest

    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.

    Jeff Higgins, Oct 28, 2007
    1. Advertisements

  3. Daniel Pitts

    Daniel T. Guest

    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. :-(
    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 T., Oct 28, 2007
  4. Daniel Pitts

    Daniel Pitts Guest

    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 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
    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.
    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, Oct 28, 2007
  5. "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
    My general preference for graphics is closest to a Visitor pattern (?):
    display function:

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

    [ 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.
    Joshua Cranmer, Oct 28, 2007
  6. Daniel Pitts

    Piotr Kobzda Guest

    Sure, writing a games is very good opportunity to learn Java.
    You may also suggest writing a *key part* of an existing game (in fact,
    interesting not only for beginners...).

    Piotr Kobzda, Oct 29, 2007
  7. 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.
    Martin Gregorie, Oct 29, 2007
  8. Daniel Pitts

    H. S. Lahman Guest

    Responding to Pitts...
    You don't need OO for this; it is basic application partitioning.
    Encapsulate the UI and DB access in subsystems with generic interfaces.
    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...
    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,...
    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

    Pathfinder Solutions
    "Model-Based Translation: The Next Step in Agile Development". Email
    for your copy.
    Pathfinder is hiring:
    H. S. Lahman, Oct 29, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.