【正文】 的組件是要new出來的，布局是要代碼控制的，皮膚都是一個個CLASS，整體效果一般都要編譯后才能看出來；而我的組件是直接拖到舞臺上的，布局大部分是直接在FLASH IDE里手動布置好的，皮膚都是一個個命名過的MC，整體效果編譯之前基本上就能看出來。可當你面對這樣的情況呢：某次游戲版本更新出現(xiàn)狀況，需要你目前功能不變，但畫面必須退回到上一個版本。盡管你可以從主程序那里獲得任何你想要的數(shù)據(jù)，盡管大部分時間你只是需要數(shù)據(jù)來顯示一下而已，但UI自己記住某些數(shù)據(jù)會大大方便自己寫代碼。所以這部分從管理的角度上來講是相對輕松的，但這不意味著小游戲開發(fā)就簡單了，有時候，麻雀雖小五臟俱全，想開發(fā)出一個性能和用戶體驗俱佳的小游戲絕非朝夕之功，要是碰到一些算法復雜的小游戲，那就有得頭痛了。模塊和場景程序員在我們公司其實是非常累的，因為每周都需要發(fā)布新的版本，每次都很趕。但不管怎么分，F(xiàn)LASH程序和美術(shù)之間的關(guān)系依舊非常親密，一個優(yōu)秀的AS程序員必然要比其它語言的程序員懂得更多美術(shù)方面的知識，至少也要能熟練操作FLASH IDE，并進行簡單的圖形處理。以我們公司為例，文件管理基本上都是由我負責的，我把需要多個美術(shù)和程序員共同維護的部分以項目名命名成一個文件夾，項目下如果需要還可以進行子分類，分類規(guī)則也是我制定。只要這個目標還在可控范圍內(nèi)，我就會給所有員工最大的自由性，把自己從管理里解脫出來，把更多的時間投入開發(fā)，畢竟對于創(chuàng)業(yè)型公司而言，快速開發(fā)，讓老板和市場看到產(chǎn)品才是主旋律，管理只需要在必要的時候強勢出手就可以了。最大的不同就是，SWF文件最終的發(fā)布路徑是內(nèi)網(wǎng)模擬測試環(huán)境，而不是本機。要是美術(shù)直接給我一個AI或者PS的源文件讓我們自己導入FLASH，那我們就更抽了，顏色模式的改變，路徑工具的失靈，大量的圖層導致裁切困難，而且還不能進行打散合并，只能一層一層的切。畢竟，元件在舞臺上怎么命名，關(guān)聯(lián)什么類，層次怎么樣，怎么被程序利用，這些只有我們程序員最清楚，這部分工作由我們程序員完成完全是合理的，也是效率最高的，美術(shù)只要把我們需要的素材交給我們，并放到方便查找的地方就可以了?；鹕秸娴膽M愧，搞FLASH搞了7年了，始終還是沒完全弄明白FLASH的諸多性能問題。內(nèi)存、CPU、SWF體積、帶寬、效果、成本，這幾個要素往往是相互矛盾的，你對其中任何一點的過分優(yōu)化，都有可能導致其它點走向反面。相信只要是虛心學習的美術(shù)，經(jīng)過一年半載的講解他們就能替你做出判斷了，這時候你再讓他們?nèi)ジ髞淼拿佬g(shù)講，你就解脫了。但其實在高端的開發(fā)中，這些理論都是廢話，幫不上多大忙，因為地球人都知道了，我們碰到的問題肯定是超越這些技術(shù)點的高端問題！ 綜上可以看出，其實前端和美術(shù)的配合過程大部分時間是由前端主導的，這也是我前面一再強調(diào)前端要多懂一些美術(shù)知識的重要原因。像我們公司，剛開始基本上只能選擇FMS+PHP+MYSQL?！扒昂蠖撕侠韯澐诌壿嫛保@句話咋看上去貌似簡單，其實里面蘊含著諸多方面的考慮。經(jīng)過這次后，老板開始纏著我們追問“怎么防止別人攻擊，提高安全性”。首先是游戲數(shù)據(jù)邏輯要盡量全做在后端，比如用戶在玩小游戲的時候，我們不要只是在用戶結(jié)束小游戲后，簡單的把數(shù)據(jù)傳回后端，后端記錄進數(shù)據(jù)庫完事，一旦攻擊者發(fā)現(xiàn)了你這個傳數(shù)據(jù)的后臺接口，完全可以避開SWF，做外掛直接呼叫你這個接口刷分，就算你驗證用戶也沒用，因為他可以先注冊一個合法的用戶，然后在外掛中登錄再刷分。經(jīng)過我這么一分析，你可能頭痛了，本來一個很簡單的小游戲計分，怎么搞得這么復雜？前后端工作量都增加了不說，對后端性能也提出了更高的要求，服務(wù)器可能要增加了，后端人手可能要增加了，開發(fā)周期也要延長了，值得么？這個問題問的很好，這正是我下面要說的：后端性能、工作量、人事分工：一旦我們每一步進行安全性與合法性驗證后，整個項目的工作量都會大大膨脹，開發(fā)周期也會大大延長；一旦我們把數(shù)據(jù)處理、業(yè)務(wù)邏輯和安全驗證都移到后端時，后端的壓力就會增加，服務(wù)器要增多，對后端人員的能力要求也會提高。因為這個沒分清的話，會影響到整個系統(tǒng)的清晰度，嚴重影響項目中后期的發(fā)展，為日后的重構(gòu)增加難度和超多的工作量，我們還指望著在重構(gòu)時加強安全性呢，到時候數(shù)據(jù)處理和業(yè)務(wù)邏輯還是要放后端！所以綜合考慮，該出手時就出手，能省的不浪費，不能省的不要摳！→前面一節(jié)談了前后端合作的難點。比如像道具屬性會有很多文字說明，這些說明應(yīng)該以類似XML文件的方式儲存為靜態(tài)文件，后端返回給前端的道具數(shù)據(jù)包里只需要一串物品ID,前端就可以根據(jù)這些物品ID在XML文件里查詢出這些道具對應(yīng)的靜態(tài)物品屬性了。當一個BUG出現(xiàn)時，后端應(yīng)當很快的用一種統(tǒng)一的方案證明數(shù)據(jù)沒有問題！這個方案必須讓前端知道，并讓前端也可以操作。★公司文化與產(chǎn)品定位→前面談了那么多，無論是策劃、美術(shù)、前端還是后端，大家通力合作，共同奮斗的目標無非就是希望開發(fā)出來一個好產(chǎn)品，而開發(fā)出一個好產(chǎn)品的目標無非就是成就一個好公司，這就涉及到“產(chǎn)品定位”與“公司文化”的問題，公司文化和產(chǎn)品定位沒做好，其它人再努力都是枉然。這種模式的優(yōu)點是大家優(yōu)勢互補，讓懂行的人完全負責相關(guān)領(lǐng)域，負責人成就感大，責任心強。我們公司老板就專政到事無巨細的程度了，就連買一個幾百塊錢的路由器都要再三跟老板請示，美術(shù)、策劃、開發(fā)所有的日程安排、人事任用都要由老板點頭。如果公司成功了，就算你再說成功是大家的，最大的成功者還是你，但如果公司失敗了，就算你找一千個理由推脫責任，最大的失敗者也是你！在這種情況下，專政者要努力提高自己的全面素質(zhì)，公司管理、產(chǎn)品、開發(fā)、策劃、美術(shù)、市場都必須有所了解，你的任何一個錯誤的決定都會把公司推向深淵，并引起相關(guān)部門人員的不滿。可能正是因為他也不知道到底需要多長時間才能開發(fā)出來，而我們又沒有取得他的信任吧，所以他就只能盡量往少的時間說，等到我們沒完成工作，大不了再延長時間而已。不過站在歷史發(fā)展觀上看兩種模式的話，我個人更偏向于“民主平等”模式，這種模式下的公司領(lǐng)導層為了保證公司能長久健康發(fā)展，肯定會不得不想盡一切辦法制定出平衡權(quán)利的法制規(guī)則，只要法制規(guī)則適應(yīng)時代，領(lǐng)導層人事變動影響是可控的。但縱觀天下，歷史的潮流是不可逆轉(zhuǎn)的，中國作為歷史發(fā)展的組成部分，腳步可以慢，但方向不會錯。不管是什么類型的公司，什么產(chǎn)品文化，這個文化一定要簡明而清晰，要深入人心，最好能濃縮成簡單的一個詞或者句子，“媽媽放心，孩子喜歡”就代表著淘米網(wǎng)絡(luò)的產(chǎn)品文化。直到現(xiàn)在，公司里上上下下，除了老板之外，沒幾個人能弄清公司的產(chǎn)品定位是什么，我們的產(chǎn)品文化是什么！這種情況導致一個很嚴重的問題，就是策劃在策劃游戲的時候，沒有核心價值觀，也就更沒什么游戲世界觀了，最終導致游戲形散神也散！16 / 16。我相信他們的用戶，他們用戶的家長，他們公司從管理層到員工每一個人，就連他們的競爭對手都對他們公司的價值觀，對他們的產(chǎn)品文化有一個清晰的認識。所以希望任何一個創(chuàng)業(yè)者在創(chuàng)業(yè)初期都認真的回答一個問題：你是只想做一個成功的企業(yè)家，還是想真正做一個成功的企業(yè)，讓這個企業(yè)能長久發(fā)展，代代相傳。相對于“人治”，我覺得“法制”更靠譜。只是曾經(jīng)浪費的時間，錯過的時機不再有，曾經(jīng)不合理制度下積累的問題，明天需要繼續(xù)補救！如果上天能給大家一次重來的機會，我相信，老板會說：“下次我一定要在項目剛開始就找一個靠譜的，值得信任的CTO！”，而程序員會說：“我下次再也不會跟著不懂技術(shù)還自以為是，橫加干涉的老板了！” 雖然“民主平等”和“高度專政”兩種模式都有其優(yōu)缺點，但最終玩的都是一個“人”字，相同項目，一個模式，不同的人玩出來的結(jié)果肯定不一樣。初創(chuàng)很長一段時間內(nèi)，他都敢拍板說一個社區(qū)一個AS一個月搞定之類的話，而且還要非常強勢的讓你接受，并拿出執(zhí)行方案。專政模式下，公司文化其實就是老板的個人文化。我們的競爭對手淘米網(wǎng)絡(luò)就是這種模式，到目前為止，他們公司發(fā)展的還是最好的。下面我先談公司文化再談產(chǎn)品文化，因為產(chǎn)品文化是包含在公司文化中的?！_定數(shù)據(jù)的正確性，對前端DEBUG非常重要，而一個BUG的解決，一般都是由前端人員入手并進行定位的。還是那句話，只要不是架構(gòu)性問題，前端不要怕麻煩，要盡量配合后端提高性能。對于我們前端來說，一個功能多占了幾K內(nèi)存，SWF文件大了幾K根本不是什么問題，可對后端來說就是很嚴重的問題了，一個人大幾K，上千人就是幾M了。在這種情況下，我覺得安全性可以暫時放一下，眾所周知的安全漏洞補上就可以了。所以正確的做法應(yīng)該是：游戲開始的時候只告知后端游戲ID→后端標識ID對應(yīng)的游戲已經(jīng)開始并記錄開始時間→用戶每次獲得一個分數(shù)時，前端傳回來的不是分數(shù)，而是一個動作ID,后端根據(jù)動作ID給用戶加分→游戲結(jié)束時，前端告知后端游戲已經(jīng)結(jié)束→后端得知游戲結(jié)束，記錄結(jié)束時間，計算時間差，根據(jù)時間差和最后得分是否符合標準做出相應(yīng)處理，如果符合標準就把最后得分入庫，并返回前端顯示給用戶，如果不符合標準，就啟動作弊處理系統(tǒng)。就算你防得了惡意進攻，你也防不了良性的外掛，想從技術(shù)層面讓別人完全攻擊不了我們也是不可能的。安全性：記得我們的游戲同時在線超過3000的時候，就已經(jīng)有人開始攻擊我們的后端了，篡改了很多人的個人資料。多看看教程，用很少的時間我們就能掌握其要領(lǐng)。擔負起主導前端與美術(shù)合作的責任，用你的智慧征服他們，用你的誠意打動他們，讓美術(shù)與前端完美結(jié)合，讓你的產(chǎn)品第一時間抓住用戶！★前端與后端的配合→FLASH與后端通訊的手段多種多樣，網(wǎng)上相關(guān)教程太多了，這里不再例舉。無所謂了，你跟不懂技術(shù)的人爭論不是自討沒趣么？老板更多時候是從管理的角度出發(fā)的，我們應(yīng)該配合。是的，“選擇和取舍”永遠都是人生最艱難的話題：手心手背都是肉，削掉哪邊呢？老婆孩子都掉海里了，救誰呢？在這樣的情況下，我覺得一個負責的前端人員，反而不應(yīng)該僅僅簡單的扔給美術(shù)一份死的文檔，告訴他們應(yīng)該怎么做，讓他們一直這么做就可以了。我現(xiàn)在的大多數(shù)性能解決方案，都是根據(jù)項目的實際情況，根據(jù)7年來的經(jīng)驗總結(jié)出的經(jīng)驗科學。 4，F(xiàn)P的性能問題對美術(shù)的影響：談到這個問題，我就想起了一個讓我抽搐已久的情況。很多純AS程序員可能有圖形恐懼癥，他們會想盡一切辦法把這部分工作推向美術(shù)，但最終他們都會很郁悶，因為他們會發(fā)現(xiàn)，除了能指定庫文件夾的命名規(guī)則外，其它的規(guī)則很難跟美術(shù)說明白，而且由于模塊的千變?nèi)f化，很難總結(jié)出一個完全通用的規(guī)則，想從美術(shù)哪里拿到一個完全不用修改，自己可以直接寫代碼的FLA文件，幾乎天方夜譚。 3，F(xiàn)LA內(nèi)元件的管理：這個問題相信很多AS程序員都碰到過，也都為此頭痛過。最后給大家一個數(shù)字，我們公司經(jīng)過將近三年的積累，已經(jīng)有幾十個G，上萬個美術(shù)素材了。模塊程序員也會都有以自己英文名命名的文件夾，他們會把美術(shù)的純FLA素材拷貝到自己的文件夾下，并根據(jù)模塊進行子分類，然后寫代碼并發(fā)布SWF，至于SWF文件如何管理，我會在下一節(jié)中討論。本來像這種美術(shù)素材管理應(yīng)該是由美術(shù)負責的，但由于這些美術(shù)素材大部分時間可能也需要程序員寫程序，美術(shù)和程序需要共享這些素材，雖然我們可以用SVN進行共享和版本控制，但程序員和美術(shù)還是要靠約定才能非常默契的知道什么時間該到什么地方找什么文件。架構(gòu)寫的再好，最終模塊都做的很糟糕，對用戶來說沒有任何價值！所以，一個老道的，有責任心的，能夠快速開發(fā)出優(yōu)良用戶體驗的AS模塊程序員，完全有理由拿高薪，因為他們能做到的，一些所謂的純架構(gòu)師未必做得到！★前端與美術(shù)的配合→老閃客們應(yīng)該都知道，F(xiàn)LASH這款軟件在歷史很長一段時間內(nèi)都是用來做動畫的，閃客和美術(shù)在這段時間內(nèi)本就是同根生。 相對于小游戲，場景和模塊就和主程序甚至是主UI