I tried to model a render system for an html5 game and learned the following:
We use render code separated from other game code with the intention of change graphic api at any time without having to touch anything except the renderer implementation. But, for html5, do we need this? Canvas is already all the multi platform it can be. The browsers are already responsible of implement the platform specific part.
A render system, if used, must be very generic. I don't think a method called renderATree() should be in the renderer. The sprite representing a tree must contain the data that you need to pass to a render generic function to produce a result that looks like a tree.
sprite.img = "media/img/trees.png"; // many types of trees in a single png file
sprite.left = 0; // we configure the sprite to represent one of those trees
sprite.top = 0;
sprite.width = 32;
sprite.height = 32;
sprite.offsetx = -16; // the sprite will be renderer centered in the x axis
sprite.offsety = -32;
renderer.renderSprite(sprite, posx, posy, rotation, scale);
If this where C++ renderSprite would probably contain api specific calls (DirectX, OpenGL), but being a html5 game, it probably contains only canvas calls. Having a render system then is only a choice of code organization.
If you still need a method like renderTree or renderMonster then I would make them part of the sprite or entity.
function Sprite ()
// The sprite interface (some vars and some functions)
function newSoldier ()
var spr = new Sprite();
var spr.render = renderSoldier; // written somewhere, contains the canvas calls to render a soldier.
And It was used like this:
When using the "Each sprite know how to render itself" approach a render system became unnecessary. Then I ended with a main loop that used functionality of the scene "class" to efficiently cull the scene and then loop through a sprite array representing the visible part of the scene calling each sprite render function. As sprites are allowed to contain render code, anything can be an sprite including a health bar that needs no image data and is renderer only with lines of different colors (easy done with canvas calls).
Also note that with the second approach sprites and entities are the same thing. I called them sprites because it was 2D game. In the first approach sprite was a "structure" that contains data for the renderer renderSprite function and a separate entity "class" that refers to a sprite was needed.
In resume, my position is:
If implementing a render system include only generic functionality on it (probably unnecessary on most htm5 games)
If you choose "Each sprite know how to render itself" having canvas calls inside the render functions does not harm in this case.