everything should translate flawlessly assuming class was registered earlier. note that you can register templated classes (sorry i don't know the correct term). for example:

Code:

registerClassAlias("flash.utils.Dictionary", Dictionary);
registerClassAlias("flash.utils.ByteArray", ByteArray);
registerClassAlias("flash.geom.Vector3D", Vector3D);
registerClassAlias("flash.geom.Point", Point);
registerClassAlias("Vector.<Vector3D>", Vector.<Vector3D> as Class);

i have written a serializer for flashpunk. http://flashpunk.net/forums/index.php?topic=3412.0

there is of course problem with serializing structures with multiple references...

start with "requirements first, coding later". ask yourself why you really want to use quadtree? how many entities are there, are they static or moving? what kind of operations will you be using on quadtree (like search the area, get closest neighbour, test for collision with static, moving).

quadtree is really nice stuff but implementations may differ significantly depending on particular case.

blocking the way could be solved in to ways:
1. (cheating) if the next grid is occupied and creature there wants to step on my current grid we should swap. easy.
2. if the next grid is occupied and the creature there is idle i should step sideways. say i want to go north, then i step east. but always the same direction left or right.

(alternatively you can try to mix those two cases. and if the creature on next grid is idle you force her to swap based on some kind of priority like strength, speed, level etc.)

this is quite popular method for path-finding and npc will just try to circle around the obstacle. once the path to destination is free it continues normally. this is not the smartest code but very fast (if you will take advantage of this matrix with precalculated paths).

as of matrix size you can store only grids that are free, excluding impassable ones. that would greatly reduce its size. however you will have to use some lookup tables...

anyway this is quite intriguing, i would love to see some demo

there are couple of questions and answers that should narrow the problem: how big is your map, how many npcs are there, is there a maximum distance to destination that npc will seek.

a* in changing environment can be implemented by adjusting heuristic function result with much higher cost for nodes that are inaccessible. either those destroyed or occupied.

but if you have a lot of ram to spare i would recommend to make a huge matrix that stores a precalculated optimal path info. it is quite huge (n x n, where n is number of nodes) but luckily symmetrical. matrix[a,b] stores next grid id if you are travelling from a to b. of course each time you change the level it should be recalculated. however not necessaraly whole but only parts that changed. but precalculated approach forgets about all dynamic obstacles.

@claw:
accessing archive is pretty straightforward. if it is small enough just load all your exe into memory buffer, read the offset from the last 4 bytes and buffer+offset will give you memory pointer to the beginning of an archive. then you should just pass this pointer to some function from archive library that supports opening archive from memory. i wont recommend you any libraries since last time i coded in c++ was sth like 10 years ago.

alternatively (however i don't really like this way) you can create temporary file with archive and just open it (any archive library supports opening archive by file name).

note that archive option is pretty good for debugging as in my opinion data should be kept outside of code. so you can store all assets in archive on disk and access it directly from folder instead of reading exe and so on. when ready for release compile you just change line that opens archive from file into code that gets it from exe.

reading exe as zip without offset as SuperDisk says may work but not necessarily. it all depends on library you will use. some will seek for archive header and some will just check first couple of bytes (and will get MZ instead of PK for zip).

one more thing. you may also use mixed approach. zip assets into archive and add it into exe as resource or buffer in .h file.

i would pack all the necessary media files into some archive, say 7z. without compression of course since pngs are already compressed. this needs some extra libs included but afaik simplest unzip source shouldn't get your exe any larger (hope you are not writing an 64k compo). than i would just attach the archive to the compiled exe's end (copy /b run.exe + data.zip final.exe on windows). final thing is to know where the data.zip starts. easiest is to get filelength of run.exe and attach it as binary long int to the end of file.exe.

some simple batches should do the trick and you will get the possibility to work with a file/directory structure instead some memory pointers to textures. this way making change will be much easier.