Still, tiles are usually in pixels and you can't draw a fraction of a pixel, so a tile of 53.3 wouldn't work, unless you are not thinking in pixels
. This would mean you are abstracting the tile size from its real size, and in this case you can choose any size you want, even negatives, but it would make your code unnecessarily complex
I'd say stick to whole numbers and, as Servant Of The Lord said, bigger is sometimes better. They can be more detailed and you'll have less tiles to draw per frame.
Still, you can always use small sizes and add detail in 2x2, 1x3 compound tile blocks that are supposed to always be used together.
Just try to KISS
One other issue to consider is how you are doing collision detection between your player and the walls of your maze. If you are going to use non-passable tiles for walls, then having larger tile sizes will mean that you can't have narrow walls between passages.
Or you'd need to separate the collision from the tiled map itself.
But I always liked to tie both up, makes things easier. Separating is usually overengineering, unless there are special needs that makes this approach a necessity.
If you need to decouple the collision data from the tiled grid, you should search vectorial collision
data, or bitmasks if your map changes collision configuration (think of Worms); I personally don't like bitmasks for this type of collision.
Edited by dejaime, 03 February 2014 - 07:20 PM.
Usually, tiles were sized 2^(k) due to some rendering optimizations. Today, rendering tiles with arbitrary sizes got way faster, so no need to keep them as a potency of two anymore.