★目錄：
→我的FLASH WEB GAME開發歷程
→當今FLASH WEB GAME概述
→創業型游戲公司面臨的問題和困難
→FLASH WEB GAME的系統架構
→FLASH WEB GAME的前端架構與人事分工
→前端與美術的配合
→前端與后端的配合
→公司文化與產品定位
→2010年：我的夢想揚帆起航
======================================正文========================================
★我的FLASH WEB GAME開發歷程
→2007年的夏天，頂著炎炎烈日，我從學校直接跑到上海，開始了我的FLASH WEB GAME創業之旅。時至今日，轉眼快三年了。作為國內比較早的一批FLASH WEB GAME開發人員，今天我粗略的總結一下這兩年多的經驗和心得。講的不對的地方，請大家多多指教。
→2007年剛到上海的時候，初創團隊只有四個人，一個CTO,一個美術，一個后臺，一個前臺。手里的產品是一個已經在臺灣運行三年左右的FLASH社區，和國內的夢境非常像。這個產品還是不錯的，早在FLASH5就在開發出來了，FLASH6出來后，又用新版本的AS1重寫過。這個產品讓我又愛又恨，愛的是，在2007年的時候，國內除了夢境和1D真的很少有能趕上它的；恨的是，這個產品竟然沒有前端源碼！要想修改還要破解！玩過AS1，在時間軸、 MC和BTN上寫過代碼的朋友應該知道這是什么概念——1個字：囧！
→后來老板可能也覺得這樣改下去不是辦法，終于同意自己重寫一個。正好07年有條新聞很火爆：國外有個FLASH社區第一次利用FLASH技術取得了重大成功，以7億美金賣給迪斯尼，它就是“企鵝俱樂部”。老板看到了商機，我們決定做一個中國版的企鵝，于是“海底世界”應運而生了。而“海底世界”的創意，只不過是我們四個初創成員在閑聊時，我開玩笑隨便說的。
→海底世界正式開發到現在差不多正好兩年，期間我們碰到無數的問題和困難，不管是公司層面或技術層面，都是如此，但始終是堅持了下來。產品一天天完善，公司規模也一天天擴大。前端從最開始的兩個人，到現在5個人；后端從最開始的FMS+PHP到現在自己寫的socket服務器；公司規模也從最開始的4個人，到現在的50多個人。
★當今FLASH WEB GAME概述
→2007：含苞欲放！
2007年可以說是FLASH WEB GAME發展史上的分水嶺。2007年之前，我們眼里只有夢境，最多再加上曇花一現的抱抱城，那時候根本沒有“FLASH WEB GAME”這個概念，大家談的都是“FLASH社區”，“FLASH社區”這個詞在很長一段時間代表著FLASH應用領域的至高點。也許2007年已經有不少團隊開始研發FLASH的MMORPG了，我曾經有幸知道幾個，但很可惜，不少都胎死腹中，2007年國內在線上運營的FLASH WEB GAME基本上還是空白。但不管怎么說，我相信2007年是蓄勢待發的一年，肯定有很多類似我們公司的團隊，在默默的努力著。
→2008年：雨后春筍！
經過2007年的積累和準備，FLASH WEB GAME業界的戰斗終于在2008年打響，以“摩爾莊園”，“海底世界”為代表的“FLASH兒童虛擬社區”開始嶄露頭角；以“縱橫天下”為代表的 FLASH策略類游戲興起；以“昆侖”為代表的FLASH MMORPG讓“無端網游”的概念又炒了起來。還有各種基于FLASH的卡牌對戰類，聯機棋牌類，模擬經營類游戲等等，都如雨后春筍般破土而出。
→2009年：百花齊放！
2008年，國內雖然一下出了很多FLASH WEB GAME,但大家只要認真收集，總歸還是能數的過來，可到了2009年，幾乎每隔一個月，都會有幾個新的FLASH WEB GAME進入大家視野，而且他們越來越完善，功能越來越強大，盈利模式也開始成熟并多樣化。2007年每出一個FLASH WEB GAME,我都會為之興奮，并很有興趣的去研究它。而到了2009年末的時候，FLASH WEB GAME已經多到我連體驗的興趣都沒了，我已經徹底搞不清楚國內到底有多少個FLASH WEB GAME在運營。而伴隨著SNS行業的成熟，基于SNS的Social game進一步擴大和模糊著FLASH WEB GAME的概念。FLASH在游戲領域里的應用，在經歷了“社區”、“策略類”、“MMORPG”后，發展到今天創意無限，精彩紛呈的“Social game”，已經很難用一個詞，根據游戲類型概括所有的FLASH應用了。所以我覺得“FLASH WEB GAME”，也就是“FLASH網頁游戲”這個詞還是相對最恰當的，這也是我前面一直使用這個詞的原因。
→2010年 – 2011年：勝者為王！
就像春秋戰國時期，在經歷過“百家爭鳴”后，必然是“天下一統”。隨著游戲巨頭和互聯網大亨對網頁游戲的逐漸重視，以及政府的介入，還有最早領跑某些領域的創業公司不斷壯大，相信在不久的將來，網頁游戲領域也會出現幾個真正的領袖。別的領域不敢說，在我們兒童市場這塊兒，淘米公司已經逐漸呈現一家獨大的趨勢，不信的話，你可以隨便找幾個小學生問問，比如你父母輩親戚朋友的孩子，問他們是否知道摩爾莊園和賽爾號，是否充值了，相信你會得到非常驚訝的答案。所以，2010年后，任何小作坊型的創業團隊再想進入FLASH WEB GAME行業，都需要更加謹慎了！
★創業型游戲公司面臨的問題和困難
→在正式進入FLASH WEB GAME的技術探討前，我左思右想，還是覺得必須先說一下創業公司存在的問題和困難，為后面可能不太“正規”的做法找一個合適的“理由”。——人不能太愛找客觀理由，但也絕對不能為了避免“找理由”之嫌，而棄客觀現實于不顧，毛爺爺曾告誡我們要懂得“實事求是”。
→任何有過創業經驗的技術團隊和公司應該都知道，教科書那套從成功公司抽象出來的模式在創業初期幾乎只能是神話一般的存在，相信沒有幾個公司能完全做到。當然那種千萬級啟動資金，有成功背景的新公司除外。像我們公司，一開始就4個人，前臺和后臺各一個人，如果我們兩個都每天用一半時間考慮架構和寫文檔，我們的產品猴年馬月也上不了線了，況且我們寫了給誰看呢？在這個階段最最重要的目標就是盡快把產品做出來，上線運營出一定效果，給產品更加明確的方向，給團隊信心，然后盡最大努力去融資，以求下一階段的發展。產品出不來，只靠一個idea和產品策劃書就想找投資的時代早就一去不復返了。
→我覺得一個創業公司最現實的發展觀應該是這樣的：初創階段（技術導向型階段）：這個階段要一切以“我們能做什么”為基礎，在財力、人力、經驗都不足的情況下，找出我們的優勢，“把我們所擅長的做到最好”是我們唯一的籌碼，畢竟初創人員能走到一起，必然是有一定共識，在某方面有優勢的。而“我們能做什么”，在初創階段很大程度上就是指技術能做什么。沒錢、沒人還想把項目做的又快又好，絕對是癡心妄想。這個階段就開始叫囂“市場主導產品”，“不看過程只看結果”等口號，完全是不務實的態度，市場上最熱門的產品你未必能開發出來，創業階段，前途未卜，你不看過程看什么？發展階段（人力導向型階段）：假設我們順利度過了第一階段，公司開始有現金流或者找到了天使投資，我們就開始布置進一步的發展了，這個階段招人將是公司的一個要務，招有創業精神的人，更要招我們需要和缺少的人。以前我們公司只有AS，于是游戲server只能用 FMS，現在應該招一個C++ socket的人了；以前公司沒有網頁前端，網站都是原畫和PHP代勞的，現在該彌補了；以前整個游戲都是架構師們設計并實現的，現在應該招一兩個做模塊打下手的人了。這個階段雖然不適合大規模擴展人手，但在要害人力點上，也絕對不能摳門，我們公司就是吃虧在socket上，公司一直不肯招一個專業寫 server端的，一直讓前端和PHP代勞，結果游戲同時在線人數一超過5000就會出各種離奇問題，最恐怖是大家都不清楚問題到底在哪里，只能大眼瞪小眼，這個時候老板就會臭罵公司這幫技術都是飯桶，這么多人還搞不定這個問題。老板不懂技術，說出這樣的話無可厚非，但老板不聽勸，死活不愿意招要害人員，這就是他的錯了。總之這個階段要以人力發展為核心，盡最大的努力把必要的人手配備齊。必須注意的是，這個階段不適合空降部門領導，公司發展階段，只有初創人員陪公司一路走來，最明白公司的問題，以及各種問題的根源。而空降的領導容易只看到問題，不明白為什么會有問題，有時候難免說出“道理上很正確，但實際上不可行”的話，而老板為了配合新領導樹立威信，很多時候不得不偏向新領導，這樣以來很容易打擊到初創人員的積極性。更嚴重的是可能讓初創人員看不到前途，創業的激情淪為打工的無味。這個階段挖墻腳空降領導，希望他們能把公司制度正規化，希望他們拯救公司的做法可能適得其反！公司初創人員這時候應該依舊是公司的頂梁柱！成熟階段（產品導向型階段）：如果有幸過了前兩個階段，到了這個階段的時候，公司應該已經實現了正向盈利，作為一個游戲公司，一旦靠自己實現盈利，相信各種投資機構肯定會主動找上門，千萬美元的投資絕對不夸張，你將會為到底接受哪家的投資而煩惱。人力、財力、物力都不再是問題，產品研發和運營的經驗也成熟了，這時候唯一要關注的就是市場，什么樣的產品更被市場和用戶接受，爭取開發出更多更好的產品。產品要多樣化，公司要規模化，要形成自己的產品鏈和平臺，抓住更多的用戶，開拓更多的盈利模式。這時候才是產品主導公司，才是從大公司挖人的時代。如果這些都做到了，當老板再次開會談“上市”的問題時，每個人臉上將會笑容依舊，只不過初創階段的笑容是那種開玩笑試的玩世不恭，而現在則是對未來的美好憧憬。
→其實任何理論都是有前提的，牛頓定律也只是在低于光速的情況下才適用。公司發展的歷程中，老板和員工肯定都會有其信仰和觀念，都會用各種言辭來說服別人。但我相信沒有那種理論和言辭是永遠正確的，尤其是書上和大公司的那些所謂的成功經驗更是要警惕，因為它們身上有太多的光環，一場本來可能很有價值的討論，說不定就會被一句“盛大就是這么做的”給結束掉！所以在我們談任何理論的時候，不妨看看公司現在所處的階段，不妨時刻謹記毛爺爺的話，實事求是的看待自己。我們公司就曾屢次吃類似的虧，公司在第一階段剛拿到天使投資，就想做第三階段的事了，結果做了很多，一件也沒做好，白白浪費了很多時間和大好機遇。其實當時老板用來說服人的理論也都是正確的，只不過不適合公司的實際發展情況而已。還有一點要強調的是，不管公司現在處于第幾階段，堅決不能全盤否定其它階段的付出和努力以及很多不得不犯的“錯誤”。之所以強調這一點，也是我們公司曾踩過的雷區，當我們發展到第二階段的時候，公司就開始忙著空降領導，然后這些領導對我們之前的做法開始逐一否定，把做后臺的哥們兒說的一無是處，搞得團隊氣氛極不融洽，吵架紅臉的情況經常發生。這就好比我黨在經歷了長征、抗戰和解放戰爭的原始積累后，在最終發動三大戰役攻打大城市時，指著毛澤東的鼻子說：“你以前那套只敢打農村，打的過就打，打不過就跑的逃跑主義路線完全是錯誤的！”試想，如果黨內空降領導都是這種態度的話，將會對我們黨和戰士們的積極性產生多大的打擊！這種情況其實在長征途中就發生過，差點就葬送了黨，好在遵義會議及時糾正了蘇聯空降回來的王明等人的左傾激進主義，挽救了黨。而我們的公司，誰來挽救我們的公司呢！
★FLASH WEB GAME的系統架構
→我在這里把一款FLASH WEB GAME的架構分為三部分：系統架構、前端架構、后端架構。“系統架構”主要是指根據一款游戲的特點以及公司的實際情況選擇合適的技術實現方案，主要包括美術方案，前端方案和后端方案；“前端架構”主要指FLASH前端的主程序以及模塊劃分；“后端架構”主要指即時通訊部分和數據庫。這章先談系統架構。
→談到架構，我不得不說，那些所謂的完美架構，能夠一次架構好，永遠不用改的說法只能是傳說，或者技術人員忽悠老板的說法，對于創業公司更是如此。創業公司初創時期更多的時候需要在游泳中學會游泳，因為大家都沒有經驗，失敗是最好的教科書。就算大家知道應該怎么做，很多時候條件也不允許。比如我們在一開始就知道應該自己寫socket服務器，可就是沒socket的人才，于是不得不先使用FMS+PHP。公司一開始的美術更精通FLASH一些，而且我們計劃的是要做“企鵝”，于是我們選用矢量圖。可后來隨著公司產品定位的不斷改變，我們的架構和解決方案也會不斷調整，當達到一個臨界點時，修改的代價已經超過重新開發，我們就不得不對架構進行“重構”了！這時候聰明的老板應該支持程序員們的意見，充分調動他們的積極性盡快改完，全公司應全力配合，盡快度過難關。而不明事理的老板肯定會每天抱怨程序員無能，搭出一個垃圾架構不能滿足產品的持續快速發展，拖了產品和市場的后腿，給程序員造成很大的壓力，積極性沒了不說，在長期經驗積累之后本來可能是一次非常好的機會能做出一個相對完美的架構，滿足日后很長一段時間的需求變更，結果因為老板過分催促和施壓，又烙下了許多隱患，而這些欠下的債，總有一天要還的，這一天來臨之時，責任雖然可以完全由程序員承擔，但整個公司都要為之付出代價！所以關鍵時刻程序員該堅持還是要堅持自己的觀點，要盡量說服老板，程序員的社交能力在這個時候就凸顯作用了，你要明白你不但是在對自己負責，也是對公司負責！另外，真的很希望天下的老板們都能明白一個道理：能夠根據公司實際情況不斷調整的程序員才是最可愛最辛苦的程序員，而不是那些什么都不管，上去就提一大堆要求，必須都滿足他，他才愿意做的程序員。
→就算時至今日，FLASH WEB GAME在國內發展差不多三年了，但我敢說FLASH WEB GAME還是沒有什么行業標準的技術解決方案，尤其是前端，大家都是自成一派。在這個時候，讓我們再次搬出那句老話：不管黑貓白貓，抓住老鼠的就是好貓。不過經過這幾年的摸索，還是有一些規律可循的：
1，美術：如果游戲畫面簡單，色彩構成相對單一，場景內總體元件能控制在100個以下，則非常適合直接使用矢量圖，畫面各組成部分盡量拆分為能重用的獨立元件。這樣雖然犧牲了客戶端的CPU，但能因為重用最大化而大大減少美術的工作量，也方便他們日后應對需求變更，比如某些元件的尺寸變動。在畫面簡單，元件又少的情況下，利用遞歸全元件位圖緩存，拿少量內存還能換回大量CPU，找出這個平衡點，完全可以做出很好的用戶體驗。
可大部分時間，我們的游戲場景可能都非常炫，畫面復雜，色彩鮮艷。使用矢量圖的話，一方面不容易畫出想要的效果和精細度，這時候使用矢量圖反而增加了美術的工作量和難度；另一方面，使用矢量圖還有可能導致客戶端CPU嚴重飆升，超出普通客戶端電腦的承受范圍。這時候我們應當用位圖做游戲背景，重用性不大的元件要盡量合并到背景位圖里，減少位圖總個數，一些簡單的動畫如果非要用FLASH做成矢量動畫的話，也要盡量做成逐幀的，相信FLASH IDE玩的轉的美術同志們應該知道怎么把一個漸變動畫瞬間轉換成逐幀動畫。逐幀動畫雖然會導致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類和飛機類單機游戲都是這么做的。可這種模式適合用來做多人聯機并且有大量交互界面的FLASH WEB GAME么？我初步思考了一下，感覺是不可能的。首先，大量的交互界面意味著需要用鼠標點擊，試想在一個逐幀動畫中，每幀都要響應鼠標是什么概念？所以 UI部分首先排除了；然后是大量的即時數據交互，每當一個異步的請求得到響應，畫面就需要做出相應的改變，這將對本來還可能比較工整的內部繪制算法制造非常大的麻煩，難度太高！基本上也不可行；最后是很多FLASH WEB GAME的畫面重用性并不是很高，比如像我們游戲的每個場景都是美術專門畫的，而不是用地圖編輯器編輯的，這就意味著你無法完全用程序拼出一個場景來；綜上我覺得一個款FLASH WEB GAME基本不可能完全使用copyPixels完成，最多是部分實現，比如我上面說的墻面和地板。除非你的游戲策劃很NB，知道什么游戲能最大限度的利用copyPixels，而這樣的策劃估計本身肯定也是個前端程序員。
2，前端：從系統架構的角度上講，前端其實很簡單。現在WEB GAME主流的前端技術無非就是AS和JS。JS的前端地位其實比AS要老，很多人的JS經過這么長時間的磨練，功力深厚，做一個策略類甚至簡單的 MMORPG都沒問題。但現在用AS來做的話可能更簡單，更容易做出更酷的效果和更好的用戶體驗。所以最近兩三年，隨著基于面向對象的AS3逐漸完善和普及，FLASH WEB GAME似乎逐漸成了唯一的主流。
其實除了as和js外，還有很多前端技術可以供我們選擇，比如shockwave，java，還有那傳說中的flash killer：silverlight和html5等等。每種技術都有其優劣勢，比如shockwave在圖形渲染方面比flash強了千百倍啊千百倍，因為它可以完全調用顯卡，我在網頁上玩過一個基于shockwave的CS，流暢度和操作感完全不亞于桌面版的CS，還有國外的哈寶以及國內的娜娜米米都是基于shockwave的。而Java和silverlight也都有強大的背景，HTML5最近也是來勢洶洶。但不管怎么樣，2010年，FLASH 仍以其廣泛的覆蓋率、酷炫的效果和逐漸成熟的開發社區，以最高的綜合評分獨領WEB GAME業界風騷。所以任何公司和團隊，如果現在想做WEB GAME的話，如果實際情況允許，FLASH還是最好的選擇。
3，后端：后端不是我的強項，我就不多說了，我只根據我們公司的經驗談談心得。我同意前后端編程有很大區別，但絕不同意前后端誰簡單誰復雜之說。根據我這幾年的觀察，我發現，前端偏重的是效果，是用戶體驗和細節處理，有時候可能還要涉及一些圖形算法；而后端則偏重數據結構和數據處理，講究的是性能、安全和擴展性。前端工作量一般比后端大，而后端需要的工作經驗比前端多，想依靠一個只掌握了理論知識的大學畢業生就支撐一個公司的后端架構是嚴重不靠譜的！前端架構師必須是一個編程高手，十幾、幾十萬行代碼要在他的手里安排的井然有序，后端架構師則必須有過大型項目經驗，并且項目同時在線人數達到過一定規模。前端架構出現問題，會嚴重拖垮開發周期，而后端架構一旦出現問題，對公司將是致命性打擊。所以在公司里宣傳所謂前端重要還是后端重要的說法，是完全錯誤的，任何一款好的產品，必將是策劃、美術、前端、后端都達標的產品，缺失任何一塊兒，都成功不了！不同部門之間的比較和較真兒沒有任何正面影響！
至于后端的技術解決方案，我感覺如果是需要大量即時交互，并且對即時性要求很高的游戲，就必須使用socket服務器。而如果對即時性要求不高，完全可以用PHP，部分的即時交互可以用socket實現或者HTTP輪詢也可以。如果你的公司也像我們一樣剛開始沒有合適的C或者JAVA socket程序員，選擇fms和sfs也未嘗不可，這樣至少可以讓前端人員代勞，讓項目可以啟動。切記這只是為解燃眉之急的下下策，長久不了，公司要想辦法盡快找到一個合適的人，在合適的時機重構。
★FLASH WEB GAME的前端架構與人事分工
→前端的主程序架構和模塊劃分與人手和人事分工是緊密聯系在一起的，而這些很大程度上又是由項目本身決定的。縱觀現在國內絕大多數FLASH WEB GAME的規模和難度，我覺得前端AS人員大概需要2-7個之間，主程序有效代碼一般不會超過10W行。在這種情況下，人事分工應當以功能和模塊進行劃分，盡量避免多人維護同一份代碼，每個人各司其職，減少維護和協作的成本。這種模式非常適合人手不夠，制度不健全，而且追求效率的初創公司。
→根據各種游戲類型的不同，分工也應該不同。策略類更注重界面開發，分工上應該向UI偏重，MMORPG類注重主架構一些，而像我們的海底世界，是更新驅動類社區游戲，每周都要發布新內容，還需要大量的小游戲和場景功能支撐，所以需要更多的模塊和小游戲程序員。
→下面就以我們公司為例詳細談一下，我們公司最多的時候，一共5個AS程序員，分工是這樣的：1個主架構，1個主UI,1個小游戲，2個場景和模塊程序員。主架構同時負責FMS的sever端；主UI同時負責前端人員管理和文件管理；小游戲人員以平均每月兩個單機或者聯機游戲的速度循環不停開發，是相對最獨立的一部分；而兩個模塊程序員，負責每周發布的新場景和新模塊功能，他們的工作量其實蠻大的。
→先談前端主架構，前端程序主架構有兩個主要任務：1，要從架構高度合理劃分前端各模塊，提出可行的實現方案；2，從AS級別搭建程序架構（非文檔級別），制定前端編程規則和接口，規范程序各部分的職責劃分。這兩個任務其實包括很多具體工作，比如：游戲啟動流程制定，確定哪些SWF文件需要外部加載，那些功能可以從主程序剝離出去單獨實現，前端配置文件怎么處理，公共素材怎么處理，MVC三層怎么劃分，主程序框架的選定，主程序怎么和后臺通訊，主程序如何與模塊協作，哪些代碼應該放在主程序中，哪些代碼應該放在模塊里，主程序如何既能提供模塊所需要的一切功能和數據，同時又相對模塊自我保護等等等等。其實我談的還只是一些大的方面，具體到實現的級別，還有大量細節工作要做。而這些工作在項目啟動之初都是非常重要的，直接影響到項目中后期的開發和維護效率。
→上面提到的那些點，我不可能全講一遍，不然就不叫“淺談FLASH WEB GAME”了！我只挑兩個比較核心的內容跟大家略做探討，就是前端AS框架和模塊劃分的問題。先談前端框架：現在市面上流行很多前端框架，不管是針對 “FLASH”的，“FLEX”的還是“通用的”都有。我們是否一定需要框架，或者必須使用某個框架，這完全是仁者見仁智者見智的事，從最終的結果上講，爭論這個問題意義不大，我相信一個5W行左右的項目，任何有5年以上編程經驗的人，不管用什么作戰策略，最終都能攻下山頭，把項目做出來。但有一點至關重要：你必須能完全把握你的架構和你使用的框架，并能跟你的前端同事解釋清楚。那好壞架構的區別在哪里呢？區別在于好的架構在開發過程中會更輕松，你不用天天擔心的你代碼，不用每天不停的寫文檔，以防止自己忘了復雜的邏輯，你可以在任何時間開始寫代碼，在任何時間去玩會兒游戲然后回來接著寫；區別在于好的架構更符合業界標準，更容易被傳統和正統的程序員接受理解；區別在于你可以用很簡單的幾句話就把你的架構思想描述清楚，用幾個很簡單的文檔就能讓別人接手你的代碼，在人事變動和工作交接的時候讓自己更輕松；區別在于當你掌握了一種通用框架或者自己總結一套成熟的架構后，你幾乎可以套用以后的大部分項目，并不斷完善它，開發越來越輕松，速度卻越來越快！
→我們的項目，主程序使用的是pureMVC框架，而主UI部分是自己寫的。主程序和主UI相互獨立，可以單獨編譯測試。主程序是純代碼，用FLEX SDK編譯，而主UI則是界面和AS混寫并用FLASH編譯。這樣就把MVC中的V從物理層面上完全獨立了。pureMVC框架正如其名字，是一款“純粹”的MVC框架，在我看來，他只是幫我們實現了MVC的編程思想和套路，其它多余的功能一點沒有，這使它具有更高的通用性，也是它最可愛的地方。根據我們的經驗，pureMVC單核心版就已經完全可以應對主程序有效代碼在10W行以下的項目了。但在我跟很多沒有用過框架的前端朋友聊天中，發現他們對這些框架本身就有抵觸心理，或者有些對MVC模式都理解的不深刻，用起MVC框架又怎能得心應手？還有一些更過分的朋友把自己的問題也歸結到框架上，說什么用了pureMVC框架后，自己的項目編譯一下要十幾分鐘，我聽了之后哭笑不得，項目編譯慢一般是因為沒有合理劃分模塊導致主程序過大才導致的，跟框架有什么關系？如果因為大家的種種誤解和這些人的言論而導致一些新人錯過學習這么一款優秀的框架，我覺得實為憾事！
pureMVC既然是一種MVC框架，這就意味著你首先要熟悉MVC。這種熟悉絕對不是對MVC的直譯：模型、視圖、控制器，而是要真正理解為什么要把程序劃分成這幾部分，在劃分主程序模塊時，要時刻能站在MVC的角度考慮問題，而當面對一段實際的代碼時，能快速準確的判斷，這段代碼應該放在MVC 中的哪部分。《pureMVC最佳實踐》這份短短幾十頁的文檔中，可以說處處閃爍著MVC的思想火花，不但清楚地闡述了怎么使用框架，而且時刻從MVC的角度告訴我們應該把哪些邏輯放在哪些部分中，應該注意什么問題。這個文檔早已經有中文版，有興趣的朋友可以自己去看看，文中有的，我這里就不贅述了。我只結合自己的體驗談一些文中可能沒有涉及的，也是在真正開發中才會碰到的問題。
1，模型部分在實際開發中除了存儲數據，還有其他作用么？是的，其實它的實際職責非常多。它要給Command和Mediator提供接口，響應用戶操作，進行數據操作或者請求遠程數據服務，進行數據的序列化和反序列化，得到異步數據后可能還要檢查數據合法化。但不管怎么樣，它始終是在和數據打交道，同時也應該是你的主程序中唯一可以直接和數據打交道的管道，別的部分要想和數據有接觸，首先要問問它同意不同意。模型處理完數據會以 Notification的消息方式通知Command或者Mediator。但絕對不能在Proxy中直接調用Mediator，這是為了保證數據層的獨立性、可移植性和重用性，也簡化了你的架構思想。不過可移植性這個優勢，估計很多搞FLASH WEB GAME的朋友暫時都沒啥機會體驗，呵呵。
2，Command，Command，Command！連叫三聲“Command”，希望可以引起大家的注意。因為Command的使用，在很大程度上反映著你對pureMVC框架的理解，甚至是對MVC模式的理解深度。在pureMVC框架中，各部分通訊是用Notification消息，Proxy可以給Command和Mediator發消息，Command可以給Command和Mediator發消息，Mediator可以給 Command和Mediator發消息，怎么樣？你現在是不是點暈了，這是正常的，其實我也有點暈！當你代碼寫到一定規模后，你會更暈。其實 pureMVC框架這么設計本來是為了讓MVC各部分盡量脫耦，但這帶來一個負面情況就是消息發送與接收機制設計的太靈活了，靈活對小項目是好事，但對大項目來說，往往意味著混亂，甚至會導致災難。那怎么辦呢？只能靠我們的自覺性自我約束，簡化架構思想了。根據《pureMVC最佳實踐》中的建議，我的做法是這樣的，盡量使用Command，讓Command成為Mediator與Proxy之間通訊的唯一橋梁，Mediator和Proxy中發出的 Notification，接收者一定是某個Command，然后再由Command處理并將結果轉發給真正的消息接收者，Command就算僅僅起一個轉發作用，僅僅有不到10行代碼，也要創建一個Command類。這樣不僅使你的架構更加清晰，而且也更符合MVC思想，Command類的大量存在還使你架構的業務邏輯具有了更好的封裝性和擴展性，可謂是一箭三雕，何樂而不為？唯一的負面影響可能是你需要創建和維護更多的Command類文件，但相對于優勢而言，這點影響不算啥。
3，我知道現在可能還有一些朋友在用FLASH IDE寫代碼，這些朋友的執著讓人欽佩，但我想任何一個熟練使用過FLEX BUDIER、FD或者FDT的朋友，都絕不會再回頭使用FLASH IDE寫代碼了。——不對啊？不是談pureMVC的么？怎么扯到IDE上去了？這是因為我現在要討論的問題就和IDE有關，假如你現在用的還是 FLASH IDE的話，除了隨時寫文檔外，我真的很難想出一個很好的方案可以讓你在沒文檔支撐的情況下，輕松掌握和隨時維護幾萬行代碼。可如果你使用的是FDT,就可以在沒有文檔的情況下，利用“ctrl + r”和“ctrl + 鼠標左鍵”，以及全文件搜索等工具，瞬間搞清楚代碼之間的聯系和邏輯，找出要修改的地方。OK，終于到pureMVC了。如果你使用的是FDT,并且開始嘗試使用pureMVC框架，可在使用的過程中，你發現你在寫主程序時，還是不停的使用“ctrl + 鼠標左鍵”，而不是“ctrl + r”，這說明你必須重新審視你對pureMVC框架的理解了，請審查你的Mediator類，看里面是不是充斥著大量的public方法，如果你的對象之間依舊是通過public方法進行引用，而不是通過Notification通訊的，那你也沒有必要繼續使用pureMVC框架了。
4，單例模式影響到底有多大？pureMVC是一個完全依賴單例模式的框架。單例模式似乎在AS界一直有很大爭議，這樣的話，pureMVC肯定也會有相應的爭議了。持反對意見的人，大多集中在“性能”和“團隊協作”方面，他們認為一個單例持有過多引用會帶來性能問題，而且生怕在團隊協作中自己的單例類被人無意修改，引發離奇的BUG。性能方面，我之前也沒做過10W以上的項目，不敢妄言，但10W行以下的項目，絕對沒有問題，如果你兩三萬行的架構就開始碰到主架構性能問題，估計十有八九是自己的代碼寫的有問題；團隊協作方面，我覺得pureMVC的Façade模式是非常靈活好用的，大家可以略做討論，制定一個簡單的規則，比如模塊只能通過façade獲取數據和發送Notification，不能直接調用主程序其他CLASS，只要架構程序員不犯錯，模塊程序員甚至連犯錯的機會都沒有，如果他們有，還是你的架構思路有問題，請繼續審視自己的代碼。反正單例模式的問題到底是什么，我到現在也沒完全搞懂，主要是我們的項目沒碰到過此類問題，希望碰到過的朋友能再仔細跟火山說說，我也好弄清楚問題到底出在哪里了，自己以后可以更好的避免此類問題發生。
額，框架部分先談上面4點吧，趕快進入下一個話題，模塊劃分：模塊劃分主要包括“核心模塊劃分”和“子模塊劃分”。核心模塊的劃分思路是這樣的：它們是游戲啟動所必須的，相互之間是緊密聯系的，還要經常的被子模塊調用；而相對的，子模塊的劃分思路是：他們在游戲啟動過程中不是必須的，可以在游戲過程中再加載，子模塊相互之間基本上完全沒有聯系，一個子模塊的增加和刪除不會影響到任何其他子模塊，子模塊可能需要調用主程序的接口或者獲得主程序的數據，但主程序絕對不應該依賴某個子模塊。
明確了模塊劃分思路再具體看看哪些部分應該劃分為核心模塊，哪些部分應該劃分為子模塊。一般情況下，核心模塊按照游戲啟動順序包括：一個殼子SWF → 配置文件包 → 登錄注冊SWF → 主程序SWF → 主UI的SWF → 公共素材包。而子模塊相對來說簡單很多，比如具體的某個小游戲，某個場景，以及某個場景里的觸發功能等等。下面我對核心模塊逐一略做解釋。“一個殼子 SWF”：這是一個體積很小，但意義很大的SWF；它后面總是跟著隨機變量，確保每次用戶加載的都是最新的；它里面定義著一些需要經常更新而且每次更新都必須保證用戶也在第一時間就得到最新值的變量；它里面最好有一個簡單背景圖，保證用戶在超低網速的時候輸入游戲網址不至于長時間面對一片空白；它里面有安全策略的設定，是我們游戲和很多第三方平臺合作的基石；它里面還定義著主程序被加載進來之前的游戲啟動流程等等。“配置文件包”：核心模塊版本號啊，全局文字說明啊，service接口定義啊，各個核心模塊需要的配置信息啊什么的，一般是一些XML文件。“登錄注冊SWF”：這個簡單，在加載重量級的 SWF前，先加載登錄注冊SWF,可以保證用戶第一時間就能打開登錄注冊界面，而且可以有效節省服務器帶寬。“主程序SWF”：這個就是我前面費了好大勁講的主程序部分了。“主UI”：主程序和主UI為什么要分開兩個SWF，我前面已經提過了，后面還有說明，這里暫時不講。“公共素材包”：公共素材包是一個游戲不可缺少，但也不能過分依賴的東西。它包括一些全局的道具和效果，比如表情、技能特效、場景傳送門等等。公共素材包里面最好就是一些簡單的動畫，體積小功能簡單，嚴禁在公共素材包里添加上百K的東西，或者代碼上百行的小模塊，公共素材包建議500K以下。
看了上面的講解，你可以能覺得核心模塊分那么多，太麻煩了。不錯，在我看來，對SWF加載流程的分解和控制，對異步程序的掌控正是衡量一個AS程序員是否經驗豐富，是否足夠老道的重要指標，很多從其它語言轉到AS并有多年編程經驗的朋友，架構方面可能和AS程序員差不多，甚至比很多自學成才的AS程序員做的更好，但這方面往往不如長期與CPU和SWF體積搏斗的老牌AS程序員。核心模塊劃分的越合理，用戶體驗往往越好，后期編寫和維護代碼的效率會越高，但在前期會比較麻煩，而且對架構師的架構經驗和能力必須提出更高的要求。什么都不分，主程序、素材、核心模塊都弄在一個SWF里，用戶一開始必須先下載完這個SWF,或者弄了一堆核心模塊和超多公共素材，用戶一開始必須面對loading條不停的周而復始，必須等所有核心要素全部加載完成才能進行一些基本操作的做法，從架構角度上講，是最簡單的做法，因為不用過多考慮復雜的異步和SWF拆分問題，但從用戶體驗和長遠的開發維護上講是非常不利的。根據我們的經驗，用戶登錄前加載的所有資源體積應該控制在200K左右，而用戶進入游戲主場景前，加載的資源總數應該控制在1M左右。還有前面提到過的那位用了 pureMVC后項目編譯一下要十幾分鐘的朋友，估計就是把所有東西都弄到一個SWF里的做法。主程序隨便改動測試一下，就要十幾分鐘，牽一發而動全身，開發效率從何談起？根據我們的經驗，任何主程序、核心模塊還有子模塊的編譯，都必須在10秒以內，這才是合理的——我的機器是07年花了3000多買的戴爾品牌機。
→談完主架構，接著談主UI。主UI一般指主要的人機交互界面，這里的主UI區分于主架構中的mediator，當你看過pureMVC文檔后，你就知道了，mediator只不過起到一個真正的V和pureMVC框架之間的橋梁作用，pureMVC里的mediator其實并不實現什么功能，真正的功能都是在主UI里實現的。但主UI又不得不算是主程序的組成部分，因為它不像其他模塊，基本上只需要調用主程序的接口就行了，本身并不需要對主程序提供接口。而主UI作為用戶操作界面，必須大量的向主程序的mediator提供接口，或者發送events。所以主程序和主UI之間的配合必須非常密切才行。
不同的游戲類型，可以選擇的UI解決方案也不同。策略類非常適合用FLEX；MMORPG這類標準網游，非常適合用ASWING；而像我們海底世界這類游戲界面非常夸張，沒什么標準規則，又不是太復雜的界面，還是適合自己開發。相信任何有過游戲項目經驗的人都應該能理解，UI也是FLASH開發中的重頭戲，很多細節的處理非常麻煩，在項目早期具有很大的工作量。還是以我們的項目為例，我們的UI架構思路是這樣的：
1，所有的界面組件都是直接拖放在stage上的，其功能代碼大部分都是在發布時編譯的，基本上不用new的方式。這種方式的好處是方便編輯界面，從總體上直觀的把握所有的UI，減輕程序運行時的負擔，同時避免addToStage帶來的諸多問題。缺點是，當UI膨脹到一定規模時，可能會需要你有一臺配置比較好的電腦——哎，說到這里我就傷心啊，我那臺玩魔獸效果全關還卡的電腦，一直陪伴我的整個UI開發歷程。
2，UI的FLA層次結構是這樣的：第一層是文檔類或者與UI主類關聯的某個MC，我們選用的是MC的方式,因為MC的方式更靈活；第二層是這個 MC里的所有組件，這些組件大部分是根據功能劃分在一起的一組元件，比如你的個人面板，而這個組件本身也是個MC；第三層是組件里的所有元件或者共用組件，元件就是背景啊，按鈕啊什么的，而共用組件比如滾動條啊翻頁組件啊什么的；主要的就這三層，其實那些共用組件MC再往里面雙擊還可以劃分一層。對應 FLA的層次結構，AS的結構如下：文檔類或者主MC關聯的類是第一層，這個類里持有所有的界面元件的引用；第二層是這些界面元件對應的組件CLASS, 組件的功能都是在這里實現的，比如個人面板的MC將會對應一個MyPanel的CLASS,這個CLASS里實現MyPanel的所有功能。至于 CLASS和元件之間是怎么對應的，我用的是一種松耦合的代理模式，也就是將MyPanel對應的MC作為參數傳遞給MyPanel這個CLASS,而這個CLASS會有自己的私有變量記錄對應MC里需要進行操作的元件，具體到功能實現時，從代碼層面上看，就好像CLASS操作的都是自己的私有變量，而不是直接操作界面元件，這樣，當界面元件修改名字時，CLASS的改動很小。而且這種代理模式可以實現一個CLASS代理不同的元件，當界面只是需要修改外觀，不需要修改功能時，非常方便。那么這些CLASS是在哪里初始化并獲得它要代理的MC呢？正是在主MC對應的UI主類中，比如當獲得MyPanel對應的MC后，就會立刻public var myPanel:MyPanel = new MyPanel(myPanel_mc);當所有的組件注冊完成后，這個UI主類就持有了所有組件的引用，可以方便主程序調用；代碼的第三層其實就是共用組件，比較特殊的是，我的共用組件，比如滾動條，也是用代理模式寫的。
3，完全代理模式為我們創造了一種可能，就是把UI和UI對應的代碼分開編譯。這跟FLEX的皮膚更換機制有異曲同工之妙，只不過它的組件是要 new出來的，布局是要代碼控制的，皮膚都是一個個CLASS，整體效果一般都要編譯后才能看出來；而我的組件是直接拖到舞臺上的，布局大部分是直接在 FLASH IDE里手動布置好的，皮膚都是一個個命名過的MC，整體效果編譯之前基本上就能看出來。FLEX在更換皮膚的時候，CLASS名絕對不能變，而我的UI 在更換皮膚時，MC的名字和層次結構不能變。FLEX關聯皮膚是在編譯時完成的，而我的UI關聯皮膚是在運行時，當啟動程序加載完UI代碼的SWF和皮膚的SWF后，動態指定的。把皮膚和功能代碼分開編譯成兩個SWF有個好處，就是在實際開發過程中，我們會碰到有時候只需要修改代碼，而有時候只需要修改界面的情況，當然，就算你把代碼和界面一起編譯成一個SWF文件了，也完全可以對應這種情況，無非是編譯一次的時間稍微長了一點點。可當你面對這樣的情況呢：某次游戲版本更新出現狀況，需要你目前功能不變，但畫面必須退回到上一個版本。這時候你傻眼了吧？你開始對策劃們咆哮：“你們能不能想想好再讓我們做啊？”但你還是不得不重新打開已經做好的UI,把里面最新的界面再修改回老版本，同時還不敢把最新的刪了，因為下一個版本估計馬上又要替換回最新的畫面了。可如果你的皮膚和代碼是分開編譯成兩個SWF的，這種情況就簡單了，你可以讓運維從SVN上拉出上一個版本的皮膚SWF重新發布一下就好了，你所要做的只不過是動一下嘴皮。
4，最后談一下UI的數據層吧，UI是否需要數據層呢？答案是肯定的。盡管你可以從主程序那里獲得任何你想要的數據，盡管大部分時間你只是需要數據來顯示一下而已，但UI自己記住某些數據會大大方便自己寫代碼。UI的數據層不需要主程序那么復雜，每個組件有自己的數據變量，然后整個UI再有一個存放公共數據的地方就足夠了。
→談完主程序和主UI，最后再簡單談一下小游戲、場景和模塊。先說小游戲吧，小游戲是相對最獨立的一塊，可能只需要主程序提供用戶數據，并在游戲結束后將分數發送給主程序就行了。所以這部分從管理的角度上來講是相對輕松的，但這不意味著小游戲開發就簡單了，有時候，麻雀雖小五臟俱全，想開發出一個性能和用戶體驗俱佳的小游戲絕非朝夕之功，要是碰到一些算法復雜的小游戲，那就有得頭痛了。其實對于海底世界這類兒童社區游戲，小游戲應該走創意和簡單路線，搞得太復雜了，既不好開發，小孩子又不一定玩得來。
相對于小游戲，場景和模塊就和主程序甚至是主UI關系密切了，但不管怎么密切，大部分時候它們都是在所要數據，發送事件，或者觸發某個界面的顯示與隱藏。如果某個模塊的修改需要經常波及到主程序，或者很多模塊在做同一件事，重復寫著同一段代碼，這時候就必須重新審視架構，看是不是某些地方架構的不合理了，不合理的地方，只要時機允許，一定要盡快改掉，絕對不能放任自流，一塊兒小毒瘤最終可能引發癌癥。模塊和場景程序員在我們公司其實是非常累的，因為每周都需要發布新的版本，每次都很趕。在這種情況下，場景和模塊程序員的責任心就非常重要，他們隨便哪里隨意了一下，會直接導致糟糕的用戶體驗，因為大部分時間，用戶直接接觸的東西都是他們的作品。架構寫的再好，最終模塊都做的很糟糕，對用戶來說沒有任何價值！所以，一個老道的，有責任心的，能夠快速開發出優良用戶體驗的AS模塊程序員，完全有理由拿高薪，因為他們能做到的，一些所謂的純架構師未必做得到！
★前端與美術的配合
→老閃客們應該都知道，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年，我的夢想必須揚帆起航，不以成敗論英雄，只為人生少留遺憾！
→完