現(xiàn)代創(chuàng)業(yè)公司面臨的問題分析

51/51★創(chuàng)業(yè)型游戲公司面臨的問題和困難→在正式進(jìn)入WEB的技術(shù)探討前，我左思右想，依舊覺得必須先講一下創(chuàng)業(yè)公司存在的問題和困難，為后面可能不太“正規(guī)”的做法找一個(gè)合適的“理由”。——人不能太愛找客觀理由，但也絕對(duì)不能為了幸免“找理由”之嫌，而棄客觀現(xiàn)實(shí)于不顧，毛爺爺曾告誡我們要明白得“實(shí)事求是”?！魏斡羞^創(chuàng)業(yè)經(jīng)驗(yàn)的技術(shù)團(tuán)隊(duì)和公司應(yīng)該都明白，教科書那套從成功公司抽象出來(lái)的模式在創(chuàng)業(yè)初期幾乎只能是神話一般的存在，相信沒有幾個(gè)公司能完全做到。因此那種千萬(wàn)級(jí)啟動(dòng)資金，有成功背景的新公司除外。像我們公司，一開始就4個(gè)人，前臺(tái)和后臺(tái)各一個(gè)人，假如我們兩個(gè)都每天用一半時(shí)刻考慮架構(gòu)和寫文檔，我們的產(chǎn)品猴年馬月也上不了線了，況且我們寫了給誰(shuí)看呢？在那個(gè)時(shí)期最最重要的目標(biāo)確實(shí)是盡快把產(chǎn)品做出來(lái)，上線運(yùn)營(yíng)出一定效果，給產(chǎn)品更加明確的方向，給團(tuán)隊(duì)信心，然后盡最大努力去融資，以求下一時(shí)期的進(jìn)展。產(chǎn)品出不來(lái)，只靠一個(gè)idea和產(chǎn)品策劃書就想找投資的時(shí)代早就一去不復(fù)返了?！矣X得一個(gè)創(chuàng)業(yè)公司最現(xiàn)實(shí)的進(jìn)展觀應(yīng)該是如此的：初創(chuàng)時(shí)期（技術(shù)導(dǎo)向型時(shí)期）：那個(gè)時(shí)期要一切以“我們能做什么”為基礎(chǔ)，在財(cái)力、人力、經(jīng)驗(yàn)都不足的情況下，找出我們的優(yōu)勢(shì)，“把我們所擅長(zhǎng)的做到最好”是我們唯一的籌碼，怎么講初創(chuàng)人員能走到一起，必定是有一定共識(shí)，在某方面有優(yōu)勢(shì)的。而“我們能做什么”，在初創(chuàng)時(shí)期專門大程度上確實(shí)是指技術(shù)能做什么。沒鈔票、沒人還想把項(xiàng)目做的又快又好，絕對(duì)是癡心妄想。那個(gè)時(shí)期就開始叫囂“市場(chǎng)主導(dǎo)產(chǎn)品”，“不看過程只看結(jié)果”等口號(hào)，完全是不務(wù)實(shí)的態(tài)度，市場(chǎng)上最熱門的產(chǎn)品你未必能開發(fā)出來(lái)，創(chuàng)業(yè)時(shí)期，前途未卜，你不看過程看什么？進(jìn)展時(shí)期（人力導(dǎo)向型時(shí)期）：假設(shè)我們順利度過了第一時(shí)期，公司開始有現(xiàn)金流或者找到了天使投資，我們就開始布置進(jìn)一步的進(jìn)展了，那個(gè)時(shí)期招人將是公司的一個(gè)要?jiǎng)?wù)，招有創(chuàng)業(yè)精神的人，更要招我們需要和缺少的人。往常我們公司只有AS，因此游戲server只能用FMS，現(xiàn)在應(yīng)該招一個(gè)C++socket的人了；往常公司沒有網(wǎng)頁(yè)前端，網(wǎng)站差不多上原畫和PHP代勞的，現(xiàn)在該彌補(bǔ)了；往常整個(gè)游戲差不多上架構(gòu)師們?cè)O(shè)計(jì)并實(shí)現(xiàn)的，現(xiàn)在應(yīng)該招一兩個(gè)做模塊打下手的人了。那個(gè)時(shí)期盡管不適合大規(guī)模擴(kuò)展人手，但在要害人力點(diǎn)上，也絕對(duì)不能摳門，我們公司確實(shí)是吃虧在socket上，公司一直不肯招一個(gè)專業(yè)寫server端的，一直讓前端和PHP代勞，結(jié)果游戲同時(shí)在線人數(shù)一超過5000就會(huì)出各種離奇問題，最恐懼是大伙兒都不清晰問題到底在哪里，只能大眼瞪小眼，那個(gè)時(shí)候老總就會(huì)臭罵公司這幫技術(shù)差不多上飯桶，這么多人還搞不定那個(gè)問題。老總不明白技術(shù)，講出如此的話無(wú)可厚非，但老總不聽勸，死活不情愿招要害人員，這確實(shí)是他的錯(cuò)了?？傊莻€(gè)時(shí)期要以人力進(jìn)展為核心，盡最大的努力把必要的人手配備齊。必須注意的是，那個(gè)時(shí)期不適合空降部門領(lǐng)導(dǎo)，公司進(jìn)展時(shí)期，只有初創(chuàng)人員陪公司一路走來(lái)，最明白公司的問題，以及各種問題的根源。而空降的領(lǐng)導(dǎo)容易只看到問題，不明白什么緣故會(huì)有問題，有時(shí)候難免講出“道理上專門正確，但實(shí)際上不可行”的話，而老總為了配合新領(lǐng)導(dǎo)樹立威信，專門多時(shí)候不得不偏向新領(lǐng)導(dǎo)，如此以來(lái)專門容易打擊到初創(chuàng)人員的積極性。更嚴(yán)峻的是可能讓初創(chuàng)人員看不到前途，創(chuàng)業(yè)的激情淪為打工的無(wú)味。那個(gè)時(shí)期挖墻腳空降領(lǐng)導(dǎo)，希望他們能把公司制度正規(guī)化，希望他們挽救公司的做法可能適得其反！公司初創(chuàng)人員這時(shí)候應(yīng)該依舊是公司的頂梁柱！成熟時(shí)期（產(chǎn)品導(dǎo)向型時(shí)期）：假如有幸過了前兩個(gè)時(shí)期，到了那個(gè)時(shí)期的時(shí)候，公司應(yīng)該差不多實(shí)現(xiàn)了正向盈利，作為一個(gè)游戲公司，一旦靠自己實(shí)現(xiàn)盈利，相信各種投資機(jī)構(gòu)確信會(huì)主動(dòng)找上門，千萬(wàn)美元的投資絕對(duì)不夸張，你將會(huì)為到底同意哪家的投資而苦惱。人力、財(cái)力、物力都不再是問題，產(chǎn)品研發(fā)和運(yùn)營(yíng)的經(jīng)驗(yàn)也成熟了，這時(shí)候唯一要關(guān)注的確實(shí)是市場(chǎng)，什么樣的產(chǎn)品更被市場(chǎng)和用戶同意，爭(zhēng)取開發(fā)出更多更好的產(chǎn)品。產(chǎn)品要多樣化，公司要規(guī)?；纬勺约旱漠a(chǎn)品鏈和平臺(tái)，抓住更多的用戶，開拓更多的盈利模式。這時(shí)候才是產(chǎn)品主導(dǎo)公司，才是從大公司挖人的時(shí)代。假如這些都做到了，當(dāng)老總再次開會(huì)談“上市”的問題時(shí)，每個(gè)人臉上將會(huì)笑容依舊，只只是初創(chuàng)時(shí)期的笑容是那種開玩笑試的玩世不恭，而現(xiàn)在則是對(duì)以后的美好向往?！聦?shí)上任何理論差不多上有前提的，牛頓定律也只是在低于光速的情況下才適用。公司進(jìn)展的歷程中，老總和職員確信都會(huì)有其信仰和觀念，都會(huì)用各種言辭來(lái)講服不人。但我相信沒有那種理論和言辭是永久正確的，尤其是書上和大公司的那些所謂的成功經(jīng)驗(yàn)更是要警惕，因?yàn)樗鼈兩砩嫌刑嗟墓猸h(huán)，一場(chǎng)本來(lái)可能專門有價(jià)值的討論，講不定就會(huì)被一句“盛大確實(shí)是這么做的”給結(jié)束掉！因此在我們談任何理論的時(shí)候，不妨看看公司現(xiàn)在所處的時(shí)期，不妨?xí)r刻謹(jǐn)記毛爺爺?shù)脑?，?shí)事求是的看待自己。我們公司就曾屢次吃類似的虧，公司在第一時(shí)期剛拿到天使投資，就想做第三時(shí)期的事了，結(jié)果做了專門多，一件也沒做好，白白白費(fèi)了專門多時(shí)刻和大好機(jī)遇。事實(shí)上當(dāng)時(shí)老總用來(lái)講服人的理論也差不多上正確的，只只是不適合公司的實(shí)際進(jìn)展情況而已。還有一點(diǎn)要強(qiáng)調(diào)的是，不管公司現(xiàn)在處于第幾時(shí)期，堅(jiān)決不能全盤否定其它時(shí)期的付出和努力以及專門多不得不犯的“錯(cuò)誤”。之因此強(qiáng)調(diào)這一點(diǎn)，也是我們公司曾踩過的雷區(qū)，當(dāng)我們進(jìn)展到第二時(shí)期的時(shí)候，公司就開始忙著空降領(lǐng)導(dǎo)，然后這些領(lǐng)導(dǎo)對(duì)我們之前的做法開始逐一否定，把做后臺(tái)的哥們兒講的一無(wú)是處，搞得團(tuán)隊(duì)氣氛極不融洽，吵架紅臉的情況經(jīng)常發(fā)生。這就好比我黨在經(jīng)歷了長(zhǎng)征、抗戰(zhàn)和解放戰(zhàn)爭(zhēng)的原始積存后，在最終發(fā)動(dòng)三大戰(zhàn)役攻打大都市時(shí)，指著毛澤東的鼻子講：“你往常那套只敢打農(nóng)村，打的過就打，打只是就跑的逃跑主義路線完全是錯(cuò)誤的！”試想，假如黨內(nèi)空降領(lǐng)導(dǎo)差不多上這種態(tài)度的話，將會(huì)對(duì)我們黨和戰(zhàn)士們的積極性產(chǎn)生多大的打擊！這種情況事實(shí)上在長(zhǎng)征途中就發(fā)生過，差點(diǎn)就葬送了黨，好在遵義會(huì)議及時(shí)糾正了蘇聯(lián)空降回來(lái)的王明等人的左傾激進(jìn)主義，挽救了黨。而我們的公司，誰(shuí)來(lái)挽救我們的公司呢！★FLASHWEBGAME的系統(tǒng)架構(gòu)→我在那個(gè)地點(diǎn)把一款FLASHWEBGAME的架構(gòu)分為三部分：系統(tǒng)架構(gòu)、前端架構(gòu)、后端架構(gòu)?！跋到y(tǒng)架構(gòu)”要緊是指依照一款游戲的特點(diǎn)以及公司的實(shí)際情況選擇合適的技術(shù)實(shí)現(xiàn)方案，要緊包括美術(shù)方案，前端方案和后端方案；“前端架構(gòu)”要緊指FLASH前端的主程序以及模塊劃分；“后端架構(gòu)”要緊指即時(shí)通訊部分和數(shù)據(jù)庫(kù)。這章先談系統(tǒng)架構(gòu)?！劦郊軜?gòu)，我不得不講，那些所謂的完美架構(gòu)，能夠一次架構(gòu)好，永久不用改的講法只能是傳講，或者技術(shù)人員忽悠老總的講法，關(guān)于創(chuàng)業(yè)公司更是如此。創(chuàng)業(yè)公司初創(chuàng)時(shí)期更多的時(shí)候需要在游泳中學(xué)會(huì)游泳，因?yàn)榇蠡飪憾紱]有經(jīng)驗(yàn)，失敗是最好的教科書。就算大伙兒明白應(yīng)該如何做，專門多時(shí)候條件也不同意。比如我們?cè)谝婚_始就明白應(yīng)該自己寫socket服務(wù)器，可確實(shí)是沒socket的人才，因此不得不先使用FMS+PHP。公司一開始的美術(shù)更精通FLASH一些，而且我們打算的是要做“企鵝”，因此我們選用矢量圖?？珊髞?lái)隨著公司產(chǎn)品定位的不斷改變，我們的架構(gòu)和解決方案也會(huì)不斷調(diào)整，當(dāng)達(dá)到一個(gè)臨界點(diǎn)時(shí)，修改的代價(jià)差不多超過重新開發(fā)，我們就不得不對(duì)架構(gòu)進(jìn)行“重構(gòu)”了！這時(shí)候聰慧的老總應(yīng)該支持程序員們的意見，充分調(diào)動(dòng)他們的積極性盡快改完，全公司應(yīng)全力配合，盡快度過難關(guān)。而不明事理的老總確信會(huì)每天抱怨程序員無(wú)能，搭出一個(gè)垃圾架構(gòu)不能滿足產(chǎn)品的持續(xù)快速進(jìn)展，拖了產(chǎn)品和市場(chǎng)的后腿，給程序員造成專門大的壓力，積極性沒了不講，在長(zhǎng)期經(jīng)驗(yàn)積存之后本來(lái)可能是一次特不行的機(jī)會(huì)能做出一個(gè)相對(duì)完美的架構(gòu)，滿足日后專門長(zhǎng)一段時(shí)刻的需求變更，結(jié)果因?yàn)槔峡傔^分督促和施壓，又烙下了許多隱患，而這些欠下的債，總有一天要還的，這一天來(lái)臨之時(shí)，責(zé)任盡管能夠完全由程序員承擔(dān)，但整個(gè)公司都要為之付出代價(jià)！因此關(guān)鍵時(shí)刻程序員該堅(jiān)持依舊要堅(jiān)持自己的觀點(diǎn)，要盡量講服老總，程序員的社交能力在那個(gè)時(shí)候就凸顯作用了，你要明白你不然而在對(duì)自己負(fù)責(zé)，也是對(duì)公司負(fù)責(zé)！另外，確實(shí)專門希望天下的老總們都能明白一個(gè)道理：能夠依照公司實(shí)際情況不斷調(diào)整的程序員才是最可愛最辛苦的程序員，而不是那些什么都不管，上去就提一大堆要求，必須都滿足他，他才情愿做的程序員?！退銜r(shí)至今日，F(xiàn)LASHWEBGAME在國(guó)內(nèi)進(jìn)展差不多三年了，但我敢講FLASHWEBGAME依舊沒有什么行業(yè)標(biāo)準(zhǔn)的技術(shù)解決方案，尤其是前端，大伙兒差不多上自成一派。在那個(gè)時(shí)候，讓我們?cè)俅伟岢瞿蔷淅显挘翰还芎谪埌棕?，抓住老鼠的確實(shí)是好貓。只是通過這幾年的摸索，依舊有一些規(guī)律可循的：1，美術(shù)：假如游戲畫面簡(jiǎn)單，色彩構(gòu)成相對(duì)單一，場(chǎng)景內(nèi)總體元件能操縱在100個(gè)以下，則特不適合直接使用矢量圖，畫面各組成部分盡量拆分為能重用的獨(dú)立元件。如此盡管犧牲了客戶端的CPU，但能因?yàn)橹赜米畲蠡蟠鬁p少美術(shù)的工作量，也方便他們?nèi)蘸髴?yīng)對(duì)需求變更，比如某些元件的尺寸變動(dòng)。在畫面簡(jiǎn)單，元件又少的情況下，利用遞歸全元件位圖緩存，拿少量?jī)?nèi)存還能換回大量CPU，找出那個(gè)平衡點(diǎn)，完全能夠做出專門好的用戶體驗(yàn)?？纱蟛糠謺r(shí)刻，我們的游戲場(chǎng)景可能都特不炫，畫面復(fù)雜，色彩鮮艷。使用矢量圖的話，一方面不容易畫出想要的效果和精細(xì)度，這時(shí)候使用矢量圖反而增加了美術(shù)的工作量和難度；另一方面，使用矢量圖還有可能導(dǎo)致客戶端CPU嚴(yán)峻飆升，超出一般客戶端電腦的承受范圍。這時(shí)候我們應(yīng)當(dāng)用位圖做游戲背景，重用性不大的元件要盡量合并到背景位圖里，減少位圖總個(gè)數(shù)，一些簡(jiǎn)單的動(dòng)畫假如非要用FLASH做成矢量動(dòng)畫的話，也要盡量做成逐幀的，相信FLASHIDE玩的轉(zhuǎn)的美術(shù)同志們應(yīng)該明白如何把一個(gè)漸變動(dòng)畫瞬間轉(zhuǎn)換成逐幀動(dòng)畫。逐幀動(dòng)畫盡管會(huì)導(dǎo)致SWF文件體積增大，但相關(guān)于換回來(lái)的客戶端CPU來(lái)講依舊值得，這事實(shí)上是犧牲了一些服務(wù)器帶寬和用戶等待時(shí)刻，換回嚴(yán)峻的客戶端CPU超載。而假如你的動(dòng)畫特不復(fù)雜和精細(xì)，精細(xì)到只有AE等粒子特效軟件才能表達(dá)的話，建議依舊直接從AE里導(dǎo)出位圖序列，在FLASH里弄成逐幀動(dòng)畫，太過復(fù)雜的動(dòng)畫絕對(duì)不能用FLASH直接做，不但專門難做出想要的效果，而且復(fù)雜矢量圖的SWF文件體積也會(huì)大大超過位圖，有可能導(dǎo)致用戶因?yàn)镾WF文件加載時(shí)刻過長(zhǎng)，失去等待的耐心，這時(shí)候我們情愿犧牲美術(shù)的工作量和工作流程，換回想要的效果，減小SWF文件體積。還有一點(diǎn)要提醒的，時(shí)刻軸動(dòng)畫不可見時(shí)，程序一定要記得將其stop掉，不像程序動(dòng)畫，時(shí)刻軸動(dòng)畫不可見時(shí)，F(xiàn)P內(nèi)部事實(shí)上依舊在重繪，對(duì)CPU依舊有阻礙的。還有一種極端情況是場(chǎng)景元件超標(biāo)，比如整個(gè)游戲內(nèi)所有元素（包括各種MC、BTN、位圖以及程序創(chuàng)建的displayObject，總量超過500，這時(shí)候你會(huì)發(fā)覺，畫面靜止還好，但只要游戲上鼠標(biāo)隨便一晃，或者有幾個(gè)人物隨便走一下路，CPU都會(huì)狂飆，就算這500個(gè)元件差不多上位圖也無(wú)濟(jì)于事。事實(shí)上這是FLASH的一個(gè)瓶頸所在，是目前所有FLASH大型項(xiàng)目都有可能碰到的問題，也是我覺得阻礙FLASH進(jìn)一步進(jìn)展的要緊障礙之一。在一個(gè)元件超多的背景圖上進(jìn)行任何的鼠標(biāo)動(dòng)作、動(dòng)畫、文本渲染，都會(huì)導(dǎo)致CPU嚴(yán)峻飆升，甚至畫面專門卡。要解決那個(gè)問題，本質(zhì)的也是唯一的方案確實(shí)是減少元件數(shù)量，要想盡一切方法降到200以下。而這需要美術(shù)、前端和策劃通力合作才行，絕對(duì)不是前端程序員就能搞定的事。策劃要從產(chǎn)品的角度上看能不能簡(jiǎn)化目前場(chǎng)景同一時(shí)刻出現(xiàn)的元素，美術(shù)要把能合并成一張圖的元件在繪圖軟件中合并成一張位圖，前端AS程序要把不需要響應(yīng)鼠標(biāo)事件的元件的mouseEnable和mouseChildren都設(shè)置成false，一些能利用copyPixels合并的位圖就合并成一張，比如能夠平鋪創(chuàng)建的房間地板和墻面，要copyPixels成一張圖，而不是new出好幾百個(gè)元件。事實(shí)上元件超標(biāo)的情況是大多數(shù)沒有經(jīng)驗(yàn)的團(tuán)隊(duì)專門容易發(fā)生的問題，這時(shí)候前端程序員要起到領(lǐng)頭羊的作用，給大伙兒講明白道理，用事實(shí)讓大伙兒信服，組織大伙兒一起把情況做的更好，而不是一味的在那兒抱怨FP效率低。因?yàn)檫@時(shí)候你是團(tuán)隊(duì)唯一能夠依靠的人，假如那個(gè)問題解決不了，盡管大伙兒都有責(zé)任，但前端毫無(wú)疑問是罪魁禍?zhǔn)祝O端情況下的極端解決方案：假如游戲策劃的特不酷，一個(gè)子彈爆炸效果就需要幾十個(gè)元件支撐，畫面上同時(shí)又需要幾十個(gè)坦克混戰(zhàn)，這時(shí)候常規(guī)的解決方案是全然達(dá)不到的，但不是講就一定無(wú)法做了，你能夠利用強(qiáng)大的BitmapData類把每幀要顯示的游戲畫面完全計(jì)算好同時(shí)在內(nèi)存中繪制，然后以一張圖的方式渲染給用戶，這時(shí)候用戶玩你的游戲仿佛就像在看逐幀的動(dòng)畫，現(xiàn)在FP占用的CPU大部分差不多上計(jì)算耗用的，而不是渲染耗用的。事實(shí)上AS的執(zhí)行效率遠(yuǎn)遠(yuǎn)高于屏幕渲染，你把CPU的要緊負(fù)荷轉(zhuǎn)移給AS，反而能做更多更炫的情況。據(jù)我的初步研究，前段時(shí)刻名噪一時(shí)的FLASH版3D雷神，還有現(xiàn)在專門多國(guó)外效率高的“有點(diǎn)假”的TD類和飛機(jī)類單機(jī)游戲差不多上這么做的?？蛇@種模式適合用來(lái)做多人聯(lián)機(jī)同時(shí)有大量交互界面的FLASHWEBGAME么？我初步考慮了一下，感受是不可能的。首先，大量的交互界面意味著需要用鼠標(biāo)點(diǎn)擊，試想在一個(gè)逐幀動(dòng)畫中，每幀都要響應(yīng)鼠標(biāo)是什么概念？因此UI部分首先排除了；然后是大量的即時(shí)數(shù)據(jù)交互，每當(dāng)一個(gè)異步的請(qǐng)求得到響應(yīng)，畫面就需要做出相應(yīng)的改變，這將對(duì)本來(lái)還可能比較工整的內(nèi)部繪制算法制造特不大的苦惱，難度太高！差不多上也不可行；最后是專門多FLASHWEBGAME的畫面重用性并不是專門高，比如像我們游戲的每個(gè)場(chǎng)景差不多上美術(shù)專門畫的，而不是用地圖編輯器編輯的，這就意味著你無(wú)法完全用程序拼出一個(gè)場(chǎng)景來(lái)；綜上我覺得一個(gè)款FLASHWEBGAME差不多不可能完全使用copyPixels完成，最多是部分實(shí)現(xiàn)，比如我上面講的墻面和地板。除非你的游戲策劃專門NB，明白什么游戲能最大限度的利用copyPixels，而如此的策劃可能本身確信也是個(gè)前端程序員。2，前端：從系統(tǒng)架構(gòu)的角度上講，前端事實(shí)上專門簡(jiǎn)單。現(xiàn)在WEBGAME主流的前端技術(shù)無(wú)非確實(shí)是AS和JS。JS的前端地位事實(shí)上比AS要老，專門多人的JS通過這么長(zhǎng)時(shí)刻的磨練，功力深厚，做一個(gè)策略類甚至簡(jiǎn)單的MMORPG都沒問題。但現(xiàn)在用AS來(lái)做的話可能更簡(jiǎn)單，更容易做出更酷的效果和更好的用戶體驗(yàn)。因此最近兩三年，隨著基于面向?qū)ο蟮腁S3逐漸完善和普及，F(xiàn)LASHWEBGAME大概逐漸成了唯一的主流。事實(shí)上除了as和js外，還有專門多前端技術(shù)能夠供我們選擇，比如shockwave，java，還有那傳講中的flashkiller：silverlight和html5等等。每種技術(shù)都有其優(yōu)劣勢(shì)，比如shockwave在圖形渲染方面比f(wàn)lash強(qiáng)了千百倍啊千百倍，因?yàn)樗軌蛲耆{(diào)用顯卡，我在網(wǎng)頁(yè)上玩過一個(gè)基于shockwave的CS，流暢度和操作感完全不亞于桌面版的CS，還有國(guó)外的哈寶以及國(guó)內(nèi)的娜娜米米差不多上基于shockwave的。而Java和silverlight也都有強(qiáng)大的背景，HTML5最近也是來(lái)勢(shì)洶洶。但不管如何樣，2010年，F(xiàn)LASH仍以其廣泛的覆蓋率、酷炫的效果和逐漸成熟的開發(fā)社區(qū)，以最高的綜合評(píng)分獨(dú)領(lǐng)WEBGAME業(yè)界風(fēng)騷。因此任何公司和團(tuán)隊(duì)，假如現(xiàn)在想做WEBGAME的話，假如實(shí)際情況同意，F(xiàn)LASH依舊最好的選擇。3，后端：后端不是我的強(qiáng)項(xiàng)，我就不多講了，我只依照我們公司的經(jīng)驗(yàn)談?wù)勑牡?。我同意前后端編程有專門大區(qū)不，但絕不同意前后端誰(shuí)簡(jiǎn)單誰(shuí)復(fù)雜之講。依照我這幾年的觀看，我發(fā)覺，前端偏重的是效果，是用戶體驗(yàn)和細(xì)節(jié)處理，有時(shí)候可能還要涉及一些圖形算法；而后端則偏重?cái)?shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)處理，講究的是性能、安全和擴(kuò)展性。前端工作量一般比后端大，而后端需要的工作經(jīng)驗(yàn)比前端多，想依靠一個(gè)只掌握了理論知識(shí)的大學(xué)畢業(yè)生就支撐一個(gè)公司的后端架構(gòu)是嚴(yán)峻不靠譜的！前端架構(gòu)師必須是一個(gè)編程高手，十幾、幾十萬(wàn)行代碼要在他的手里安排的井然有序，后端架構(gòu)師則必須有過大型項(xiàng)目經(jīng)驗(yàn)，同時(shí)項(xiàng)目同時(shí)在線人數(shù)達(dá)到過一定規(guī)模。前端架構(gòu)出現(xiàn)問題，會(huì)嚴(yán)峻拖垮開發(fā)周期，而后端架構(gòu)一旦出現(xiàn)問題，對(duì)公司將是致命性打擊。因此在公司里宣傳所謂前端重要依舊后端重要的講法，是完全錯(cuò)誤的，任何一款好的產(chǎn)品，必將是策劃、美術(shù)、前端、后端都達(dá)標(biāo)的產(chǎn)品，缺失任何一塊兒，都成功不了！不同部門之間的比較和較真兒沒有任何正面阻礙！至于后端的技術(shù)解決方案，我感受假如是需要大量即時(shí)交互，同時(shí)對(duì)即時(shí)性要求專門高的游戲，就必須使用socket服務(wù)器。而假如對(duì)即時(shí)性要求不高，完全能夠用PHP，部分的即時(shí)交互能夠用socket實(shí)現(xiàn)或者HTTP輪詢也能夠。假如你的公司也像我們一樣剛開始沒有合適的C或者JAVAsocket程序員，選擇fms和sfs也未嘗不可，如此至少能夠讓前端人員代勞，讓項(xiàng)目能夠啟動(dòng)。切記這只是為解燃眉之急的下下策，長(zhǎng)久不了，公司要想方法盡快找到一個(gè)合適的人，在合適的時(shí)機(jī)重構(gòu)?！颋LASHWEBGAME的前端架構(gòu)與人事分工→前端的主程序架構(gòu)和模塊劃分與人手和人事分工是緊密聯(lián)系在一起的，而這些專門大程度上又是由項(xiàng)目本身決定的?？v觀現(xiàn)在國(guó)內(nèi)絕大多數(shù)FLASHWEBGAME的規(guī)模和難度，我覺得前端AS人員大概需要2-7個(gè)之間，主程序有效代碼一般可不能超過10W行。在這種情況下，人事分工應(yīng)當(dāng)以功能和模塊進(jìn)行劃分，盡量幸免多人維護(hù)同一份代碼，每個(gè)人各司其職，減少維護(hù)和協(xié)作的成本。這種模式特不適合人手不夠，制度不健全，而且追求效率的初創(chuàng)公司?！勒崭鞣N游戲類型的不同，分工也應(yīng)該不同。策略類更注重界面開發(fā)，分工上應(yīng)該向UI偏重，MMORPG類注重主架構(gòu)一些，而像我們的海底世界，是更新驅(qū)動(dòng)類社區(qū)游戲，每周都要公布新內(nèi)容，還需要大量的小游戲和場(chǎng)景功能支撐，因此需要更多的模塊和小游戲程序員?！旅婢鸵晕覀児緸槔敿?xì)談一下，我們公司最多的時(shí)候，一共5個(gè)AS程序員，分工是如此的：1個(gè)主架構(gòu)，1個(gè)主UI,1個(gè)小游戲，2個(gè)場(chǎng)景和模塊程序員。主架構(gòu)同時(shí)負(fù)責(zé)FMS的sever端；主UI同時(shí)負(fù)責(zé)前端人員治理和文件治理；小游戲人員以平均每月兩個(gè)單機(jī)或者聯(lián)機(jī)游戲的速度循環(huán)不停開發(fā)，是相對(duì)最獨(dú)立的一部分；而兩個(gè)模塊程序員，負(fù)責(zé)每周公布的新場(chǎng)景和新模塊功能，他們的工作量事實(shí)上蠻大的?！日勄岸酥骷軜?gòu)，前端程序主架構(gòu)有兩個(gè)要緊任務(wù)：1，要從架構(gòu)高度合理劃分前端各模塊，提出可行的實(shí)現(xiàn)方案；2，從AS級(jí)不搭建程序架構(gòu)（非文檔級(jí)不），制定前端編程規(guī)則和接口，規(guī)范程序各部分的職責(zé)劃分。這兩個(gè)任務(wù)事實(shí)上包括專門多具體工作，比如：游戲啟動(dòng)流程制定，確定哪些SWF文件需要外部加載，那些功能能夠從主程序剝離出去單獨(dú)實(shí)現(xiàn)，前端配置文件如何處理，公共素材如何處理，MVC三層如何劃分，主程序框架的選定，主程序如何和后臺(tái)通訊，主程序如何與模塊協(xié)作，哪些代碼應(yīng)該放在主程序中，哪些代碼應(yīng)該放在模塊里，主程序如何既能提供模塊所需要的一切功能和數(shù)據(jù)，同時(shí)又相對(duì)模塊自我愛護(hù)等等等等。事實(shí)上我談的還只是一些大的方面，具體到實(shí)現(xiàn)的級(jí)不，還有大量細(xì)節(jié)工作要做。而這些工作在項(xiàng)目啟動(dòng)之初差不多上特不重要的，直接阻礙到項(xiàng)目中后期的開發(fā)和維護(hù)效率?！厦嫣岬降哪切c(diǎn)，我不可能全講一遍，不然就不叫“淺談FLASHWEBGAME”了！我只挑兩個(gè)比較核心的內(nèi)容跟大伙兒略做探討，確實(shí)是前端AS框架和模塊劃分的問題。先談前端框架：現(xiàn)在市面上流行專門多前端框架，不管是針對(duì)“FLASH”的，“FLEX”的依舊“通用的”都有。我們是否一定需要框架，或者必須使用某個(gè)框架，這完全是仁者見仁智者見智的事，從最終的結(jié)果上講，爭(zhēng)論那個(gè)問題意義不大，我相信一個(gè)5W行左右的項(xiàng)目，任何有5年以上編程經(jīng)驗(yàn)的人，不管用什么作戰(zhàn)策略，最終都能攻下山頭，把項(xiàng)目做出來(lái)。但有一點(diǎn)至關(guān)重要：你必須能完全把握你的架構(gòu)和你使用的框架，并能跟你的前端同事解釋清晰。那好壞架構(gòu)的區(qū)不在哪里呢？區(qū)不在于好的架構(gòu)在開發(fā)過程中會(huì)更輕松，你不用天天擔(dān)心的你代碼，不用每天不停的寫文檔，以防止自己忘了復(fù)雜的邏輯，你能夠在任何時(shí)刻開始寫代碼，在任何時(shí)刻去玩會(huì)兒游戲然后回來(lái)接著寫；區(qū)不在于好的架構(gòu)更符合業(yè)界標(biāo)準(zhǔn)，更容易被傳統(tǒng)和正統(tǒng)的程序員同意理解；區(qū)不在于你能夠用專門簡(jiǎn)單的幾句話就把你的架構(gòu)思想描述清晰，用幾個(gè)專門簡(jiǎn)單的文檔就能讓不人接手你的代碼，在人事變動(dòng)和工作交接的時(shí)候讓自己更輕松；區(qū)不在于當(dāng)你掌握了一種通用框架或者自己總結(jié)一套成熟的架構(gòu)后，你幾乎能夠套用以后的大部分項(xiàng)目，并不斷完善它，開發(fā)越來(lái)越輕松，速度卻越來(lái)越快！→我們的項(xiàng)目，主程序使用的是pureMVC框架，而主UI部分是自己寫的。主程序和主UI相互獨(dú)立，能夠單獨(dú)編譯測(cè)試。主程序是純代碼，用FLEXSDK編譯，而主UI則是界面和AS混寫并用FLASH編譯。如此就把MVC中的V從物理層面上完全獨(dú)立了。pureMVC框架正如其名字，是一款“純粹”的MVC框架，在我看來(lái)，他只是幫我們實(shí)現(xiàn)了MVC的編程思想和套路，其它多余的功能一點(diǎn)沒有，這使它具有更高的通用性，也是它最可愛的地點(diǎn)。依照我們的經(jīng)驗(yàn)，pureMVC單核心版就差不多完全能夠應(yīng)對(duì)主程序有效代碼在10W行以下的項(xiàng)目了。但在我跟專門多沒有用過框架的前端朋友談天中，發(fā)覺他們對(duì)這些框架本身就有抵觸心理，或者有些對(duì)MVC模式都理解的不深刻，用起MVC框架又怎能得心應(yīng)手？還有一些更過分的朋友把自己的問題也歸結(jié)到框架上，講什么用了pureMVC框架后，自己的項(xiàng)目編譯一下要十幾分鐘，我聽了之后哭笑不得，項(xiàng)目編譯慢一般是因?yàn)闆]有合理劃分模塊導(dǎo)致主程序過大才導(dǎo)致的，跟框架有什么關(guān)系？假如因?yàn)榇蠡飪旱姆N種誤解和這些人的言論而導(dǎo)致一些新人錯(cuò)過學(xué)習(xí)這么一款優(yōu)秀的框架，我覺得實(shí)為憾事！pureMVC既然是一種MVC框架，這就意味著你首先要熟悉MVC。這種熟悉絕對(duì)不是對(duì)MVC的直譯：模型、視圖、操縱器，而是要真正理解什么緣故要把程序劃分成這幾部分，在劃分主程序模塊時(shí)，要時(shí)刻能站在MVC的角度考慮問題，而當(dāng)面對(duì)一段實(shí)際的代碼時(shí)，能快速準(zhǔn)確的推斷，這段代碼應(yīng)該放在MVC中的哪部分?！秔ureMVC最佳實(shí)踐》這份短短幾十頁(yè)的文檔中，能夠講處處閃耀著MVC的思想火花，不但清晰地闡述了如何使用框架，而且時(shí)刻從MVC的角度告訴我們應(yīng)該把哪些邏輯放在哪些部分中，應(yīng)該注意什么問題。那個(gè)文檔早差不多有中文版，有興趣的朋友能夠自己去看看，文中有的，我那個(gè)地點(diǎn)就不贅述了。我只結(jié)合自己的體驗(yàn)談一些文中可能沒有涉及的，也是在真正開發(fā)中才會(huì)碰到的問題。1，模型部分在實(shí)際開發(fā)中除了存儲(chǔ)數(shù)據(jù)，還有其他作用么？是的，事實(shí)上它的實(shí)際職責(zé)特不多。它要給Command和Mediator提供接口，響應(yīng)用戶操作，進(jìn)行數(shù)據(jù)操作或者請(qǐng)求遠(yuǎn)程數(shù)據(jù)服務(wù)，進(jìn)行數(shù)據(jù)的序列化和反序列化，得到異步數(shù)據(jù)后可能還要檢查數(shù)據(jù)合法化。但不管如何樣，它始終是在和數(shù)據(jù)打交道，同時(shí)也應(yīng)該是你的主程序中唯一能夠直接和數(shù)據(jù)打交道的管道，不的部分要想和數(shù)據(jù)有接觸，首先要問問它同意不同意。模型處理完數(shù)據(jù)會(huì)以Notification的消息方式通知Command或者M(jìn)ediator。但絕對(duì)不能在Proxy中直接調(diào)用Mediator，這是為了保證數(shù)據(jù)層的獨(dú)立性、可移植性和重用性，也簡(jiǎn)化了你的架構(gòu)思想。只是可移植性那個(gè)優(yōu)勢(shì)，可能專門多搞FLASHWEBGAME的朋友臨時(shí)都沒啥機(jī)會(huì)體驗(yàn)，呵呵。2，Command，Command，Command！連叫三聲“Command”，希望能夠引起大伙兒的注意。因?yàn)镃ommand的使用，在專門大程度上反映著你對(duì)pureMVC框架的理解，甚至是對(duì)MVC模式的理解深度。在pureMVC框架中，各部分通訊是用Notification消息，Proxy能夠給Command和Mediator發(fā)消息，Command能夠給Command和Mediator發(fā)消息，Mediator能夠給Command和Mediator發(fā)消息，如何樣？你現(xiàn)在是不是點(diǎn)暈了，這是正常的，事實(shí)上我也有點(diǎn)暈！當(dāng)你代碼寫到一定規(guī)模后，你會(huì)更暈。事實(shí)上pureMVC框架這么設(shè)計(jì)本來(lái)是為了讓MVC各部分盡量脫耦，但這帶來(lái)一個(gè)負(fù)面情況確實(shí)是消息發(fā)送與接收機(jī)制設(shè)計(jì)的太靈活了，靈活對(duì)小項(xiàng)目是好事，但對(duì)大項(xiàng)目來(lái)講，往往意味著混亂，甚至?xí)?dǎo)致災(zāi)難。那如何辦呢？只能靠我們的自覺性自我約束，簡(jiǎn)化架構(gòu)思想了。依照《pureMVC最佳實(shí)踐》中的建議，我的做法是如此的，盡量使用Command，讓Command成為Mediator與Proxy之間通訊的唯一橋梁，Mediator和Proxy中發(fā)出的Notification，接收者一定是某個(gè)Command，然后再由Command處理并將結(jié)果轉(zhuǎn)發(fā)給真正的消息接收者，Command就算僅僅起一個(gè)轉(zhuǎn)發(fā)作用，僅僅有不到10行代碼，也要?jiǎng)?chuàng)建一個(gè)Command類。如此不僅使你的架構(gòu)更加清晰，而且也更符合MVC思想，Command類的大量存在還使你架構(gòu)的業(yè)務(wù)邏輯具有了更好的封裝性和擴(kuò)展性，可謂是一箭三雕，何樂而不為？唯一的負(fù)面阻礙可能是你需要?jiǎng)?chuàng)建和維護(hù)更多的Command類文件，但相關(guān)于優(yōu)勢(shì)而言，這點(diǎn)阻礙不算啥。3，我明白現(xiàn)在可能還有一些朋友在用FLASHIDE寫代碼，這些朋友的執(zhí)著讓人欽佩，但我想任何一個(gè)熟練使用過FLEXBUDIER、FD或者FDT的朋友，都絕可不能再回頭使用FLASHIDE寫代碼了?！粚?duì)啊？不是談pureMVC的么？如何扯到IDE上去了？這是因?yàn)槲椰F(xiàn)在要討論的問題就和IDE有關(guān)，假如你現(xiàn)在用的依舊FLASHIDE的話，除了隨時(shí)寫文檔外，我確實(shí)專門難想出一個(gè)專門好的方案能夠讓你在沒文檔支撐的情況下，輕松掌握和隨時(shí)維護(hù)幾萬(wàn)行代碼。可假如你使用的是FDT,就能夠在沒有文檔的情況下，利用“ctrl+r”和“ctrl+鼠標(biāo)左鍵”，以及全文件搜索等工具，瞬間搞清晰代碼之間的聯(lián)系和邏輯，找出要修改的地點(diǎn)。OK，終于到pureMVC了。假如你使用的是FDT,同時(shí)開始嘗試使用pureMVC框架，可在使用的過程中，你發(fā)覺你在寫主程序時(shí)，依舊不停的使用“ctrl+鼠標(biāo)左鍵”，而不是“ctrl+r”，這講明你必須重新審視你對(duì)pureMVC框架的理解了，請(qǐng)審查你的Mediator類，看里面是不是充斥著大量的public方法，假如你的對(duì)象之間依舊是通過public方法進(jìn)行引用，而不是通過Notification通訊的，那你也沒有必要接著使用pureMVC框架了。4，單例模式阻礙到底有多大？pureMVC是一個(gè)完全依靠單例模式的框架。單例模式大概在AS界一直有專門大爭(zhēng)議，如此的話，pureMVC確信也會(huì)有相應(yīng)的爭(zhēng)議了。持反對(duì)意見的人，大多集中在“性能”和“團(tuán)隊(duì)協(xié)作”方面，他們認(rèn)為一個(gè)單例持有過多引用會(huì)帶來(lái)性能問題，而且生怕在團(tuán)隊(duì)協(xié)作中自己的單例類被人無(wú)意修改，引發(fā)離奇的BUG。性能方面，我之前也沒做過10W以上的項(xiàng)目，不敢妄言，但10W行以下的項(xiàng)目，絕對(duì)沒有問題，假如你兩三萬(wàn)行的架構(gòu)就開始碰到主架構(gòu)性能問題，可能十有八九是自己的代碼寫的有問題；團(tuán)隊(duì)協(xié)作方面，我覺得pureMVC的Fa?ade模式是特不靈活好用的，大伙兒能夠略做討論，制定一個(gè)簡(jiǎn)單的規(guī)則，比如模塊只能通過fa?ade獵取數(shù)據(jù)和發(fā)送Notification，不能直接調(diào)用主程序其他CLASS，只要架構(gòu)程序員不犯錯(cuò)，模塊程序員甚至連犯錯(cuò)的機(jī)會(huì)都沒有，假如他們有，依舊你的架構(gòu)思路有問題，請(qǐng)接著審視自己的代碼。反正單例模式的問題到底是什么，我到現(xiàn)在也沒完全搞明白，要緊是我們的項(xiàng)目沒碰到過此類問題，希望碰到過的朋友能再認(rèn)真跟火山講講，我也好弄清晰問題到底出在哪里了，自己以后能夠更好的幸免此類問題發(fā)生。額，框架部分先談上面4點(diǎn)吧，趕快進(jìn)入下一個(gè)話題，模塊劃分：模塊劃分要緊包括“核心模塊劃分”和“子模塊劃分”。核心模塊的劃分思路是如此的：它們是游戲啟動(dòng)所必須的，相互之間是緊密聯(lián)系的，還要經(jīng)常的被子模塊調(diào)用；而相對(duì)的，子模塊的劃分思路是：他們?cè)谟螒騿?dòng)過程中不是必須的，能夠在游戲過程中再加載，子模塊相互之間差不多上完全沒有聯(lián)系，一個(gè)子模塊的增加和刪除可不能阻礙到任何其他子模塊，子模塊可能需要調(diào)用主程序的接口或者獲得主程序的數(shù)據(jù)，但主程序絕對(duì)不應(yīng)該依靠某個(gè)子模塊。明確了模塊劃分思路再具體看看哪些部分應(yīng)該劃分為核心模塊，哪些部分應(yīng)該劃分為子模塊。一般情況下，核心模塊按照游戲啟動(dòng)順序包括：一個(gè)殼子SWF→配置文件包→登錄注冊(cè)SWF→主程序SWF→主UI的SWF→公共素材包。而子模塊相對(duì)來(lái)講簡(jiǎn)單專門多，比如具體的某個(gè)小游戲，某個(gè)場(chǎng)景，以及某個(gè)場(chǎng)景里的觸發(fā)功能等等。下面我對(duì)核心模塊逐一略做解釋。“一個(gè)殼子SWF”：這是一個(gè)體積專門小，但意義專門大的SWF；它后面總是跟著隨機(jī)變量，確保每次用戶加載的差不多上最新的；它里面定義著一些需要經(jīng)常更新而且每次更新都必須保證用戶也在第一時(shí)刻就得到最新值的變量；它里面最好有一個(gè)簡(jiǎn)單背景圖，保證用戶在超低網(wǎng)速的時(shí)候輸入游戲網(wǎng)址不至于長(zhǎng)時(shí)刻面對(duì)一片空白；它里面有安全策略的設(shè)定，是我們游戲和專門多第三方平臺(tái)合作的基石；它里面還定義著主程序被加載進(jìn)來(lái)之前的游戲啟動(dòng)流程等等?！芭渲梦募保汉诵哪K版本號(hào)啊，全局文字講明啊，service接口定義啊，各個(gè)核心模塊需要的配置信息啊什么的，一般是一些XML文件?！暗卿涀?cè)SWF”：那個(gè)簡(jiǎn)單，在加載重量級(jí)的SWF前，先加載登錄注冊(cè)SWF,能夠保證用戶第一時(shí)刻就能打開登錄注冊(cè)界面，而且能夠有效節(jié)約服務(wù)器帶寬。“主程序SWF”：那個(gè)確實(shí)是我前面費(fèi)了好大勁講的主程序部分了。“主UI”：主程序和主UI什么緣故要分開兩個(gè)SWF，我前面差不多提過了，后面還有講明，那個(gè)地點(diǎn)臨時(shí)不講?！肮菜夭陌保汗菜夭陌且粋€(gè)游戲不可缺少，但也不能過分依靠的東西。它包括一些全局的道具和效果，比如表情、技能特效、場(chǎng)景傳送門等等。公共素材包里面最好確實(shí)是一些簡(jiǎn)單的動(dòng)畫，體積小功能簡(jiǎn)單，嚴(yán)禁在公共素材包里添加上百K的東西，或者代碼上百行的小模塊，公共素材包建議500K以下?？戳松厦娴闹v解，你能夠能覺得核心模塊分那么多，太苦惱了。不錯(cuò)，在我看來(lái)，對(duì)SWF加載流程的分解和操縱，對(duì)異步程序的掌控正是衡量一個(gè)AS程序員是否經(jīng)驗(yàn)豐富，是否足夠老道的重要指標(biāo)，專門多從其它語(yǔ)言轉(zhuǎn)到AS并有多年編程經(jīng)驗(yàn)的朋友，架構(gòu)方面可能和AS程序員差不多，甚至比專門多自學(xué)成才的AS程序員做的更好，但這方面往往不如長(zhǎng)期與CPU和SWF體積搏斗的老牌AS程序員。核心模塊劃分的越合理，用戶體驗(yàn)往往越好，后期編寫和維護(hù)代碼的效率會(huì)越高，但在前期會(huì)比較苦惱，而且對(duì)架構(gòu)師的架構(gòu)經(jīng)驗(yàn)和能力必須提出更高的要求。什么都不分，主程序、素材、核心模塊都弄在一個(gè)SWF里，用戶一開始必須先下載完那個(gè)SWF,或者弄了一堆核心模塊和超多公共素材，用戶一開始必須面對(duì)loading條不停的周而復(fù)始，必須等所有核心要素全部加載完成才能進(jìn)行一些差不多操作的做法，從架構(gòu)角度上講，是最簡(jiǎn)單的做法，因?yàn)椴挥眠^多考慮復(fù)雜的異步和SWF拆分問題，但從用戶體驗(yàn)和長(zhǎng)遠(yuǎn)的開發(fā)維護(hù)上講是特不不利的。依照我們的經(jīng)驗(yàn)，用戶登錄前加載的所有資源體積應(yīng)該操縱在200K左右，而用戶進(jìn)入游戲主場(chǎng)景前，加載的資源總數(shù)應(yīng)該操縱在1M左右。還有前面提到過的那位用了pureMVC后項(xiàng)目編譯一下要十幾分鐘的朋友，可能確實(shí)是把所有東西都弄到一個(gè)SWF里的做法。主程序隨便改動(dòng)測(cè)試一下，就要十幾分鐘，牽一發(fā)而動(dòng)全身，開發(fā)效率從何談起？依照我們的經(jīng)驗(yàn)，任何主程序、核心模塊還有子模塊的編譯，都必須在10秒以內(nèi)，這才是合理的——我的機(jī)器是07年花了3000多買的戴爾品牌機(jī)?！勍曛骷軜?gòu)，接著談主UI。主UI一般指要緊的人機(jī)交互界面，那個(gè)地點(diǎn)的主UI區(qū)分于主架構(gòu)中的mediator，當(dāng)你看過pureMVC文檔后，你就明白了，mediator只只是起到一個(gè)真正的V和pureMVC框架之間的橋梁作用，pureMVC里的mediator事實(shí)上并不實(shí)現(xiàn)什么功能，真正的功能差不多上在主UI里實(shí)現(xiàn)的。但主UI又不得不確實(shí)是主程序的組成部分，因?yàn)樗幌衿渌K，差不多上只需要調(diào)用主程序的接口就行了，本身并不需要對(duì)主程序提供接口。而主UI作為用戶操作界面，必須大量的向主程序的mediator提供接口，或者發(fā)送events。因此主程序和主UI之間的配合必須特不緊密才行。不同的游戲類型，能夠選擇的UI解決方案也不同。策略類特不適合用FLEX；MMORPG這類標(biāo)準(zhǔn)網(wǎng)游，特不適合用ASWING；而像我們海底世界這類游戲界面特不夸張，沒什么標(biāo)準(zhǔn)規(guī)則，又不是太復(fù)雜的界面，依舊適合自己開發(fā)。相信任何有過游戲項(xiàng)目經(jīng)驗(yàn)的人都應(yīng)該能理解，UI也是FLASH開發(fā)中的重頭戲，專門多細(xì)節(jié)的處理特不苦惱，在項(xiàng)目早期具有專門大的工作量。依舊以我們的項(xiàng)目為例，我們的UI架構(gòu)思路是如此的：1，所有的界面組件差不多上直接拖放在stage上的，其功能代碼大部分差不多上在公布時(shí)編譯的，差不多上不用new的方式。這種方式的好處是方便編輯界面，從總體上直觀的把握所有的UI，減輕程序運(yùn)行時(shí)的負(fù)擔(dān)，同時(shí)幸免addToStage帶來(lái)的諸多問題。缺點(diǎn)是，當(dāng)UI膨脹到一定規(guī)模時(shí)，可能會(huì)需要你有一臺(tái)配置比較好的電腦——哎，講到那個(gè)地點(diǎn)我就難過啊，我那臺(tái)玩魔獸效果全關(guān)還卡的電腦，一直陪伴我的整個(gè)UI開發(fā)歷程。2，UI的FLA層次結(jié)構(gòu)是如此的：第一層是文檔類或者與UI主類關(guān)聯(lián)的某個(gè)MC，我們選用的是MC的方式,因?yàn)镸C的方式更靈活；第二層是那個(gè)MC里的所有組件，這些組件大部分是依照功能劃分在一起的一組元件，比如你的個(gè)人面板，而那個(gè)組件本身也是個(gè)MC；第三層是組件里的所有元件或者共用組件，元件確實(shí)是背景啊，按鈕啊什么的，而共用組件比如滾動(dòng)條啊翻頁(yè)組件啊什么的；要緊的就這三層，事實(shí)上那些共用組件MC再往里面雙擊還能夠劃分一層。對(duì)應(yīng)FLA的層次結(jié)構(gòu)，AS的結(jié)構(gòu)如下：文檔類或者主MC關(guān)聯(lián)的類是第一層，那個(gè)類里持有所有的界面元件的引用；第二層是這些界面元件對(duì)應(yīng)的組件CLASS,組件的功能差不多上在那個(gè)地點(diǎn)實(shí)現(xiàn)的，比如個(gè)人面板的MC將會(huì)對(duì)應(yīng)一個(gè)MyPanel的CLASS,那個(gè)CLASS里實(shí)現(xiàn)MyPanel的所有功能。至于CLASS和元件之間是如何對(duì)應(yīng)的，我用的是一種松耦合的代理模式，也確實(shí)是將MyPanel對(duì)應(yīng)的MC作為參數(shù)傳遞給MyPanel那個(gè)CLASS,而那個(gè)CLASS會(huì)有自己的私有變量記錄對(duì)應(yīng)MC里需要進(jìn)行操作的元件，具體到功能實(shí)現(xiàn)時(shí)，從代碼層面上看，就看起來(lái)CLASS操作的差不多上自己的私有變量，而不是直接操作界面元件，如此，當(dāng)界面元件修改名字時(shí)，CLASS的改動(dòng)專門小。而且這種代理模式能夠?qū)崿F(xiàn)一個(gè)CLASS代理不同的元件，當(dāng)界面只是需要修改外觀，不需要修改功能時(shí)，特不方便。那么這些CLASS是在哪里初始化并獲得它要代理的MC呢？正是在主MC對(duì)應(yīng)的UI主類中，比如當(dāng)獲得MyPanel對(duì)應(yīng)的MC后，就會(huì)趕忙publicvarmyPanel:MyPanel=newMyPanel(myPanel_mc);當(dāng)所有的組件注冊(cè)完成后，那個(gè)UI主類就持有了所有組件的引用，能夠方便主程序調(diào)用；代碼的第三層事實(shí)上確實(shí)是共用組件，比較專門的是，我的共用組件，比如滾動(dòng)條，也是用代理模式寫的。3，完全代理模式為我們制造了一種可能，確實(shí)是把UI和UI對(duì)應(yīng)的代碼分開編譯。這跟FLEX的皮膚更換機(jī)制有異曲同工之妙，只只是它的組件是要new出來(lái)的，布局是要代碼操縱的，皮膚差不多上一個(gè)個(gè)CLASS，整體效果一般都要編譯后才能看出來(lái)；而我的組件是直接拖到舞臺(tái)上的，布局大部分是直接在FLASHIDE里手動(dòng)布置好的，皮膚差不多上一個(gè)個(gè)命名過的MC，整體效果編譯之前差不多上就能看出來(lái)。FLEX在更換皮膚的時(shí)候，CLASS名絕對(duì)不能變，而我的UI在更換皮膚時(shí)，MC的名字和層次結(jié)構(gòu)不能變。FLEX關(guān)聯(lián)皮膚是在編譯時(shí)完成的，而我的UI關(guān)聯(lián)皮膚是在運(yùn)行時(shí)，當(dāng)啟動(dòng)程序加載完UI代碼的SWF和皮膚的SWF后，動(dòng)態(tài)指定的。把皮膚和功能代碼分開編譯成兩個(gè)SWF有個(gè)好處，確實(shí)是在實(shí)際開發(fā)過程中，我們會(huì)碰到有時(shí)候只需要修改代碼，而有時(shí)候只需要修改界面的情況，因此，就算你把代碼和界面一起編譯成一個(gè)SWF文件了，也完全能夠?qū)?yīng)這種情況，無(wú)非是編譯一次的時(shí)刻略微長(zhǎng)了一點(diǎn)點(diǎn)。可當(dāng)你面對(duì)如此的情況呢：某次游戲版本更新出現(xiàn)狀況，需要你目前功能不變，但畫面必須退回到上一個(gè)版本。這時(shí)候你傻眼了吧？你開始對(duì)策劃們咆哮：“你們能不能想想好再讓我們做??？”但你依舊不得不重新打開差不多做好的UI,把里面最新的界面再修改回老版本，同時(shí)還不敢把最新的刪了，因?yàn)橄乱粋€(gè)版本可能立即又要替換回最新的畫面了?？杉偃缒愕钠つw和代碼是分開編譯成兩個(gè)SWF的，這種情況就簡(jiǎn)單了，你能夠讓運(yùn)維從SVN上拉出上一個(gè)版本的皮膚SWF重新公布一下就好了，你所要做的只只是是動(dòng)一下嘴皮。4，最后談一下UI的數(shù)據(jù)層吧，UI是否需要數(shù)據(jù)層呢？答案是確信的。盡管你能夠從主程序那兒獲得任何你想要的數(shù)據(jù)，盡管大部分時(shí)刻你只是需要數(shù)據(jù)來(lái)顯示一下而已，但UI自己記住某些數(shù)據(jù)會(huì)大大方便自己寫代碼。UI的數(shù)據(jù)層不需要主程序那么復(fù)雜，每個(gè)組件有自己的數(shù)據(jù)變量，然后整個(gè)UI再有一個(gè)存放公共數(shù)據(jù)的地點(diǎn)就足夠了?！勍曛鞒绦蚝椭鱑I，最后再簡(jiǎn)單談一下小游戲、場(chǎng)景和模塊。先講小游戲吧，小游戲是相對(duì)最獨(dú)立的一塊，可能只需要主程序提供用戶數(shù)據(jù)，并在游戲結(jié)束后將分?jǐn)?shù)發(fā)送給主程序就行了。因此這部分從治理的角度上來(lái)講是相對(duì)輕松的，但這不意味著小游戲開發(fā)就簡(jiǎn)單了，有時(shí)候，麻雀雖小五臟俱全，想開發(fā)出一個(gè)性能和用戶體驗(yàn)俱佳的小游戲絕非朝夕之功，要是碰到一些算法復(fù)雜的小游戲，那就有得頭痛了。事實(shí)上關(guān)于海底世界這類兒童社區(qū)游戲，小游戲應(yīng)該走創(chuàng)意和簡(jiǎn)單路線，搞得太復(fù)雜了，既不行開發(fā)，小小孩又不一定玩得來(lái)。相關(guān)于小游戲，場(chǎng)景和模塊就和主程序甚至是主UI關(guān)系緊密了，但不管如何緊密，大部分時(shí)候它們差不多上在所要數(shù)據(jù)，發(fā)送事件，或者觸發(fā)某個(gè)界面的顯示與隱藏。假如某個(gè)模塊的修改需要經(jīng)常波及到主程序，或者專門多模塊在做同一件事，重復(fù)寫著同一段代碼，這時(shí)候就必須重新審視架構(gòu)，看是不是某些地點(diǎn)架構(gòu)的不合理了，不合理的地點(diǎn)，只要時(shí)機(jī)同意，一定要盡快改掉，絕對(duì)不能放任自流，一塊兒小毒瘤最終可能引發(fā)癌癥。模塊和場(chǎng)景程序員在我們公司事實(shí)上是特不累的，因?yàn)槊恐芏夹枰夹碌陌姹?，每次都專門趕。在這種情況下，場(chǎng)景和模塊程序員的責(zé)任心就特不重要，他們隨便哪里隨意了一下，會(huì)直接導(dǎo)致糟糕的用戶體驗(yàn)，因?yàn)榇蟛糠謺r(shí)刻，用戶直接接觸的東西差不多上他們的作品。架構(gòu)寫的再好，最終模塊都做的專門糟糕，對(duì)用戶來(lái)講沒有任何價(jià)值！因此，一個(gè)老道的，有責(zé)任心的，能夠快速開發(fā)出優(yōu)良用戶體驗(yàn)的AS模塊程序員，完全有理由拿高薪，因?yàn)樗麄兡茏龅降模恍┧^的純架構(gòu)師未必做得到！★前端與美術(shù)的配合→老閃客們應(yīng)該都明白，F(xiàn)LASH這款軟件在歷史專門長(zhǎng)一段時(shí)刻內(nèi)差不多上用來(lái)做動(dòng)畫的，閃客和美術(shù)在這段時(shí)刻內(nèi)本確實(shí)是同根生。后來(lái)隨著第二版AS1和AS2逐漸完善，以及AS3的強(qiáng)勢(shì)出爐，閃客們才逐漸分化成純程序和純美術(shù)兩個(gè)陣營(yíng)了。但不管如何分，F(xiàn)LASH程序和美術(shù)之間的關(guān)系依舊特不親熱，一個(gè)優(yōu)秀的AS程序員必定要比其它語(yǔ)言的程序員明白得更多美術(shù)方面的知識(shí)，至少也要能熟練操作FLASHIDE，并進(jìn)行簡(jiǎn)單的圖形處理。FLASH程序員與美術(shù)的合作大部分時(shí)刻是由AS程序員主導(dǎo)的，要緊表現(xiàn)在以下幾個(gè)方面：1，F(xiàn)LA文件治理：把有聯(lián)系的美術(shù)素材放進(jìn)一個(gè)FLA文件中統(tǒng)一治理，既能有效減少美術(shù)素材的數(shù)量，也方便程序員寫程序。本來(lái)像這種美術(shù)素材治理應(yīng)該是由美術(shù)負(fù)責(zé)的，但由于這些美術(shù)素材大部分時(shí)刻可能也需要程序員寫程序，美術(shù)和程序需要共享這些素材，盡管我們能夠用SVN進(jìn)行共享和版本操縱，但程序員和美術(shù)依舊要靠約定才能特不默契的明白什么時(shí)刻該到什么地點(diǎn)找什么文件。而那個(gè)約定就什么我們程序員應(yīng)該制定的，因?yàn)閾?jù)我觀看，程序員在條理性和制定規(guī)則方面一般比美術(shù)更靠譜。以我們公司為例，文件治理差不多上差不多上由我負(fù)責(zé)的，我把需要多個(gè)美術(shù)和程序員共同維護(hù)的部分以項(xiàng)目名命名成一個(gè)文件夾，項(xiàng)目下假如需要還能夠進(jìn)行子分類，分類規(guī)則也是我制定。而大部分的子模塊可能只需要一個(gè)美術(shù)加一個(gè)程序員就搞定了，這時(shí)候美術(shù)就把素材放到以自己英文名命名的文件夾下，至于他們的文件夾內(nèi)如何分類，我會(huì)給出意見，但并不強(qiáng)制治理。模塊程序員也會(huì)都有以自己英文名命名的文件夾，他們會(huì)把美術(shù)的純FLA素材拷貝到自己的文件夾下，并依照模塊進(jìn)行子分類，然后寫代碼并公布SWF，至于SWF文件如何治理，我會(huì)在下一節(jié)中討論。事實(shí)上我的治理目標(biāo)特不簡(jiǎn)單，我只需要所有的美術(shù)和程序員能在任何時(shí)候瞬間找到我們需要的素材和源代碼所在地，同時(shí)把需要的版本調(diào)出來(lái)。只要那個(gè)目標(biāo)還在可控范圍內(nèi)，我就會(huì)給所有職員最大的自由性，把自己從治理里解脫出來(lái)，把更多的時(shí)刻投入開發(fā)，怎么講關(guān)于創(chuàng)業(yè)型公司而言，快速開發(fā)，讓老總和市場(chǎng)看到產(chǎn)品才是主旋律，治理只需要在必要的時(shí)候強(qiáng)勢(shì)出手就能夠了。事實(shí)上，我們公司的文件治理，我每隔半年才會(huì)強(qiáng)勢(shì)治理一次，用大概一周的時(shí)刻重新規(guī)范規(guī)則，其它時(shí)刻差不多處于放任自流狀態(tài)，但從沒出過什么大問題。最后給大伙兒一個(gè)數(shù)字，我們公司通過將近三年的積存，差不多有幾十個(gè)G，上萬(wàn)個(gè)美術(shù)素材了。2，SWF文件治理：SWF文件一般是由前端程序員公布并治理的，只是也有一些SWF可能不需要些代碼，比如家具、個(gè)人面板背景等等，這些能夠直接由美術(shù)治理，治理方案和FLA文件治理差不多。最大的不同確實(shí)是，SWF文件最終的公布路徑是內(nèi)網(wǎng)模擬測(cè)試環(huán)境，而不是本機(jī)。像我們?nèi)绱说母买?qū)動(dòng)游戲，不可能為每一個(gè)模塊都單獨(dú)搭建擬真測(cè)試環(huán)境，假如如此的話，可能我們測(cè)試環(huán)境還沒搭好，就該上線并預(yù)備下一周的更新了，因此所有的模塊最終的整合測(cè)試差不多上直接上內(nèi)網(wǎng)測(cè)試環(huán)境進(jìn)行。3，F(xiàn)LA內(nèi)元件的治理：那個(gè)問題相信專門多AS程序員都碰到過，也都為此頭痛過。美術(shù)給到程序員手里的FLA文件可能是混亂不堪，庫(kù)里沒有任何分類，元件名也差不多上清一色的“元件1、元件2，元件3……”，元件內(nèi)部遮罩，組合，層次也都沒啥規(guī)律。要是美術(shù)直接給我一個(gè)AI或者PS的源文件讓我們自己導(dǎo)入FLASH，那我們就更抽了，顏色模式的改變，路徑工具的失靈，大量的圖層導(dǎo)致裁切困難，而且還不能進(jìn)行打散合并，只能一層一層的切。那個(gè)時(shí)候，正如我前面提到的，一個(gè)合格的AS程序員應(yīng)該對(duì)美術(shù)和圖形軟件有更多的了解，你應(yīng)當(dāng)及時(shí)糾正美術(shù)不恰當(dāng)?shù)淖龇?，甚至給出合理的解決方案，比如你應(yīng)該明白FLASH只支持RGB顏色模式，AI不但整個(gè)文檔能夠指定顏色模式，每個(gè)圖層也能夠單獨(dú)指定，當(dāng)美術(shù)給到你的AI導(dǎo)入FLASH有色彩差異的時(shí)候，能關(guān)心美術(shù)找到哪里的顏色模式不對(duì)，并建議他們以后只使用RGB模式。專門多純AS程序員可能有圖形恐懼癥，他們會(huì)想盡一切方法把這部分工作推向美術(shù)，但最終他們都會(huì)專門郁悶，因?yàn)樗麄儠?huì)發(fā)覺，除了能指定庫(kù)文件夾的命名規(guī)則外，其它的規(guī)則專門難跟美術(shù)講明白，而且由于模塊的千變?nèi)f化，專門難總結(jié)出一個(gè)完全通用的規(guī)則，想從美術(shù)哪里拿到一個(gè)完全不用修改，自己能夠直接寫代碼的FLA文件，幾乎天方夜譚。因此，與其讓FLA文件在美術(shù)和程序的你來(lái)我往中白費(fèi)時(shí)刻，與其讓自己在對(duì)美術(shù)的鄙視中憤懣抱怨，不如提升一下自己的美術(shù)常識(shí)和圖形處理差不多功。怎么講，元件在舞臺(tái)上如何命名，關(guān)聯(lián)什么類，層次如何樣，如何被程序利用，這些只有我們程序員最清晰，這部分工作由我們程序員完成完全是合理的，也是效率最高的，美術(shù)只要把我們需要的素材交給我們，并放到方便查找的地點(diǎn)就能夠了。放下程序員的架子，主動(dòng)走入美術(shù)的世界，對(duì)我們程序員絕對(duì)有好處。4，F(xiàn)P的性能問題對(duì)美術(shù)的阻礙：談到那個(gè)問題，我就想起了一個(gè)讓我抽搐已久的情況。我們老總總是喜愛語(yǔ)重心長(zhǎng)的對(duì)我講：“火山，你給咱們前端人員和美術(shù)出一個(gè)方案吧，告訴他們?nèi)绾巫瞿軌蜃孎LASH性能最高！”額，現(xiàn)在請(qǐng)問哪位朋友能夠幫火山回答那個(gè)問題?；鹕酱_實(shí)慚愧，搞FLASH搞了7年了，始終依舊沒完全弄明白FLASH的諸多性能問題。不管往常的MM依舊現(xiàn)在ADOBE，都將其圖形處理和屏幕渲染部分視為其鎮(zhèn)山之寶，不肯公開其技術(shù)內(nèi)幕，我也就始終無(wú)法從理論的高度給出一個(gè)本質(zhì)的回答。我現(xiàn)在的大多數(shù)性能解決方案，差不多上依照項(xiàng)目的實(shí)際情況，依照7年來(lái)的經(jīng)驗(yàn)總結(jié)出的經(jīng)驗(yàn)科學(xué)。而且我始終不相信，誰(shuí)能夠一個(gè)給出一個(gè)適合所有項(xiàng)目的、通用的性能解決方案，能夠同時(shí)讓內(nèi)存、CPU、帶寬占用都最少，而且畫面又專門炫，功能專門強(qiáng)大，SWF文件特不小，可玩性特不高，而開發(fā)周期和成本卻專門少。內(nèi)存、CPU、SWF體積、帶寬、效果、成本，這幾個(gè)要素往往是相互矛盾的，你對(duì)其中任何一點(diǎn)的過分優(yōu)化，都有可能導(dǎo)致其它點(diǎn)走向反面。我深信，在目前那個(gè)時(shí)期，一個(gè)性能方面的高手，絕對(duì)不是看他能不能給出一個(gè)全面優(yōu)化的方案，而是看他在面對(duì)不同的項(xiàng)目，不同的情況時(shí)，如何做出選擇和取舍。是的，“選擇和取舍”永久差不多上人生最困難的話題：手心手背差不多上肉，削掉哪邊呢？夫人小孩都掉海里了，救誰(shuí)呢？在如此的情況下，我覺得一個(gè)負(fù)責(zé)的前端人員，反而不應(yīng)該僅僅簡(jiǎn)單的扔給美術(shù)一份死的文檔，告訴他們應(yīng)該如何做，讓他們一直這么做就能夠了。前端人員應(yīng)該在每次面對(duì)一個(gè)實(shí)際情況時(shí)，都不厭其煩的跟美術(shù)講清緣由，我們應(yīng)該盡量授人以“漁”，而不授人以“魚”，讓他們明白選擇的道理，而不是簡(jiǎn)單的告訴他們選擇什么。相信只要是虛心學(xué)習(xí)的美術(shù)，通過一年半載的講解他們就能替你做出推斷了，這時(shí)候你再讓他們?nèi)ジ髞?lái)的美術(shù)講，你就解脫了。專門惋惜，大部分不明白技術(shù)的老總可能覺得你是在故弄玄虛，非要你給出一份文檔。無(wú)所謂了，你跟不明白技術(shù)的人爭(zhēng)論不是自討沒趣么？老總更多時(shí)候是從治理的角度動(dòng)身的，我們應(yīng)該配合。我們也不是沒什么可寫，比如盡量減少元件數(shù)量啊，減小SWF體積啊，減少持續(xù)性動(dòng)畫啊，多做觸發(fā)性動(dòng)畫啊，少用遮罩和濾鏡啊，不要嵌入中文字體啊，提高元件重用性啊等等等等！這些建議聽上去完全正確，忽悠不明白技術(shù)的人正合適。但事實(shí)上在高端的開發(fā)中，這些理論差不多上廢話，幫不上多大忙，因?yàn)榈厍蛉硕济靼琢?，我們碰到的問題確信是超越這些技術(shù)點(diǎn)的高端問題！綜上能夠看出，事實(shí)上前端和美術(shù)的配合過程大部分時(shí)刻是由前端主導(dǎo)的，這也是我前面一再?gòu)?qiáng)調(diào)前端要多明白一些美術(shù)知識(shí)的重要緣故。當(dāng)你能夠和美術(shù)一起談?wù)撁佬g(shù)理論，在美術(shù)的電腦上直接操作給他們看，當(dāng)你從美術(shù)的角度給他們提出解決方案的時(shí)候，你往往會(huì)更容易被美術(shù)所同意。擔(dān)負(fù)起主導(dǎo)前端與美術(shù)合作的責(zé)任，用你的智慧制服他們，用你的誠(chéng)意打動(dòng)他們，讓美術(shù)與前端完美結(jié)合，讓你的產(chǎn)品第一時(shí)刻抓住用戶！★前端與后端的配合→FLASH與后端通訊的手段多種多樣，網(wǎng)上相關(guān)教程太多了，那個(gè)地點(diǎn)不再例舉。但專門多時(shí)候，創(chuàng)業(yè)團(tuán)隊(duì)由于受制于各種現(xiàn)實(shí)條件，可選擇的方案并不多。像我們公司，剛開始差不多上只能選擇FMS+PHP+MYSQL。事實(shí)上，關(guān)于我們前端來(lái)講，后端選擇什么解決方案對(duì)我們的阻礙并不大，我們無(wú)非確實(shí)是用的API不一樣而已。多看看教程，用專門少的時(shí)刻我們就能掌握其要領(lǐng)。那么前后端合作的難點(diǎn)是什么呢？我覺得關(guān)鍵是邏輯的劃分?！扒昂蠖撕侠韯澐诌壿嫛保@句話咋看上去貌似簡(jiǎn)單，事實(shí)上里面蘊(yùn)含著諸多方面的考慮。比如安全性、后端性能、工作量、人事分工等等。安全性：記得我們的游戲同時(shí)在線超過3000的時(shí)候，就差不多有人開始攻擊我們的后端了，篡改了專門多人的個(gè)人資料。幸虧攻擊的人只是我們一個(gè)善意的玩家，假如是惡意的商業(yè)攻擊，后果不堪設(shè)想。通過這次后，老總開始纏著我們追問“如何防止不人攻擊，提高安全性”。那個(gè)問題又一次把我們難住了，我們都明白，基于HTTP的請(qǐng)求不被截取是不可能的，而SWF文件又不存在絕對(duì)的安全。就算你防得了惡意進(jìn)攻，你也防不了良性的外掛，想從技術(shù)層面讓不人完全攻擊不了我們也是不可能的。那我們是不是只能坐以待斃了？不是！假如前、后端在合作的時(shí)候，數(shù)據(jù)邏輯與合法性檢查差不多上做在后端的，就能夠?qū)ｉT好的幸免一些良性外掛。首先是游戲數(shù)據(jù)邏輯要盡量全做在后端，比如用戶在玩小游戲的時(shí)候，我們不要只是在用戶結(jié)束小游戲后，簡(jiǎn)單的把數(shù)據(jù)傳回后端，后端記錄進(jìn)數(shù)據(jù)庫(kù)完事，一旦攻擊者發(fā)覺了你那個(gè)傳數(shù)據(jù)的后臺(tái)接口，完全能夠避開SWF，做外掛直接呼叫你那個(gè)接口刷分，就算你驗(yàn)證用戶也沒用，因?yàn)樗軌蛳茸?cè)一個(gè)合法的用戶，然后在外掛中登錄再刷分。因此，你還能夠?qū)τ螒蚍謹(jǐn)?shù)先加密在傳給后端，提高攻擊難度，但這也是不保險(xiǎn)的，因?yàn)榧用芩惴ň驮谀愕腟WF文件中，不人能夠?qū)ｉT容易獲得。因此正確的做法應(yīng)該是：游戲開始的時(shí)候只告知后端游戲ID→后端標(biāo)識(shí)ID對(duì)應(yīng)的游戲差不多開始并記錄開始時(shí)刻→用戶每次獲得一個(gè)分?jǐn)?shù)時(shí)，前端傳回來(lái)的不是分?jǐn)?shù)，而是一個(gè)動(dòng)作ID,后端依照動(dòng)作ID給用戶加分→游戲結(jié)束時(shí)，前端告知后端游戲差不多結(jié)束→后端得知游戲結(jié)束，記錄結(jié)束時(shí)刻，計(jì)算時(shí)刻差，依照時(shí)刻差和最后得分是否符合標(biāo)準(zhǔn)做出相應(yīng)處理，假如符合標(biāo)準(zhǔn)就把最后得分入庫(kù)，并返回前端顯示給用戶，假如不符合標(biāo)準(zhǔn)，就啟動(dòng)作弊處理系統(tǒng)。而那個(gè)標(biāo)準(zhǔn)一般是由數(shù)值策劃給出的。通過我這么一分析，你可能頭痛了，本來(lái)一個(gè)專門簡(jiǎn)單的小游戲計(jì)分，如何搞得這么復(fù)雜？前后端工作量都增加了不講，對(duì)后端性能也提出了更高的要求，服務(wù)器可能要增加了，后端人手可能要增加了，開發(fā)周期也要延長(zhǎng)了，值得么？那個(gè)問題問的專門好，這正是我下面要講的：后端性能、工作量、人事分工：一旦我們每一步進(jìn)行安全性與合法性驗(yàn)證后，整個(gè)項(xiàng)目的工作量都會(huì)大大膨脹，開發(fā)周期也會(huì)大大延長(zhǎng)；一旦我們把數(shù)據(jù)處理、業(yè)務(wù)邏輯和安全驗(yàn)證都移到后端時(shí)，后端的壓力就會(huì)增加，服務(wù)器要增多，對(duì)后端人員的能力要求也會(huì)提高。專門多初創(chuàng)團(tuán)隊(duì)在項(xiàng)目初期人力財(cái)力，軟件硬件都不足，可能顧不上那么多，一心想著早點(diǎn)讓項(xiàng)目上線。在這種情況下，我覺得安全性能夠臨時(shí)放一下，眾所周知的安全漏洞補(bǔ)上就能夠了。但“數(shù)據(jù)處理和業(yè)務(wù)邏輯”那個(gè)，寧可開發(fā)的慢一點(diǎn)，寧可再招個(gè)后端高手，寧可多幾臺(tái)服務(wù)器成本，也要把它們盡量都放在后端。因?yàn)槟莻€(gè)沒分清的話，會(huì)阻礙到整個(gè)系統(tǒng)的清晰度，嚴(yán)峻阻礙項(xiàng)目中后期的進(jìn)展，為日后的重構(gòu)增加難度和超多的工作量，我們還希望著在重構(gòu)時(shí)加強(qiáng)安全性呢，到時(shí)候數(shù)據(jù)處理和業(yè)務(wù)邏輯依舊要放后端！因此綜合考慮，該出手時(shí)就出手，能省的不白費(fèi)，不能省的不要摳！→前面一節(jié)談了前后端合作的難點(diǎn)。那個(gè)地點(diǎn)再簡(jiǎn)單的談兩個(gè)要點(diǎn)：1，前端人員不要往常端的角度看后端：前端和后端有個(gè)本質(zhì)的區(qū)不，確實(shí)是前端的負(fù)荷是分擔(dān)在每個(gè)客戶端的，而服務(wù)端的負(fù)荷是集中在服務(wù)器上的。關(guān)于我們前端來(lái)講，一個(gè)功能多占了幾K內(nèi)存，SWF文件大了幾K全然不是什么問題，可對(duì)后端來(lái)講確實(shí)是專門嚴(yán)峻的問題了，一個(gè)人大幾K，上千人確實(shí)是幾M了。服務(wù)器在連接數(shù)、內(nèi)存和CPU之間會(huì)有微妙的平衡點(diǎn)，一旦那個(gè)平衡點(diǎn)被打破，隨便再多哪怕一點(diǎn)點(diǎn)資源占用，整個(gè)服務(wù)器的性能都會(huì)嚴(yán)峻下降，阻礙用戶體驗(yàn)，因此，假如你有幾十上百臺(tái)冗余服務(wù)器供你負(fù)載平衡，你能夠當(dāng)我沒講，可假如你像我們公司一樣，一開始就3、5臺(tái)服務(wù)器的話，就請(qǐng)前端人員一定要多多配合后端人員，幫他們省出每一個(gè)字節(jié)，每一次請(qǐng)求。比如像道具屬性會(huì)有專門多文字講明，這些講明應(yīng)該以類似XML文件的方式儲(chǔ)存為靜態(tài)文件，后端返回給前端的道具數(shù)據(jù)包里只需要一串物品ID,前端就能夠依照這些物品ID在XML文件里查詢出這些道具對(duì)應(yīng)的靜態(tài)物品屬性了。不看這些數(shù)據(jù)可能只有十幾K，對(duì)后端來(lái)講意義重大。依舊那句話，只要不是架構(gòu)性問題，前端不要怕苦惱，要盡量配合后端提高性能。2，前端后端要有專門明顯的BUG分界點(diǎn)。當(dāng)一個(gè)BUG出現(xiàn)時(shí)，后端應(yīng)當(dāng)專門快的用一種統(tǒng)一的方案證明數(shù)據(jù)沒有問題！那個(gè)方案必須讓前端明白，并讓前端也能夠操作。大伙兒熟知的phpremoting里有一個(gè)servicebrowser，那個(gè)東西就專門好，它能排列出所有PHP的接口，我們輸入?yún)?shù)，它就返回結(jié)果，我們能夠依照結(jié)果直接查看數(shù)據(jù)是否正確?！_定數(shù)據(jù)的正確性，對(duì)前端DEBUG特不重要，而一個(gè)BUG的解決，一般差不多上由前端人員入手并進(jìn)行定位的。→事實(shí)上相關(guān)于前端和美術(shù)的合作，前端與后端的合作依舊簡(jiǎn)單清晰的，前后端在開發(fā)的過程中，應(yīng)該是特不獨(dú)立的，后端開發(fā)完全能夠先啟動(dòng)，把數(shù)據(jù)接口提早寫好，等著與前端整合，而當(dāng)整合過程發(fā)生問題時(shí)，又能夠?qū)ｉT快的界定是誰(shuí)的問題?！锕疚幕c產(chǎn)品定位→前面談了那么多，不管是策劃、美術(shù)、前端依舊后端，大伙兒通力合作，共同奮斗的目標(biāo)無(wú)非確實(shí)是希望開發(fā)出來(lái)一個(gè)好產(chǎn)品，而開發(fā)出一個(gè)好產(chǎn)品的目標(biāo)無(wú)非確實(shí)是成就一個(gè)好公司，這就涉及到“產(chǎn)品定位”與“公司文化”的問題，公司文化和產(chǎn)品定位沒做好，其它人再努力差不多上枉然?？烧沁@兩個(gè)問題，從我們公司成立到現(xiàn)在一直困擾著我，我抓破腦袋苦思冥想，總結(jié)出我們公司的公司文化確實(shí)是“老總講了算”，而我們的產(chǎn)品文化確實(shí)是“與時(shí)俱進(jìn)，不斷重新定位”。下面我先談公司文化再談產(chǎn)品文化，因?yàn)楫a(chǎn)品文化是包含在公司文化中的。→公司文化：一個(gè)公司的文化在專門大程度上是由初創(chuàng)團(tuán)隊(duì)建立的，而初創(chuàng)