How to apply the game architecture with an existing engine?

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

    • How to apply the game architecture with an existing engine?

      Hi every one!
      GCC4 is a great book and I enjoyed reading it. I learned much, especially from the ideas about Process and Component. Thanks to Mike and Rez!

      I'm now trying to write a simple 2D game and I come across some questions:
      1.As we know, the visual representation of the game should be managed by Game View, while the Game Logic knows little (or nothing) about that. But many of the Actors do have RenderComponent or AudioComponent that contains data of the game representation. Do the components break the rule?
      - If yes, should we move the data to somewhere else?
      - If no, how to decide that what data should be in the component and what should not? What method should the components offer?

      2. I'm going to use an engine (named cocos2d-x). The engine encapsulates the system related codes (which basically means that it offers the applications layer) and offers a class named Sprite. The class is used for displaying 2D elements. A common practice for novice is to inherit from the class and simply write any logic you want into it. I'm afraid that this approach may cause disaster in maintenance and I want to stick with the Application_GameLogic_GameView architecture described by the GCC4. How should I design the architecture and components so that:
      - The Application_GameLogic_GameView and the Actor_Component architecture is applied properly
      - Making use of some system of the engine (such as the Sprite class and the application-layer-like codes)

      My English is poor and I may missed something in the book answering the questions. If it's the case, please tell me what chapters I should read again :)
      Thank you very much!

    • babygogogo wrote:

      Hi every one!
      GCC4 is a great book and I enjoyed reading it. I learned much, especially from the ideas about Process and Component. Thanks to Mike and Rez!

      Welcome!


      1.As we know, the visual representation of the game should be managed by Game View, while the Game Logic knows little (or nothing) about that. But many of the Actors do have RenderComponent or AudioComponent that contains data of the game representation. Do the components break the rule?
      - If yes, should we move the data to somewhere else?
      - If no, how to decide that what data should be in the component and what should not? What method should the components offer?

      No, because the logic still doesn't know anything about rendering. All it knows is that it has a map of Actors. The Actor class is really just a way to group everything related to a single game object in one place, but the key is that the logic doesn't know anything about the renderable component and the view doesn't know anything about the logic components (like the script component for example).

      Components should offer whatever methods make sense for the component. You want to create a component whenever you have a property of an actor you want to express. On The Sims 4, we had dozens of components for all sorts of things. Basically, if it belongs to an actor, it should probably be a component.

      Some engines (namely Unity) turn nearly everything into components. Your primary method for writing code is to write a component and add it to a game object. I tend to think that's a bit overkill, but it still works really well.


      2. I'm going to use an engine (named cocos2d-x). The engine encapsulates the system related codes (which basically means that it offers the applications layer) and offers a class named Sprite. The class is used for displaying 2D elements. A common practice for novice is to inherit from the class and simply write any logic you want into it. I'm afraid that this approach may cause disaster in maintenance and I want to stick with the Application_GameLogic_GameView architecture described by the GCC4. How should I design the architecture and components so that:
      - The Application_GameLogic_GameView and the Actor_Component architecture is applied properly
      - Making use of some system of the engine (such as the Sprite class and the application-layer-like codes)

      You should prefer composition to inheritance. In other words, you should prefer to contain an object rather than inherit from it.

      Using the sprite as an example, I would create a renderable component that had an instance of Sprite inside it.

      Make sense?

      -Rez

    • Thank you for replying!:)

      No, because the logic still doesn't know anything about rendering. All it knows is that it has a map of Actors. The Actor class is really just a way to group everything related to a single game object in one place, but the key is that the logic doesn't know anything about the renderable component and the view doesn't know anything about the logic components (like the script component for example).

      So it is perfectly fine that the render component contains the data for rendering (just like the color data of the SceneNode in TeapotRenderComponent).
      Also, it is natural for the render components to know how to render themselves (like the SceneNode which has VRender() method), right?

      Using the sprite as an example, I would create a renderable component that had an instance of Sprite inside it.

      In the TeapotWars, it seems that the render component is a wrapper class of the SceneNode. The primary job of the component includes reading data from .xml files, creating a proper SceneNode inside the component, and sending events. However, the component doesn't render itself--that's the job of the SceneNode inside it.
      So, the SceneNode is basically the same thing as the Sprite. And this is the exact reason that I should create a render component that contains an instance of Sprite, right?

      I'm not sure if I'm right or not, especially to the relationships of the render component and the SceneNode. If there's anything wrong, please tell me, thank you:)


    • So it is perfectly fine that the render component contains the data for rendering (just like the color data of the SceneNode in TeapotRenderComponent).

      Yep.


      Also, it is natural for the render components to know how to render themselves (like the SceneNode which has VRender() method), right?

      Yes and no. It really depends on the engine. Remember, there are as many ways to handle things as there are programmers. In my own game engine, the renderable component doesn't know how to do any rendering. All it knows is how to fill out a render command when asked. The render thread does all the actual rendering based on the render commands.


      In the TeapotWars, it seems that the render component is a wrapper class of the SceneNode. The primary job of the component includes reading data from .xml files, creating a proper SceneNode inside the component, and sending events. However, the component doesn't render itself--that's the job of the SceneNode inside it.
      So, the SceneNode is basically the same thing as the Sprite. And this is the exact reason that I should create a render component that contains an instance of Sprite, right?

      Yes, this is correct.

      -Rez