[转]我的FLASH情结2010——浅谈FLASH WEB GAME与创业（下）
我的FLASH情结2010——浅谈FLASH WEB GAME与创业
★前端与美术的配合
→老闪客们应该都知道，FLASH这款软件在历史很长一段时间内都是用来做动画的，闪客和美术在这段时间内本就是同根生。后来随着第二版AS1和AS2逐渐完善，以及AS3的强势出炉，闪客们才逐渐分化成纯程序和纯美术两个阵营了。但不管怎么分，FLASH程序和美术之间的关系依旧非常亲密，一个优秀的AS程序员必然要比其它语言的程序员懂得更多美术方面的知识，至少也要能熟练操作FLASH IDE，并进行简单的图形处理。FLASH程序员与美术的合作大部分时间是由AS程序员主导的，主要表现在以下几个方面：
1，FLA文件管理：把有联系的美术素材放进一个FLA文件中统一管理，既能有效减少美术素材的数量，也方便程序员写程序。本来像这种美术素材管理应该是由美术负责的，但由于这些美术素材大部分时间可能也需要程序员写程序，美术和程序需要共享这些素材，虽然我们可以用SVN进行共享和版本控制，但程序员和美术还是要靠约定才能非常默契的知道什么时间该到什么地方找什么文件。而这个约定就什么我们程序员应该制定的，因为据我观察，程序员在条理性和制定规则方面一般比美术更靠谱。以我们公司为例，文件管理基本上都是由我负责的，我把需要多个美术和程序员共同维护的部分以项目名命名成一个文件夹，项目下如果需要还可以进行子分类，分类规则也是我制定。而大部分的子模块可能只需要一个美术加一个程序员就搞定了，这时候美术就把素材放到以自己英文名命名的文件夹下，至于他们的文件夹内如何分类，我会给出意见，但并不强制管理。模块程序员也会都有以自己英文名命名的文件夹，他们会把美术的纯FLA素材拷贝到自己的文件夹下，并根据模块进行子分类，然后写代码并发布SWF，至于SWF文件如何管理，我会在下一节中讨论。其实我的管理目标非常简单，我只需要所有的美术和程序员能在任何时候瞬间找到我们需要的素材和源代码所在地，并且把需要的版本调出来。只要这个目标还在可控范围内，我就会给所有员工最大的自由性，把自己从管理里解脱出来，把更多的时间投入开发，毕竟对于创业型公司而言，快速开发，让老板和市场看到产品才是主旋律，管理只需要在必要的时候强势出手就可以了。事实上，我们公司的文件管理，我每隔半年才会强势管理一次，用大概一周的时间重新规范规则，其它时间基本处于放任自流状态，但从没出过什么大问题。最后给大家一个数字，我们公司经过将近三年的积累，已经有几十个G，上万个美术素材了。
2，SWF文件管理：SWF文件一般是由前端程序员发布并管理的，不过也有一些SWF可能不需要些代码，比如家具、个人面板背景等等，这些可以直接由美术管理，管理方案和FLA文件管理差不多。最大的不同就是，SWF文件最终的发布路径是内网模拟测试环境，而不是本机。像我们这样的更新驱动游戏，不可能为每一个模块都单独搭建拟真测试环境，如果这样的话，可能我们测试环境还没搭好，就该上线并准备下一周的更新了，所以所有的模块最终的整合测试都是直接上内网测试环境进行。
3，FLA内元件的管理：这个问题相信很多AS程序员都碰到过，也都为此头痛过。美术给到程序员手里的FLA文件可能是混乱不堪，库里没有任何分类，元件名也都是清一色的“元件1、元件2，元件3……”，元件内部遮罩，组合，层次也都没啥规律。要是美术直接给我一个AI或者PS的源文件让我们自己导入FLASH，那我们就更抽了，颜色模式的改变，路径工具的失灵，大量的图层导致裁切困难，而且还不能进行打散合并，只能一层一层的切。这个时候，正如我前面提到的，一个合格的AS程序员应该对美术和图形软件有更多的了解，你应当及时纠正美术不恰当的做法，甚至给出合理的解决方案，比如你应该知道FLASH只支持RGB颜色模式，AI不但整个文档可以指定颜色模式，每个图层也可以单独指定，当美术给到你的AI导入FLASH有色彩差异的时候，能帮助美术找到哪里的颜色模式不对，并建议他们以后只使用RGB模式。很多纯AS程序员可能有图形恐惧症，他们会想尽一切办法把这部分工作推向美术，但最终他们都会很郁闷，因为他们会发现，除了能指定库文件夹的命名规则外，其它的规则很难跟美术说明白，而且由于模块的千变万化，很难总结出一个完全通用的规则，想从美术哪里拿到一个完全不用修改，自己可以直接写代码的FLA文件，几乎天方夜谭。所以，与其让FLA文件在美术和程序的你来我往中浪费时间，与其让自己在对美术的鄙视中愤懑抱怨，不如提升一下自己的美术常识和图形处理基本功。毕竟，元件在舞台上怎么命名，关联什么类，层次怎么样，怎么被程序利用，这些只有我们程序员最清楚，这部分工作由我们程序员完成完全是合理的，也是效率最高的，美术只要把我们需要的素材交给我们，并放到方便查找的地方就可以了。放下程序员的架子，主动走入美术的世界，对我们程序员绝对有好处。
4，FP的性能问题对美术的影响：谈到这个问题，我就想起了一个让我抽搐已久的情况。我们老板总是喜欢语重心长的对我说：“火山，你给咱们前端人员和美术出一个方案吧，告诉他们怎么做可以让FLASH性能最高！”额，现在请问哪位朋友可以帮火山回答这个问题。火山真的惭愧，搞FLASH搞了7年了，始终还是没完全弄明白FLASH的诸多性能问题。不管以前的MM还是现在ADOBE，都将其图形处理和屏幕渲染部分视为其镇山之宝，不肯公开其技术内幕，我也就始终无法从理论的高度给出一个本质的回答。我现在的大多数性能解决方案，都是根据项目的实际情况，根据7年来的经验总结出的经验科学。而且我始终不相信，谁可以一个给出一个适合所有项目的、通用的性能解决方案，可以同时让内存、CPU、带宽占用都最少，而且画面又很炫，功能很强大，SWF文件非常小，可玩性非常高，而开发周期和成本却很少。内存、CPU、SWF体积、带宽、效果、成本，这几个要素往往是相互矛盾的，你对其中任何一点的过分优化，都有可能导致其它点走向反面。我深信，在目前这个时期，一个性能方面的高手，绝对不是看他能不能给出一个全面优化的方案，而是看他在面对不同的项目，不同的情况时，如何做出选择和取舍。是的，“选择和取舍”永远都是人生最艰难的话题：手心手背都是肉，削掉哪边呢？老婆孩子都掉海里了，救谁呢？在这样的情况下，我觉得一个负责的前端人员，反而不应该仅仅简单的扔给美术一份死的文档，告诉他们应该怎么做，让他们一直这么做就可以了。前端人员应该在每次面对一个实际情况时，都不厌其烦的跟美术讲清缘由，我们应该尽量授人以“渔”，而不授人以“鱼”，让他们明白选择的道理，而不是简单的告诉他们选择什么。相信只要是虚心学习的美术，经过一年半载的讲解他们就能替你做出判断了，这时候你再让他们去跟后来的美术讲，你就解脱了。很可惜，大部分不懂技术的老板可能觉得你是在故弄玄虚，非要你给出一份文档。无所谓了，你跟不懂技术的人争论不是自讨没趣么？老板更多时候是从管理的角度出发的，我们应该配合。我们也不是没什么可写，比如尽量减少元件数量啊，减小SWF体积啊，减少持续性动画啊，多做触发性动画啊，少用遮罩和滤镜啊，不要嵌入中文字体啊，提高元件重用性啊等等等等！这些建议听上去完全正确，忽悠不懂技术的人正合适。但其实在高端的开发中，这些理论都是废话，帮不上多大忙，因为地球人都知道了，我们碰到的问题肯定是超越这些技术点的高端问题！
综上可以看出，其实前端和美术的配合过程大部分时间是由前端主导的，这也是我前面一再强调前端要多懂一些美术知识的重要原因。当你可以和美术一起谈论美术理论，在美术的电脑上直接操作给他们看，当你从美术的角度给他们提出解决方案的时候，你往往会更容易被美术所接受。担负起主导前端与美术合作的责任，用你的智慧征服他们，用你的诚意打动他们，让美术与前端完美结合，让你的产品第一时间抓住用户！
★前端与后端的配合
→FLASH与后端通讯的手段多种多样，网上相关教程太多了，这里不再例举。但很多时候，创业团队由于受制于各种现实条件，可选择的方案并不多。像我们公司，刚开始基本上只能选择FMS+PHP+MYSQL。其实，对于我们前端来说，后端选择什么解决方案对我们的影响并不大，我们无非就是用的API不一样而已。多看看教程，用很少的时间我们就能掌握其要领。那么前后端合作的难点是什么呢？我觉得关键是逻辑的划分。
→“前后端合理划分逻辑”，这句话咋看上去貌似简单，其实里面蕴含着诸多方面的考虑。比如安全性、后端性能、工作量、人事分工等等。安全性：记得我们的游戏同时在线超过3000的时候，就已经有人开始攻击我们的后端了，篡改了很多人的个人资料。幸亏攻击的人只是我们一个善意的玩家，如果是恶意的商业攻击，后果不堪设想。经过这次后，老板开始缠着我们追问“怎么防止别人攻击，提高安全性”。这个问题又一次把我们难住了，我们都知道，基于HTTP的请求不被截取是不可能的，而SWF文件又不存在绝对的安全。就算你防得了恶意进攻，你也防不了良性的外挂，想从技术层面让别人完全攻击不了我们也是不可能的。那我们是不是只能坐以待毙了？不是！如果前、后端在合作的时候，数据逻辑与合法性检查都是做在后端的，就可以很好的避免一些良性外挂。首先是游戏数据逻辑要尽量全做在后端，比如用户在玩小游戏的时候，我们不要只是在用户结束小游戏后，简单的把数据传回后端，后端记录进数据库完事，一旦攻击者发现了你这个传数据的后台接口，完全可以避开SWF，做外挂直接呼叫你这个接口刷分，就算你验证用户也没用，因为他可以先注册一个合法的用户，然后在外挂中登录再刷分。当然，你还可以对游戏分数先加密在传给后端，提高攻击难度，但这也是不保险的，因为加密算法就在你的SWF文件中，别人可以很容易获得。所以正确的做法应该是：游戏开始的时候只告知后端游戏ID→后端标识ID对应的游戏已经开始并记录开始时间→用户每次获得一个分数时，前端传回来的不是分数，而是一个动作ID,后端根据动作ID给用户加分→游戏结束时，前端告知后端游戏已经结束→后端得知游戏结束，记录结束时间，计算时间差，根据时间差和最后得分是否符合标准做出相应处理，如果符合标准就把最后得分入库，并返回前端显示给用户，如果不符合标准，就启动作 弊处理系统。而这个标准一般是由数值策划给出的。经过我这么一分析，你可能头痛了，本来一个很简单的小游戏计分，怎么搞得这么复杂？前后端工作量都增加了不说，对后端性能也提出了更高的要求，服务器可能要增加了，后端人手可能要增加了，开发周期也要延长了，值得么？这个问题问的很好，这正是我下面要说的：后端性能、工作量、人事分工：一旦我们每一步进行安全性与合法性验证后，整个项目的工作量都会大大膨胀，开发周期也会大大延长；一旦我们把数据处理、业务逻辑和安全验证都移到后端时，后端的压力就会增加，服务器要增多，对后端人员的能力要求也会提高。很多初创团队在项目初期人力财力，软件硬件都不足，可能顾不上那么多，一心想着早点让项目上线。在这种情况下，我觉得安全性可以暂时放一下，众所周知的安全漏洞补上就可以了。但“数据处理和业务逻辑”这个，宁可开发的慢一点，宁可再招个后端高手，宁可多几台服务器成本，也要把它们尽量都放在后端。因为这个没分清的话，会影响到整个系统的清晰度，严重影响项目中后期的发展，为日后的重构增加难度和超多的工作量，我们还指望着在重构时加强安全性呢，到时候数据处理和业务逻辑还是要放后端！所以综合考虑，该出手时就出手，能省的不浪费，不能省的不要抠！
→前面一节谈了前后端合作的难点。这里再简单的谈两个要点：
1，前端人员不要以前端的角度看后端：前端和后端有个本质的区别，就是前端的负荷是分担在每个客户端的，而服务端的负荷是集中在服务器上的。对于我们前端来说，一个功能多占了几K内存，SWF文件大了几K根本不是什么问题，可对后端来说就是很严重的问题了，一个人大几K，上千人就是几M了。服务器在连接数、内存和CPU之间会有微妙的平衡点，一旦这个平衡点被打破，随便再多哪怕一点点资源占用，整个服务器的性能都会严重下降，影响用户体验，当然，如果你有几十上百台冗余服务器供你负载平衡，你可以当我没说，可如果你像我们公司一样，一开始就3、5台服务器的话，就请前端人员一定要多多配合后端人员，帮他们省出每一个字节，每一次请求。比如像道具属性会有很多文字说明，这些说明应该以类似XML文件的方式储存为静态文件，后端返回给前端的道具数据包里只需要一串物品ID,前端就可以根据这些物品ID在XML文件里查询出这些道具对应的静态物品属性了。别看这些数据可能只有十几K，对后端来说意义重大。还是那句话，只要不是架构性问题，前端不要怕麻烦，要尽量配合后端提高性能。
2，前端后端要有很明显的BUG分界点。当一个BUG出现时，后端应当很快的用一种统一的方案证明数据没有问题！这个方案必须让前端知道，并让前端也可以操作。大家熟知的php remoting里有一个servicebrowser，这个东西就很好，它能罗列出所有PHP的接口，我们输入参数，它就返回结果，我们可以根据结果直接查看数据是否正确。——确定数据的正确性，对前端DEBUG非常重要，而一个BUG的解决，一般都是由前端人员入手并进行定位的。
→其实相对于前端和美术的合作，前端与后端的合作还是简单清晰的，前后端在开发的过程中，应该是非常独立的，后端开发完全可以先启动，把数据接口提前写好，等着与前端整合，而当整合过程发生问题时，又可以很快的界定是谁的问题。
★公司文化与产品定位
→前面谈了那么多，无论是策划、美术、前端还是后端，大家通力合作，共同奋斗的目标无非就是希望开发出来一个好产品，而开发出一个好产品的目标无非就是成就一个好公司，这就涉及到“产品定位”与“公司文化”的问题，公司文化和产品定位没做好，其它人再努力都是枉然。可正是这两个问题，从我们公司成立到现在一直困扰着我，我抓破脑袋苦思冥想，总结出我们公司的公司文化就是“老板说了算”，而我们的产品文化就是“与时俱进，不断重新定位”。下面我先谈公司文化再谈产品文化，因为产品文化是包含在公司文化中的。
→公司文化：一个公司的文化在很大程度上是由初创团队建立的，而初创团队一般分两种，一种是权利分散型，初创团队在各个领域都有领头人，虽然也有形式上的CEO，但产品、研发、市场相互干涉的并不多，领导层内部“三权分立，民主平等”，对外发言人则可以统一由CEO代劳。这种模式的优点是大家优势互补，让懂行的人完全负责相关领域，负责人成就感大，责任心强。缺点是，权利分散就要求领导层必须非常团结，配合默契，如果他们之间出现矛盾，对公司影响会很大。我们的竞争对手淘米网络就是这种模式，到目前为止，他们公司发展的还是最好的。另外一种模式就是“老板专政”模式，专政到什么程度，跟老板对权利的欲望有关。我们公司老板就专政到事无巨细的程度了，就连买一个几百块钱的路由器都要再三跟老板请示，美术、策划、开发所有的日程安排、人事任用都要由老板点头。“专政模式”在创业初期也未必就是坏事，因为创业初期，困难重重，大家又都有自己的想法，每个人的信心都比较脆弱，如果没有一个强势的人主掌大事，所有人容易形成一盘散沙的尴尬局面。专政模式下，公司文化其实就是老板的个人文化。专政的人一定要有专政的资本，有专政的能力，掌握着公司最大的权利，就必须承担最大的责任。如果公司成功了，就算你再说成功是大家的，最大的成功者还是你，但如果公司失败了，就算你找一千个理由推脱责任，最大的失败者也是你！在这种情况下，专政者要努力提高自己的全面素质，公司管理、产品、开发、策划、美术、市场都必须有所了解，你的任何一个错误的决定都会把公司推向深渊，并引起相关部门人员的不满。我们公司就是典型，老板以前是做销售的，对策划、开发和美术，甚至是互联网都没什么概念，做海底世界前连QQ都没用过！虽然他在资历和财力方面当之无愧，但其短板也是无法否认的事实。初创很长一段时间内，他都敢拍板说一个社区一个AS一个月搞定之类的话，而且还要非常强势的让你接受，并拿出执行方案。至于他为什么敢这么坚决的做出这个错误的决定，我也不明白。可能正是因为他也不知道到底需要多长时间才能开发出来，而我们又没有取得他的信任吧，所以他就只能尽量往少的时间说，等到我们没完成工作，大不了再延长时间而已。可这对我们这些开发者就造成很大困扰了，这种根本不可能达成的目标如何拿出执行方案呢？开发规划如何做呢？最后开发不出来谁承担责任呢？于是一个怪圈形成了：老板不信任开发→制定不合理的开发目标→制定不合理的开发规划→开发规划没完成或者大打折扣→老板认为开发者能力不行更不信任开发→老板要求开发者提升自身能力满足他的要求→开发者依旧满足不了老板→老板在工作能力和员工素质上全面怀疑开着者→制定更加不合理的开发目标甚至是惩罚制度→项目更加完不成……额，这真是一个装满了苦水，倒又倒不出的杯具！当然，只要不是傻子，在这个悲剧的循环过程中，不管是老板还是开发者都会变得越来越“聪明”，老板一天天成熟了，程序员一天天世故了。只是曾经浪费的时间，错过的时机不再有，曾经不合理制度下积累的问题，明天需要继续补救！如果上天能给大家一次重来的机会，我相信，老板会说：“下次我一定要在项目刚开始就找一个靠谱的，值得信任的CTO！”，而程序员会说：“我下次再也不会跟着不懂技术还自以为是，横加干涉的老板了！”
虽然“民主平等”和“高度专政”两种模式都有其优缺点，但最终玩的都是一个“人”字，相同项目，一个模式，不同的人玩出来的结果肯定不一样。同是专政模式，奥比岛就比海底世界成功。不过站在历史发展观上看两种模式的话，我个人更偏向于“民主平等”模式，这种模式下的公司领导层为了保证公司能长久健康发展，肯定会不得不想尽一切办法制定出平衡权利的法制规则，只要法制规则适应时代，领导层人事变动影响是可控的。而“专政模式”的专政者，为了保证其一手建立起来的商业帝国不至于在自己退位后轰然倒塌，肯定不得不想尽一切办法寻找接班人，帝国的命运系于接班人的选择。相对于“人治”，我觉得“法制”更靠谱。看到这里也许你又该搬出中国特色来反驳了，说什么中国的企业不合适。但纵观天下，历史的潮流是不可逆转的，中国作为历史发展的组成部分，脚步可以慢，但方向不会错。80后已经开始觉醒，90后会继续努力的。所以希望任何一个创业者在创业初期都认真的回答一个问题：你是只想做一个成功的企业家，还是想真正做一个成功的企业，让这个企业能长久发展，代代相传。一个成功的企业家的成功是个人的，而一个成功的企业的成功是大家的，是社会的！
→产品文化：产品文化包含于公司文化，“民主平等”的公司，产品的文化就是“管理层相同价值观”的文化，而“高度专政”的公司，产品文化就是“老板个人”的文化。不管是什么类型的公司，什么产品文化，这个文化一定要简明而清晰，要深入人心，最好能浓缩成简单的一个词或者句子，“妈妈放心，孩子喜欢”就代表着淘米网络的产品文化。这个口号从淘米成立不久就已经开始喊了，到现在没有变过。我相信他们的用户，他们用户的家长，他们公司从管理层到员工每一个人，就连他们的竞争对手都对他们公司的价值观，对他们的产品文化有一个清晰的认识。而我们公司呢？反观我们公司，在这方面做的非常差，公司从成立到现在产品定位一直在变，刚开始要做一个针对初高中生和女孩子的休闲社区，搞了几个月后，又发现企鹅，一股脑的投入到儿童这块儿蓝海市场，说要做一个中国版的企鹅俱乐部，再后来可能觉得儿童市场有点小，收费比较困难了，又想把产品目标用户群再提高一下，提高到初高中生也能玩，游戏复杂度也要随之提高，这样还没做多长时间，又看到人家淘米推出赛尔号这种PK游戏了，又觉得纯绿色游戏的可玩性不高，对用户尤其是男孩子的吸引力不够，又要在我们的游戏里也加入PK和打怪了。直到现在，公司里上上下下，除了老板之外，没几个人能弄清公司的产品定位是什么，我们的产品文化是什么！这种情况导致一个很严重的问题，就是策划在策划游戏的时候，没有核心价值观，也就更没什么游戏世界观了，最终导致游戏形散神也散！
游戏一直在改版，功能一直在开发，BUG一直都存在，性能一直上不去，目标用户群一直在改变，老用户一直在流失，我只能用一个词形容我的心情：痛心疾首！
★2010年：我的梦想扬帆起航
→从毕业就一直在酷噜，一直做FLASH WEB GAME，当时的想法很简单，就是想体验一下顶尖的FLASH应用开发。转眼即将三年了，回眸探望，几多感慨，但终究还是能淡然处之。毕竟大家都不容易，大家都在摸索，也都在摸索中前进和成长，公司现在其实已经比刚开始好多了。
→如今再打开4年前那篇《我的FLASH情结2006》，激扬的文字震撼我心。而现在的我，在海底世界的前端开发中已经找不到往日的激情，每日重复的机械劳动。而自己的理想，更是逐渐飘渺远去，一种温水煮青蛙的危机感油然而生。于是2010年，我向公司递交辞呈，结束我毕业后的第一份工作；再写一篇《我的FLASH情结2010》暂时结束FLASH WEB GAME开发。
→那么2010年，我要做什么呢？没错，我要开始做自己的项目了。我们公司的一位在商场上混迹多年的大股东在年会上语重心长的对我说：“火山啊，你现在自己做项目有两个最大的问题，一是你没在大公司呆过，对一些正规的公司流程不了解；二是你原始资本积累还严重不足，很难支撑项目长久下去。”其实我自己又何尝不明白呢，我知道自己这次单干也是九死一生，但我实在等不了了，7年的技术积累，3年的工作积累，为的就是今天，我也是奔三的人了，都讲男人30而立，马上要面对结婚生孩子，上有老下有小的艰难局面，我再不趁机把握最后这两年相对轻松自由的机会，以后会更难。我的梦想可能很天真，但我会做的很认真。
→其实冷静下来想想，也没什么好怕的，想当年我敢带着一千块钱闯上海，今天我就敢拿着几万块钱自己干，大不了折腾完了再到大公司打工深造呗。虽然我工作三年才积累了几万块钱这听上去有点寒，虽然我每个月最多只能给自己播出1000块钱的创业资本这听上去有点少，虽然我自己得把策划、开发、美术和运营全做了这听上去有点假，虽然现在我还天天穿着高中和从亲戚那里捡来的衣服这看上去有点苦，但这都是外人看我的观点，我自己是乐在其中，浑然不觉，哈哈。不管怎么样，2010年，我的梦想必须扬帆起航，不以成败论英雄，只为人生少留遗憾！
→寂寞火山：http://www.huoshan.org/#BoKe_143
★前端与美术的配合
→老闪客们应该都知道，FLASH这款软件在历史很长一段时间内都是用来做动画的，闪客和美术在这段时间内本就是同根生。后来随着第二版AS1和AS2逐渐完善，以及AS3的强势出炉，闪客们才逐渐分化成纯程序和纯美术两个阵营了。但不管怎么分，FLASH程序和美术之间的关系依旧非常亲密，一个优秀的AS程序员必然要比其它语言的程序员懂得更多美术方面的知识，至少也要能熟练操作FLASH IDE，并进行简单的图形处理。FLASH程序员与美术的合作大部分时间是由AS程序员主导的，主要表现在以下几个方面：
1，FLA文件管理：把有联系的美术素材放进一个FLA文件中统一管理，既能有效减少美术素材的数量，也方便程序员写程序。本来像这种美术素材管理应该是由美术负责的，但由于这些美术素材大部分时间可能也需要程序员写程序，美术和程序需要共享这些素材，虽然我们可以用SVN进行共享和版本控制，但程序员和美术还是要靠约定才能非常默契的知道什么时间该到什么地方找什么文件。而这个约定就什么我们程序员应该制定的，因为据我观察，程序员在条理性和制定规则方面一般比美术更靠谱。以我们公司为例，文件管理基本上都是由我负责的，我把需要多个美术和程序员共同维护的部分以项目名命名成一个文件夹，项目下如果需要还可以进行子分类，分类规则也是我制定。而大部分的子模块可能只需要一个美术加一个程序员就搞定了，这时候美术就把素材放到以自己英文名命名的文件夹下，至于他们的文件夹内如何分类，我会给出意见，但并不强制管理。模块程序员也会都有以自己英文名命名的文件夹，他们会把美术的纯FLA素材拷贝到自己的文件夹下，并根据模块进行子分类，然后写代码并发布SWF，至于SWF文件如何管理，我会在下一节中讨论。其实我的管理目标非常简单，我只需要所有的美术和程序员能在任何时候瞬间找到我们需要的素材和源代码所在地，并且把需要的版本调出来。只要这个目标还在可控范围内，我就会给所有员工最大的自由性，把自己从管理里解脱出来，把更多的时间投入开发，毕竟对于创业型公司而言，快速开发，让老板和市场看到产品才是主旋律，管理只需要在必要的时候强势出手就可以了。事实上，我们公司的文件管理，我每隔半年才会强势管理一次，用大概一周的时间重新规范规则，其它时间基本处于放任自流状态，但从没出过什么大问题。最后给大家一个数字，我们公司经过将近三年的积累，已经有几十个G，上万个美术素材了。
2，SWF文件管理：SWF文件一般是由前端程序员发布并管理的，不过也有一些SWF可能不需要些代码，比如家具、个人面板背景等等，这些可以直接由美术管理，管理方案和FLA文件管理差不多。最大的不同就是，SWF文件最终的发布路径是内网模拟测试环境，而不是本机。像我们这样的更新驱动游戏，不可能为每一个模块都单独搭建拟真测试环境，如果这样的话，可能我们测试环境还没搭好，就该上线并准备下一周的更新了，所以所有的模块最终的整合测试都是直接上内网测试环境进行。
3，FLA内元件的管理：这个问题相信很多AS程序员都碰到过，也都为此头痛过。美术给到程序员手里的FLA文件可能是混乱不堪，库里没有任何分类，元件名也都是清一色的“元件1、元件2，元件3……”，元件内部遮罩，组合，层次也都没啥规律。要是美术直接给我一个AI或者PS的源文件让我们自己导入FLASH，那我们就更抽了，颜色模式的改变，路径工具的失灵，大量的图层导致裁切困难，而且还不能进行打散合并，只能一层一层的切。这个时候，正如我前面提到的，一个合格的AS程序员应该对美术和图形软件有更多的了解，你应当及时纠正美术不恰当的做法，甚至给出合理的解决方案，比如你应该知道FLASH只支持RGB颜色模式，AI不但整个文档可以指定颜色模式，每个图层也可以单独指定，当美术给到你的AI导入FLASH有色彩差异的时候，能帮助美术找到哪里的颜色模式不对，并建议他们以后只使用RGB模式。很多纯AS程序员可能有图形恐惧症，他们会想尽一切办法把这部分工作推向美术，但最终他们都会很郁闷，因为他们会发现，除了能指定库文件夹的命名规则外，其它的规则很难跟美术说明白，而且由于模块的千变万化，很难总结出一个完全通用的规则，想从美术哪里拿到一个完全不用修改，自己可以直接写代码的FLA文件，几乎天方夜谭。所以，与其让FLA文件在美术和程序的你来我往中浪费时间，与其让自己在对美术的鄙视中愤懑抱怨，不如提升一下自己的美术常识和图形处理基本功。毕竟，元件在舞台上怎么命名，关联什么类，层次怎么样，怎么被程序利用，这些只有我们程序员最清楚，这部分工作由我们程序员完成完全是合理的，也是效率最高的，美术只要把我们需要的素材交给我们，并放到方便查找的地方就可以了。放下程序员的架子，主动走入美术的世界，对我们程序员绝对有好处。
4，FP的性能问题对美术的影响：谈到这个问题，我就想起了一个让我抽搐已久的情况。我们老板总是喜欢语重心长的对我说：“火山，你给咱们前端人员和美术出一个方案吧，告诉他们怎么做可以让FLASH性能最高！”额，现在请问哪位朋友可以帮火山回答这个问题。火山真的惭愧，搞FLASH搞了7年了，始终还是没完全弄明白FLASH的诸多性能问题。不管以前的MM还是现在ADOBE，都将其图形处理和屏幕渲染部分视为其镇山之宝，不肯公开其技术内幕，我也就始终无法从理论的高度给出一个本质的回答。我现在的大多数性能解决方案，都是根据项目的实际情况，根据7年来的经验总结出的经验科学。而且我始终不相信，谁可以一个给出一个适合所有项目的、通用的性能解决方案，可以同时让内存、CPU、带宽占用都最少，而且画面又很炫，功能很强大，SWF文件非常小，可玩性非常高，而开发周期和成本却很少。内存、CPU、SWF体积、带宽、效果、成本，这几个要素往往是相互矛盾的，你对其中任何一点的过分优化，都有可能导致其它点走向反面。我深信，在目前这个时期，一个性能方面的高手，绝对不是看他能不能给出一个全面优化的方案，而是看他在面对不同的项目，不同的情况时，如何做出选择和取舍。是的，“选择和取舍”永远都是人生最艰难的话题：手心手背都是肉，削掉哪边呢？老婆孩子都掉海里了，救谁呢？在这样的情况下，我觉得一个负责的前端人员，反而不应该仅仅简单的扔给美术一份死的文档，告诉他们应该怎么做，让他们一直这么做就可以了。前端人员应该在每次面对一个实际情况时，都不厌其烦的跟美术讲清缘由，我们应该尽量授人以“渔”，而不授人以“鱼”，让他们明白选择的道理，而不是简单的告诉他们选择什么。相信只要是虚心学习的美术，经过一年半载的讲解他们就能替你做出判断了，这时候你再让他们去跟后来的美术讲，你就解脱了。很可惜，大部分不懂技术的老板可能觉得你是在故弄玄虚，非要你给出一份文档。无所谓了，你跟不懂技术的人争论不是自讨没趣么？老板更多时候是从管理的角度出发的，我们应该配合。我们也不是没什么可写，比如尽量减少元件数量啊，减小SWF体积啊，减少持续性动画啊，多做触发性动画啊，少用遮罩和滤镜啊，不要嵌入中文字体啊，提高元件重用性啊等等等等！这些建议听上去完全正确，忽悠不懂技术的人正合适。但其实在高端的开发中，这些理论都是废话，帮不上多大忙，因为地球人都知道了，我们碰到的问题肯定是超越这些技术点的高端问题！
综上可以看出，其实前端和美术的配合过程大部分时间是由前端主导的，这也是我前面一再强调前端要多懂一些美术知识的重要原因。当你可以和美术一起谈论美术理论，在美术的电脑上直接操作给他们看，当你从美术的角度给他们提出解决方案的时候，你往往会更容易被美术所接受。担负起主导前端与美术合作的责任，用你的智慧征服他们，用你的诚意打动他们，让美术与前端完美结合，让你的产品第一时间抓住用户！
★前端与后端的配合
→FLASH与后端通讯的手段多种多样，网上相关教程太多了，这里不再例举。但很多时候，创业团队由于受制于各种现实条件，可选择的方案并不多。像我们公司，刚开始基本上只能选择FMS+PHP+MYSQL。其实，对于我们前端来说，后端选择什么解决方案对我们的影响并不大，我们无非就是用的API不一样而已。多看看教程，用很少的时间我们就能掌握其要领。那么前后端合作的难点是什么呢？我觉得关键是逻辑的划分。
→“前后端合理划分逻辑”，这句话咋看上去貌似简单，其实里面蕴含着诸多方面的考虑。比如安全性、后端性能、工作量、人事分工等等。安全性：记得我们的游戏同时在线超过3000的时候，就已经有人开始攻击我们的后端了，篡改了很多人的个人资料。幸亏攻击的人只是我们一个善意的玩家，如果是恶意的商业攻击，后果不堪设想。经过这次后，老板开始缠着我们追问“怎么防止别人攻击，提高安全性”。这个问题又一次把我们难住了，我们都知道，基于HTTP的请求不被截取是不可能的，而SWF文件又不存在绝对的安全。就算你防得了恶意进攻，你也防不了良性的外挂，想从技术层面让别人完全攻击不了我们也是不可能的。那我们是不是只能坐以待毙了？不是！如果前、后端在合作的时候，数据逻辑与合法性检查都是做在后端的，就可以很好的避免一些良性外挂。首先是游戏数据逻辑要尽量全做在后端，比如用户在玩小游戏的时候，我们不要只是在用户结束小游戏后，简单的把数据传回后端，后端记录进数据库完事，一旦攻击者发现了你这个传数据的后台接口，完全可以避开SWF，做外挂直接呼叫你这个接口刷分，就算你验证用户也没用，因为他可以先注册一个合法的用户，然后在外挂中登录再刷分。当然，你还可以对游戏分数先加密在传给后端，提高攻击难度，但这也是不保险的，因为加密算法就在你的SWF文件中，别人可以很容易获得。所以正确的做法应该是：游戏开始的时候只告知后端游戏ID→后端标识ID对应的游戏已经开始并记录开始时间→用户每次获得一个分数时，前端传回来的不是分数，而是一个动作ID,后端根据动作ID给用户加分→游戏结束时，前端告知后端游戏已经结束→后端得知游戏结束，记录结束时间，计算时间差，根据时间差和最后得分是否符合标准做出相应处理，如果符合标准就把最后得分入库，并返回前端显示给用户，如果不符合标准，就启动作 弊处理系统。而这个标准一般是由数值策划给出的。经过我这么一分析，你可能头痛了，本来一个很简单的小游戏计分，怎么搞得这么复杂？前后端工作量都增加了不说，对后端性能也提出了更高的要求，服务器可能要增加了，后端人手可能要增加了，开发周期也要延长了，值得么？这个问题问的很好，这正是我下面要说的：后端性能、工作量、人事分工：一旦我们每一步进行安全性与合法性验证后，整个项目的工作量都会大大膨胀，开发周期也会大大延长；一旦我们把数据处理、业务逻辑和安全验证都移到后端时，后端的压力就会增加，服务器要增多，对后端人员的能力要求也会提高。很多初创团队在项目初期人力财力，软件硬件都不足，可能顾不上那么多，一心想着早点让项目上线。在这种情况下，我觉得安全性可以暂时放一下，众所周知的安全漏洞补上就可以了。但“数据处理和业务逻辑”这个，宁可开发的慢一点，宁可再招个后端高手，宁可多几台服务器成本，也要把它们尽量都放在后端。因为这个没分清的话，会影响到整个系统的清晰度，严重影响项目中后期的发展，为日后的重构增加难度和超多的工作量，我们还指望着在重构时加强安全性呢，到时候数据处理和业务逻辑还是要放后端！所以综合考虑，该出手时就出手，能省的不浪费，不能省的不要抠！
→前面一节谈了前后端合作的难点。这里再简单的谈两个要点：
1，前端人员不要以前端的角度看后端：前端和后端有个本质的区别，就是前端的负荷是分担在每个客户端的，而服务端的负荷是集中在服务器上的。对于我们前端来说，一个功能多占了几K内存，SWF文件大了几K根本不是什么问题，可对后端来说就是很严重的问题了，一个人大几K，上千人就是几M了。服务器在连接数、内存和CPU之间会有微妙的平衡点，一旦这个平衡点被打破，随便再多哪怕一点点资源占用，整个服务器的性能都会严重下降，影响用户体验，当然，如果你有几十上百台冗余服务器供你负载平衡，你可以当我没说，可如果你像我们公司一样，一开始就3、5台服务器的话，就请前端人员一定要多多配合后端人员，帮他们省出每一个字节，每一次请求。比如像道具属性会有很多文字说明，这些说明应该以类似XML文件的方式储存为静态文件，后端返回给前端的道具数据包里只需要一串物品ID,前端就可以根据这些物品ID在XML文件里查询出这些道具对应的静态物品属性了。别看这些数据可能只有十几K，对后端来说意义重大。还是那句话，只要不是架构性问题，前端不要怕麻烦，要尽量配合后端提高性能。
2，前端后端要有很明显的BUG分界点。当一个BUG出现时，后端应当很快的用一种统一的方案证明数据没有问题！这个方案必须让前端知道，并让前端也可以操作。大家熟知的php remoting里有一个servicebrowser，这个东西就很好，它能罗列出所有PHP的接口，我们输入参数，它就返回结果，我们可以根据结果直接查看数据是否正确。——确定数据的正确性，对前端DEBUG非常重要，而一个BUG的解决，一般都是由前端人员入手并进行定位的。
→其实相对于前端和美术的合作，前端与后端的合作还是简单清晰的，前后端在开发的过程中，应该是非常独立的，后端开发完全可以先启动，把数据接口提前写好，等着与前端整合，而当整合过程发生问题时，又可以很快的界定是谁的问题。
★公司文化与产品定位
→前面谈了那么多，无论是策划、美术、前端还是后端，大家通力合作，共同奋斗的目标无非就是希望开发出来一个好产品，而开发出一个好产品的目标无非就是成就一个好公司，这就涉及到“产品定位”与“公司文化”的问题，公司文化和产品定位没做好，其它人再努力都是枉然。可正是这两个问题，从我们公司成立到现在一直困扰着我，我抓破脑袋苦思冥想，总结出我们公司的公司文化就是“老板说了算”，而我们的产品文化就是“与时俱进，不断重新定位”。下面我先谈公司文化再谈产品文化，因为产品文化是包含在公司文化中的。
→公司文化：一个公司的文化在很大程度上是由初创团队建立的，而初创团队一般分两种，一种是权利分散型，初创团队在各个领域都有领头人，虽然也有形式上的CEO，但产品、研发、市场相互干涉的并不多，领导层内部“三权分立，民主平等”，对外发言人则可以统一由CEO代劳。这种模式的优点是大家优势互补，让懂行的人完全负责相关领域，负责人成就感大，责任心强。缺点是，权利分散就要求领导层必须非常团结，配合默契，如果他们之间出现矛盾，对公司影响会很大。我们的竞争对手淘米网络就是这种模式，到目前为止，他们公司发展的还是最好的。另外一种模式就是“老板专政”模式，专政到什么程度，跟老板对权利的欲望有关。我们公司老板就专政到事无巨细的程度了，就连买一个几百块钱的路由器都要再三跟老板请示，美术、策划、开发所有的日程安排、人事任用都要由老板点头。“专政模式”在创业初期也未必就是坏事，因为创业初期，困难重重，大家又都有自己的想法，每个人的信心都比较脆弱，如果没有一个强势的人主掌大事，所有人容易形成一盘散沙的尴尬局面。专政模式下，公司文化其实就是老板的个人文化。专政的人一定要有专政的资本，有专政的能力，掌握着公司最大的权利，就必须承担最大的责任。如果公司成功了，就算你再说成功是大家的，最大的成功者还是你，但如果公司失败了，就算你找一千个理由推脱责任，最大的失败者也是你！在这种情况下，专政者要努力提高自己的全面素质，公司管理、产品、开发、策划、美术、市场都必须有所了解，你的任何一个错误的决定都会把公司推向深渊，并引起相关部门人员的不满。我们公司就是典型，老板以前是做销售的，对策划、开发和美术，甚至是互联网都没什么概念，做海底世界前连QQ都没用过！虽然他在资历和财力方面当之无愧，但其短板也是无法否认的事实。初创很长一段时间内，他都敢拍板说一个社区一个AS一个月搞定之类的话，而且还要非常强势的让你接受，并拿出执行方案。至于他为什么敢这么坚决的做出这个错误的决定，我也不明白。可能正是因为他也不知道到底需要多长时间才能开发出来，而我们又没有取得他的信任吧，所以他就只能尽量往少的时间说，等到我们没完成工作，大不了再延长时间而已。可这对我们这些开发者就造成很大困扰了，这种根本不可能达成的目标如何拿出执行方案呢？开发规划如何做呢？最后开发不出来谁承担责任呢？于是一个怪圈形成了：老板不信任开发→制定不合理的开发目标→制定不合理的开发规划→开发规划没完成或者大打折扣→老板认为开发者能力不行更不信任开发→老板要求开发者提升自身能力满足他的要求→开发者依旧满足不了老板→老板在工作能力和员工素质上全面怀疑开着者→制定更加不合理的开发目标甚至是惩罚制度→项目更加完不成……额，这真是一个装满了苦水，倒又倒不出的杯具！当然，只要不是傻子，在这个悲剧的循环过程中，不管是老板还是开发者都会变得越来越“聪明”，老板一天天成熟了，程序员一天天世故了。只是曾经浪费的时间，错过的时机不再有，曾经不合理制度下积累的问题，明天需要继续补救！如果上天能给大家一次重来的机会，我相信，老板会说：“下次我一定要在项目刚开始就找一个靠谱的，值得信任的CTO！”，而程序员会说：“我下次再也不会跟着不懂技术还自以为是，横加干涉的老板了！”
虽然“民主平等”和“高度专政”两种模式都有其优缺点，但最终玩的都是一个“人”字，相同项目，一个模式，不同的人玩出来的结果肯定不一样。同是专政模式，奥比岛就比海底世界成功。不过站在历史发展观上看两种模式的话，我个人更偏向于“民主平等”模式，这种模式下的公司领导层为了保证公司能长久健康发展，肯定会不得不想尽一切办法制定出平衡权利的法制规则，只要法制规则适应时代，领导层人事变动影响是可控的。而“专政模式”的专政者，为了保证其一手建立起来的商业帝国不至于在自己退位后轰然倒塌，肯定不得不想尽一切办法寻找接班人，帝国的命运系于接班人的选择。相对于“人治”，我觉得“法制”更靠谱。看到这里也许你又该搬出中国特色来反驳了，说什么中国的企业不合适。但纵观天下，历史的潮流是不可逆转的，中国作为历史发展的组成部分，脚步可以慢，但方向不会错。80后已经开始觉醒，90后会继续努力的。所以希望任何一个创业者在创业初期都认真的回答一个问题：你是只想做一个成功的企业家，还是想真正做一个成功的企业，让这个企业能长久发展，代代相传。一个成功的企业家的成功是个人的，而一个成功的企业的成功是大家的，是社会的！
→产品文化：产品文化包含于公司文化，“民主平等”的公司，产品的文化就是“管理层相同价值观”的文化，而“高度专政”的公司，产品文化就是“老板个人”的文化。不管是什么类型的公司，什么产品文化，这个文化一定要简明而清晰，要深入人心，最好能浓缩成简单的一个词或者句子，“妈妈放心，孩子喜欢”就代表着淘米网络的产品文化。这个口号从淘米成立不久就已经开始喊了，到现在没有变过。我相信他们的用户，他们用户的家长，他们公司从管理层到员工每一个人，就连他们的竞争对手都对他们公司的价值观，对他们的产品文化有一个清晰的认识。而我们公司呢？反观我们公司，在这方面做的非常差，公司从成立到现在产品定位一直在变，刚开始要做一个针对初高中生和女孩子的休闲社区，搞了几个月后，又发现企鹅，一股脑的投入到儿童这块儿蓝海市场，说要做一个中国版的企鹅俱乐部，再后来可能觉得儿童市场有点小，收费比较困难了，又想把产品目标用户群再提高一下，提高到初高中生也能玩，游戏复杂度也要随之提高，这样还没做多长时间，又看到人家淘米推出赛尔号这种PK游戏了，又觉得纯绿色游戏的可玩性不高，对用户尤其是男孩子的吸引力不够，又要在我们的游戏里也加入PK和打怪了。直到现在，公司里上上下下，除了老板之外，没几个人能弄清公司的产品定位是什么，我们的产品文化是什么！这种情况导致一个很严重的问题，就是策划在策划游戏的时候，没有核心价值观，也就更没什么游戏世界观了，最终导致游戏形散神也散！
游戏一直在改版，功能一直在开发，BUG一直都存在，性能一直上不去，目标用户群一直在改变，老用户一直在流失，我只能用一个词形容我的心情：痛心疾首！
★2010年：我的梦想扬帆起航
→从毕业就一直在酷噜，一直做FLASH WEB GAME，当时的想法很简单，就是想体验一下顶尖的FLASH应用开发。转眼即将三年了，回眸探望，几多感慨，但终究还是能淡然处之。毕竟大家都不容易，大家都在摸索，也都在摸索中前进和成长，公司现在其实已经比刚开始好多了。
→如今再打开4年前那篇《我的FLASH情结2006》，激扬的文字震撼我心。而现在的我，在海底世界的前端开发中已经找不到往日的激情，每日重复的机械劳动。而自己的理想，更是逐渐飘渺远去，一种温水煮青蛙的危机感油然而生。于是2010年，我向公司递交辞呈，结束我毕业后的第一份工作；再写一篇《我的FLASH情结2010》暂时结束FLASH WEB GAME开发。
→那么2010年，我要做什么呢？没错，我要开始做自己的项目了。我们公司的一位在商场上混迹多年的大股东在年会上语重心长的对我说：“火山啊，你现在自己做项目有两个最大的问题，一是你没在大公司呆过，对一些正规的公司流程不了解；二是你原始资本积累还严重不足，很难支撑项目长久下去。”其实我自己又何尝不明白呢，我知道自己这次单干也是九死一生，但我实在等不了了，7年的技术积累，3年的工作积累，为的就是今天，我也是奔三的人了，都讲男人30而立，马上要面对结婚生孩子，上有老下有小的艰难局面，我再不趁机把握最后这两年相对轻松自由的机会，以后会更难。我的梦想可能很天真，但我会做的很认真。
→其实冷静下来想想，也没什么好怕的，想当年我敢带着一千块钱闯上海，今天我就敢拿着几万块钱自己干，大不了折腾完了再到大公司打工深造呗。虽然我工作三年才积累了几万块钱这听上去有点寒，虽然我每个月最多只能给自己播出1000块钱的创业资本这听上去有点少，虽然我自己得把策划、开发、美术和运营全做了这听上去有点假，虽然现在我还天天穿着高中和从亲戚那里捡来的衣服这看上去有点苦，但这都是外人看我的观点，我自己是乐在其中，浑然不觉，哈哈。不管怎么样，2010年，我的梦想必须扬帆起航，不以成败论英雄，只为人生少留遗憾！
→寂寞火山：http://www.huoshan.org/#BoKe_143