In looking over my old articles and attempting to determine just how to revamp them (they are in pretty sorry shape, sadly), I also wound up thinking about my first book (which covered the same topics and then some), and I came up with a rather distilled version of my first book: Seven Essential Elements of a Tile Based Engine.
Keep in mind that when I’m talking “engine” here, I’m strictly speaking of a RENDERING engine. As such, as with any project, there is a “zeroth” element, which is to Make a Solid Plan.
The first essential element is a board, which represents the game world. In tile based games, there is almost invariably some sort of grid, be it square, isometric, hexagonal or whatever. Within the grid are the objects that comprise the world. Depending on need, the grid locations might be as simple as a bit or number, but may be rather complex lists of stacks of object existing within the grid, not to mention other aspects that describe the grid itself.
The second essential element is image management. It is absolutely essential to be able to refer to every image (sprite, tile or whatever, the difference is mainly semantic) by a simple id number, and I should be able to render that image onto any graphical context I wish, using only a single x and y value. I should not have to do any sort of voodoo to get my warrior sprite to render on my isometric grass tile. i use the same x and y value, and they are correctly rendered with the feet of the warrior in the middle of the isometric tile, because the image manager loads this information from the image itself, as in the extended sprite templates.
The third essential element is a plotter. Once you’ve got a board that abstractly represents the world and images that show what those abstract elements might look like, you need to be able to convert from a grid coordinate to a rendered coordinate. For this element, we completely forget about the screen, and pretend that we can render the entire gameworld in an abstract worldspace. The main issue solved here is that you may have a 8×8 grid of tiles that represents a game of reversi. When I render grid location (0,0), what sort of spacial relationship will it have with grid location(1,0) or (0,1) in order for the graphics in each to render correctly?
The fourth essential element is a scroller, which has very little to do with graphics, and everything to do with math. A scroller takes the output of a plotter, which is a coordinate in an abstract and boundless worldspace, and converts it to a sceen coordinate. In a game where the grid does not extend beyond the bounds of the screen, the scoller is of less importance, but the use of separate world and screen spaces still has value.
The fifth essential element is a mapper, which takes a screen coordinate and determines the grid location corresponding with it, typically for pointing device input.
The sixth essential element is a walker, which allows movement from one grid location to another grid location based on starting location and a direction of movement. Typically less important in square coordinate systems (as they are elementary), but in isometric and hexagonal grid systems, these can be quite useful.
The seventh essential element uses all of the other six, and is called a renderer. It may redraw the entire screen each frame, or it may use dirty rectangles. The important thing is that each update, it knows what grid locations need to be redrawn.
The above, if you were to sprinkle in a bunch of code dumps, would be my first book.