mvc view

Hi, I cannot get the Mvc patern applied to the game i’m planning.

I got my game loop with active rendering. In the View class, How do I paint on the screen can I use a function like this?

paintCursor(Cursor cursor, Graphics g) ?

the Graphical representation of a cursor cursorGfx:

public class CursorGfx extends TileSprite {
  private Animation anim;
  private int cursorWidth, cursorHeight;
  private int offsetX, offsetY;
  
  public CursorGfx(int row, int col, int tileSize, LinkedList<BufferedImage> imgList) {
    super(row, col, tileSize);
    initAnimation(imgList);

    try {
      Image img = imgList.get(0);
      cursorWidth = img.getWidth(null);
      cursorHeight = img.getHeight(null);
    } catch(Exception e) {
        e.printStackTrace();
    }

    // The cursor can be smaller or bigger then the TileSize.
    //offsetX = (cursorWidth - world.getMapTileSize()) / 2;
    //offsetY = (cursorHeight - world.getMapTileSize()) / 2;
  }

  private void initAnimation(LinkedList<BufferedImage> imgList) {
    anim = new Animation();
    anim.addFrame(imgList.get(0), 250);
    anim.addFrame(imgList.get(1), 500);
  }

  public void update(long elapsedTime, local.model.map.Cursor cursor) {
    super.update(elapsedTime);                            // Update Animation
    super.setPixelLocation(cursor.getX(),cursor.getY());  // Update Position
  }

  public void paint(Graphics g) {
    super.paint(g);
    paintPosition(g);
  }

  private void paintPosition(Graphics g) {
    g.setColor( Color.GREEN);
    g.drawString("posX:" + super.getLocX(), 5, 200);
    g.drawString("posY:" + super.getLocY(), 5, 215);
  }

Do I have to add a update Method that updates the position prior to the painting?
or can I not pass a Model object to the view so i would need to use paintCursor(int x, int y, boolean active , Graphics g) ?

in my Game loop I have:

cursor.setPixelLocation(input.getMouseX(), input.getMouseY());
screen.updateCursor(elapsedTime, cursor);
screen.paint(g)

or how do you paint your model to the screen.

Your view should independently decide when it should be updated in most of the cases except for the data that are not often changed in the model.

I have another question:
Do I have to store x,y coordinates, Animations in the model?
or how is the sprite position updated.

nvm, I think I will find everything I need on this excellent weby;
http://www.mine-control.com/zack/patterns/gamepatterns.html

You should store the data that are required to compute the collisions in the model, at least x y and the bounding boxes or anything that has the same role. The view contains then the data needed to know how to draw the sprite. The sprite position is updated by reading the keyboard in the Monitor (cf. MVC 2) or from a part of the view (MVC), using the controller to send what has been read to the model and then the model checks if the new coordinates are valid. If they are valid after the collision detection test, the coordinates are updated. The view reads these new coordinates through the controller to know where to draw the sprite.

For what it’s worth, I don’t think MVC really applies here. One of the amazing things about MVC is that it means everything and nothing, depending on who you ask. That is, some folks refer to any separation of model from interface as “MVC”. You can’t really call that wrong unless you’re a proscriptive linguist, which doesn’t get real far in our jargon-fraught discipline.

Anyway, traditionally MVC describes the explicit separation of the Model, View, and Controller. That is, there are three different objects or components that play each of these roles in the software architecture. Swing is explicitly not an example of MVC: see http://java.sun.com/docs/books/tutorial/uiswing/components/model.html and http://java.sun.com/products/jfc/tsc/articles/architecture/.

In game programming, I do not think that there is ample reason to separate explicitly the Model, View, and Controller. These three are usually tightly coupled in the game design: the size and shape of a sprite is directly related to how fast it moves or how it collides, for example. Another way to look at it is to ask the question: what is a sprite aside from the combination of some data and behaviors (model) that is directly related to a thing on the screen (view), within some interaction context (controller-ish)? My advice is to let your game logic also object also render itself. I usually start with something like the following and work up from there.


public interface Sprite {
  public void update(int deltaMS);
  public void render(Graphics g);
}

If you’re intent on building a large system or framework, I think a much more appropriate pattern is Visual Proxy, a specialization of Model-View-Presenter. The essence of this pattern is that a model is responsible for creating its own view, and this approach exploits the fact that these two are tightly coupled in the problem and hence should be tightly coupled in the solution. The only place I have seen this described well is in Allen Holub’s rather heady series of articles in JavaWorld a decade ago, the first of which is at http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html.

That’s wrong. One of the reasons is that it makes it easier to design multiplayer online games by putting the model onto a server, the views onto the clients and the controller might be divided in two parts, one part in the server and one part in the client. Using MVC also allows to clearly separate the concerns, to drive the code more easily understandable and maintainable. Many commercial games use MVC or at least the Document-View pattern, for example Quake 2. It is true that many aspects in a game are tightly coupled but it is not a reason to avoid trying to clearly distribute the responsibilities between the software components.

You guys might find this article interesting.

The Guerilla Guide to Game Code

Bad link. Here’s a better one here. Sorry, couldn’t figure out how to edit my post.

Oh my god, I quit. Here’s the URL:

Golly!

I was tailoring my comments to the original poster, who I would guess is not working on a large-scale or multiplayer game. I suppose “you got me” in a sense that I usually encourage best practices from the get-go. My concern is that I see the term MVC thrown around all over the Web with very little qualification of what it actually means. As I mentioned above, Sun themselves say that Swing is not MVC, but one can find dozens of well-intentioned articles on-line explaining how it is.

In my study of GUIs, I find MVP to be preferable to MVC . Under MVP / Visual Proxy for games, you would still have a separation of view from data, but the view is provided by the model itself, not externally thrust upon it. The model determines the view: they are not independent, and this is what I mean by being coupled. It’s the good kind of coupling, not the unnecessary Singleton kind :slight_smile: For example, you might have a method on the model called “getVisual()” that returns a 3D model, a sprite, an animation, etc. The “controller” communicates with the model, and the view is supplied by the model, in contrast to having a controller that communicates explicitly with both the view and the model. Whether this is lazily created, loaded by a resource manager, accessed via a weak reference, etc., does not contradict the use of the MVP architectural pattern. The more I think about it (and this is my third post edit), I think what you’re describing could just as well be MVC as MVP. That is, it doesn’t contradict the use of MVP instead. For instance, one can still serialize a data object and pass it between clients and servers. Each client should be able to generate the view for the object. Technically, the server could too, but of course it wouldn’t.

I will have to spend more time thinking about this. The c2 wiki has some really interesting discussions along these lines in case anyone is curious. Anyone else out there studied these two software architectures and care to comment?

Yes Swing applies the Model-View pattern but not MVC. MVC is well known as it is one of the most used design pattern, it is sometimes called a canonical design pattern (sorry for the translation), I studied it in my lesson of software modeling. MVC is used in Hibernate, Struts, Spring… It has a precise definition, I don’t see what you mean and writing a game engine requires a long time, I know what I mean as I’ve been working on mine since october 2006, it is not easy.

Man, I need to drink my coffee. I misread your post, sorry about that, hence my editing this post again.

MVC is precisely defined… by people who want to say they are following MVC. That is, there is the original MVC, which is precisely defined, and then there’s everything since that has called itself MVC, all of which has been precisely defined, but different. I’ll see if I can dig up some of the more interesting c2 wiki pages on it.

I prefer to follow the strict definition from the original paper on Smalltalk. Others prefer to use the definition in Buschmann et al. As I recall, they are not the same. From my perspective, the MVC vs. MVP distinction becomes increasingly unclear when MVC is not defined in the original sense.

I was speaking about the definition of the book of the “Gang of Four”: “Design Patterns – Elements of Reusable Object-Oriented Software”. MVC is one of the 23 GoF design patterns.

No it’s not.

you got me there too, I guess, it is however much referred to in the book. So I can understand the mistake.

You mean something like this?

[quote]There is no such clarity and stability with ModelViewController (MVC hereafter). There is general agreement that it is a powerful concept, but general disagreement as to everything else: what is or isn’t an implementation of MVC, whether MvcIsNotObjectOriented and how far this matters, and so on. The discussion is sometimes conducted at near-religious levels of fervour, which suggests that clarity and stability may still be some way off.
[/quote]

Yes, exactly. Thanks, Tang. The other one that I remember is http://c2.com/cgi/wiki?WhatsaControllerAnyway.

I should thank Tang too for pointing me at c2.com, which I had been neglecting for years. It came up in an earlier conversation, and now I point lots of people there. There are some really deep conversations about software design to be found on those pages.

The c2 wiki is awesome, it doesn’t seem to be terribly active now, but theres heaps of really interesting discussion and advice buried deep within it. ;D

Back on topic, I don’t think MVC is terribly useful for most games. It might be a nice fit for buissiness apps where the logic and rendering really are very separate, but as games get increasingly sophisticated the internal representation and the visual representation get closer together and require tighter intergration. One example is FPS hit detection. Back in the doom days your internal representation could be simple boxes, and the visual just a sprite. Completely separate and don’t need to interact in any way. But now we expect to be able to do proper collision between bullets and the enemy model (for head shots, and so shooting through someone’s legs actually misses rather than hits). Suddenly we’ve got a single representation (the model data) which affects both logic and rendering.

And it gets really complicated when your animation has to feed back into your movement logic (eg. only allowing people to turn after a character plants a foot to spring off of) which in turn feeds back to your animation and rendering.

I have found that the “visual proxy” method mentioned above works very nicely instead of MVC. It gives you a good separation between logic and rendering while still allowing for the tight interaction you need. Plus it’s a good starting point to put a non-immediate rendering system on top of.

MVC is a mix of Observer, Composite and Strategy, these 3 design patterns are in your list. Sorry for the lack of accuracy.

I still disagree and many games use MVC. Lots of people agree with you but complicated doesn’t mean impossible and using MVC may help a lot in online gaming, I won’t repeat what I said. If you don’t succeed in dividing several aspects in your game in order to apply MVC, it might mean that something is wrong in the design of your application, it might mean that some aspects are too tight because of the way you designed it or the way you implemented it whereas it should be easier. I admit that I had some difficulties to use MVC when I began game programming. Now, it is slowly becoming easier even though my collision system is becoming more complex.