views:

124

answers:

2

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?

+2  A: 
Noah Roberts
How does this work when the design specifies that the object inherits both from Entity and IRenderable? In C++ that would be an ambiguous call I think? (But C++ doesn't have an 'interface' keyword, does it?)
dash-tom-bang
It's somewhat common to redefine struct as interface in C++ to preserve some code logics... Though I'm not sure about what should be done in this multiple inheritance case.
Kotti
@dash-tom-bang - Yeah, that can be an issue. If both base classes have implementations of the same function (and with some visitor patterns you will) then you can have problems. As long as the function you're overriding comes from the same grandparent though it seems to be ok. I'm doing it on one platform at any rate. The only time I've run into trouble is when both bases declare new virtuals of the same name. When that happens you'll be stuck coming up with something different and/or redesigning the tree/web.
Noah Roberts
My point was specifically with the visitor though. Calling `myVisitor.visit(myObject)` is ambiguous, since Object derives from both of the visited classes. You'd have to do `myVisitor.visit(static_cast<Entity>(myObject))` instead, thereby losing the power of the visitor in this case.
dash-tom-bang
+2  A: 

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.

dash-tom-bang
I probably should mention- making the renderable a component of the entity rather than a base class makes it possible to share the renderable representation between instances of any given entity type. You only need to load one set of zombie graphics even if you have dozens of zombies in your level.
dash-tom-bang
This approach seems good, I'll try to reorganize my code and see what happens and what other problems will I face. Thanks a lot.
Kotti