I found this to be a very interesting read:
http://www.gamasutra.com/features/20050414/rouwe_01.shtml

It is Shell Shock, ‘nam 67 (an medal of honor type fps) made with MVC.

They touch on animation as a sticky point for them as well, because for some games the animation is NOT just a view concern, but it can change the model as well due to shifting bounding boxes or detailed collision requirements.

I think in most MVC use cases there are going to be some fuzzy areas where you have to compromise the principles due to the harsh reality, heh.

I have not done ANY MVC work yet myself, but I am drawing out different UML designs right now to see what structure will work best for me.

I can already see that the division will be the only thing that will keep me sane as it is a multiplayer game with a polling engine where the game pieces could be local users, simple ai, or remote players. Being able to manage the difference by just making multiple controllers where needed is going to be very nice.

My first go at this I had a lot of repeated code for local and remote player objects. Now the difference is just what the controller does with the input which can either be polling responses or clicks being forwarded from the view. I have never been happier to throw old code away, heh.

One problem I face is that there is some natural encapsulation of objects that need to be scattered through M, V an C. For example, it is natural to have a spaseship as an object, however, the spaceship has a model (it is part of the physics engine), a view (a mesh or sprite that could be view dependant) and a controller (in my engine some AIs are part of the controller since they can replace users easily).

How do you handle this problem in your game engine? Do you know of an open source example I can have a look at?

I’ve looked at the game/component approach, and I agree that it doesn’t seem like quite enough.

Though, I also don’t think MVC by itself is enough either..
I think adding more abstraction to the architecture could be more beneficial. I think a domain-driven design approach to game programming, with a more complicated/abstracted architecture would lend itself very well to game programming.

My proposed architecture is something similiar to the following (based on MVC and domain driven design)

Application Layer
- Contains application.interfaces, and application.services
all services use interfaces, generally hold logic for animation, and things that the models/entities have to do

Domain Layer
- Domain.Model contains physical entities
- Domain.Repositories contains repository interfaces for accessing Models from the db

Infrastructure layer
- infrastructure.orm if you want an ORM, put it here (ex. EF)
- infrastructure.repositories – concrete implementation of interfaces from domain.repositories

IOC layer
- Inversion of control if want to use it (would be interesting to see how it works with game dev.) this architecture lends itself to using IOC containers and dependancy injection

Test Layer
- unit tests

Controllers Layer
- access the models, pass data to ui layer (views)

UI Layer
- UI stuff

Again, I am just starting game dev, and I haven’t tried any of this in the context of game dev yet, however I plan on trying it. Anyone have experience with anything similar and can offer some feedback?

I’ll give you a brief overview of how my MVC engine works:

Controller
This handles the input and flow of the game logic. This is akin to the states your game can be in. My primary two controllers are main menu controller and an in-game controller.

They are responsible for converting input into something the game world (model) can understand. Eg “Create unit x at base y”.

Model
This handles all game logic. It has nothing to do with input, rendering or networking. It is a pure view into the game world. Designers need only worry about what’s in the model.

View
The view handles rendering of the model. Unlike what you said, the view DOES know about the model. The has read-only access to the model. This model can be anything. For my main menu it’s a list of UI controls the controller has built. For the in game view, it’s the game world.

To keep things clean and consistent I use Interfaces in most places. Rather than “reusing views in different controllers” what is more important is “having multiple views on a single controller”. For example there might be a 2D and a 3D view of the game world.