   Animation and world state
  I have a turn-based strategy game in the works, featuring a proverbial tiled world map and proverbial military units.Currently I have a World object that owns the map and units. Each unit is obviously associated with a tile by the world; units don't know their own tile. Each tile may of course also be mapped to an (x, y) screen coordinate, though the tiles themselves don't necessarily correspond to actual coordinates. Drawing everything is a simple matter of running through all the tiles and units and getting their associated sprite. Nothing fancy.My issue is figuring out how to handle animations without adding too much animation-specific knowledge to the World class. For example, unit movement is logically just changing a unit's tile. I want to animate unit movement though, where a unit's sprite slides to the coordinate corresponding to the destination tile. This is keeping in mind that the game is turn-based and units exist on logical tiles instead of actual coordinates. It's not like the unit's y-coordinate goes up as long as I press the up arrow.In this case I may update the unit's tile after the movement animation is finished, but I still need to figure out how to draw this animation in relation to drawing the rest of the map. I need to be sure I don't draw the moving unit's regular sprite, which has logically not moved yet, when drawing all the units. I also need to make sure I draw all sprites in the right order so that the animated sprite properly fits among the rest of the sprites.I suppose I could put some animation state into the World class itself. Units may have a "is moving" flag and a float ranging from zero to one to represent how far they are to their new tile. I'm worried about letting the World class handle too much of its animation though, since managing the world is going to be hard enough as it is and I have more animations in mind.   
  I'd say that units should know where in realspace they are, and you'll need some consistent way to translate from gridspace to realspace. In addition, each unit should know where they're supposed to be (again, in realspace). When you want a unit to move from tile A to tile B, you tell them "Hey, your new intended position is where tile B is", and also "move" them (in the gridspace that they don't actually care about) to tile B immediately. Then over the course of the next few frames/seconds/whatever, the unit will say "Hey, I'm not where I'm supposed to be, I should move", and can handle its own animating.   ;  I handle animation by stuffing that information in a Sprite object contained by a unit. This is then updated with an update() function which handles all of the logic involved in changing frames.As far as the units are concerned, there are two ways to handle it. Either the units know where they are and so draw themselves or your world knows where they are and provides that information to the animation logic.In your approach I'd provide a screen-space coordinate to the 'sprite' object (or whatever handles drawing). Or, if you don't want the unit to draw itself you can have it store images and when the world asks for it provide it with a reference to the image to draw.   ;  The sprites will need a position offset from the tile they're associated with.When the sprite starts to move, the offset will translate them away from the center of the tile. Half way to the new tile they will be associated to the new tile and the offset negated. The offset will then proceed to zero to bring them to the center of the new tile.The world object should not be resposible for this. IT is the responsibility of each tile object.struct Obj{  float offset[2];  int tileTexture;};Obj map[rows x colums];void drawMap( ){  for( int i = 0; i < rowsxcolums; ++i )    drawTile( maps.tileTexture, mapPos( i ) + maps.offset );};  Well, every type of unit is already associated with an image (was calling this a sprite, but more on that later).  When drawing a unit, I get the unit's type and get the image associated with that type.My goal is to make sure the world and units know as little as possible about how they're getting drawn and animated.  So, I don't quite like Derakon's and bzroom's suggestions where units know both their tiles and their screen coordinates.leeor_net's suggestion got me thinking about giving each unit a Sprite object that, more than just drawing an image like it does now, also keeps track of animation state for certain unit tasks.  So, I'd have movement sprites, attack sprites, death sprites, and so on.  These sprite objects keep track of the animation state so that the world and unit's don't have to.Normally a unit would have an "idle" sprite for rendering the unit's idle image.  When initiating a unit move, the world sets the unit's sprite to a "movement" sprite instead of just moving the unit first, giving the sprite the tile to move towards. The movement sprite would render the unit's walking animation and have an offset which shifts the image towards the destination tile.  The world would be able to detect when a sprite has reached the end of its animation.  When the movement sprite has finished, the world would finally do the actual location update of the traveling unit and set its sprite back to an idle sprite.This scheme could also work for other world state changes that need to be timed for animation.  For example, a unit attacking another unit to the world looks like world.unitAttack(attackerIndex, targetIndex), where the target unit is immediately taken off the map if it dies.  When using these sprite objects, initiating an attack may involve setting the attacker's sprite to an attack sprite.  At the specific frame where damage should be done to the target, unitAttack would be called.  If the target died, its sprite would be set to a death animation, otherwise it's sprite would be set to a recoil animation.  At the end of the defender's sprite animation the defender's sprite would be set back to an idle sprite, or the defender would be removed from the map if it's dead.How does this sound? Too many holes? Not enough holes?   