*******************************************
二进制Socket是最好的选择，如果服务器端语言选择java，那么配合开源的AMF3，底层通讯是很简便的，完全省去了烦琐了打包解包过程。RTMP协议建议不要用来处
理纯数据应用，除非是中小型应用。只有在做流媒体应用时RTMP才是唯一的选择。
不过服务器最重要的并不是通信层，而是数据库的设计，持久层的设计，以及服务器本身程序的结构设计，这些东西实际也没什么好讨论的，得靠经验和积累。楼主对
这方面有兴趣，不如自己多尝试，多遇到问题然后解决问题，自然就会有提升。就算现在有几个高手来帖子里发表几句感慨，实际上对你也不会有太大帮助。这里我可
以给你一个正在使用的技术组合，希望能帮助你少走一些弯路。
JAVA+MINA+AMF3，具体的内容网上能搜索到很多。
*******************************************
社区是这样的:
关键部分。
1、服务器，最好socket,一般java,功力深的或者C++，不过Java已足矣
通讯这块其实看你喜欢用哪个了，像我们就是纯文本，但在flash端做了解码，直接解析成数组之类的对象,以方便开发
2、程序结构。这个挺重要的。因为代码比较庞大，必须要有一个清晰、稳定的结构。个人推荐模块化开发。(专门的框架+模块组合）配合svn,因为这个是个团队开发
，因此配合、接口挺重要。
3、2.5D的地图引擎。这个最难。不过如果你借鉴以前C++的经验。必须额外注意性能。因为c++，flash是flash，虽然理论是相通的，但平台跑起来就会不一样了。
（就像我们社区做实时滚屏，也许c很简单，但在flash里，我们确实花了很大精力才让人感觉可以）
至于引擎你可以使用45度格子的，或者进步一点，使用1piexl精确的。寻路推荐A*加以改进。
用户房间那块也稍微麻烦点，看你用给什么房间编辑器。注意下扩展性。
换装：其实这个很简单的，真的很简单
4、还是性能。另外额外注意垃圾回收。应该有好的代码习惯。
社区主要的就这些的，会者其实不难，具体点，就够写很长的文章了。。
其实一但主程拆分模块。模块其实挺简单的。就像你们平常开发应用那样简单。
社区这技术其实并不前沿，也不难，因为flash已经具备了所有社区开发需要的条件。就像Xcity,已经是好多年前的作品了，呵呵。
*******************************************
因为flash自己的渲染有做脏矩形计算，就像上面所说，没有更改过或者不需要重新渲染是不会重新计算的。而你自己每次更改BitmapData反而会让flashplayer刷
新BD整个大小（虽然你用Copy）。有时候传统的反而会快些。其实使用直接更改xy还会比scrollRect稍微快那么一点点。scrollRect只会在某些特殊情况下比xy要
快。
*******************************************
地图编辑器在这里。其实有时候性能并不一定是纯BitmapData引擎最高。就像我给你的截图，按理来说Flex+air应该会更慢。渲染优化是多方面的，当然实际的情况
会比理论上更差个10-20左右。不过具体的flash内部渲染机制大家也无从知晓。adobe也并没用这方面的文档，自己BitmapData可控性高些，代价是损失鼠标事件。
自己要做BitmapData渲染引擎脏矩形裁剪屏幕外的是必须的。flash自己也会把屏幕外的渲染裁剪掉。
总的来说，矢量位图混合会比纯位图慢，alpha会比非alpha慢，两个渲染矩形叠加会比不叠加慢。Display背景透明会比不透明慢，高品质会比低品质慢，开位图平
滑会比不开慢。
不过有你这测试总是好事。adobe没有给出什么具体优化说明，也没有渲染优化的详细文档。大家也就只能测试了。
建议你去仔细研究下图形学和屏幕图像渲染(AS要做向高端要求基本都已经和代码无关了，能写出经典算法/结构/模式的都是些神中之神，老东西还是很有用的，站在
巨人的肩膀上比较好做事。)。重建flash Display渲染再带鼠标事件其实挺吃力的。
*******************************************
拿人物与大型建筑物为例
第一，你要检测是否要进行人物与建筑物的排序（跟哪个建筑物无关）；
第二，如果判断后要进行排序，进行人物与建筑物的碰撞检测，碰到了则排序，否则不排序；
对于第一步说明，由于你不可能实时监测人物与该地图所有建筑物的碰撞情况，所以你要对该建筑物划定一个区域，到达该区域后启动检测开关；
对于第二步，开启碰撞检测开关后，当发生碰撞后要进行人物与建筑物的排序，假设该建筑物有阴影，当人物与该阴影碰撞后则把人物排在建筑物后面，否则人物始终
在建筑物前面。
对于这个阴影的设置你可以在地图编辑器里面设定，其实第一步的检测区域可以跟该阴影划到一个步骤里（前提是你用阴影的方法而不是其他的景深排序法）
*******************************************
BitmapData使用构造函数只支持2880（加载后32M），如果加载外部图片，可以更大一些，大致是原来尺寸的两倍，忘了是内存64M还是128M了。
图片加载，如果考虑加载速度，当然是文件字节尺寸重要
如果是显示绘制速度，就是长宽尺寸了
Flash支持的位图
你要加载的位图太大了,图片占用内存大小是 宽*高*3 ,虽然loader可以显示超过2880的图片,但效率肯定是不行了.出路切图或fp10,哈哈
*******************************************
这个问题要从人眼感觉抖动的原因来分析
第一种情况是常说的屏幕撕裂，就是垂直同步的事情，可以简单理解为显存的数据更新跟屏幕的绘制刷新缺少同步，一次屏幕刷新的结果可能是多次显存更新的片段集
合，这种情况只能使用更接近垂直同步的机制来绘制。Flash游戏一般有两种方式，一种是利用Flash的DisplayList，一种是自己完全用Bitmap/BitmapData来绘
制，前一种是Flash内置的，支持脏矩形合并，在画面变动不大的情况下，效率很高，第二种方式在Flash 9的年代，对于画面变动大的情况，效率较高，在Flash 10
的年代，已经没有明显优势，反而CPU占用更高。天书CPU占用不高，是采用了前一种方式。总之，减少地图面积，使用高效的绘制方案是解决这个问题的有效方法。
第二种情况是因为人眼对于不平滑的变化会感觉不适。这个也有若干方法来改进，比如天书采用的镜头跟随，镜头的变化是独立于人物移动的，镜头的变化速度是平滑
的，不会出现瞬间从0变到4，而是0->1->2->3->4逐渐变化的，而且x和y两个方向要分别保持平滑；此外背景图片的对比度也不要太高，太高的对比度变化，会加剧
人眼的不适应；移动速度也应该适中，动得太快，也会加剧人眼的不适应。
基本从这几个方面来综合解决，就能改善效果了。
又想地图大，又想人物移动速度快，又想背景对比度高，又想让人眼感觉舒服是不现实的。
有些规格是技术来决定的，而不是美术和策划。
*******************************************
*******************************************