Some MVC related questions

[Alluvian]

I am drawing out my classes for a game in early development, and largely as a learning experience, I am wanting to implement MVC as much as I can.

For background, the game can be thought of as a boardgame. Tilebased, turnbased, multiplayer being kept in mind for release 1 or a future edition, so I want to keep it in mind when making the framework.

Each boardpiece (going to call them entities) will have a lot of data with it, so it makes sense to me to have each gamepiece as an MVC trio.

The entity models will all be referenced/collected in a gamestate class/object that handles their non-autonomous functionality. They are going to store properties like grid positions, health, action points, inventories, basically I am thinking of drawing the line that anything that would need to be in a savegame goes with the model properties, and nothing more.

The entity views will handle all the animation states, tweening, and the x and y pixel positions relative to the gameboard taking into effect scaling, etc...

There will also be views for hud elements, and the board itself. All of the views will be aggregated by a renderengine class that is basically going to be the view equivalent of gamestate. Each entity will know how to draw itself, but the render engine will be responsible for telling it when to redraw.

So.... That leaves controllers, and this is where I am having separation anxiety. There seems to be thousands of different schools of thought on what the C in MVC should encompass.

Model / Controller boundary

I have seen some game frameworks where it seems like AI is handled in the controllers, but wouldn't that normally be considered domain logic? Is it okay to put AI in the controller? I really like the idea of being able to assign controllers like "LocalHuman", "RemoteHuman", and "AIEnemy" to the same gamepiece depending on the situation. It would allow me to charm a player, or to easily reuse model and view for a gamepiece in multiplayer and even use them as NPC enemies or even allies. Is this kosher? If AI is in the controller, it will have to know pretty much ALL of the domain logic. Or should I even care, am I letting the strict framework bind me instead of using it as a tool?

I see this as a slippery slope. Putting AI into the controllers then makes me think if pathfinding should be on the controller or model? I still think I am going to put that in the gamestate class, but I waffle.

Maybe controller should just be "what do I do when you click on me" and have the model composite with some separate AI classes.

My idea of handling AI in the controller came largely from a dev at gorilla games:
http://www.gamasutra.com/features/20...rouwe_01.shtml
This take on the framework seems to have a very fat controller and very thin model.

View Controller boundary

So, then I start looking at the UI. I really don't have a firm grasp on how EXACTLY interaction will work in the game itself, and it is likely to change a lot in testing, so I want it to be pretty flexible. Do users want to drag their piece to move, or click to select, click destination, etc...

In a game, how little should the view be used for UI? Should the individual entity views intercept and pass click data to the entity controller or should the larger V renderengine capture all input and pass it to some controller collection, some kind of gameFLOW object. Then it would track what to do with all the clicks depending on what phase of the game it is in (like ignoring most clicks when the computer is moving its pieces or when a remote player is thinking out their turn). gameflow could have UI type properties that don't seem to fit anywhere else like what is highlighted, or what is being dragged right now.

What kind of statements do I send to the controller from the view? I am thinking things like "User clicked on player 2", "user clicked on tile row4, column 30".

If a player is dragging a gamepiece across the board, does the controller have to get spammed constantly about where that piece is as it is being dragged or do I just let the user drag the piece entirely in the view and then tell the controller "piecex dragged to grid x,y". Who stores data on what is draggable at any given moment? Controller?


Thanks for reading!
Sorry for the rambling, this has been mostly stream of consciousness. I have been reading WAY too many conflicting reports and don't know any good programmers locally to bug, heh.


I have a feeling most responses here will be "Don't use MVC framework", but there is a bigger picture that I want to learn this as it applies to game development. I am moving to a new state and several local game dev studios are there and they all use MVC heavily due to rather large teams. I'd love to direct my hobby towards possible future employment where possible.

[dandylion13]

Hi Alluvian,

The MVC is the best architectural pattern that I've found for games. It's solves so many problems automatically and scales seamlessly. I'm a big MVC fan!

Regarding your controller question:

Yes, AI in the game controller. The game controller should handle all the game logic. The game model *could* do some internal processing for some housekeeping tasks, but it shouldn't be actively involved in the minutia of game logic. For example The model could flag winning and losing conditions, but it probably shouldn't be more granular than that. You loose flexibility if you assign the model too much specific processing to do, and that flexibility is the great advantage of the MVC in the first place. Better to keep the model as generic as possible, and snap in different controllers to handle the game specifics (like AI) as you need them. The model's job is really just to be a repository of game data.

I'm not entirely sure I understand you other question, but let me try

You've got individual game pieces which are self-contained MVC systems doing things like listening for mouse clicks, right? I'll assume these exist inside a big, global "game MVC" system which is the game model, game view and game controller?

All those game pieces basically become part of your game data. They're "visual data," yes, but data nonetheless. So, as data, You could store them in a two dimensional array in the game model (You'd need a two dimensional array to store both their models and views... or you could just use two arrays). Because the game controller has access to the global game model, it will then also have access to the game piece models and views. So, it can read their states and make changes to their models, and remove them from the game if it needs to. The global game controller becomes a second controller for the game pieces. It's quite acceptable for models to have more than one controller in an MVC framework.

Anyway, that's one approach that might work and remains a strict MVC implementation

(You'll also have a global "game view" but its job will just be to display the board/level and menus, not handle clicks on individual game objects.)

[Alluvian]

Thanks for easing some concerns. I think most of the 'model holds domain logic' comes from web applications. A quote I have seen about strict MVC is "You should have smart models, thin controllers, and dumb views". That does not fit the game application of MVC very well, usually in a game I see smart controllers, thin models, and dumb views.

My main second main concern other than putting things like AI in the controller was where to capture mouseclicks. Obviously it is the view, but I was wondering what layer of the view. Let me give you an idea of what my UML looks like in my head.

Each entity has an entity model, and entity view and an entity controller. Entities right now are the gamepieces and the gametiles.

I think of these as lowercase m, lowercase v, and lowercase c. To ease delegation and tasks within m, v, and c there seems to also be need for aggregates of all of these. So there I have uppercase M (GAMESTATE), uppercase V (RENDERENGINE), and uppercase C (GAMEFLOW). They handle all non-autonomous actions or data retrieval that needs multiple models. GAMESTATE has an array of all entity models for instance and would have methods that need to look at multiple game pieces like collision detection, telling me what is at grid coordinate x, y, or determining pathfinding between point a and b.

That is the easiest part for me, the model. I can easily see direct interaction with lowercase m making sense. Some controller telling mob21 to lose 6 hit points or to move to a given grid coordinate.

The view is also pretty straightforward except some questions about capturing user input:

Should my individual entity views be capturing mouseclicks on them or should my RENDERENGINE (the parent) be capturing mouseclicks? The RENDERENGINE can maybe avoid confusion if a gamepiece graphic and a tile graphic are occupying the same pixel by sending one event to the controller instead of one for the gamepiece and one for the gametile.

And a similar question on the controller, do I want to send UI events directly to the little c or just to the uppercase C aggregator?
I would really have to pass it up to the parent object in C almost always anyway. A gamepiece controller really does not know what to do about a mouseclick on it unless it knows what exactly is going on in the other gamepiece controllers. Clicking on an enemy could be requesting data about that enemy or responding to a prompt about which enemy to attack. That data would be stored in the GAMEFLOW, or uppercase C. I could have that data in all entity controllers, but that seems like a LOT of data duplication and is asking for bugs (multiple controllers being flagged as active)

FINALLY, who listens for keyboard input? Should the view handle all UI or just the GUI?

Does this make any sense?

[dandylion13]

My guess is...

- v handles mouse clicks, c processes those clicks and stores them in m.
- C can read all that data and change it if necessary. That's because C has access to M, and m is stored in M. (M.m)
- V can use m's data too if it needs it for rendering because it also has read access to M.

... just some ideas