前言
前一段時間义起，我換了一份工作砌左，來到了一家新的公司一個新的項目組脖咐。這個項目是一款有IP的卡牌類游戲，客戶端所采用的引擎是cocos2dx 2.X的C++版本汇歹，所用的UI編輯器是cocosbuilder屁擅，通訊協(xié)議是http。其實是一款蠻不錯的產(chǎn)品产弹，但是整個客戶端的架構(gòu)有很大的問題派歌。所以就想著寫這樣一篇文章，談?wù)勛约簩τ谝豢钣螒虍a(chǎn)品客戶端架構(gòu)的想法痰哨。
注意項
下面就羅列一些胶果，客戶端開發(fā)需要注意的地方。有一些是需要在最初始階段斤斧，就需要考慮的早抠。也有一些是可以在開發(fā)過程中，慢慢調(diào)整優(yōu)化的撬讽。
客戶端引擎的選擇
首先要談的是引擎的選擇蕊连，雖然現(xiàn)在游戲引擎已經(jīng)非常多了，但是實際上在引擎的選擇上游昼，并不是特別多甘苍。
- Unity3d：3D手游首選
- Cocos2dx-js：2D手游首選（其實Lua也挺好，在C++綁定上更加方便烘豌，但是個人比較喜歡JS载庭，而且很多引擎都支持JS作為開發(fā)語言）
- Egret、Cocos2dx-js：2D頁游首選（Egret有時間沒關(guān)注了，不知道現(xiàn)在功能如何囚聚，之前看了它的功能靖榕，其實并不夠強大，但是它的配套工具做的不錯靡挥，我對它的印象還是挺好的序矩，）
開發(fā)流程
開發(fā)流程關(guān)系到整個項目人員的工作安排鸯绿，如果流程不規(guī)范跋破，效率會特別低。比較靠譜的流程大體是下面這個樣子：
策劃方案->美術(shù)效果圖->拼UI（最好有專人負責拼界面）->客戶端功能開發(fā)
一般來說服務(wù)端會在看到美術(shù)效果圖之后確定協(xié)議瓶蝴，確定完協(xié)議之后毒返，客戶端就可以開始寫協(xié)議相關(guān)的代碼（所以程序基本是在美術(shù)效果圖之后開始動工，如果策劃發(fā)現(xiàn)功能不對舷手，只需要在美術(shù)效果圖這一步進行修改）
還有就是策劃方案最好能領(lǐng)先游戲好幾個版本拧簸。比如：
1.0 要做基本養(yǎng)成
1.1 要做裝備升階
1.2 要做工會系統(tǒng)
1.3 要加一個新的殺時間玩法
不用特別細，但是一定要領(lǐng)先當前版本男窟，游戲制作人必須清楚的知道要做一個什么樣子的游戲盆赤。不然需求不明確，美術(shù)歉眷，程序會反復(fù)的修改牺六，耽誤效率更影響士氣。
美術(shù)汗捡、代碼資源管理
游戲用到的美術(shù)資源淑际，客戶端代碼，服務(wù)端代碼扇住，最好放在不同的倉庫下春缕。這樣做的原因是：
- 可以把每個人的權(quán)限區(qū)分開，比如美術(shù)可能艘蹋，只需要美術(shù)倉庫的權(quán)限
- 不會因為美術(shù)資源锄贼、策劃文檔的改動，影響到客戶端SVN版本號
- ...
多語言版本的考慮
現(xiàn)在游戲行業(yè)競爭特別激烈女阀，某一題材的游戲咱娶，在大陸不火爆，但是可能在東南亞强品，或者北美就很吃香膘侮，所以很多游戲都有語言版本。
游戲多語言版本的考慮的榛，會增加非常多的工作量琼了，所以在游戲早期，一定要考慮好。
多語言版本中文字方面主要包括：
- 代碼中的動態(tài)文字
- 策劃表里面的文字
- UI編輯器編輯的文字
- UI中的文字圖片雕薪。
（可能還有其它文字昧诱，比如運營活動之類。同時UI布局樣式也是需要考慮的）
這些文字的規(guī)范一定要定制好所袁，方便后期替換盏档。大體的規(guī)則就是把這些文字最終都導(dǎo)入到一張（或幾張）文字表里面，后期通過替換文字表就可以直接出一個新的語言包燥爷。這里面文字圖片是比較特殊的蜈亩，但是也可以通過給文字圖片加前綴的方式來區(qū)分是否要替換。
游戲中引導(dǎo)和戰(zhàn)斗模塊的設(shè)計
這兩個模塊如果一開始設(shè)計的不好前翎，那么到后期稚配，前者會變得很難維護，后者變得很難擴展港华。
強制引導(dǎo)部分如果代碼出問題道川，那玩家基本就是直接流失了。
而戰(zhàn)斗模塊立宜，如果一款游戲?qū)?zhàn)斗要求比較高冒萄，那么戰(zhàn)斗邏輯的擴展性一定要非常強。（比如策劃突然想到一個技能："灼傷"橙数，效果: 人物攻擊時有30%的概率尊流，讓敵方進入灼傷狀態(tài)：每秒扣100血，持續(xù)10秒商模。 程序這邊總不能說不支持這種情況奠旺，或者說要花很長時間改代碼結(jié)構(gòu)）
游戲更新機制
這也是重點，現(xiàn)在越來越多的手游采用腳本開發(fā)施流，極大的簡化了游戲的更新流程响疚，不再需要重新發(fā)布。一般來說游戲會有c++代碼瞪醋、腳本代碼忿晕、資源文件三個版本號。
更新這塊有很多細節(jié)點银受，比如：如何判斷客戶端當前資源是否已經(jīng)是最新的践盼，就有不少值得注意的地方（當發(fā)布了一個新包到appstore，用戶通過更新來實現(xiàn)安裝的操作宾巍，不會清空原有的下載資源）咕幻。
圖片內(nèi)存優(yōu)化
游戲內(nèi)存優(yōu)化的解決方案，網(wǎng)上已經(jīng)很多了顶霞，這里就不展開說了肄程。
傳輸協(xié)議
在http和socket中選通訊方式锣吼，我更加傾向于socket。通過socket來傳輸二進制數(shù)據(jù)流是非常節(jié)省的蓝厌，估計是用http來傳json這種方式的1/4~1/3玄叠。而且socket可以讓服務(wù)端主動發(fā)送消息給客戶端，唯一值得注意的拓提，就是斷線重連這一塊（iPhone退到后臺就自動斷線了）读恃。
客戶端UI的適配問題
這是一個很大的問題，不管采用哪種都不是特別完美代态，所以具體的方案的和美術(shù)設(shè)計掛鉤寺惫。
Android適配
由于Android機型多種多樣，我們的游戲在不同的Android設(shè)備上的表現(xiàn)可能各不相同胆数。比較容易出現(xiàn)的大概是以下幾點：
- 圖片導(dǎo)致的問題：一般來說一張圖片的大小不要超過1024*1024（模型Android機型的opengl不支持更大的尺寸）
- 內(nèi)存問題
- ...
場景管理肌蜻、彈窗管理
我比較推薦將場景互墓、彈窗區(qū)分開來必尼，用兩個管理器來控制它們的顯示和切換。
消息觸發(fā)機制
一個方便的消息觸發(fā)機制篡撵，可以讓代碼結(jié)構(gòu)更加清晰判莉。一般來說這種消息機制會采用觀察者模式，代碼實現(xiàn)都是大同小異：
addEvent(eventType, callbcak)
trigger(eventType)
各種腳本工具
除了導(dǎo)表之類的必備工具育谬，開發(fā)過程中還需要許多各式各樣腳本工具券盅，來提高開發(fā)效率。如：SVN(GIT)更新以及獲取版本號膛檀、小圖打包成大圖锰镀、文字提取替換等功能，都可以通過一個腳本來實現(xiàn)咖刃。比較推薦python來寫泳炉，原因主要是跨平臺、第三方庫比較多嚎杨。
本文同步發(fā)表在個人網(wǎng)站xtutu.me
