I don't see why it wouldn't apply. Physics doesn't need to know anything about how the object looks. It just needs to know about its physical properties. They may be created alongside the 3D model at authoring time but it's really a separate aspect. I should be able to switch to rendering in wireframe or sprite mode and still have the physics engine work precisely the way it did before.

Quote:Original post by dv
I too think MVC fits in nicely.

Renderer, physics, AI are views of the game objects model. The renderer displays them on screen, the physics engine takes care of collision detection and appropiate responses, AI reacts to model changes etc. the added benefit of the MVC pattern in this case is that all the other views will automatically be updated if the model is changed. For example, when the physics engine moves an object, renderer and AI are notified. This can be extended to user input and networking.

...

I somewhat disagree with your thinking there.

In MVC pattern you usually would have views only have read-only kind of access to models. This would be ideal. With physics being thought of as view for example, it has to apply changes to the models at some point in the process. It can't be exactly thought to be a perfect view becouse of this contradiction.

To apply changes to models in MVC you would use controllers to manipulate the data.

So there doesn't seem to be a perfect way to separate physics from models the way of MVC, unless we introduce physics controllers which get commands from some module listening to view ... but this seems to go a little bit on the side of overengineering?

I would consider physics part of the model, and it would update periodically in the same way that it would without MVC. The model's state changes as a result and the rendering view (or networking view, or whatever) reflects that.

Quote:Original post by lightbringer
On another note, the Model in MVC often can and does include business logic - classes or methods that manipulate the state of the model. Depending on who you ask, it is not just data, but note the difference between business logic and flow control.

This is quite true, and in fact I don't see how you could implement MVC without "business logic" in the model. So including physics as part of the model, and passing it off to a physics sub-system with other data in the model in order to be modified fits nicely actually.

If you're going for separation and your entities are complex enough to justify the extra work involved, an MVC approach plus composition of different components for each model works pretty nice...

Quote:Original post by Kylotan
I don't see why it wouldn't apply. Physics doesn't need to know anything about how the object looks. It just needs to know about its physical properties. They may be created alongside the 3D model at authoring time but it's really a separate aspect. I should be able to switch to rendering in wireframe or sprite mode and still have the physics engine work precisely the way it did before.

I'm not saying it doesn't apply, I'm just wondering if there are other (common) alternatives or specialisations used in the 3D gaming world.

For example in (a strict interpretation of) MVC the model knows nothing of its views, but in many games things that are happening out of the players immediate area are not calculated.

Quote:Original post by taijianT
For example in (a strict interpretation of) MVC the model knows nothing of its views, but in many games things that are happening out of the players immediate area are not calculated.

That does not conflict with MVC, really. The world state is part of the model. That means the model knows where the player is and where the objects are (for instance, the transforms are stored in the scene graph), and can do the calculations as needed (aka when the controller tells the model to update itself as part of the game loop - notice that in a strict interpretation of MVC, your controller could nothing until it receives player input, and we wouldn't have an interactive game... so much for the utility of MVC ^_^;;;). Your concept of view in terms of 3D games might be a bit too broad - the view for games (or for any MVC application, really) is just what is being rendered, geometry chunks that are being sent to the renderer from the game world, where they are sorted and presented on screen.

So to answer your question, as Kylotan already said, yes, the model is quite separate from the view. The physics is part of the model (often the physics "engine" maintains its own internal model of the game world and runs a simulation on it - think collisions, springs, joints and such).

Quote:Original post by lightbringer
...So to answer your question, as Kylotan already said, yes, the model is quite separate from the view. The physics is part of the model...

My example wasn't so good, but my question is not really about MVC, I know it fits, and obviously physics is part of the model. I'm asking if there are other high level paradigms that are commonly used...

Quote:Original post by taijianT
I'm not saying it doesn't apply, I'm just wondering if there are other (common) alternatives or specialisations used in the 3D gaming world.

Quote:
Original post by Kylotan
Physics doesn't need to know anything about how the object looks. It just needs to know about its physical properties...

An alternative way to look at it would be to say that the way something looks is one of its physical properties. Or better ... the way something looks is a manifestation of its physical properties just as the way something moves is a manifestation of its physical properties. If we built up from this point of view we might have a paradigm which resolved around objects and interactions (or particles and forces)*.

That is not to say that this paradigm doesn't have a view, but view has been pushed down the conceptual hierarchy in the same way that the "physics module" is lower down the conceptual hierarchy than the Model or View in MVC.

*I'm not saying this is a plausible/tractable model (at least not now).

So one last time ... are there any other models/paradigms/high level design patterns (commonly) used for 3D games?