Here's my original answer to a similar question on SO from a while back, at least concerning the MVC part of your question:

It's rarely used in games. It took me a while to figure out why, but here's my thoughts:

MVC exists to make a distinction between two representations. The Model is the abstract representation of your data. It's how the machine views the state of your application. The View (and Controllers) represent a more concrete visible instantiation of that system in a way that's meaningful to humans.

In most business apps, these two worlds are pretty different. For example, a spreadsheet's model is simply a 2D grid of values. It doesn't have to think about how wide the cells are in pixels, where the scrollbars are, etc. At the same time, the spreadsheet view doesn't know how cell values are calculated or stored.

In a game, those two worlds are much closer to each other. The game world (model) is typically a set of entities positioned in some virtual space. The game view is also a set of entities positioned in some virtual space. Bounding volumes, animation, position, etc., all things you would consider part of the "view" are also directly used by the "model": animation can affect physics and AI, etc.

The end result is that the line between model and view in a game would be arbitrary and not helpful: you'd end up duplicating a lot of state between them.

Instead, games tend to decouple things along domain boundaries: AI, physics, audio, rendering, etc. will be kept as separate as possible.

Here's my original answer to a similar question on SO from a while back, at least concerning the MVC part of your question:

It's rarely used in games. It took me a while to figure out why, but here's my thoughts:

MVC exists to make a distinction between two representations. The Model is the abstract representation of your data. It's how the machine views the state of your application. The View (and Controllers) represent a more concrete visible instantiation of that system in a way that's meaningful to humans.

In most business apps, these two worlds are pretty different. For example, a spreadsheet's model is simply a 2D grid of values. It doesn't have to think about how wide the cells are in pixels, where the scrollbars are, etc. At the same time, the spreadsheet view doesn't know how cell values are calculated or stored.

In a game, those two worlds are much closer to each other. The game world (model) is typically a set of entities positioned in some virtual space. The game view is also a set of entities positioned in some virtual space. Bounding volumes, animation, position, etc., all things you would consider part of the "view" are also directly used by the "model": animation can affect physics and AI, etc.

The end result is that the line between model and view in a game would be arbitrary and not helpful: you'd end up duplicating a lot of state between them.

Instead, games tend to decouple things along domain boundaries: AI, physics, audio, rendering, etc. will be kept as separate as possible.