【正文】 進(jìn)行任何的鼠標(biāo)動作、動畫、文本渲染，都會導(dǎo)致CPU嚴(yán)重飆升，甚至畫面很卡。而如果你的動畫非常復(fù)雜和精細(xì)，精細(xì)到只有AE等粒子特效軟件才能表達(dá)的話，建議還是直接從AE里導(dǎo)出位圖序列，在FLASH里弄成逐幀動畫，太過復(fù)雜的動畫絕對不能用FLASH直接做，不但很難做出想要的效果，而且復(fù)雜矢量圖的SWF文件體積也會大大超過位圖，有可能導(dǎo)致用戶因為SWF文件加載時間過長，失去等待的耐心，這時候我們情愿犧牲美術(shù)的工作量和工作流程，換回想要的效果，減小SWF文件體積。 可大部分時間，我們的游戲場景可能都非常炫，畫面復(fù)雜，色彩鮮艷。在這個時候，讓我們再次搬出那句老話：不管黑貓白貓，抓住老鼠的就是好貓。公司一開始的美術(shù)更精通FLASH一些，而且我們計劃的是要做“企鵝”，于是我們選用矢量圖?！劦郊軜?gòu)，我不得不說，那些所謂的完美架構(gòu)，能夠一次架構(gòu)好，永遠(yuǎn)不用改的說法只能是傳說，或者技術(shù)人員忽悠老板的說法，對于創(chuàng)業(yè)公司更是如此。這就好比我黨在經(jīng)歷了長征、抗戰(zhàn)和解放戰(zhàn)爭的原始積累后，在最終發(fā)動三大戰(zhàn)役攻打大城市時，指著毛澤東的鼻子說：“你以前那套只敢打農(nóng)村，打的過就打，打不過就跑的逃跑主義路線完全是錯誤的！”試想，如果黨內(nèi)空降領(lǐng)導(dǎo)都是這種態(tài)度的話，將會對我們黨和戰(zhàn)士們的積極性產(chǎn)生多大的打擊！這種情況其實(shí)在長征途中就發(fā)生過，差點(diǎn)就葬送了黨，好在遵義會議及時糾正了蘇聯(lián)空降回來的王明等人的左傾激進(jìn)主義，挽救了黨。我們公司就曾屢次吃類似的虧，公司在第一階段剛拿到天使投資，就想做第三階段的事了，結(jié)果做了很多，一件也沒做好，白白浪費(fèi)了很多時間和大好機(jī)遇。如果這些都做到了，當(dāng)老板再次開會談“上市”的問題時，每個人臉上將會笑容依舊，只不過初創(chuàng)階段的笑容是那種開玩笑試的玩世不恭，而現(xiàn)在則是對未來的美好憧憬。這個階段挖墻腳空降領(lǐng)導(dǎo)，希望他們能把公司制度正規(guī)化，希望他們拯救公司的做法可能適得其反！公司初創(chuàng)人員這時候應(yīng)該依舊是公司的頂梁柱！成熟階段（產(chǎn)品導(dǎo)向型階段）：如果有幸過了前兩個階段，到了這個階段的時候，公司應(yīng)該已經(jīng)實(shí)現(xiàn)了正向盈利，作為一個游戲公司，一旦靠自己實(shí)現(xiàn)盈利，相信各種投資機(jī)構(gòu)肯定會主動找上門，千萬美元的投資絕對不夸張，你將會為到底接受哪家的投資而煩惱?？傊@個階段要以人力發(fā)展為核心，盡最大的努力把必要的人手配備齊。這個階段就開始叫囂“市場主導(dǎo)產(chǎn)品”，“不看過程只看結(jié)果”等口號，完全是不務(wù)實(shí)的態(tài)度，市場上最熱門的產(chǎn)品你未必能開發(fā)出來，創(chuàng)業(yè)階段，前途未卜，你不看過程看什么？發(fā)展階段（人力導(dǎo)向型階段）：假設(shè)我們順利度過了第一階段，公司開始有現(xiàn)金流或者找到了天使投資，我們就開始布置進(jìn)一步的發(fā)展了，這個階段招人將是公司的一個要務(wù)，招有創(chuàng)業(yè)精神的人，更要招我們需要和缺少的人。產(chǎn)品出不來，只靠一個idea和產(chǎn)品策劃書就想找投資的時代早就一去不復(fù)返了?！瞬荒芴珢壅铱陀^理由，但也絕對不能為了避免“找理由”之嫌，而棄客觀現(xiàn)實(shí)于不顧，毛爺爺曾告誡我們要懂得“實(shí)事求是”?！魏斡羞^創(chuàng)業(yè)經(jīng)驗的技術(shù)團(tuán)隊和公司應(yīng)該都知道，教科書那套從成功公司抽象出來的模式在創(chuàng)業(yè)初期幾乎只能是神話一般的存在，相信沒有幾個公司能完全做到?！矣X得一個創(chuàng)業(yè)公司最現(xiàn)實(shí)的發(fā)展觀應(yīng)該是這樣的：初創(chuàng)階段（技術(shù)導(dǎo)向型階段）：這個階段要一切以“我們能做什么”為基礎(chǔ)，在財力、人力、經(jīng)驗都不足的情況下，找出我們的優(yōu)勢，“把我們所擅長的做到最好”是我們唯一的籌碼，畢竟初創(chuàng)人員能走到一起，必然是有一定共識，在某方面有優(yōu)勢的。以前我們公司只有AS，于是游戲server只能用FMS，現(xiàn)在應(yīng)該招一個C++ socket的人了；以前公司沒有網(wǎng)頁前端，網(wǎng)站都是原畫和PHP代勞的，現(xiàn)在該彌補(bǔ)了；以前整個游戲都是架構(gòu)師們設(shè)計并實(shí)現(xiàn)的，現(xiàn)在應(yīng)該招一兩個做模塊打下手的人了。必須注意的是，這個階段不適合空降部門領(lǐng)導(dǎo)，公司發(fā)展階段，只有初創(chuàng)人員陪公司一路走來，最明白公司的問題，以及各種問題的根源。人力、財力、物力都不再是問題，產(chǎn)品研發(fā)和運(yùn)營的經(jīng)驗也成熟了，這時候唯一要關(guān)注的就是市場，什么樣的產(chǎn)品更被市場和用戶接受，爭取開發(fā)出更多更好的產(chǎn)品?！鋵?shí)任何理論都是有前提的，牛頓定律也只是在低于光速的情況下才適用。其實(shí)當(dāng)時老板用來說服人的理論也都是正確的，只不過不適合公司的實(shí)際發(fā)展情況而已。而我們的公司，誰來挽救我們的公司呢！★FLASH WEB GAME的系統(tǒng)架構(gòu)→我在這里把一款FLASH WEB GAME的架構(gòu)分為三部分：系統(tǒng)架構(gòu)、前端架構(gòu)、后端架構(gòu)。創(chuàng)業(yè)公司初創(chuàng)時期更多的時候需要在游泳中學(xué)會游泳，因為大家都沒有經(jīng)驗，失敗是最好的教科書。可后來隨著公司產(chǎn)品定位的不斷改變，我們的架構(gòu)和解決方案也會不斷調(diào)整，當(dāng)達(dá)到一個臨界點(diǎn)時，修改的代價已經(jīng)超過重新開發(fā)，我們就不得不對架構(gòu)進(jìn)行“重構(gòu)”了！這時候聰明的老板應(yīng)該支持程序員們的意見，充分調(diào)動他們的積極性盡快改完，全公司應(yīng)全力配合，盡快度過難關(guān)。不過經(jīng)過這幾年的摸索，還是有一些規(guī)律可循的： 1，美術(shù)：如果游戲畫面簡單，色彩構(gòu)成相對單一，場景內(nèi)總體元件能控制在100個以下，則非常適合直接使用矢量圖，畫面各組成部分盡量拆分為能重用的獨(dú)立元件。使用矢量圖的話，一方面不容易畫出想要的效果和精細(xì)度，這時候使用矢量圖反而增加了美術(shù)的工作量和難度；另一方面，使用矢量圖還有可能導(dǎo)致客戶端CPU嚴(yán)重飆升，超出普通客戶端電腦的承受范圍。還有一點(diǎn)要提醒的，時間軸動畫不可見時，程序一定要記得將其stop掉，不像程序動畫，時間軸動畫不可見時，F(xiàn)P內(nèi)部其實(shí)依舊在重繪，對CPU還是有影響的。要解決這個問題，本質(zhì)的也是唯一的方案就是減少元件數(shù)量，要想盡一切辦法降到200以下。因為這時候你是團(tuán)隊唯一可以依靠的人，如果這個問題解決不了，雖然大家都有責(zé)任，但前端毫無疑問是罪魁禍?zhǔn)祝? 極端情況下的極端解決方案：如果游戲策劃的非?？?，一個子彈爆炸效果就需要幾十個元件支撐，畫面上同時又需要幾十個坦克混戰(zhàn)，這時候常規(guī)的解決方案是根本達(dá)不到的，但不是說就一定無法做了，你可以利用強(qiáng)大的BitmapData類把每幀要顯示的游戲畫面完全計算好并且在內(nèi)存中繪制，然后以一張圖的方式渲染給用戶，這時候用戶玩你的游戲仿佛就像在看逐幀的動畫，此時FP占用的CPU大部分都是計算耗用的，而不是渲染耗用的。首先，大量的交互界面意味著需要用鼠標(biāo)點(diǎn)擊，試想在一個逐幀動畫中，每幀都要響應(yīng)鼠標(biāo)是什么概念？所以UI部分首先排除了；然后是大量的即時數(shù)據(jù)交互，每當(dāng)一個異步的請求得到響應(yīng)，畫面就需要做出相應(yīng)的改變，這將對本來還可能比較工整的內(nèi)部繪制算法制造非常大的麻煩，難度太高！基本上也不可行；最后是很多FLASH WEB GAME的畫面重用性并不是很高，比如像我們游戲的每個場景都是美術(shù)專門畫的，而不是用地圖編輯器編輯的，這就意味著你無法完全用程序拼出一個場景來；綜上我覺得一個款FLASH WEB GAME基本不可能完全使用copyPixels完成，最多是部分實(shí)現(xiàn)，比如我上面說的墻面和地板。JS的前端地位其實(shí)比AS要老，很多人的JS經(jīng)過這么長時間的磨練，功力深厚，做一個策略類甚至簡單的MMORPG都沒問題。每種技術(shù)都有其優(yōu)劣勢，比如shockwave在圖形渲染方面比flash強(qiáng)了千百倍啊千百倍，因為它可以完全調(diào)用顯卡，我在網(wǎng)頁上玩過一個基于shockwave的CS，流暢度和操作感完全不亞于桌面版的CS，還有國外的哈寶以及國內(nèi)的娜娜米米都是基于shockwave的。 3，后端：后端不是我的強(qiáng)項，我就不多說了，我只根據(jù)我們公司的經(jīng)驗談?wù)勑牡?。前端架?gòu)出現(xiàn)問題，會嚴(yán)重拖垮開發(fā)周期，而后端架構(gòu)一旦出現(xiàn)問題，對公司將是致命性打擊。切記這只是為解燃眉之急的下下策，長久不了，公司要想辦法盡快找到一個合適的人，在合適的時機(jī)重構(gòu)。這種模式非常適合人手不夠，制度不健全，而且追求效率的初創(chuàng)公司。主架構(gòu)同時負(fù)責(zé)FMS的sever端；主UI同時負(fù)責(zé)前端人員管理和文件管理；小游戲人員以平均每月兩個單機(jī)或者聯(lián)機(jī)游戲的速度循環(huán)不停開發(fā)，是相對最獨(dú)立的一部分；而兩個模塊程序員，負(fù)責(zé)每周發(fā)布的新場景和新模塊功能，他們的工作量其實(shí)蠻大的。而這些工作在項目啟動之初都是非常重要的，直接影響到項目中后期的開發(fā)和維護(hù)效率。但有一點(diǎn)至關(guān)重要：你必須能完全把握你的架構(gòu)和你使用的框架，并能跟你的前端同事解釋清楚。這樣就把MVC中的V從物理層面上完全獨(dú)立了。這種熟悉絕對不是對MVC的直譯：模型、視圖、控制器，而是要真正理解為什么要把程序劃分成這幾部分，在劃分主程序模塊時，要時刻能站在MVC的角度考慮問題，而當(dāng)面對一段實(shí)際的代碼時，能快速準(zhǔn)確的判斷，這段代碼應(yīng)該放在MVC中的哪部分。 1，模型部分在實(shí)際開發(fā)中除了存儲數(shù)據(jù)，還有其他作用么？是的，其實(shí)它的實(shí)際職責(zé)非常多。但絕對不能在Proxy中直接調(diào)用Mediator，這是為了保證數(shù)據(jù)層的獨(dú)立性、可移植性和重用性，也簡化了你的架構(gòu)思想。在pureMVC框架中，各部分通訊是用Notification消息，Proxy可以給Command和Mediator發(fā)消息，Command可以給Command和Mediator發(fā)消息，Mediator可以給Command和Mediator發(fā)消息，怎么樣？你現(xiàn)在是不是點(diǎn)暈了，這是正常的，其實(shí)我也有點(diǎn)暈！當(dāng)你代碼寫到一定規(guī)模后，你會更暈。這樣不僅使你的架構(gòu)更加清晰，而且也更符合MVC思想，Command類的大量存在還使你架構(gòu)的業(yè)務(wù)邏輯具有了更好的封裝性和擴(kuò)展性，可謂是一箭三雕，何樂而不為？唯一的負(fù)面影響可能是你需要創(chuàng)建和維護(hù)更多的Command類文件，但相對于優(yōu)勢而言，這點(diǎn)影響不算啥。OK，終于到pureMVC了。持反對意見的人，大多集中在“性能”和“團(tuán)隊協(xié)作”方面，他們認(rèn)為一個單例持有過多引用會帶來性能問題，而且生怕在團(tuán)隊協(xié)作中自己的單例類被人無意修改，引發(fā)離奇的BUG。反正單例模式的問題到底是什么，我到現(xiàn)在也沒完全搞懂，主要是我們的項目沒碰到過此類問題，希望碰到過的朋友能再仔細(xì)跟火山說說，我也好弄清楚問題到底出在哪里了，自己以后可以更好的避免此類問題發(fā)生。一般情況下，核心模塊按照游戲啟動順序包括：一個殼子SWF → 配置文件包 → 登錄注冊SWF → 主程序SWF → 主UI的SWF → 公共素材包?！芭渲梦募保汉诵哪K版本號啊，全局文字說明啊，service接口定義啊，各個核心模塊需要的配置信息啊什么的，一般是一些XML文件。“公共素材包”：公共素材包是一個游戲不可缺少，但也不能過分依賴的東西。不錯，在我看來，對SWF加載流程的分解和控制，對異步程序的掌控正是衡量一個AS程序員是否經(jīng)驗豐富，是否足夠老道的重要指標(biāo)，很多從其它語言轉(zhuǎn)到AS并有多年編程經(jīng)驗的朋友，架構(gòu)方面可能和AS程序員差不多，甚至比很多自學(xué)成才的AS程序員做的更好，但這方面往往不如長期與CPU和SWF體積搏斗的老牌AS程序員。還有前面提到過的那位用了pureMVC后項目編譯一下要十幾分鐘的朋友，估計就是把所有東西都弄到一個SWF里的做法。但主UI又不得不算是主程序的組成部分，因為它不像其他模塊，基本上只需要調(diào)用主程序的接口就行了，本身并不需要對主程序提供接口。策略類非常適合用FLEX；MMORPG這類標(biāo)準(zhǔn)網(wǎng)游，非常適合用ASWING；而像我們海底世界這類游戲界面非?？鋸垼瑳]什么標(biāo)準(zhǔn)規(guī)則，又不是太復(fù)雜的界面，還是適合自己開發(fā)。缺點(diǎn)是，當(dāng)UI膨脹到一定規(guī)模時，可能會需要你有一臺配置比較好的電腦——哎，說到這里我就傷心啊，我那臺玩魔獸效果全關(guān)還卡的電腦，一直陪伴我的整個UI開發(fā)歷程。而且這種代理模式可以實(shí)現(xiàn)一個CLASS代理不同的元件，當(dāng)界面只是需要修改外觀，不需要修改功能時，非常方便。這跟FLEX的皮膚更換機(jī)制有異曲同工之妙，只不過它