浅谈FLASHWEBGAME与创业.docx
《浅谈FLASHWEBGAME与创业.docx》由会员分享，可在线阅读，更多相关《浅谈FLASHWEBGAME与创业.docx（27页珍藏版）》请在冰点文库上搜索。
浅谈FLASHWEBGAME与创业
★我的FLASHWEBGAME开发历程
→2007年的夏天，顶着炎炎烈日，我从学校直接跑到上海，开始了我的FLASHWEBGAME创业之旅。
时至今日，转眼快三年了。
作为国内比较早的一批FLASHWEBGAME开发人员，今天我粗略的总结一下这两年多的经验和心得。
讲的不对的地方，请大家多多指教。
→2007年刚到上海的时候，初创团队只有四个人，一个CTO,一个美术，一个后台，一个前台。
手里的产品是一个已经在台湾运行三年左右的FLASH社区，和国内的梦境非常像。
这个产品还是不错的，早在FLASH5就在开发出来了，FLASH6出来后，又用新版本的AS1重写过。
这个产品让我又爱又恨，爱的是，在2007年的时候，国内除了梦境和1D真的很少有能赶上它的；恨的是，这个产品竟然没有前端源码！
要想修改还要破解！
玩过AS1，在时间轴、MC和BTN上写过代码的朋友应该知道这是什么概念——1个字：
囧！
→后来老板可能也觉得这样改下去不是办法，终于同意自己重写一个。
正好07年有条新闻很火爆：
国外有个FLASH社区第一次利用FLASH技术取得了重大成功，以7亿美金卖给迪斯尼，它就是“企鹅俱乐部”。
老板看到了商机，我们决定做一个中国版的企鹅，于是“海底世界”应运而生了。
而“海底世界”的创意，只不过是我们四个初创成员在闲聊时，我开玩笑随便说的。
→海底世界正式开发到现在差不多正好两年，期间我们碰到无数的问题和困难，不管是公司层面或技术层面，都是如此，但始终是坚持了下来。
产品一天天完善，公司规模也一天天扩大。
前端从最开始的两个人，到现在5个人；后端从最开始的FMS+PHP到现在自己写的socket服务器；公司规模也从最开始的4个人，到现在的50多个人。
★当今FLASHWEBGAME概述
→2007：
含苞欲放！
2007年可以说是FLASHWEBGAME发展史上的分水岭。
2007年之前，我们眼里只有梦境，最多再加上昙花一现的抱抱城，那时候根本没有“FLASHWEBGAME”这个概念，大家谈的都是“FLASH社区”，“FLASH社区”这个词在很长一段时间代表着FLASH应用领域的至高点。
也许2007年已经有不少团队开始研发FLASH的MMORPG了，我曾经有幸知道几个，但很可惜，不少都胎死腹中，2007年国内在线上运营的FLASHWEBGAME基本上还是空白。
但不管怎么说，我相信2007年是蓄势待发的一年，肯定有很多类似我们公司的团队，在默默的努力着。
→2008年：
雨后春笋！
经过2007年的积累和准备，FLASHWEBGAME业界的战斗终于在2008年打响，以“摩尔庄园”，“海底世界”为代表的“FLASH儿童虚拟社区”开始崭露头角；以“纵横天下”为代表的FLASH策略类游戏兴起；以“昆仑”为代表的FLASHMMORPG让“无端网游”的概念又炒了起来。
还有各种基于FLASH的卡牌对战类，联机棋牌类，模拟经营类游戏等等，都如雨后春笋般破土而出。
→2009年：
百花齐放！
2008年，国内虽然一下出了很多FLASHWEBGAME,但大家只要认真收集，总归还是能数的过来，可到了2009年，几乎每隔一个月，都会有几个新的FLASHWEBGAME进入大家视野，而且他们越来越完善，功能越来越强大，盈利模式也开始成熟并多样化。
2007年每出一个FLASHWEBGAME,我都会为之兴奋，并很有兴趣的去研究它。
而到了2009年末的时候，FLASHWEBGAME已经多到我连体验的兴趣都没了，我已经彻底搞不清楚国内到底有多少个FLASHWEBGAME在运营。
而伴随着SNS行业的成熟，基于SNS的Socialgame进一步扩大和模糊着FLASHWEBGAME的概念。
FLASH在游戏领域里的应用，在经历了“社区”、“策略类”、“MMORPG”后，发展到今天创意无限，精彩纷呈的“Socialgame”，已经很难用一个词，根据游戏类型概括所有的FLASH应用了。
所以我觉得“FLASHWEBGAME”，也就是“FLASH网页游戏”这个词还是相对最恰当的，这也是我前面一直使用这个词的原因。
→2010年–2011年：
胜者为王！
就像春秋战国时期，在经历过“百家争鸣”后，必然是“天下一统”。
随着游戏巨头和互联网大亨对网页游戏的逐渐重视，以及政府的介入，还有最早领跑某些领域的创业公司不断壮大，相信在不久的将来，网页游戏领域也会出现几个真正的领袖。
别的领域不敢说，在我们儿童市场这块儿，淘米公司已经逐渐呈现一家独大的趋势，不信的话，你可以随便找几个小学生问问，比如你父母辈亲戚朋友的孩子，问他们是否知道摩尔庄园和赛尔号，是否充值了，相信你会得到非常惊讶的答案。
所以，2010年后，任何小作坊型的创业团队再想进入FLASHWEBGAME行业，都需要更加谨慎了！
★创业型游戏公司面临的问题和困难
→在正式进入FLASHWEBGAME的技术探讨前，我左思右想，还是觉得必须先说一下创业公司存在的问题和困难，为后面可能不太“正规”的做法找一个合适的“理由”。
——人不能太爱找客观理由，但也绝对不能为了避免“找理由”之嫌，而弃客观现实于不顾，毛爷爷曾告诫我们要懂得“实事求是”。
→任何有过创业经验的技术团队和公司应该都知道，教科书那套从成功公司抽象出来的模式在创业初期几乎只能是神话一般的存在，相信没有几个公司能完全做到。
当然那种千万级启动资金，有成功背景的新公司除外。
像我们公司，一开始就4个人，前台和后台各一个人，如果我们两个都每天用一半时间考虑架构和写文档，我们的产品猴年马月也上不了线了，况且我们写了给谁看呢？
在这个阶段最最重要的目标就是尽快把产品做出来，上线运营出一定效果，给产品更加明确的方向，给团队信心，然后尽最大努力去融资，以求下一阶段的发展。
产品出不来，只靠一个idea和产品策划书就想找投资的时代早就一去不复返了。
→我觉得一个创业公司最现实的发展观应该是这样的：
初创阶段（技术导向型阶段）：
这个阶段要一切以“我们能做什么”为基础，在财力、人力、经验都不足的情况下，找出我们的优势，“把我们所擅长的做到最好”是我们唯一的筹码，毕竟初创人员能走到一起，必然是有一定共识，在某方面有优势的。
而“我们能做什么”，在初创阶段很大程度上就是指技术能做什么。
没钱、没人还想把项目做的又快又好，绝对是痴心妄想。
这个阶段就开始叫嚣“市场主导产品”，“不看过程只看结果”等口号，完全是不务实的态度，市场上最热门的产品你未必能开发出来，创业阶段，前途未卜，你不看过程看什么？
发展阶段（人力导向型阶段）：
假设我们顺利度过了第一阶段，公司开始有现金流或者找到了天使投资，我们就开始布置进一步的发展了，这个阶段招人将是公司的一个要务，招有创业精神的人，更要招我们需要和缺少的人。
以前我们公司只有AS，于是游戏server只能用FMS，现在应该招一个C++socket的人了；以前公司没有网页前端，网站都是原画和PHP代劳的，现在该弥补了；以前整个游戏都是架构师们设计并实现的，现在应该招一两个做模块打下手的人了。
这个阶段虽然不适合大规模扩展人手，但在要害人力点上，也绝对不能抠门，我们公司就是吃亏在socket上，公司一直不肯招一个专业写server端的，一直让前端和PHP代劳，结果游戏同时在线人数一超过5000就会出各种离奇问题，最恐怖是大家都不清楚问题到底在哪里，只能大眼瞪小眼，这个时候老板就会臭骂公司这帮技术都是饭桶，这么多人还搞不定这个问题。
老板不懂技术，说出这样的话无可厚非，但老板不听劝，死活不愿意招要害人员，这就是他的错了。
总之这个阶段要以人力发展为核心，尽最大的努力把必要的人手配备齐。
必须注意的是，这个阶段不适合空降部门领导，公司发展阶段，只有初创人员陪公司一路走来，最明白公司的问题，以及各种问题的根源。
而空降的领导容易只看到问题，不明白为什么会有问题，有时候难免说出“道理上很正确，但实际上不可行”的话，而老板为了配合新领导树立威信，很多时候不得不偏向新领导，这样以来很容易打击到初创人员的积极性。
更严重的是可能让初创人员看不到前途，创业的激情沦为打工的无味。
这个阶段挖墙脚空降领导，希望他们能把公司制度正规化，希望他们拯救公司的做法可能适得其反！
公司初创人员这时候应该依旧是公司的顶梁柱！
成熟阶段（产品导向型阶段）：
如果有幸过了前两个阶段，到了这个阶段的时候，公司应该已经实现了正向盈利，作为一个游戏公司，一旦靠自己实现盈利，相信各种投资机构肯定会主动找上门，千万美元的投资绝对不夸张，你将会为到底接受哪家的投资而烦恼。
人力、财力、物力都不再是问题，产品研发和运营的经验也成熟了，这时候唯一要关注的就是市场，什么样的产品更被市场和用户接受，争取开发出更多更好的产品。
产品要多样化，公司要规模化，要形成自己的产品链和平台，抓住更多的用户，开拓更多的盈利模式。
这时候才是产品主导公司，才是从大公司挖人的时代。
如果这些都做到了，当老板再次开会谈“上市”的问题时，每个人脸上将会笑容依旧，只不过初创阶段的笑容是那种开玩笑试的玩世不恭，而现在则是对未来的美好憧憬。
→其实任何理论都是有前提的，牛顿定律也只是在低于光速的情况下才适用。
公司发展的历程中，老板和员工肯定都会有其信仰和观念，都会用各种言辞来说服别人。
但我相信没有那种理论和言辞是永远正确的，尤其是书上和大公司的那些所谓的成功经验更是要警惕，因为它们身上有太多的光环，一场本来可能很有价值的讨论，说不定就会被一句“盛大就是这么做的”给结束掉！
所以在我们谈任何理论的时候，不妨看看公司现在所处的阶段，不妨时刻谨记毛爷爷的话，实事求是的看待自己。
我们公司就曾屡次吃类似的亏，公司在第一阶段刚拿到天使投资，就想做第三阶段的事了，结果做了很多，一件也没做好，白白浪费了很多时间和大好机遇。
其实当时老板用来说服人的理论也都是正确的，只不过不适合公司的实际发展情况而已。
还有一点要强调的是，不管公司现在处于第几阶段，坚决不能全盘否定其它阶段的付出和努力以及很多不得不犯的“错误”。
之所以强调这一点，也是我们公司曾踩过的雷区，当我们发展到第二阶段的时候，公司就开始忙着空降领导，然后这些领导对我们之前的做法开始逐一否定，把做后台的哥们儿说的一无是处，搞得团队气氛极不融洽，吵架红脸的情况经常发生。
这就好比我党在经历了长征、抗战和解放战争的原始积累后，在最终发动三大战役攻打大城市时，指着毛泽东的鼻子说：
“你以前那套只敢打农村，打的过就打，打不过就跑的逃跑主义路线完全是错误的！
”试想，如果党内空降领导都是这种态度的话，将会对我们党和战士们的积极性产生多大的打击！
这种情况其实在长征途中就发生过，差点就葬送了党，好在遵义会议及时纠正了苏联空降回来的王明等人的左倾激进主义，挽救了党。
而我们的公司，谁来挽救我们的公司呢！
★FLASHWEBGAME的系统架构
→我在这里把一款FLASHWEBGAME的架构分为三部分：
系统架构、前端架构、后端架构。
“系统架构”主要是指根据一款游戏的特点以及公司的实际情况选择合适的技术实现方案，主要包括美术方案，前端方案和后端方案；“前端架构”主要指FLASH前端的主程序以及模块划分；“后端架构”主要指即时通讯部分和数据库。
这章先谈系统架构。
→谈到架构，我不得不说，那些所谓的完美架构，能够一次架构好，永远不用改的说法只能是传说，或者技术人员忽悠老板的说法，对于创业公司更是如此。
创业公司初创时期更多的时候需要在游泳中学会游泳，因为大家都没有经验，失败是最好的教科书。
就算大家知道应该怎么做，很多时候条件也不允许。
比如我们在一开始就知道应该自己写socket服务器，可就是没socket的人才，于是不得不先使用FMS+PHP。
公司一开始的美术更精通FLASH一些，而且我们计划的是要做“企鹅”，于是我们选用矢量图。
可后来随着公司产品定位的不断改变，我们的架构和解决方案也会不断调整，当达到一个临界点时，修改的代价已经超过重新开发，我们就不得不对架构进行“重构”了！
这时候聪明的老板应该支持程序员们的意见，充分调动他们的积极性尽快改完，全公司应全力配合，尽快度过难关。
而不明事理的老板肯定会每天抱怨程序员无能，搭出一个垃圾架构不能满足产品的持续快速发展，拖了产品和市场的后腿，给程序员造成很大的压力，积极性没了不说，在长期经验积累之后本来可能是一次非常好的机会能做出一个相对完美的架构，满足日后很长一段时间的需求变更，结果因为老板过分催促和施压，又烙下了许多隐患，而这些欠下的债，总有一天要还的，这一天来临之时，责任虽然可以完全由程序员承担，但整个公司都要为之付出代价！
所以关键时刻程序员该坚持还是要坚持自己的观点，要尽量说服老板，程序员的社交能力在这个时候就凸显作用了，你要明白你不但是在对自己负责，也是对公司负责！
另外，真的很希望天下的老板们都能明白一个道理：
能够根据公司实际情况不断调整的程序员才是最可爱最辛苦的程序员，而不是那些什么都不管，上去就提一大堆要求，必须都满足他，他才愿意做的程序员。
→就算时至今日，FLASHWEBGAME在国内发展差不多三年了，但我敢说FLASHWEBGAME还是没有什么行业标准的技术解决方案，尤其是前端，大家都是自成一派。
在这个时候，让我们再次搬出那句老话：
不管黑猫白猫，抓住老鼠的就是好猫。
不过经过这几年的摸索，还是有一些规律可循的：
1，美术：
如果游戏画面简单，色彩构成相对单一，场景内总体元件能控制在100个以下，则非常适合直接使用矢量图，画面各组成部分尽量拆分为能重用的独立元件。
这样虽然牺牲了客户端的CPU，但能因为重用最大化而大大减少美术的工作量，也方便他们日后应对需求变更，比如某些元件的尺寸变动。
在画面简单，元件又少的情况下，利用递归全元件位图缓存，拿少量内存还能换回大量CPU，找出这个平衡点，完全可以做出很好的用户体验。
可大部分时间，我们的游戏场景可能都非常炫，画面复杂，色彩鲜艳。
使用矢量图的话，一方面不容易画出想要的效果和精细度，这时候使用矢量图反而增加了美术的工作量和难度；另一方面，使用矢量图还有可能导致客户端CPU严重飙升，超出普通客户端电脑的承受范围。
这时候我们应当用位图做游戏背景，重用性不大的元件要尽量合并到背景位图里，减少位图总个数，一些简单的动画如果非要用FLASH做成矢量动画的话，也要尽量做成逐帧的，相信FLASHIDE玩的转的美术同志们应该知道怎么把一个渐变动画瞬间转换成逐帧动画。
逐帧动画虽然会导致SWF文件体积增大，但相对于换回来的客户端CPU来说还是值得，这其实是牺牲了一些服务器带宽和用户等待时间，换回严重的客户端CPU超载。
而如果你的动画非常复杂和精细，精细到只有AE等粒子特效软件才能表达的话，建议还是直接从AE里导出位图序列，在FLASH里弄成逐帧动画，太过复杂的动画绝对不能用FLASH直接做，不但很难做出想要的效果，而且复杂矢量图的SWF文件体积也会大大超过位图，有可能导致用户因为SWF文件加载时间过长，失去等待的耐心，这时候我们情愿牺牲美术的工作量和工作流程，换回想要的效果，减小SWF文件体积。
还有一点要提醒的，时间轴动画不可见时，程序一定要记得将其stop掉，不像程序动画，时间轴动画不可见时，FP内部其实依旧在重绘，对CPU还是有影响的。
还有一种极端情况是场景元件超标，比如整个游戏内所有元素（包括各种MC、BTN、位图以及程序创建的displayObject，总量超过500，这时候你会发现，画面静止还好，但只要游戏上鼠标随便一晃，或者有几个人物随便走一下路，CPU都会狂飙，就算这500个元件都是位图也无济于事。
其实这是FLASH的一个瓶颈所在，是目前所有FLASH大型项目都有可能碰到的问题，也是我觉得阻碍FLASH进一步发展的主要障碍之一。
在一个元件超多的背景图上进行任何的鼠标动作、动画、文本渲染，都会导致CPU严重飙升，甚至画面很卡。
要解决这个问题，本质的也是唯一的方案就是减少元件数量，要想尽一切办法降到200以下。
而这需要美术、前端和策划通力合作才行，绝对不是前端程序员就能搞定的事。
策划要从产品的角度上看能不能简化目前场景同一时间出现的元素，美术要把能合并成一张图的元件在绘图软件中合并成一张位图，前端AS程序要把不需要响应鼠标事件的元件的mouseEnable和mouseChildren都设置成false，一些能利用copyPixels合并的位图就合并成一张，比如可以平铺创建的房间地板和墙面，要copyPixels成一张图，而不是new出好几百个元件。
其实元件超标的情况是大多数没有经验的团队很容易发生的问题，这时候前端程序员要起到领头羊的作用，给大家讲明白道理，用事实让大家信服，组织大家一起把事情做的更好，而不是一味的在那里抱怨FP效率低。
因为这时候你是团队唯一可以依靠的人，如果这个问题解决不了，虽然大家都有责任，但前端毫无疑问是罪魁祸首！
极端情况下的极端解决方案：
如果游戏策划的非常酷，一个子弹爆炸效果就需要几十个元件支撑，画面上同时又需要几十个坦克混战，这时候常规的解决方案是根本达不到的，但不是说就一定无法做了，你可以利用强大的BitmapData类把每帧要显示的游戏画面完全计算好并且在内存中绘制，然后以一张图的方式渲染给用户，这时候用户玩你的游戏仿佛就像在看逐帧的动画，此时FP占用的CPU大部分都是计算耗用的，而不是渲染耗用的。
其实AS的执行效率远远高于屏幕渲染，你把CPU的主要负荷转移给AS，反而能做更多更炫的事情。
据我的初步研究，前段时间名噪一时的FLASH版3D雷神，还有现在很多国外效率高的“有点假”的TD类和飞机类单机游戏都是这么做的。
可这种模式适合用来做多人联机并且有大量交互界面的FLASHWEBGAME么？
我初步思考了一下，感觉是不可能的。
首先，大量的交互界面意味着需要用鼠标点击，试想在一个逐帧动画中，每帧都要响应鼠标是什么概念？
所以UI部分首先排除了；然后是大量的即时数据交互，每当一个异步的请求得到响应，画面就需要做出相应的改变，这将对本来还可能比较工整的内部绘制算法制造非常大的麻烦，难度太高！
基本上也不可行；最后是很多FLASHWEBGAME的画面重用性并不是很高，比如像我们游戏的每个场景都是美术专门画的，而不是用地图编辑器编辑的，这就意味着你无法完全用程序拼出一个场景来；综上我觉得一个款FLASHWEBGAME基本不可能完全使用copyPixels完成，最多是部分实现，比如我上面说的墙面和地板。
除非你的游戏策划很NB，知道什么游戏能最大限度的利用copyPixels，而这样的策划估计本身肯定也是个前端程序员。
2，前端：
从系统架构的角度上讲，前端其实很简单。
现在WEBGAME主流的前端技术无非就是AS和JS。
JS的前端地位其实比AS要老，很多人的JS经过这么长时间的磨练，功力深厚，做一个策略类甚至简单的MMORPG都没问题。
但现在用AS来做的话可能更简单，更容易做出更酷的效果和更好的用户体验。
所以最近两三年，随着基于面向对象的AS3逐渐完善和普及，FLASHWEBGAME似乎逐渐成了唯一的主流。
其实除了as和js外，还有很多前端技术可以供我们选择，比如shockwave，java，还有那传说中的flashkiller：
silverlight和html5等等。
每种技术都有其优劣势，比如shockwave在图形渲染方面比flash强了千百倍啊千百倍，因为它可以完全调用显卡，我在网页上玩过一个基于shockwave的CS，流畅度和操作感完全不亚于桌面版的CS，还有国外的哈宝以及国内的娜娜米米都是基于shockwave的。
而Java和silverlight也都有强大的背景，HTML5最近也是来势汹汹。
但不管怎么样，2010年，FLASH仍以其广泛的覆盖率、酷炫的效果和逐渐成熟的开发社区，以最高的综合评分独领WEBGAME业界风骚。
所以任何公司和团队，如果现在想做WEBGAME的话，如果实际情况允许，FLASH还是最好的选择。
3，后端：
后端不是我的强项，我就不多说了，我只根据我们公司的经验谈谈心得。
我同意前后端编程有很大区别，但绝不同意前后端谁简单谁复杂之说。
根据我这几年的观察，我发现，前端偏重的是效果，是用户体验和细节处理，有时候可能还要涉及一些图形算法；而后端则偏重数据结构和数据处理，讲究的是性能、安全和扩展性。
前端工作量一般比后端大，而后端需要的工作经验比前端多，想依靠一个只掌握了理论知识的大学毕业生就支撑一个公司的后端架构是严重不靠谱的！
前端架构师必须是一个编程高手，十几、几十万行代码要在他的手里安排的井然有序，后端架构师则必须有过大型项目经验，并且项目同时在线人数达到过一定规模。
前端架构出现问题，会严重拖垮开发周期，而后端架构一旦出现问题，对公司将是致命性打击。
所以在公司里宣传所谓前端重要还是后端重要的说法，是完全错误的，任何一款好的产品，必将是策划、美术、前端、后端都达标的产品，缺失任何一块儿，都成功不了！
不同部门之间的比较和较真儿没有任何正面影响！
至于后端的技术解决方案，我感觉如果是需要大量即时交互，并且对即时性要求很高的游戏，就必须使用socket服务器。
而如果对即时性要求不高，完全可以用PHP，部分的即时交互可以用socket实现或者HTTP轮询也可以。
如果你的公司也像我们一样刚开始没有合适的C或者JAVAsocket程序员，选择fms和sfs也未尝不可，这样至少可以让前端人员代劳，让项目可以启动。
切记这只是为解燃眉之急的下下策，长久不了，公司要想办法尽快找到一个合适的人，在合适的时机重构。
★FLASHWEBGAME的前端架构与人事分工
→前端的主程序架构和模块划分与人手和人事分工是紧密联系在一起的，而这些很大程度上又是由项目本身决定的。
纵观现在国内绝大多数FLASHWEBGAME的规模和难度，我觉得前端AS人员大概需要2-7个之间，主程序有效代码一般不会超过10W行。
在这种情况下，人事分工应当以功能和模块进行划分，尽量避免多人维护同一份代码，每个人各司其职，减少维护和协作的成本。
这种模式非常适合人手不够，制度不健全，而且追求效率的初创公司。
→根据各种游戏类型的不同，分工也应该不同。
策略类更注重界面开发，分工上应该向UI偏重，MMORPG类注重主架构一些，而像我们的海底世界，是更新驱动类社区游戏，每周都要发布新内容，还需要大量的小游戏和场景功能支撑，所以需要更多的模块和小游戏程序员。
→下面就以我们公司为例详细谈一下，我们公司最多的时候，一共5个AS程序员，分工是这样的：
1个主架构，1个主UI,1个小游戏，2个场景和模块程序员。
主架构同时负责FMS的sever端；主UI同时负责前端人员管理和文件管理；小游戏人员以平均每月两个单机或者联机游戏的速度循环不停开发，是相对最独立的一部分；而两个模块程序员，负责每周发布的新场景和新模块功能，他们的工作量其实蛮大的。
→先谈前端主架构，前端程序主架构有两个主要任务：
1，要从架构高度合理划分前端各模块，提出可行的实现方案；2，从AS级别搭建程序架构（非文档级别），制定前端编程规则和接口，规范程序各部分的职责划分。
这两个任务其实包括很多具体工作，比如：
游戏启动流程制定，确定哪些SWF文件需要外部加载，那些功能可以从主程序剥离出去单独实现，前端配置文件怎么处理，公共素材怎么处理，MVC三层怎么划分，主程序框架的选定，主程序怎么和后台通讯，主程序如何与模块协作，哪些代码应该放在主程序中，哪些代码应该放在模块里，主程序如何既能提供模块所需要的一切功能和数据，同时又相对模块自我保护等等等等。
其实我谈的还只是一些大的方面，具体到实现的级别，还有大量细节工作要做。
而这些工作在项目启动之初都是非常重要的，直接影响到项目中后期的开发和维护效率。
→上面提到的那些点，我不可能全讲一遍，不然就不叫“浅谈FLASHWEBGAME”了！
我只挑两个比较核心的内容跟大家略做探讨，就是前端AS框架和模块划分的问题。
先谈前端框架：
现在市面上流行很多前端框架，不管
升级会员 