Should an object in a 2D game render itself?

  • Should an object in a 2D game render itself? jmasterx

    I'm making a 2D street fighter-like game that is not tile based. Usually people recommend that entities be given to a renderer that render them, not them render themselves, but it seems the inverse is better,

    Why is one better over the other?


  • Disclaimer: your question doesn't give much detail so I'm responding with a general principle. Please excuse me if I misunderstood your use or 'render'.

    I generally use an external object to render various actors in a scene as a way of encapsulating scene level properties and methods outside of the individual 'actor objects.' Objects in the scene should only contain internal methods and properties; they should only know about what they themselves are and what they do. Presumably, they will be influenced by other objects in the game as well as user input. This will effect how/whether they are rendered on the screen. A 'director object' can, for example, translate the 'w' keypress to jump, then tell the actor object .jump(). Such director level logic can also tell actors to enter or exit the scene entirely.

    Cheers, David

  • What if someday you want to port your game to a different resolution (ie iPhone and friends). Thus, a global property about rendering changes, how do you easily update your code?

  • In general it's always about how easy it is to maintain and expand your code. Tomorrow you figure out that you don't like the graphics API you're using currently, and want to switch. Will you now have to go through all of your objects classes and change everything, or do you still just need to change your code in one central point of the project?

    It depends on what your objects are really doing when you call render(). As long as they just wrap method calls around your graphics engine, it's completely fine, since logics <-> graphics distinction will still be given.

    For example, if your render() methods are basically convenience-methods and look something like this:

    void MyClass::render(const Graphics &g)


    void MyClass::render()


    void MyClass::render()

    or close to that, I don't think it's a problem whatsoever.

  • What I used was an observer-based design. When I created an instance of a class I wanted to render, then a pointer to it was stored in the central Renderer class. When you call RenderFrame(), then the renderer already has all the existing objects it needs to render and accessed their properties to do it. The classes themselves had no idea that they were going to be rendered at all. This API was nice and clean and easy to use.

  • You want the rendering system to be in control of what gets drawn when. If instead the sprites are in control of the rendering you loose on lots of efficiency gains and flexibility. I'm of the opinion that having the render system in control results in cleaner code.

    Some advantages of centralized rendering:

    • z-ordering:
      If the game objects themselves are responsible for rendering you'll have to make sure you call them in the correct order. Otherwise background objects may be drawn over foreground objects.
      With the render system in control, it can choose to sort all render objects, detect overloaps at render-time and just render those, or just forego ordering all together. The point is that decision can be made easily now.
    • batching:
      The other obvious advantage of allowing the render system to be in control is batching. Here again the render system has to option to batch sprite renders the share a texture. It can use triangle slicing to render everything with one call. It may be able to cache some render calculations. Or it could just render each sprite in turn with none of that fancy stuff. (Note: it is possible batch when each object renders itself, but the problem is less efficient and more complex).

    The way I implement this in my games it to have game objects register the sprites they want drawn with the render system. When the object no longer wants the object drawn it unregisters the sprite, or marks it inactive.

    All that said. If it's easier to have your game objects render themselves by all means do it that way. It's much more important to make progress and get something / anything drawn than it is to have a perfect architecture.

  • An couple of considerations :

    • as you mentionned, each sprite would have to "hint" about which bitmap to use, but if the entity has to render itself. What would that 'hint' be ? If it is a reference to a different bitmap, sprite sheet, etc... for each sprite, then you might end up using more memory than necessary, or having troubles managing that memory. An advantage of a separate renderer is that you have only one class responsible for any asset management. That said, in a SF2-like fighting game, you might only have two sprites ;)

    • as mentionned elsewhere, whenever you want to change your graphical API, you have to change the code for all your sprites.

    • rendering is rarely done whithout a reference to some graphical context. So either there is a global variable that represent this concept, or each sprite has an interface with render(GraphicalContext ctx). This mixes the graphical API and the logic of your game (which some people will find unelegant), and might cause compilation issues.

    • I personnaly find that separating the rendering from the individual entities is an interesting first step in the direction of viewing your game as a system that does not necessarily need graphics at all. What I mean is that when you put rendering out of the way, you realize lots of the gameplay happens in a "non-graphic world" where the coordinates of the entities, their internal states, etc... is what matters. This opens the door to automated testing, more decoupled system, etc...

    All in all, I tend to prefer systems where rendering is done by a seperate class. That does not mean your sprites can not have some attributes that are "graphically related" (animation name, animation frame, height x width, sprite id etc... ), if that makes the renderer easier to write or more efficient.

    And I don't know if that would apply to 3D (where the notion of meshes, and the coordinates variable you would use would maybe be tied to your 3D API ; whereas x,y,h,w is pretty much independant of any 2D API).

    Hoping this helps.

c++ rendering
Related questions and answers
  • I'm creating a component-based game object system. Some tips: GameObject is simply a list of Components. There are GameSubsystems. For example, rendering, physics etc. Each GameSubsystem contains pointers to some of Components. GameSubsystem is a very powerful and flexible abstraction: it represents any slice (or aspect) of the game world. There is a need in a mechanism of registering... a decision which Components to register (and how to organize them). For example, GameSubsystemRender can register Renderable Components. pro. Components know nothing about how they are used. Low

  • of them updating up to 3-5 times a second). If the players are in a 2D space (it's 3D but the z difference shouldn't affect visibility) what is the best way to manage the visibility of other players... for other players should only be sent to a game client if their player is near the other players (i.e. you shouldn't get health updates for people you can't see on the other side of the map). The main... with the system though, as it isn't that efficient (besides knowing which grid they are in, no other caching) and sometimes visibility limits should extend beyond 2 grids of distance. Is there a better

  • I'm writing a game engine which is going very fine. However, I'm now posed with handling textures. My Engine is in 2D, for simplicity reasons mostly to get a good idea of how to work with OpenGL. I... and apply them to polygons. The way my engine works in drawing things is like this: Load up a tile map file and parse it. The tile map contains all the information like events, lights, passability..._interior_cave1.xml, which contains all the information on what textures are used. It loads the textures as said by the tileset-XML-file, it gives them an ID and then the SceneManager-class knows how to lay out

  • instantiate them. All this, is what I can think of now. I know my editor can still be using game objects even if it is external, but the game am I into is for iphone using cocos2d and the editor...I have a 2D basic editor written in Qt, and I'm in the process of adding entities. I want the editor to be able to receive RTTI information from entities to change properties, create some logic being...) Where should I place the messaging system for my game engine? Lua? C++? I'm tempted to just have C++ object to behave as servers, offering services to lua business logic. Things like physics system

  • I make a game in 2d I'd store all of my objects in instances of different classes, then when my drawing routine comes up- just draw the objects that are on screen. With a 3D environment it would... to send those corresponding objects an "apply" request, and have them apply themselves? Or is there a better way? Question 3: If I have a completely dynamic map, but with objects that won't change very often, are there any guidelines as to the performance differences between GL_STATIC_DRAW and GL_DYNAMIC_DRAW? Final Question: Should I even consider using vertex lists? Or are VBOs just a better

  • better. I would also like compatability, If Theres one that fits DirectX(at least 9) and OpenGL, then that would be good) 2D Graphics(I liked SFML, so it its possible to get something that works with SFML...Lately I have been working on a game that i plan to make online. I have used different libraries to make this game as far as i could, but I feel that I should rethink on how Im sertting this game up... with the Physics correctly... So my main question is: What would be a good combination of libraries to make an online game with? Im sure that many people have good combinations of libraries for making a game

  • This is the first time I'm trying to make a 2D game, so I'm having quite a few difficulties in getting things right. Right now I'm trying to figure out exactly how the entity state machine should...) is therefore highly wasteful. Then again, making each entity state a singleton hardly seems appropriate. What do you suggest I do? (The same can be said about game states, so whatever the solution to this is, I guess it can be applied to game states as well.) 2. The state of the entity sprite. Most of the time, whenever the state of the entity changes, the sprite that is used to represent it must

  • errors on request through comment). But as of now the main problem is when i render my model(it is a plane with simple, unblended pixelated texture), it looks like this on my Laptop(Left Image), but when I render on the desktop(Right Image), it looks the way its supposed to be. Im pretty sure this problem might not be relevant to this site, but im not sure on where else to post this(if it needs to be moved then so be it), but i felt it would fit here just a bit, since its a game-dev type question. Anyways, My compiler is MinGW that uses the IDE Code::Blocks. also the operating system that im

  • Dear all, this is going to be tough: I have created a game object factory that generates objects of my wish. However, I get memory leaks which I can not fix. Memory leaks are generated by return...; nRecordCount; nLoop++ ) { // if the object exists in the container and is valid, then render it if( vFactories[nLoop] != NULL) delete vFactories[nLoop](); } return... vector container. I have chosen this way because I parse an object map file. I have object type IDs (integer values) which I need to translate them into real objects. Because I have over 100