a) There is no easy way of mapping a "path" on to tiles in cocos. You could check your tile id (every tile "type" has an ID) and if it's of a certain type (water, for example), then also create a static chipmunk/box2d body+shape so the player can't go there.
Still, I don't find this to be an elegant solution and would be too cpu/memory intensive with even medium sized maps.
b) either/or as they say, depends on your needs, for basic collision detection they perform similarly, chipmunk has a bit more documentation and the more recent version of box2d lacks documentation, so perhaps that could influence choice.
c) not really, in my game "Mini Taxi" i have an 8192x8192 pixel world (256x256 of 32x32px tiles).
Of course to do that you need to "optimize", but that depends on your needs/game design.
This is what I did in a similar situation (mini taxi, again):
- Draw the visual elements of the city with tiles using "Tiled" (or stitching together sprites, tiles are much more performing though, depends on your needs and visual style)
- Break up the "giant" tilemap into 64 smaller chunks (custom script/tool)
- Create a custom level editor (C++ using QT libraries) to allow me to place all the extra elements (including collision shapes and sprites/3d buildings), define what is a "road" for AI to follow, spawn points for pedestrians, etc. Export all the data into an .xml file
- Parse the XML file in the game to create all the elements that I placed visually in the level editor, create arrays of paths, arrays of spawn points, arrays of everything...
- I divided the "space" into 64 quads, by creating a container class, and each quad has it's chunk of tilemap and an array of all the "elements" (sprites, chipmunk shapes, nodes for the game logic, etc), then during the simulation I check in what quad the player is, and only show that one and the surrounding ones that might be visible.
All other "quads" are disabled, meaning no calculations or drawing occurs.
I found that, due to the size of the map and the number of elements I had (each quad can have 30 static shapes, 50 dynamic shapes, 3d buildings, sprites, etc), it was MANDATORY to divide the world, something that is very often used in physical simulations also (spatial hashing is the term I think).
Further, creating a level editor each time can be a pain the ass and take some time, but in the long run it's the only "reasonable" way of placing lots of elements, as doing it with code by typing in numbers is a ridiculous prospect if you have a big world, or many levels and so on.
So, I would say, even a simple thing like this can require lots of work :)
I hope this helps somewhat, if you do decide to go down the route I described I could help you out by providing scraps of a level editor in QT (c++).
Good luck!
Patrick
