M-V-C is one of many "patterns" from the non-game software industry that folks sometimes apply to games.

Th general problem with such approaches is that they come from the non-game software industry, and may or may not be applicable to games.

MVC is a business app model as i recall.

Game software, otoh, is modeling and simulation software. so one would expect "patterns" from modeling and simulation to be applicable, and "patterns" from other types of software to be perhaps less so. if you want to think of the game's data as the model, render as the view, and process_input and update as the controller (or would update be part of the model? i'd have to look up MVC again), i see no major harm. as long as it doesn't lead to unnatural code organization, and therefore unnecessary complexity.

me personally, i'd stick with "patterns" that come from game development- such as the "main game loop" pattern! <g>.

or the "render all" pattern, or the "update all" pattern. or the "process_input" pattern. or the "entities list" pattern, or the "world/level map" pattern.

THESE are the "patterns" one sees in games, not stuff like MVC.

me personally, i'd stick with "patterns" that come from game development- such as the "main game loop" pattern! <g>.

or the "render all" pattern, or the "update all" pattern. or the "process_input" pattern. or the "entities list" pattern, or the "world/level map" pattern.

I am curious about this. Is there any source you could indicate about design patterns for games?

I am curious about this. Is there any source you could indicate about design patterns for games?

check my journal

i'm about to add an entry!

-

Maybe I'm a little rusty on model view controller (although it is one of the first things I learned at university), but games are a very good example of it as far as I'm concerned.

The model is your "data set" or the game simulation.

The view is the rendering of your simulation.

The controller is the input mechanism used to feed the simulation to effect change on it (controllers/mouse/keyboard and input processing feeding into your game simulation).

MVC is all about separating and enforcing responsibility, so that you don't have GUI or rendering code affecting your data set, and that you can display your data set as many ways as you want (i.e. different camera settings).

You can get my take on it, in my article MVC and CBES as it Relates to Game Programming

Actually it is frequently used in games.

One ubiquitous example is online games where processing is done on the server. The authoritative model is kept on the server. The view is shown on the client machine, and many different views can exist. The controller transmits clicks into events that get fed back to the model.

It applies for the whole gambit of online games. Everything from Words With Friends to WoW follow the MVC idioms.

Many large games follow the pattern. Although you don't need to follow it, it absolutely simplifies things. You have a game simulator that does the work. You have a decoupled rendering engine. And you have a decoupled user interface that generates events for processing.

Game software, otoh, is modeling and simulation software. so one would expect "patterns" from modeling and simulation to be applicable, and "patterns" from other types of software to be perhaps less so. if you want to think of the game's data as the model, render as the view, and process_input and update as the controller (or would update be part of the model? i'd have to look up MVC again), i see no major harm. as long as it doesn't lead to unnatural code organization, and therefore unnecessary complexity.

me personally, i'd stick with "patterns" that come from game development- such as the "main game loop" pattern! <g>.

or the "render all" pattern, or the "update all" pattern. or the "process_input" pattern. or the "entities list" pattern, or the "world/level map" pattern.

But MVC and its variants are perfectly suitable patterns for modeling and simulation software, including games. Compared to typical business software there's only a slight shift from independent views of separate UI elements to consolidated (but often hierarchical) views of the whole game and from controllers related to user interaction with UI elements to various types of controllers (remote network players, AI agents, etc.) related to important model objects.

The mentioned game-related patterns are easily combined with a good model-view-controller separation: the main game loop ties together all steps of model, view and controller processing in the correct order and with the correct timing; rendering updates the view from the model; simulation updates involve only the model, which is very important; processing input is the job of some of the controllers ; lists of entities and maps are possible internal structures of the model.

me personally, i'd stick with "patterns" that come from game development- such as the "main game loop" pattern! <g>.

or the "render all" pattern, or the "update all" pattern. or the "process_input" pattern. or the "entities list" pattern, or the "world/level map" pattern.

I am curious about this. Is there any source you could indicate about design patterns for games?

I've been following Bob Nystrom's in progress web book on this http://gameprogrammingpatterns.com/. It's easy enough to follow even as an amateur and there are already a lot of handy chapters online.