I would like to know the correct implementation to declare game logic and view logic:
I see 3 ways of implementing this:
1.Storing (eg writing preprocessing to store the change to a property) property changes to data entities that are dispatched to listener(s) of the data entity. The main listener being the view, where the view contains the declared rendering logic (ie changing the entities animation based on a property change, changing the entities render object position).
State Model (x,y,z,state) -> View (listens to change in x,y,z,state)->Scene graph object (x,y,z,animation, gets set by the View)
The issue with this is that it becomes evident that game engines are executing a lot of
char switch statements (eg the names of properties) in the View.
2.Declaring the view as updating to the entirety of the model. Eg, instead of saving the changes as specified in 1) the view updates the render objects on every tick by inspecting the entire model, as opposed to the provided changes of 1). The tradeoff between 1 and 2 is the necessity of the additional execution of storing the property changes on the state tick.
3.Declaring animation logic in the state logic. Eg, instantiated member render objects are dummy objects when rendering is not performed.
As specified in the title, what is the correct implementation to reacting to the game state in the sense of where should one declare display/rendering/animation (view) logic that reacts to the game state?
What is the implementation used in most game engines that facilitate large projects? (if possible, please specify for specific engines: SupremeCommander/clones, SC2, Unreal, ID, Frostbite, Anvil)
Which implementation do studios implement to architect projects using said engines? It's apparent that it is possible to not seperate model from view in the above engines. Eg, if you implement an entity, you would presumably want it to be viable in multiplayer, coop, and single player.
The questions regarding other engines deals with the fact that perhaps it has been evaluated that it is not a sufficiently optimized implementation to consume the state in a View as opposed to executing direct calls to render objects.
So, on tick we update the game data simulation. For example:
The state of a unit's weapon is updated to firing. However, updating the view of the weapon to firing (by for example, setting the animation of the weapon and animating the hand) is not necessary in all instances of the simulation.