next »

[J.G. Martins]

So, some time ago, in this thread there was a post by Michelle about the MVC pattern. She dropped this article about one implementation. Since it seems such a good design pattern, I'd love to get some more ideas/discussion/feedback regarding it.

So basically, the Model is the digital logical representation of an entity. It would contain stuff like position in the gameworld, life, status, size of beard, etc.

The Controller is kind of the AI interface. Somewhere in there, an algorithm queries the Model to know the current state, and makes a high-level decision, then translates it into low-level actions that have to be executed by the Model. Thus, the Model queries the Controller as to, say, its desired direction, speed, weapon in hand, etc.

The View contains information regarding the way you represent the entity visually. From the article, it seems that the View queries the Model in order to translate its logical state into current visual representation (that the user can see). Thus, the Model must keep enough information so that this translation can occur, but is essencially independent from the View itself. Note that a Model may have several views: the simplest example is the on-screen sprite or 3d model and the minimap identifier.



So, the Model is independent from the View, but not from the Controller. What would be the merits of making the Model independent from anything at all? Why can't it live as an entity with no dependencies? Why can't it be the Model that provides an interface through which the Controller commands it? The Controller would become more like a puppet-master and the Model the puppet... this seems what the Game Programming wiki talks about in its article, but it's not elaborated.

What are the pros and cons of each then? Either way, it seems somewhat straightforward to implement new Controllers or Views (one of the main advantages derived from MVC usage).

Thoughts?

[Lynx]

You might have a controller controlling many units of the same models, or a group of models, hence the distinction.

[Ina Vegt]

The idea is basically (As I understand it):

The Model holds, hands out, and stores data, nothing else.
The View creates the user interface.
The Controller queries the model for data, manipulates it, and gives it to the view.
The Controller also queries the view for events, processes them, and hands data to the model.

With this system, if you wish to change, say, the save game format (say, xml to your own format), or switch to a different graphics storage format (Say, .gif to .png), you can keep the controller intact, and just make the needed changes to the model.

Likewise, you can completely overhaul the user interface, without needing to change the controller.

In addition, if you're going to make major changes to one of the three, you can do it in a seperate folder, and keep the other two using the old as long as the new one isn't finished, and if you did it right, you'll be able to use the new without changing the other two, even though they had been built for the old.

It's part of the OO way of thinking, you could sorta see the three as big objects, the most top-level objects you have, the Controller doesn't need to know how you save your game, as long as he can ask the Model to load a savegame.

This has the biggest advantage when you work in teams, though. (Say, in a website, SQL guys create the model, HTML guys create the view, and PHP guys create the controller, each of them can create temporary stubs for the others's work so they can get working immediatel.)

[Lord Tim]

I've actually worked with these a bit, and here's how I've used it (C#).

The Model is essentially an interface. It doesn't have any real code. Just variables that can be changed. (With C# each variable also has a corresponding event which gets triggered if the variable is changed). The model has no knowledge of the view or the controller. It just contains data.

The View can see the model, but not the controller. It is similar to the model in that it has very little code. Mostly, it just has variables that hold the state of the UI so the controller doesn't have to know what kind of UI it has. Only the view can see the UI, and the UI can only see the view.

The Controller can see both the view and the model. In C#, it works off events that are triggered by the model/view. This is the part that is actually exposed to other objects. You call methods in the controller, and it gets data from the model, and sets data on the view.

From what I've used of it, you'd have one of these for each object in your OO code, and not just one big thing controlling everything, although that would work too. Hope this helps.

[professor dead]

i flossed my teeth this morning, you don't see me bitching about it.

[J.G. Martins]

Thanks, Lynx, that makes sense

Ina and Tim, I don't think you're talking about applying the MVC pattern to game development, but enterprise services of some sort, correct?

I don't truly agree with the fact that the Model should simply hold data. It should encapsulate very well the entity that it's representing, otherwise, other parts of the program must know how to work with and handle Model data. This violates some programming principles.

Imagine something as simple as a train. The only thing it can do is go forwards. The Model would simply have a "speed" setting. There can be a few different types of Controllers for it: one that tries to reach the destination as fast as possible, another one that follows a schedule with trainstops at predefined times, etc.

How do the Controllers control the speed? There should be maximum speed, acceleration and deceleration properties, for example. By making the Model data only, all Controllers need to be programmed to handle these characteristics that are intrinsic to the Model. So, for every Controller you do, you'll be worrying about not exceeding speed and such. Bad Controller programming will lead to restriction violation and whacky happenings in-game.

To simplify Controller development, this kind of stuff could easily be encapsulated within the Model. It can query or get told by the Controller what the desired speed is such that it will enable the train to maximize a utility function of some sort. The Controller figures out what the desired speed should be, and the Model runs a routine to try to get to that speed.

This way, as long as the one, single Model is well programmed, no violations will occur. You can write as many Controllers as you want, you won't be able to make it break, although stupid decisions may be made

What do you guys think?

[cpets]

After spending quite a bit of time trying to get a proper understanding of MVC and its applications, I've come to the conclusion that MVC is whatever you want it to be.

Most every project that uses MVC defines the concepts as they like, and then goes on to make exceptions appropriate to the problem domain. Check out Apple's take on MVC. They establish an entire vocabulary around subclassifications of controller, which is great for people working within Cocoa, but pretty much meaningless outside of it.

And then there's this FAQ entry from Django, which calls its controllers views, its views templates, and its models models. They note that the definitions are debatable, and they're right.

I think the best thing MVC can teach us is that we can break our programs down along lines that we might not otherwise consider. If we're modeling a car, the obvious components are wheels, engine, steering wheel, and so on. But these concepts are too coarse, so we subdivide further to WheelModel, WheelView, WheelController.

And this works fairly well for GUI development, but in games, the MVC trinity is overly simplistic. I read this article this morning, and it certainly makes MVC-type distinctions, but it goes much further. It also avoids shoehorning its objects in to MVC classes, which is refreshing.

So I guess in the end, the principles of MVC are great and instructive, but if you're even thinking in these terms, you've probably already extracted most of the benefit. If your physics logic is separate from your display logic, and your ai logic is separate from your physics, it doesn't matter what you call it. You've won the MVC game.

[J.G. Martins]

Heheheh, thanks Cap, that was a good post. I'll have to find some time to read up on those articles! Thanks again

[Ivan]

I tend to think of MVC as a positive byproduct of good code design. I don't think it's a very good paradigm to actually design projects by (it tends to overcomplicate things), but most good architectures will more or less resemble some form of MVC in the end.

[Traveller]

I just started my first MVC project recently, and while I don't have a great understanding...here's my take.

The model enforces rules; your car may be driven by a human Controller or an AI Controller, but none of them should be able to make it go from 0 to 200 in a second (unless you are playing F-Zero).  This helps you by making sure a transition from one Controller to another is fairly uncomplicated.

The model doesn't hold any graphical data at all; that is the View's job.  This helps you by making it easier to split stuff into a client-server architecture, among other things.

Heck, they both help out client-server a lot.  If your View for a tank says "it's green" and your Controller says "played by a bot", the Model is what says "it keeps going in a mostly straight line if you don't accelerate or brake".  The Model is useful for both client and server, and may not even need modification to the core game logic.  Ideally, you use the exact same Model class on client and on the server!  The View is entirely useless for the Server (the Model might know what to load in the view, but it doesn't DO it on the server), and the Controller is different at both ends of the line--the server has a BotController and the player has a NetworkDrivenController or whatever.

I think it's irrelevant whether the model polls the controller, or the controller pushes things at the model, for practical coding.  My game even bends model-view a tiny bit by occasionally having references to the view in the model where convenient for really nested stuff.  The big advantage to me for MVC is it makes network multiplayer development a lot easier!

I WOULD say that it doesn't make sense for a model not to have a controller.  Things like sparks and snowflakes that are purely visual and not the same across clients...those have a view but not a model or controller (something spawns a ParticleView and gives it to the ViewHandler, but no models anywhere).  Things like meshes that are not world geometry, but will never move (like, say, a really fancy chair in the middle of the room) DO still need a model, in my mind, AND a controller:  The client has a controller saying "this is a physics object controlled by the server" and the server has a controller saying "this is never going to move" or "this can only be moved by scripted stuff".  Doesn't matter if the chair never DOES need to move, and just as easy to code.  But if you ever need to add a way for it to move later, it'll save you lots of time.

If it doesn't need a controller, then in most cases it doesn't need a view.  It's rare to have something that can impact the world, but never change.  And in my game, being sent downstream to the client by the server *IS* a Controller.  The only View-only things are spawned entirely clientside, by a View on a Model that was sent downstream...by the server.

[nihilocrat]

Hmm, my code has a naiive idea of MVC. The View is "stuff you see" and the controller is "means to control objects in the View or Model", and the Model fully represents the game if it had no display or input interface. The event-dispatching classes are actually in the Model, and I should probably really have it in the controller. I try to make sure that data is passed around between the layers in one of two ways; certain objects that are allowed to combine the layers, and triggering and handling events. The View tends to be pretty thick; it contains stuff which you can see but has no bearing in gameplay, like particle systems for effects.

The core of it is the events system. This is really a great thing, because there are many things that might happen when an actual event occurs in your game, and keeping stuff seperate but still able to do something about the event makes things really clean. When a bullet hits a ship, a "bullet_hit_ship" event is dispatched. The Ship object in the model handles this to calculate damage, the renderer handles it to generate an explosion effect, and the audio system handles it to play an explosion sound. Doing all of this in the actual collision callback function is possible, but gets unwieldy very quickly.

Logic / presentation separation of some sort becomes vitally important if you ever want your engine to power a network multiplayer game. I wouldn't know where to start if you didn't at least have a strict "GameLogic" / "GameVisuals" seperation.

[Zaknafein]

I tend to think of MVC as a positive byproduct of good code design. I don't think it's a very good paradigm to actually design projects by (it tends to overcomplicate things), but most good architectures will more or less resemble some form of MVC in the end.

YES. This.
I'm probably overreacting, but my opinion of design patterns much resembles Jeff Atwood's; don't use them blindly, and if possible don't use them at all. Good understanding of the problem domain and the programming language/environment, and just plain common sense (KISS, DRY, YAGNI) will guide you much better than ready-made solutions.

[Hajo]

I'm probably overreacting, but my opinion of design patterns [...] don't use them blindly, and if possible don't use them at all.

I think it's futile to advice not to use them. Imagine if people start to avoid all the patterns. Search for other ways to achieve observer functionality, proxies, factories, commands, facades and such ... the patterns were discovered as patterns because they were commonly used, and found to be good ways to solve certain problems.

Sure, people should thinks first what they do, but design patterns are good guidelines how to solve particular problems. While MVC seems to be one of the most often misunderstood or wrongly used patterns, I still think it can be very useful once you understood why it was designed this way.

[bateleur]

The thing about design patterns is that one often comes across code or even entire projects where the programmer has made a huge mess and a design pattern would have improved matters enormously.

At the other end of the scale, there are programmers who are simply brilliant and devising ingenious code structures which save them work and make everything wonderfully robust.

Somewhere in the middle is me (and likely most other moderately experienced programmers), capable of coming up with basically non-stupid designs, but unlikely to find the best possible way to do every project first time.

Reading about and talking about design patterns is useful not so much because they're the perfect way to do things as because they have some chance of saving you from bad ways of doing things. (And in particular, from unstructured mess!)

[progrium]

There are lots of ways to look at MVC. I've seen soooo many. There are also variations where model and view are the only elements because the controller is implicit in whatever environment. It can even be recursive, where you can break down the "view" in your system to have it's own MVC stack conceptually.

It's a nice separation of concerns and Chris Hecker has made a great general point about proper decomposition schemes providing loads of power.

Just how I break it down in the context: model is domain specific (todo lists, weapons, wikipedia articles, players, users). Controller is infrastructure specific (HTTP requests, game modes or states, etc). Views are user perspectives into the system. They might be templates, meshes, what have you.

When I design OOP, I try to make my model (the domain specific part) independent of the type of system it's being modeled in. So I could take it out of my web app and put it in a game world or into a command line program. It's the core reason for what I'm building... the thing I'm modeling.

The controller is infrastructure and usually is more tightly coupled with the view because the controller is generally responsible for manipulating the model and giving it to the view. The controller might be YOUR ENGINE. In fact, even if you don't do MVC, you can still try to conceptually break down your system in to MVC because it's just a conceptual model.

[r.kachowski]

I came across

videos when I was messing around with ruby on rails. There's a whole site of them here.

It's basically the most awesome set of videos on MVC you could imagine with Burt Reynolds added on top.

[Traveller]

Hey, here's a fun naming question!

"Model" is an annoying term when you're working in 3d.  It's mostly just confusing, because any sensible API or toolkit will call them "Model3D" or "APIModel" or something not just one word long, but still.  But I have trouble finding another word that expresses "Model" in the MVC sense.  It models the whatever data you're tracking, but just 'data' doesn't work because that's different, and 'representation' sounds like it belongs in view.

So what else can you call "model" besides "model"?  Even my thesaurus doesn't help much.

[Ivan]

It's funny that this thread was created. I just started on a project at work that's using PureMVC for AS3.

[Mikademus]

Basically, in a games context, it is really simple. The model is a game object. It doesn't know anything about its representation. Unless it is dependent on input the sum of the models, which constitutes the game, can play itself. Controller provides input to the game logic (the models) and sometimes adjusts the view. View objects reflect models and user interface aspects of the controller. That's it.

So at its very core, MVC is to decouple three central application aspects as fully from each other as possible.

[Solved]

Ignore this post