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.