What changes in a 2D game?

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

    • Would the tile engine just be a SceneNode that gets rendered in the Scene.OnRender() method? Would that be a special render call like the camera is or just one of the children? I'm assuming it would be the first thing in he list of children (Scene.cpp:100 1. Static objects & terrain).

      Would a sprite just be a type of SceneNode? I'm thinking every actor with a RenderComponent would have an associated SpriteSceneNode that would know how to render the sprite.

      I'm trying to make sense of this architecture and how it fits into a 2D game. I'm also using MonoGame(XNA) so I'm trying to figure out how all this fits in with all the examples I'm running across. All the examples are very tightly coupled and this loosely coupled architecture is much nicer.

      Here is an example I'm looking at. david-gouveia.com/portfolio/2d…arallax-scrolling-in-xna/

      In this example, the Camera doesn't draw anything. It's just used to setup the view that each layer is drawing. How would that be setup in the GCC architecture? Each Layer would be coming from the tile engine. Is the Camera in this case an Actor? If so, how would it communicate it's changes to each LayerSceneNode? Would every LayerSceneNode have the same ActorId that is the Camera?

      Thanks.

      Thanks.
    • In a 2D game, what sort of things would change? Would the views, screens, and scenes work the same, except they're rending sprites instead? Where does a tile engine/renderer fit into this?


      The core architecture wouldn't have to change much, but the internals probably would. For example, attachments would need to work differently. In a 3D game, you can do simple attachments by just adding the attachment as a child and let matrix math do the work for you. In a 2D game, it's not that easy.

      Would the tile engine just be a SceneNode that gets rendered in the Scene.OnRender() method? Would that be a special render call like the camera is or just one of the children? I'm assuming it would be the first thing in he list of children (Scene.cpp:100 1. Static objects & terrain).


      My first hit would be to have the tile engine be a scene node with the tiles as children to that node, but that might be overkill. In my own personal engine, the tile engine is its own thing rendered as the first layer, but my rendering system is very different than the one presented in GCC.

      Would a sprite just be a type of SceneNode? I'm thinking every actor with a RenderComponent would have an associated SpriteSceneNode that would know how to render the sprite.


      Yes.

      I'm trying to make sense of this architecture and how it fits into a 2D game. I'm also using MonoGame(XNA) so I'm trying to figure out how all this fits in with all the examples I'm running across. All the examples are very tightly coupled and this loosely coupled architecture is much nicer.

      Here is an example I'm looking at. david-gouveia.com/portfolio/2d…arallax-scrolling-in-xna/


      The vast majority of the architecture is just fine for a 2D game, but I think a lot of the graphics stuff is overkill as I mentioned above.

      In this example, the Camera doesn't draw anything. It's just used to setup the view that each layer is drawing. How would that be setup in the GCC architecture? Each Layer would be coming from the tile engine. Is the Camera in this case an Actor? If so, how would it communicate it's changes to each LayerSceneNode? Would every LayerSceneNode have the same ActorId that is the Camera?/


      For what it's worth, I'll post a brief description of how my own 2D rendering system works. Maybe that'll give you an idea of how to approach something like this.

      In my own engine, the rendering system has an array of render queues where each queue represents a single layer of objects. The queues contain RenderCommand objects which have everything you need to render something to the screen: position, orientation, scale, pointer to the texture resource, etc. There is a single function that exists on my Scene class (the top-level render manager) called AddObjectToScene() which takes in a RenderCommand object. It adds it to the appropriate queue. Everything that is ever rendered in the game goes through this function. It doesn't care where it came from.

      When it's time the render, the commands in each queue are sorted based on the rules for that queue. Then each queue is rendered in order. Objects from later queues will always be drawn above objects from earlier queues. For example, the last queue I have is reserved for UI, so the UI is always rendered on top.

      Objects within the queue are sorted based on rules. For example, UI objects are stored in a big tree so rendering happens from the root of the tree to the leaves. Sprites are sorted by position so I can have the illusion of a sprite walking behind or in front of another. Tiles are sorted by texture because they will never overlap and this allows me to minimize state changes.

      All game objects in my engine (which I call entities) that can be rendered will have a Renderable component. Every frame, the Renderable component will create a RenderCommand object and call AddObjectToScene(). The UI does the same.

      My tile engine is its own class. It exists outside of the Entity system entirely. I did this for a number of reasons, but the two big ones are efficiency (Entities can be expensive) and the fact that I needed to be able to deal with the tile engine as a whole for things like pathfinding. It made sense that it should be its own object.

      Every frame, the tile engine will loop through all visible tiles, create RenderCommands for each one, and call AddObjectToScene().

      I hope that helps. This is a simplified version of what I'm doing that ignores a lot of the other complexities associated with my rendering system (threading, deferred rendering for dynamic 2D shadows, Direct3D & OpenGL abstraction layers, etc.)

      -Rez