1
\$\begingroup\$

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.

The questions:

  1. 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?

  2. 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)

  3. 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.

\$\endgroup\$
  • \$\begingroup\$ The question isn't concise as is. Is the base question, should the view handle the the model as monolithic object or instead handle a finer granularity and react to each specific change done to the model? \$\endgroup\$ – wolfdawn Feb 5 '14 at 14:03
  • \$\begingroup\$ I spent probably 20 minutes specifying the question and culled it down to the three distinct easy to understand options and have solicited answers in another forum. Yes, the question is as you specified, 1 or 2 (or 3, I mean you just restated what I asked...) and a confirmation that 1 is a good implementation and whether some other implementation exists. How is the question not concise? It specifies 3 implementations, and asks for the correct implementation of the problem vs inertia, whether it is one of the 3 is irrelevant. I am asking for the preferred implementation. \$\endgroup\$ – dlots Feb 5 '14 at 14:24
  • \$\begingroup\$ 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 changes or the game state in a View as opposed to executing direct calls to render objects. This is a serious consideration as it would be an optimization to cull the abstraction specified in #1 and #2. \$\endgroup\$ – dlots Feb 5 '14 at 14:42
  • \$\begingroup\$ I think what confused me was that it's numbered 1. 1. 2. (probably a site "feature") instead of 1. 2. 3. - besides I did not mean that your question is in poor form, just that I want your help to get to the bottom of it. \$\endgroup\$ – wolfdawn Feb 5 '14 at 14:42
  • \$\begingroup\$ The question comes down the fact that: If no one is writing games as giant View reactors to state I don't necessarily want to start even if it's logically correct. If on the other hand if everyone is in fact writing games as View reactors, I'm fine with that too. Soo, basically how does Anvil, Frostbite, COD, Blizzard, Source do it? \$\endgroup\$ – dlots Feb 5 '14 at 14:58
1
\$\begingroup\$

There is rarely one correct way to accomplish anything when it comes to design patterns. There are of course properties that we as programmers deem useful. When we are required to reuse or extend code we tend to cherish flexibility. This property is often attributed to decoupling objects. Hence I don't believe the third option is strongly advised.

The other issue that was brought up is the amount of granularity that would be preferable; As in should we react to each separate change or instead render the model in it's entirety. This is a tradeoff between additional flexibility and optimization vs. robustness and simplicity. This is nearly entirely opinion based and is heavily influenced by the requirements of the project and the technology that is being used. I always lean towards simplicity because of time budget and debugging concerns. If the system is well made it may leave the issue of granularity to the game designer or rely on the robust solution. I would not advise to force the high granularity approach and I believe it is not forced in any engine I used this far.

\$\endgroup\$
  • \$\begingroup\$ Thank you for your answer. As this is a crtical portion of an engine, I would like to solicit additional answers with regards to commercial engines in the context of 2 goals: optimizing to hit 16ms, facilitating industry preferred workflows. I've given this question a lot of thought and I have 800 points on Stackoverflow. It really is an important question for me. \$\endgroup\$ – dlots Feb 5 '14 at 15:07
  • \$\begingroup\$ Hitting 16 ms mostly relates to computationally heavy processes such as AI, physics and rendering. I don't think the design pattern you pick will play a major role in optimizing performance. Industry preferred workflow are a viable concern to some but would require us to contact industry leaders and sum up the statistics which is often beyond the scope of this format. \$\endgroup\$ – wolfdawn Feb 5 '14 at 15:31
  • \$\begingroup\$ I think you would be surprised with regards to 16ms, especially considering the targets are potentially WebGL and AVM2 and implementations are with regards to inertia and the tradeoff. I am not looking for an epidemiological study. :) There are plenty of AAA developers who can offer their experience or traversal of the Carmack's, Sweeney's, Gaben's work. \$\endgroup\$ – dlots Feb 5 '14 at 15:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.