1.關於遊戲引擎
在15年3月開始準備做h5遊戲的時候，首先遇到的問題就是引擎選型的問題。
當時市面上的2d引擎主要有3個:白鷺egret,layabox和cocos2d-js。
一方面，是因爲我以前用cocos2d-x(c++)做了一年多的手遊客戶端，所以，很自然就選擇了cocos2d-js。另一方面，是因爲當時市面上其他兩個引擎的成功項目還不多。
cocos引擎的每一次版本更新，我們都會第一時間在我們的遊戲裏面進行測試。
如果發現遊戲在android手機上的性能有明顯提升，我們就會跟着引擎版本一起升級。站在巨人的肩膀上，我們可以事半功倍。
從15年3月的v3.5，到15年9月的v3.8，到15年11月的v3.9，直到最近16年7月的v3.12。我們一共更新了3次遊戲引擎！
PS:js-tests裏面的OpenGl Test直到v3.12纔在android真機上能看到運行效果，淚流滿面！
2.關於數據加密和通信協議
因爲是強聯網遊戲，所以只能是websocket。因爲我們原來的手遊客戶端和服務器之前是tcpsocket，傳輸的內容是sha1加密過的自定義格式的二進制數據。
所以項目的第一個難點就是怎麼用js實現json字符串的二進制編碼和解碼，以及sha1加密和解密。
TODO:其實沒有必要每一條上下行都加密和編碼解碼，這會造成客戶端和服務器端cpu壓力過大。只需要保護一些重要的事件(如登錄、充值、扣金幣等)即可！
遊戲的第一個demo做好了，上線一測試，問題來了：有些android手機的默認瀏覽器根本不支持websocket！
最開始我的解決辦法比較簡單粗暴，不支持就彈提示："你的手機瀏覽器不支持websocket，請換chrome瀏覽器！"
市場表示接受不了：真實玩家都跑了！除了公司的測試人員，誰都不會爲了玩一個h5遊戲還去專門下載一個瀏覽器！更何況除了瀏覽器，還有微信和qq，怎麼破？
最終的解決辦法，就是通信層從websocket改成websocket+http雙協議，對外封裝成Net。業務層對websocket的調用都改成對Net的調用。
Net默認連websocket，如果不支持，就自動切換到http長輪詢。不管是websocket還是http，傳輸的內容還是之前加密過的二進制數據。
雖然http的長輪詢在實時戰鬥的時候，會有卡頓，但是聊勝於無，至少這部分玩家能進到遊戲裏面，可以玩單機副本，和其他系統。不會因爲不支持websocket而進不來！
根據我們的數據分析統計，這部分玩家居然有10%。可能不同渠道導入的用戶，這個值會有不同！而且隨着時間的推移，這個比例應該越來越少！
PS:不支持websocket的android手機，跟IE6一樣令人討厭，都是阻礙生產力發展的，必將被歷史淘汰！
3.關於android和微信
中國的市場現狀就是,H5遊戲必須考慮android手機，必須考慮微信和qq這兩個傳播渠道。只關注用pc瀏覽器開發和蘋果手機測試沒問題，是不明智的，也是對公司的不負責任。
開發的時候可以用pc瀏覽器調試，但是發佈之前必須在android手機的微信裏面，打開遊戲看是否有兼容性問題，同時確認流暢度。
如果pc和蘋果手機都能跑到50~60幀,但是android的微信就只有10多幀，那就必須在圖片尺寸和動畫效果等方面做取捨。
我們的標準是保證遊戲在android中端機的微信裏面打開，最低25幀。
今年4月份微信的瀏覽器內核自動從webkit升級成Blink，這是對H5整個行業的重大利好！
竊以爲，白鷺、layabox和cocos2d，包括unity，虛幻，這幾個遊戲引擎之爭，現在來看，都是在爭VR和3D，但是最終是看誰對奇葩輩出的android的全覆蓋支持最好，誰就能最終佔領中國乃至全球市場！
4.關於音樂和音效播放
cocos2d-js引擎自帶的CocosDension有bug，不能同時播放一個以上的音樂。而且在中低端的android的微信裏面，聲音品質會變差（像破鑼一樣發呲）
我們的解決方案就是引入第三方的howler.js
5.關於資源分場景加載
cocos2d-js默認的resource.js裏面，所有資源都是在一個數組裏面，所以預加載的時候必須全部都加載完了才能進遊戲！剛開始開發的時候，這樣沒有問題。
但是到了後期，隨着系統的增加，資源文件也越來越多，對第一次玩遊戲的玩家來說，因爲瀏覽器沒有緩衝，需要全部加載，在wifi環境都需要等待1分鐘以上，這會導致大量的新玩家流失！
我們的解決辦法是，分場景加載資源。在resource.js裏面，將資源按場景分成N個數組，每次加載某個場景的時候，只預加載對應數組裏面的資源。
6.關於json文件壓縮
隨着遊戲開發的進行，場景越來越多，ccs生成的json文件也越來越多，同時各種地圖、商品、道具、獎勵等數據的完善，對應的json文件內容越來越多，文件大小越來越大！
最後遊戲發佈的時候，發現居然有70個場景json文件，合計1.3M。有27個配置json文件，合計755K。等待這幾十個文件加載的時間可不短！
解決辦法，引入第三方的jszip，可以將多個json文件合併成一個zip，文件大小隻有原來的8%。
寫了個python腳本，把ccs和configs兩個目錄下的json文件先轉成一個一行，再用jszip打包成2個zip文件，遊戲一開始先用jszip加載這兩個zip，解壓的json放到全局數組裏面。
注意這裏面有個坑，策劃的excel裏面不能出現半角逗號，否則jszip打包會報錯。強制策劃不輸入半角逗號不太合理，解決辦法是go生成json的時候替換半角逗號爲全角逗號。
然後複寫了引擎的cc.loader.loadJson這個函數，對打包的json文件特殊處理(不用額外發起http請求，直接從全局數組裏面拿)有了5、6這兩步的優化，現在新手在第一次Loading頁只需要等待4秒就能進入遊戲。
7.關於混淆
cocos封裝了google的混淆編譯腳本，但是這裏面有個坑：就是加了--advance參數之後，所有變量名都會被混淆，包括object的內部函數名稱和變量。
解決辦法就是在你不想混淆的函數或者變量（object{}對外暴露的public函數和變量 以及 引用的第三方庫的函數 ）前面加上一行：
/** @expose */
注意：千萬不要xxx.yyy 和 xxx['yyy'] 混着用!否則加/** @expose */也沒用，必須全部統一成其中一種寫法！
8.關於上線發佈流程和cdn緩存
1)本地運行publish.sh：本地混淆編譯，本地測試publish/html5/index.html是否正常
2)本地運行oline_t1.sh：根據當前時間生成版本號,publish/html5目錄下的res和game.min.js和index.html裏面的相對路徑都改成http://cdn域名/版本號的文件地址,
將res和game.min.js加上版本號之後，上傳cdn服務器。更新測試服t1的index.html,通知測試！
3)本地運行online_s1.sh：更新正式服s1上的index.html。發佈完畢。
說明:
1)客戶端和服務器端程序員都是mac開發環境，每人的機子上都有一套完整的前後端遊戲環境。本地開發，本地調試，沒有問題之後通過git提交代碼到公司內網git服務器。這樣可以最大限度保證多人協作的同時，互不影響開發進度！
2)因爲cdn加了時間版本號，所以每一次的發佈都是馬上生效，不需要等緩存過期。也不擔心多人各自發布覆蓋對方的代碼。發步完馬上可以查看效果，大大提高生產效率。以cdn的空間換效率，非常划算！
3)python的fab包是個好東西，可以遠程登錄服務器執行shell命令，實現本地一鍵發佈。不需要在服務器上通過git的鉤子來實現自動發佈！
9.關於斷線重連(websocket)
1)客戶端每隔58秒有一個心跳上行，保持與服務器的鏈接
2)多標籤的瀏覽器在切換tab或者瀏覽器進入後臺的時候或者斷網，都會導致心跳失效
3)每次客戶端發送上行的時候，先判斷Net.isConnect()是否爲true。如果false就先保存上行事件和數據，然後重連，然後重新登錄，然後發送保存的上行事件和數據。這些都是在後臺進行，如果重連失敗則彈出提示，點擊確認之後刷新頁面。
10.關於運營商的域名劫持和移動端js加彈出廣告
運營商耍流氓，中國又是一個"法制"國家，除了上https，沒有別的辦法！
我們選擇的是沃通的超安SSL，單域一年4888元
http://www.wosign.com/price.htm
11.關於客戶端AI
1）NPC碰到障礙物之後會固定角度轉向，避免卡死在角落。其他時間會隨機轉向。
2) 自動添加NPC，保證房間內NPC的最低數量
3）同一時刻只有一個NPC處於追蹤玩家狀態，有定時器觸發追蹤者的選角切換