[quote name='phil_t' timestamp='1326137764' post='4901035']
I don't think you'd want each tile to be a "TileObject" - there would be performance and memory usage implications. You could achieve the same effect with the flyweight pattern though.
Hm kind of a hijack, but its still on topic:
Would the performance realy be so bad if the grid was like 20x20?
[/quote]
That's probably fine.
Perhaps I'm mistaken, but the flyweight pattern is like sharing one object for multiple purposes, containing some variables inside to store the differences. In this case each tile has it's own image, pointers to objects stored on it (players/enemies/animals/items whatever) and whether the tile can be accessed. This cannot easily be done using a flyweight pattern doesn't it?
I was thinking more like a tile just a tiny descriptor (byte or int or something) that lets you reference additional information. For instance, if a tile is a grass tile, then you can look up static information what the image should be for a grass tile, whether an entity can move onto it, etc...
I guess it's not technically a flyweight pattern unless you make an object that, when given a tile descriptor, would expose information about a tile in a nice easy-to-consume manner. Regardless, the point is that the tile can contain just the minimal amount of information necessary that describes it.
For a 20 x 20 grid though, probably none of this really matters. Just do whatever is easiest/simplest.
Although for dynamic tile information, such as which entities items are on it at the current time, I would tend to favor keeping these in a separate list of entities where each entity stores the coordinates at which it is located. It reduces the micro-management you would need to do of tracking adding an entity to a tile while removing it from another. Of course it makes it more difficult/slower to answer the question "what entity is in this tile?", but given that there is generally a small number of entities compared to tiles, it's not a big deal to loop through them.