So gennerally for 2d tile maps a tile is either passable or impassible... so an actor can move to any passable adjacent tile.

I am looking for a good way to decouple the passablity of a cell from the traversal to/from the cell.

Which do you suppose is the best way?

1) Each tile contains a value indicating if the passage to the right and bottom tiles are valid.

Pro: Requires very little modification to a standard 2d array implementation

Con: Checking for passage works on different cells depending on direction of travel... i.e to travel right or down you check your current tile, but travel up or left requires checking the destination tile.

2) Each tile contains a value indicating the passage to adjacent tiles

Pro: Can still be implemented using a standard 2d array implementation

Con: Disabling travel between two tiles requires setting a value on both the tiles (semi-redundant data... semi b/c you could implement 1 way passages, etc).

3) Use a separate array for tile data and traversal data... in the tile array the data describes the tile, in the separate array the data represents the "wall" between two cells.

Pro: No data redundancy, consistent mapping

Con: Requires entirely new map structure with more complex mapping, look up functions...

4) Awesome method that I haven't thought of... pro: It may be awesome, con: I didn't think of it yet...

This smells like some premature optimization: http://c2.com/cgi/wiki?PrematureOptimization

Any one of these will work. Pick the one that requires the least amount of effort on your part and the one that seems like it will be the easiest to understand in six months if you really do need to optimize this. Don't worry about the "right" way, because you may not know what that is.

Is the right way:

1. The algorithm that runs the fastest for all the AI you're doing because the iPad version is now too slow?

2. The algorithm that is the easiest because this code isn't called that often but seems the source of all kinds of bugs?

3. The algorithm that uses the least amount of data so that the levels (which have gotten too big) can be brought down in size?

I would go with solution 5) Do the most simple, inefficient thing you can and move on until there is a need to fix the code. You'll be glad you kept it simple.

Another point to add to what Glass_Knife is saying, is that you may discover the need for things you haven't thought of yet, and if that does not fit with the structure you decided today, you may have to change things further down the road anyway.

If you still want another idea, I just thought of something else just now. If you instead of putting the data itself in a map array, you could put pointers to some class or struct or whatever you prefer, and you will have something that is easy to extend in the future. (That is not light-weight though.)

There is no given answer, however...