What pattern is used to render tiles?

Question

I want to render a tile-based map and I am not sure which class structure to use to keep logic and rendering separeted.

My class structure so far on the logic side: One abstract parent class Tile with an attribute int tileType and one class extending Tile for every kind of tile. Every of the extending class defines the value, for example in the class Tree extends Tile I have tileType = 2 and in the class Wall extends Tile I have tileType = 3.

When I render a map, I go through the array of tiles and do something like this:

switch (tileType) {
...
case 2: texture = treeTexture; break;
case 3: texture = wallTexture; break;
...
}
draw(texture, x, y);

I wonder if the class structure makes sense and if this is a good solution to render tiles? Or what other solutions are there to render tiled maps while keeping logic and rendering separated?

Answer 1

The way i am doing this kind of job is :

class Tile 
{
public:
    enum Type
    {
        Water,//0
        Grass,//1
        Snow,//2
        Sand//3
    };
    enum Type2// secondary type
    {
        Mountain,
        Forrest,
        None
    };
public:
    Tile(std::shared_ptr<Surface> surf, int x, int y, int width , int height,Type type);
    void Draw(int x , int y ,Graphics& gfx);
    void InitLayout2(std::shared_ptr<Surface> surf, Type2 type);
private:
    std::shared_ptr<Surface> m_terrain;
    std::shared_ptr<Surface> m_terrain2;
    Type m_type;
    Type2 m_type2;
    RectI m_rect;
    bool m_Passable;
};

then map owns all tiles std::vector m_tiles; and the way i am setting this vector is i am using map.png file , then read each of a pixel call function : Tile::Type CheckTyle(Color c); witch return me what type of tile it is then switch return value and assign tile with a pointer to surface

Answer 2

The best way I can think to eliminate the coupling between tiles and the rendering system is to pass whatever structure holds the map data to the rendering system.

The simple answer is, somewhere, something has to be coupled. I agree having your tiles or your map draw themselves directly is a maintainability nightmare in the long run. Even giving the rendering system an overload function, draw() which can take a world or map object and digest it to make each draw call based on type, direction, etc.

The real answer is you also need to decouple the rendering system from the map and tiles which it needs to draw. To do so is simple, but important as it pushes the non-graphic jobs out of your logical tile object and will also push the logical map parsing code out of your rendering system... You need a world object, and a matching system which is intimate with tiles and worlds. This being tiles only real dependency can split data up into blocks that other systems can parse. So, get image from tile type becomes a world job, then you pass that returned image object to the renderer.. This gives everything a nice engine layer to rest on, while keeping everything simple.