Another design-related C++ question

Hi!

I am trying to find some optimal solutions in C++ coding patterns, and this is one of my game engine - related questions.

Take a look at the game object declaration (I removed almost everything, that has no connection with the question).

// Abstract representation of a game object
class Object : 
public Entity, 
       IRenderable, ISerializable {

   // Object parameters
   // Other not really important stuff

public:
   // @note Rendering template will never change while
   // the object 'lives'
   Object(RenderTemplate& render_template, /* params */) : /*...*/ { }

private:
   // Object rendering template
   RenderTemplate render_template;

public:
   /**
    * Default object render method
    * Draws rendering template data at (X, Y) with (Width, Height) dimensions
    *
    * @note If no appropriate rendering method overload开发者_运维百科 is specified 
    * for any derived class, this method is called
    *
    * @param  Backend & b  
    * @return void
    * @see         
    */
   virtual void Render(Backend& backend) const {
      // Render sprite from object's
      // rendering template structure
      backend.RenderFromTemplate(
         render_template, 
         x, y, width, height
         );
   }
};

Here is also the IRenderable interface declaration:

// Objects that can be rendered
interface IRenderable {
   /**
    * Abstract method to render current object
    *
    * @param  Backend & b  
    * @return void
    * @see
    */
   virtual void Render(Backend& b) const = 0;
}

and a sample of a real object that is derived from Object (with severe simplifications :)

// Ball object
class Ball : public Object {
   // Ball params
public:
   virtual void Render(Backend& b) const {
      b.RenderEllipse(/*params*/);
   }
};

What I wanted to get is the ability to have some sort of standard function, that would draw sprite for an object (this is Object::Render) if there is no appropriate overload.

So, one can have objects without Render(...) method, and if you try to render them, this default sprite-rendering stuff is invoked. And, one can have specialized objects, that define their own way of being rendered.

I think, this way of doing things is quite good, but what I can't figure out - is there any way to split the objects' "normal" methods (like Resize(...) or Rotate(...)) implementation from their rendering implementation?

Because if everything is done the way described earlier, a common .cpp file, that implements any type of object would generally mix the Resize(...), etc methods implementation and this virtual Render(...) method and this seems to be a mess. I actually want to have rendering procedures for the objects in one place and their "logic implementation" - in another.

Is there a way this can be done (maybe alternative pattern or trick or hint) or this is where all this polymorphic and virtual stuff sucks in terms of code placement?

---

In this particular example, I'm not sure that it's desirable to separate Resize from Render, since Resize has a direct impact on the rendered image.

The way I do it is make the Entitys contain the Renderable. E.g. an Entity would have a member variable that is the sprite to be rendered. When the entity becomes visible, it hands the sprite to the rendering system and says, basically, "ok draw this each frame until I tell you to stop," although the rendering engine does culling of off-screen objects and other madness. Perhaps obviously, the rendering engine then maintains a list of renderable things (or maybe several lists if you want to split sprites from lines or particles for rendering efficiency), and then it just churns through that much less complicated list of items when it's time to do the draw.

That way, the entity can control the renderable, it can scale it or rotate it (i.e. manipulate its rendering matrix), but it doesn't need to decide when it's appropriate to draw it beyond whether or not it is "alive". The rendering engine, though, only knows how to draw the item in question and doesn't need knowledge of your entity graph.

---

Pull IRenderable away from Entity and only inherit from that interface when you want to.

Then use visitor:

struct rendering_visitor : visitor<Entity>, visitor<IRenderable>
{
  void visit(Entity & e) { ... do default stuff ... }
  void visit(IRenderable & renderable) { renderable.Render(); }
};

See "Modern C++ Design" for a good visitor implementation. Your Renderable will need to be visitable, as also your Entities. You've got some higherarchy going on, which the recommended book doesn't talk about but isn't too difficult to figure out.

There are other ways to implement visitors as well. Take your pick.