Right now I have 3 objects.
Player, Map and Camera.
They all need information from each other.
For example, player needs to know where he is on the map.
The map needs to know where the player is.
The camera needs to know information from both the map and player.
How would you design this? Just have a SetMap function for player and SetPlayer function for map, etc?
I would suggest a review of Model View Controller patten in practice. Basically you want to avoid too much sharing, but often it can’t be avoid without excessive over design IMO. Then how you communicate depends on details.
Sorry, but sometimes it pays just to “hack it up” and see what falls out. Re-factoring later is always an option. Writing code is better than over thinking design IMO, because by writing code you understand what problem the design is attempting to solve better.
Oftentimes my MVCs are all singletons, so they can be easily referenced from anywhere. Or, I have a main class that holds references to them, and typically the Model doesn’t care about the Controller or the View, but the Controller and View both need the Model. So I instantiate the Model first. Then basically the Controller periodically updates stuff in the Model based on input events, and the View periodically draws everything in the Model. This means a lot of accessors, but it’s fairly easy to keep clean and most of the time you can keep things separately encapsulated enough that you’re only passing a few objects across.
Ugh. People who make MCV out of three singletons shouldn’t be allowed to give architectural advice. 
A little OT:
I am one of the “singletons are antipatterns” people. Singletons are the same as global static variables. Bad.
When i find myself wanting a singleton i ask myself “single with respect to what”. Single per JVM (almost never) Single per application instance (not necessarily the same thing), single per thread… etc. It doesn’t take long to work out that you don’t really want a singleton.
Anyway i use Dependency Injection frameworks now. So i leave the management of how many instances to the glue code.
Ew!
stuff => look at the diagram below.
I would create a Game object that holds the Player, Map, Camera and other shared data. Then pass the game object to everyone. You avoid the problems with singletons and you have only one object you have to send around.
Hm, all right. I tend to have a slightly different implementation of MVC every game I make because I wasn’t completely clear that there was such a specific distinction. As far as I understood the main point was that one handles input, one handles the program’s state, and one handles the output. But it’s logical for the “controller” to be the one that delegates communication between the model and the view. I only ever formally learned about MV architectures, so looks like I’ve been assuming wrong on what the C part does.
As for the singleton thing. I should probably specify that I’ve been working in Objective-C lately, and for whatever reason that’s the way they do it (singletons all over the place) whereas Java just uses static classes. So I’ve pretty much been following the programming paradigm on the platform I’ve been working with. And I actually don’t usually make the MVC globally accessible, I just do it when I’m being lazy and don’t want to access things the right way. I should scale down the singletons, come to think of it. I’ve started using them everywhere since becoming an iPhone developer…
So don’t listen to me. Read these far more educated opinions on the subject. 
Ew… what???
You make fun of Eli, dont you? His description was quite right. The Model must not have any idea of a View (to allow for different or multiple Views of the data), but a View holds a reference of a Model to know what to display. Every modification to the Model is done through the Controller (usually in response to some events or messages), but the Controller does not wrap the Model or something.
hence why i said go and look at this in practice. Real code just doesn’t map to simplistic “this is the best way to do it”. Its also just coding something up is a good idea. Working code is better than a non working “perfect” design… that once you start implementing you realize is useless for your particular problem.
Have any open source examples of largish Java games that are code “right”?
He is saying is that you need to adapt to the problem you are solving, which will likely be different for each project.
I agree with delt0r. Strict MVC in generally can cause more problems than it solves. It is most useful when you have multiple views for the same model. If you aren’t doing that, it probably isn’t worth the trouble. If whatever bastardization of MVC you implement can’t support two completely different views of the same model, then you aren’t doing MVC.
This is how I do it (when I’m not using singletons! :P), although it’s not the way Riven said to do it. Works fine for me.
public class Main
{
private Controller controller;
private Model model;
private View view;
public Main()
{
model = new Model();
controller = new Controller(model);
view = new View(model);
}
public void gameLoop()
{
while(running)
{
controller.update();
model.update();
view.draw();
}
}
}
public class Controller
{
private Model model;
public Controller(Model theModel)
{
model = theModel;
}
public void update()
{
for (int i = 0; i < inputEvents.size(); i++)
{
model.setSomething(someValue);
}
}
}
public class View
{
private Model model;
public View(Model theModel)
{
model = theModel;
}
public void draw()
{
model.getBackground().draw();
for (int i = 0; i < model.getStuff(); i++)
{
model.getStuff().get(i).draw();
}
}
}
public class Model
{
private World world;
private CoolGameStuff stuff;
private GameState state;
public Model()
{
//boop boop
}
public void update()
{
world.doPhysicsAndStuff();
state.update();
stuff.doYourThing();
}
}
So unlike what Riven was saying I make the Model the only class that doesn’t know about anything else, whereas the view and controller both know about the model. The controller knows how to update the model from input events, and the view knows how to show the model’s current state. This approach has always remained very clean for me because all of the actual game always ends up in the model, safe from the potential confusion of having nested input events and the like. Also, it makes it very easy to have multiple views and/or multiple input sources.
@Eli
In strict MVC you would move the model.update() stuff to controller.update(), so that the model doesn’t have any logic in it. It just stores the games state for the current timestep and maybe knows how to load and save itself. What you do is more like a separation of the display logic from the game with your controller being a simple input manager. I wouldn’t call it MVC, but this design is fine however for most use cases.
Eli’s description is (with all respect) very far from what defines MVC. Sure, people mis-implement is all over the place, but that doesn’t make it right.
Please read the official documentation (http://java.sun.com/blueprints/patterns/MVC-detailed.html) of the MVC model, not that wikipedia crap. The Model is allowed to have listeners, and the View is encouraged to be such a listener. The Model doesn’t know about the View, it notifies listeners (possibly the View) of events.
http://java.sun.com/blueprints/patterns/images/mvc-structure-generic.gif
Something frequently glossed over in this fairly naive view of MVC is that the view itself may maintain an intermediary model which it uses for rendering, and may well pull together several Models (eg. a JList will use a ListSelectionModel and a ListModel). The best way to think about it is to apply this restriction: the “Model” should have no information to do with rendering at all - it should all be abstract state, with no knowledge of whether something is visible, where it’s displayed, or what colour it might be. The job of the View is to notice changes to its Models and adjust its internal representations accordingly in order to accurately render itself.
The same principle applies to games.
My game state consists of, for example, a list of gidrahs. The gidrahs are not renderable. They maintain references to Sprites, and those Sprites themselves aren’t actually renderable, they’re just little models. There’s a SpriteEngine that actually looks at Sprites and builds the actual data structures used to render the scene - that’s the View here. And so on.
Cas
I was refering to the fact, that Eli described the interaction of the three components correctly and you don’t.
which more or less correctly describes the roles of the components, while
is either wrong or misunderstandable. Take a look at the diagram you linked - the View must know the Model to know what to display (doing the “sate query”) and the Controller is no accessor to the Model at least not in a wrapping fashion (like your statements seem to suggest to me). Also the Model does not know the View, at least not interface wise. It may “know” the View because it is hooked as a Listener, but that doesn’t make the View and its functionality available to the Model (again like your statements seem to suggest to me).
My experience of the MVC pattern come from daily work with multiple languages, frameworks and application setups - not from Wikipedia. Also I doubt that Sun is the originator of the MVC pattern so the term “official documentation” might be a bit exaggeratory.
You are right about the misimplementations, though. There are myriads of (mostly web-) frameworks out there, that state they implement MVC but doing only something vaguely related…
Yep, I see. I just wanted to explain what I understood from your first post.
This is all interesting, but I’m curious how many of you use strict MVC for games? One reason I don’t think it makes too much sense to have the model notifying of the view of changes via a listener is because in a game setup you will typically have separate timing for rendering and updating - therefore it makes more sense for the view to pull the current state from the model whenever it happens to be rendering.
As for putting all game logic in a Controller… I suppose that means that the game loop and the like are in the controller, and they update everything? That seems like it’s also a pain in games, because I like having an update() function in every Entity where it knows how to update itself. It seems like in true MVC you’d have to only store the current Entity data in one class, then somewhere else have the update() function.
Seems like in a game context it’s more of a pain than it’s worth.