Regarding Logic-View separation

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Regarding Logic-View separation

      Greetings. I have read all there is about logic and view separation in the book, but i dont get the whole picture, and i still didnt understand the concept even after reading source code. Can you explain it with example of some very simple game, please? Lets say, i have a multiplayer version of Pong:
      [IMG:https://cdn.scratch.mit.edu/static/site/projects/thumbnails/301/3901.png]

      What i dont understand is how it all fits together.
      Obviously an Actor list should be in logic, but where do i store its visual representation, such as paddle image? Sounds like it should be in View, but how...
      There is a place where i draw everything, what does it look like ? I can only think of View requesting list of all Actors from Logic and drawing them, but it kind of breaks the separation.
      In this case of Pong, View is only sending UP/DOWN commands to Logic, but what kind of events Logic sends to view ?

      Thanks in advance.
    • An important thing to realize about the model-view-controller is that the model is the only one that shouldn't be allowed to 'see' the others. View should have direct access to the model, and render it however it likes, as well as the controller should have access to the model so it can manipulate the data. The idea here is that the controller can directly manipulate the model, causing the results to display in the view.

      The complication starts in how View knows what to render and where, in GCC's code they specifically mention how they made a compromise in the Render component which directly constructs and holds onto a scene node, this is ok, as a programmer you must know that its more important that something works than fitting into an architecture such as model-view-controller ie. If you need to bend the rules occasionally, do it. This however is used in the case of a scene graph, where pre-defined nodes are made and traversed for rendering later. This doesn't mean you HAVE to do it this way, however scene graphs are a proven way of doing things. Imagine this situation instead.

      Model

      The model data in the case of pong may be sprites, in this case you have really just 2 pieces of data that are important for the view: Sprite ID, and position. The model will not construct anything, instead it will simply hold onto this info.

      View

      The view when beginning its rendering, would iterate over the model data, culling sprites off camera, and sorting them into batches. It would than render the built list of 'render calls' ie.

      Source Code

      1. for-each modelEntry in sortedModelList
      2. render(modelEntry.spriteId, modelEntry.position)


      Controller

      The controller is really simple, and sometimes it is even built into the view, this will really just send commands off to an interpreter, or even more simply directly manipulate the model ie.

      Source Code

      1. if Keyboard.Left isDown
      2. modelEntry.position += 5 * deltaTime
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz