> Video games have a main loop, take input, compute the next state, and then merely render the state to the screen. There is no point in manipulating the "UI". The data flow is very clear.
I always thought this is basically the MVC pattern. And it's obviously the only sane way to do things.
Edit: I don't mind the donwvotes, but am I wrong? The MVC pattern simply seems to mandate, at its core, the separation between the model, its graphical representation, and the input from the user. Input -> model -> view. So a game loop where the user input is gathered, the model is updated by calculating the next state, and the view is displayed seems to me an instance of MVC.
Didn't down vote, but the original mvc was a bit subtler than that - originally dubbed user-model-view-controller - the idea was that the user has a mental model of the domain, and the computer has a concrete data model - and the user can act on a view via controllers to translate changes in their mental model to the underlying data model.
(one example of this, while not very graphical, might be a withdrawal from a bank account;the program stores a transaction - the user sees a "Change" in amount available in the account - in the user's mind there's 300 dollars in the account before withdrawing 100 dollars, and 200 after - but this view is a (beneficial lie - the "account" is merely a sum of transactions).
In short mvc wasn't really about a tight mapping between widgets and internal state of the data model - but about translating between the users idea of the domain model and the implementation.
But certainly implementing mvc in a object/message oriented language like smalltalk leads to data flow of input event > controller translation > model update > view update.
Actually that's one way to do things, the two ways being retained mode and immediate mode.
And each has their own use cases and challenges.
Traditionally, however, most well known GUIs (most of the apps people use on the desktop) were done with retained mode libraries (GTK, Qt, Cocoa, and so on).
>So a game loop where the user input is gathered, the model is updated by calculating the next state, and the view is displayed seems to me an instance of MVC.
There's nothing preventing the view being a retained mode UI widget tree -- which is how MVC was commonly implemented iirc.
I always thought this is basically the MVC pattern. And it's obviously the only sane way to do things.
Edit: I don't mind the donwvotes, but am I wrong? The MVC pattern simply seems to mandate, at its core, the separation between the model, its graphical representation, and the input from the user. Input -> model -> view. So a game loop where the user input is gathered, the model is updated by calculating the next state, and the view is displayed seems to me an instance of MVC.