【正文】 在運行時，當啟動程序加載完UI代碼的SWF和皮膚的SWF后，動態(tài)指定的。→談完主程序和主UI，最后再簡單談一下小游戲、場景和模塊。架構寫的再好，最終模塊都做的很糟糕，對用戶來說沒有任何價值！所以，一個老道的，有責任心的，能夠快速開發(fā)出優(yōu)良用戶體驗的AS模塊程序員，完全有理由拿高薪，因為他們能做到的，一些所謂的純架構師未必做得到！★前端與美術的配合→老閃客們應該都知道，F(xiàn)LASH這款軟件在歷史很長一段時間內都是用來做動畫的，閃客和美術在這段時間內本就是同根生。模塊程序員也會都有以自己英文名命名的文件夾，他們會把美術的純FLA素材拷貝到自己的文件夾下，并根據(jù)模塊進行子分類，然后寫代碼并發(fā)布SWF，至于SWF文件如何管理，我會在下一節(jié)中討論。 3，F(xiàn)LA內元件的管理：這個問題相信很多AS程序員都碰到過，也都為此頭痛過。 4，F(xiàn)P的性能問題對美術的影響：談到這個問題，我就想起了一個讓我抽搐已久的情況。是的，“選擇和取舍”永遠都是人生最艱難的話題：手心手背都是肉，削掉哪邊呢？老婆孩子都掉海里了，救誰呢？在這樣的情況下，我覺得一個負責的前端人員，反而不應該僅僅簡單的扔給美術一份死的文檔，告訴他們應該怎么做，讓他們一直這么做就可以了。擔負起主導前端與美術合作的責任，用你的智慧征服他們，用你的誠意打動他們，讓美術與前端完美結合，讓你的產(chǎn)品第一時間抓住用戶！★前端與后端的配合→FLASH與后端通訊的手段多種多樣，網(wǎng)上相關教程太多了，這里不再例舉。安全性：記得我們的游戲同時在線超過3000的時候，就已經(jīng)有人開始攻擊我們的后端了，篡改了很多人的個人資料。所以正確的做法應該是：游戲開始的時候只告知后端游戲ID→后端標識ID對應的游戲已經(jīng)開始并記錄開始時間→用戶每次獲得一個分數(shù)時，前端傳回來的不是分數(shù)，而是一個動作ID,后端根據(jù)動作ID給用戶加分→游戲結束時，前端告知后端游戲已經(jīng)結束→后端得知游戲結束，記錄結束時間，計算時間差，根據(jù)時間差和最后得分是否符合標準做出相應處理，如果符合標準就把最后得分入庫，并返回前端顯示給用戶，如果不符合標準，就啟動作弊處理系統(tǒng)。對于我們前端來說，一個功能多占了幾K內存，SWF文件大了幾K根本不是什么問題，可對后端來說就是很嚴重的問題了，一個人大幾K，上千人就是幾M了?！_定數(shù)據(jù)的正確性，對前端DEBUG非常重要，而一個BUG的解決，一般都是由前端人員入手并進行定位的。我們的競爭對手淘米網(wǎng)絡就是這種模式，到目前為止，他們公司發(fā)展的還是最好的。初創(chuàng)很長一段時間內，他都敢拍板說一個社區(qū)一個AS一個月搞定之類的話，而且還要非常強勢的讓你接受，并拿出執(zhí)行方案。相對于“人治”，我覺得“法制”更靠譜。我相信他們的用戶，他們用戶的家長，他們公司從管理層到員工每一個人，就連他們的競爭對手都對他們公司的價值觀，對他們的產(chǎn)品文化有一個清晰的認識。不管是什么類型的公司，什么產(chǎn)品文化，這個文化一定要簡明而清晰，要深入人心，最好能濃縮成簡單的一個詞或者句子，“媽媽放心，孩子喜歡”就代表著淘米網(wǎng)絡的產(chǎn)品文化。不過站在歷史發(fā)展觀上看兩種模式的話，我個人更偏向于“民主平等”模式，這種模式下的公司領導層為了保證公司能長久健康發(fā)展，肯定會不得不想盡一切辦法制定出平衡權利的法制規(guī)則，只要法制規(guī)則適應時代，領導層人事變動影響是可控的。如果公司成功了，就算你再說成功是大家的，最大的成功者還是你，但如果公司失敗了，就算你找一千個理由推脫責任，最大的失敗者也是你！在這種情況下，專政者要努力提高自己的全面素質，公司管理、產(chǎn)品、開發(fā)、策劃、美術、市場都必須有所了解，你的任何一個錯誤的決定都會把公司推向深淵，并引起相關部門人員的不滿。這種模式的優(yōu)點是大家優(yōu)勢互補，讓懂行的人完全負責相關領域，負責人成就感大，責任心強。當一個BUG出現(xiàn)時，后端應當很快的用一種統(tǒng)一的方案證明數(shù)據(jù)沒有問題！這個方案必須讓前端知道，并讓前端也可以操作。因為這個沒分清的話，會影響到整個系統(tǒng)的清晰度，嚴重影響項目中后期的發(fā)展，為日后的重構增加難度和超多的工作量，我們還指望著在重構時加強安全性呢，到時候數(shù)據(jù)處理和業(yè)務邏輯還是要放后端！所以綜合考慮，該出手時就出手，能省的不浪費，不能省的不要摳！→前面一節(jié)談了前后端合作的難點。首先是游戲數(shù)據(jù)邏輯要盡量全做在后端，比如用戶在玩小游戲的時候，我們不要只是在用戶結束小游戲后，簡單的把數(shù)據(jù)傳回后端，后端記錄進數(shù)據(jù)庫完事，一旦攻擊者發(fā)現(xiàn)了你這個傳數(shù)據(jù)的后臺接口，完全可以避開SWF，做外掛直接呼叫你這個接口刷分，就算你驗證用戶也沒用，因為他可以先注冊一個合法的用戶，然后在外掛中登錄再刷分?！扒昂蠖撕侠韯澐诌壿嫛保@句話咋看上去貌似簡單，其實里面蘊含著諸多方面的考慮。但其實在高端的開發(fā)中，這些理論都是廢話，幫不上多大忙，因為地球人都知道了，我們碰到的問題肯定是超越這些技術點的高端問題！ 綜上可以看出，其實前端和美術的配合過程大部分時間是由前端主導的，這也是我前面一再強調前端要多懂一些美術知識的重要原因。內存、CPU、SWF體積、帶寬、效果、成本，這幾個要素往往是相互矛盾的，你對其中任何一點的過分優(yōu)化，都有可能導致其它點走向反面。畢竟，元件在舞臺上怎么命名，關聯(lián)什么類，層次怎么樣，怎么被程序利用，這些只有我們程序員最清楚，這部分工作由我們程序員完成完全是合理的，也是效率最高的，美術只要把我們需要的素材交給我們，并放到方便查找的地方就可以了。最大的不同就是，SWF文件最終的發(fā)布路徑是內網(wǎng)模擬測試環(huán)境，而不是本機。以我們公司為例，文件管理基本上都是由我負責的，我把需要多個美術和程序員共同維護的部分以項目名命名成一個文件夾，項目下如果需要還可以進行子分類，分類規(guī)則也是我制定。模塊和場景程序員在我們公司其實是非常累的，因為每周都需要發(fā)布新的版本，每次都很趕。盡管你可以從主程序那里獲得任何你想要的數(shù)據(jù)，盡管大部分時間你只是需要數(shù)據(jù)來顯示一下而已，但UI自己記住某些數(shù)據(jù)會大大方便自己寫代碼。這跟FLEX的皮膚更換機制有異曲同工之妙，只不過它的組件是要new出來的，布局是要代碼控制的，皮膚都是一個個CLASS，整體效果一般都要編譯后才能看出來；而我的組件是直接拖到舞臺上的，布局大部分是直接在FLASH IDE里手動布置好的，皮膚都是一個個命名過的MC，整體效果編譯之前基本上就能看出來。缺點是，當UI膨脹到一定規(guī)模時，可能會需要你有一臺配置比較好的電腦——哎，說到這里我就傷心啊，我那臺玩魔獸效果全關還卡的電腦，一直陪伴我的整個UI開發(fā)歷程。但主UI又不得不算是主程序的組成部分，因為它不像其他模塊，基本上只需要調用主程序的接口就行了，本身并不需要對主程序提供接口。不錯，在我看來，對SWF加載流程的分解和控制，對異步程序的掌控正是衡量一個AS程序員是否經(jīng)驗豐富，是否足夠老道的重要指標，很多從其它語言轉到AS并有多年編程經(jīng)驗的朋友，架構方面可能和AS程序員差不多，甚至比很多自學成才的AS程序員做的更好，但這方面往往不如長期與CPU和SWF體積搏斗的老牌AS程序員?！芭渲梦募保汉诵哪K版本號啊，全局文字說明啊，service接口定義啊，各個核心模塊需要的配置信息啊什么的，一般是一些XML文件。反正單例模式的問題到底是什么，我到現(xiàn)在也沒完全搞懂，主要是我們的項目沒碰到過此類問題，希望碰到過的朋友能再仔細跟火山說說，我也好弄清楚問題到底出在哪里了，自己以后可以更好的避免此類問題發(fā)生。OK，終于到pureMVC了。在pureMVC框架中，各部分通訊是用Notification消息，Proxy可以給Command和Mediator發(fā)消息，Command可以給Command和Mediator發(fā)消息，Mediator可以給Command和Mediator發(fā)消息，怎么樣？你現(xiàn)在是不是點暈了，這是正常的，其實我也有點暈！當你代碼寫到一定規(guī)模后，你會更暈。 1，模型部分在實際開發(fā)中除了存儲數(shù)據(jù)，還有其他作用么？是的，其實它的實際職責非常多。這樣就把MVC中的V從物理層面上完全獨立了。而這些工作在項目啟動之初都是非常重要的，直接影響到項目中后期的開發(fā)和維護效率。這種模式非常適合人手不夠，制度不健全，而且追求效率的初創(chuàng)公司。前端架構出現(xiàn)問題，會嚴重拖垮開發(fā)周期，而后端架構一旦出現(xiàn)問題，對公司將是致命性打擊。每種技術都有其優(yōu)劣勢，比如shockwave在圖形渲染方面比flash強了千百倍啊千百倍，因為它可以完全調用顯卡，我在網(wǎng)頁上玩過一個基于shockwave的CS，流暢度和操作感完全不亞于桌面版的CS，還有國外的哈寶以及國內的娜娜米米都是基于shockwave的。首先，大量的交互界面意味著需要用鼠標點擊，試想在一個逐幀動畫中，每幀都要響應鼠標是什么概念？所以UI部分首先排除了；然后是大量的即時數(shù)據(jù)交互，每當一個異步的請求得到響應，畫面就需要做出相應的改變，這將對本來還可能比較工整的內部繪制算法制造非常大的麻煩，難度太高！基本上也不可行；最后是很多FLASH WEB GAME的畫面重用性并不是很高，比如像我們游戲的每個場景都是美術專門畫的，而不是用地圖編輯器編輯的，這就意味著你無法完全用程序拼出一個場景來；綜上我覺得一個款FLASH WEB GAME基本不可能完全使用copyPixels完成，最多是部分實現(xiàn)，比如我上面說的墻面和地板。要解決這個問題，本質的也是唯一的方案就是減少元件數(shù)量，要想盡一切辦法降到200以下。使用矢量圖的話，一方面不容易畫出想要的效果和精細度，這時候使用矢量圖反而增加了美術的工作量和難度；另一方面，使用矢量圖還有可能導致客戶端CPU嚴重飆升，超出普通客戶端電腦的承受范圍。可后來隨著公司產(chǎn)品定位的不斷改變，我們的架構和解決方案也會不斷調整，當達到一個臨界點時，修改的代價已經(jīng)超過重新開發(fā)，我們就不得不對架構進行“重構”了！這時候聰明的老板應該支持程序員們的意見，充分調動他們的積極性盡快改完，全公司應全力配合，盡快度過難關。而我們的公司，誰來挽救我們的公司呢！★FLASH WEB GAME的系統(tǒng)架構→我在這里把一款FLASH WEB GAME的架構分為三部分：系統(tǒng)架構、前端架構、后端架構?！鋵嵢魏卫碚摱际怯星疤岬模ｎD定律也只是在低于光速的情況下才適用。必須注意的是，這個階段不適合空降部門領導，公司發(fā)展階段，只有初創(chuàng)人員陪公司一路走來，最明白公司的問題，以及各種問題的根源?！矣X得一個創(chuàng)業(yè)公司最現(xiàn)實的發(fā)展觀應該是這樣的：初創(chuàng)階段（技術導向型階段）：這個階段要一切以“我們能做什么”為基礎，在財力、人力、經(jīng)驗都不足的情況下，找出我們的優(yōu)勢，“把我們所擅長的做到最好”是我們唯一的籌碼，畢竟初創(chuàng)人員能走到一起，必然是有一定共識，在某方面有優(yōu)勢的?！瞬荒芴珢壅铱陀^理由，但也絕對不能為了避免“找理由”之嫌，而棄客觀現(xiàn)實于不顧，毛爺爺曾告誡我們要懂得“實事求是”。這個階段就開始叫囂“市場主導產(chǎn)品”，“不看過程只看結果”等口號，完全是不務實的態(tài)度，市場上最熱門的產(chǎn)品你未必能開發(fā)出來，創(chuàng)業(yè)階段，前途未卜，你不看過程看什么？發(fā)展階段（人力導向型階段）：假設我們順利度過了第一階段，公司開始有現(xiàn)金流或者找到了天使投資，我們就開始布置進一步的發(fā)展了，這個階段招人將是公司的一個要務，招有創(chuàng)業(yè)精神的人，更要招我們需要和缺少的人。這個階段挖墻腳空降領導，希望他們能把公司制度正規(guī)化，希望他們拯救公司的做法可能適得其反！公司初創(chuàng)人員這時候應該依舊是公司的頂梁柱！成熟階段（產(chǎn)品導向型階段）：如果有幸過了前兩個階段，到了這個階段的時候，公司應該已經(jīng)實現(xiàn)了正向盈利，作為一個游戲公司，一旦靠自己實現(xiàn)盈利，相信各種投資機構肯定會主動找上門