   Designing a Flexible Tile Class
  I am trying to create a flexible tile format to be used in my map editor and future games.  I am trying to keep the tiles smaller so they can be copied easily but also easy to use while coding.  I want to avoid dynamic_cast's and if "this type" do this else ... you know what I mean.  This is the best that I have came up so far but the Animate function does not seem right to me.// The tile info classclass TileInfo {public:typedef std::map<std::string,TileAnimation> AnimationContainer;AnimationContainer animations;// The animations in the tileint tileSet;   // The tileSetbool walkable;// Is the tile walkable?};// The tile classclass Tile {public:typedef boost::shared_ptr<TileInfo> TileInfoPtr;virtual ~Tile() { }virtual void Animate() { }// Animated the tileTileInfoPtr info;// The tile information};// An animated Tileclass AnimatedTile : public Tile {private:std::string currentAnimation;// The current animationint currentFrame;   // The current frameint animationSpeed;// The speed of the animationpublic:AnimatedTile() : currentAnimation(""), currentFrame(0), animationSpeed(1) { }};This TileInfo and tilesets would be stored within a MapHandler that also handles the actual map.  The TileAnimation just consists of Frames that refer to a position in a tileset.  I was originally thinking about putting the Tile and AnimatedTile classes as one but it doesn't make sense to store the current animation, frame and animation speed if the tile is not animated.  This made me split the two classes.  But then to update the animations I would have to have some sort of Animate function, but this brings a problem, do I dynamic_cast to check if it's an animated tile or do I put a dummy Animate function in the Tile class.  I don't like either because they don't seem right and there must be a better way but I prefer the dummy Animate function in the Tile class over using dynamic_casts.  Does anyone know a cleaner way to do this or any other suggestions that would give me a flexible design? Any opinions would be appreciated.Thanks,vbuser   
  You could have a generic/virtual Render() function in the base class that in the animated tile class calls the Animate() function internally. Since the Render() interface is virtual, it would call the correct one without you having to worry about it.I am not really qualified to explain why/how this works but I am sure you can find an answer Here.I am also sure someone else here has some better links to articles/tutorials on polymorphism but those should at least get you started.;  Thanks for the idea, but I think I will make it an Update function which updates animations, triggers, etc instead because I am trying to keep the rendering away from the tile data.  I certainly like this option better that the other two I had[smile].Thanks,vbuser   ;  I'd start with a set of class defitions and patterns.TileInstance: data that describes the tile-state of a cell.TileClass: data that describes a type of Tile.Now, how are you going to use these tiles?I'd propose using this pattern:Visitor: your renderer will visit each visible tile, extract the data it needs to render, and render the data.  This keeps the rendering code out of the tile code.Now, you have to figure out what data the renderer needs from a tile in order to animate it.  Ideally the information will be the same for both animated and non-animated tiles.Static tiles are different than animated tiles because they don't change.  Interestingly, a static tile is almost impossible to distinguish from an animated tile that changes very very very slowly.How about we use that fact?...Proposal:All tiles produce "frames" of image data.All tiles have an "update velocity".Tiles sometimes don't have to be updated.typedef int TileTimestamp;class TileClass{  public:    virtual TileFrame* GetFrame(TileTimestamp index) = 0;    virtual TileTimestamp TimestampAdvance(TileTimestamp old, int repeat = 1) = 0;    virtual bool FrameChanged( TileTimestamp old, TileTimestamp new ) = 0;    virtual ~TileClass{};};The "TileFrame" contains the data required to render the tile at a specific index.Then we have:class StaticTileClass: public virtual TileClass{  public:    virtual TileFrame* GetFrame(TileTimestamp index) { return GetStaticFrame(); }    virtual TileFrame* GetStaticFrame() = 0;    virtual bool FrameChanged( TileTimestamp, TileTimestamp ) { return false; };    virtual TileTimestamp TimestampAdvance( TileTimestamp ) { return TileTimestamp(); }};Static tiles thus produce a single image.  Animated tiles can produce a sequence of images.The last TileTimestamp your Tiles are rendered at is stored in each of TileInstances.  The Render thread asks each Tile if it needs updating since the last update, and if so it updates it.  Static tiles simply say "I never need updating".If the above proves too expensive (because you have to iterate over every tile), you could ask a tile for when the next time it needs to be queried.Note that I think the proper place to store the current frame number of an animation is in the instance of the tile, not in the overall description of the tile.  This allows multiple tiles on the screen to be out-of-sync with each other but still be the same class of tile.Make sense?;  Thanks and yes that makes sense.  I was thinking about doing something like this before, but I couldn't seem to create a good clean interface to do it with.  Your way seems nice and clean.  I can hopefully get time to work on it tommorrow night and see if I can get some of it up and running. One other thing, you have public virtual inheritance for the StaticTileClass.  I thought you only needed virtual inheritance with multiple inheritance when you are inheriting from the same class more than once.  Is there a reason for the virtual inheritance?Thanks again for the help.   ;  To avoid possible issues, I have defaults when doing C++ coding.If a class is more than just a pseudo-POD collection of raw data, then:My destructors are all virtual.My abstract-class destructors are implemented inline.My inheritance is all virtual.I create private copy constructors and operator==s and leave them unimplemented.etc.My polymorphic classes have a pure virtual interface that is implemented seperately.When I do need an operator==, I write it using the copy/swap idiom.New classes and helper functions created in a .cpp file are created in an anonymous namespace.Classes in header files are created in a namespace."Helper" classes in header files are either class-local or created in a sub-name-space.I do the above by default.  In the situations where there is a reason for not doing the above, I consider the alternatives and do it.  But I have decided that the above are "best default practices".The reason behind most of those default decisions is that the alternative can often generate subtle bugs and strange behaviour.[1]So, the reason I'm using public virtual inheritance is that there isn't a particular reason not to use public virtual inheritance.--[1]  As an example, given two classes in different .cpp files with the same name, linked together, each with a default constructor defined in the body of the class, they two constructors share linkage, and one of the two constructors is silently discarded.  The result is objects that get garbage constructors.  The same thing happens if they have methods with the same signature (same type-names for all of the parameters).  The same thing happens with "inline" functions.;  I finnally have some tiles on screen now.  Thanks for helping me with my tile class and now I can get my animated tiles up and going[smile].  Also thanks for the good explaination about why you used virtual inheritance as well as other good practices while coding. Cya,vbuser   