前言
前一段時(shí)間，我換了一份工作，來到了一家新的公司一個(gè)新的項(xiàng)目組。這個(gè)項(xiàng)目是一款有IP的卡牌類游戲，客戶端所采用的引擎是cocos2dx 2.X的C++版本，所用的UI編輯器是cocosbuilder，通訊協(xié)議是http。其實(shí)是一款蠻不錯(cuò)的產(chǎn)品，但是整個(gè)客戶端的架構(gòu)有很大的問題。所以就想著寫這樣一篇文章，談?wù)勛约簩τ谝豢钣螒虍a(chǎn)品客戶端架構(gòu)的想法。
注意項(xiàng)
下面就羅列一些，客戶端開發(fā)需要注意的地方。有一些是需要在最初始階段，就需要考慮的。也有一些是可以在開發(fā)過程中，慢慢調(diào)整優(yōu)化的。
客戶端引擎的選擇
首先要談的是引擎的選擇，雖然現(xiàn)在游戲引擎已經(jīng)非常多了，但是實(shí)際上在引擎的選擇上，并不是特別多。
- Unity3d：3D手游首選
- Cocos2dx-js：2D手游首選（其實(shí)Lua也挺好，在C++綁定上更加方便，但是個(gè)人比較喜歡JS，而且很多引擎都支持JS作為開發(fā)語言）
- Egret、Cocos2dx-js：2D頁游首選（Egret有時(shí)間沒關(guān)注了，不知道現(xiàn)在功能如何，之前看了它的功能，其實(shí)并不夠強(qiáng)大，但是它的配套工具做的不錯(cuò)，我對它的印象還是挺好的，）
開發(fā)流程
開發(fā)流程關(guān)系到整個(gè)項(xiàng)目人員的工作安排，如果流程不規(guī)范，效率會(huì)特別低。比較靠譜的流程大體是下面這個(gè)樣子：
策劃方案->美術(shù)效果圖->拼UI（最好有專人負(fù)責(zé)拼界面）->客戶端功能開發(fā)
一般來說服務(wù)端會(huì)在看到美術(shù)效果圖之后確定協(xié)議，確定完協(xié)議之后，客戶端就可以開始寫協(xié)議相關(guān)的代碼（所以程序基本是在美術(shù)效果圖之后開始動(dòng)工，如果策劃發(fā)現(xiàn)功能不對，只需要在美術(shù)效果圖這一步進(jìn)行修改）
還有就是策劃方案最好能領(lǐng)先游戲好幾個(gè)版本。比如：
1.0 要做基本養(yǎng)成
1.1 要做裝備升階
1.2 要做工會(huì)系統(tǒng)
1.3 要加一個(gè)新的殺時(shí)間玩法
不用特別細(xì)，但是一定要領(lǐng)先當(dāng)前版本，游戲制作人必須清楚的知道要做一個(gè)什么樣子的游戲。不然需求不明確，美術(shù)，程序會(huì)反復(fù)的修改，耽誤效率更影響士氣。
美術(shù)、代碼資源管理
游戲用到的美術(shù)資源，客戶端代碼，服務(wù)端代碼，最好放在不同的倉庫下。這樣做的原因是：
- 可以把每個(gè)人的權(quán)限區(qū)分開，比如美術(shù)可能，只需要美術(shù)倉庫的權(quán)限
- 不會(huì)因?yàn)槊佬g(shù)資源、策劃文檔的改動(dòng)，影響到客戶端SVN版本號(hào)
- ...
多語言版本的考慮
現(xiàn)在游戲行業(yè)競爭特別激烈，某一題材的游戲，在大陸不火爆，但是可能在東南亞，或者北美就很吃香，所以很多游戲都有語言版本。
游戲多語言版本的考慮，會(huì)增加非常多的工作量，所以在游戲早期，一定要考慮好。
多語言版本中文字方面主要包括：
- 代碼中的動(dòng)態(tài)文字
- 策劃表里面的文字
- UI編輯器編輯的文字
- UI中的文字圖片。
（可能還有其它文字，比如運(yùn)營活動(dòng)之類。同時(shí)UI布局樣式也是需要考慮的）
這些文字的規(guī)范一定要定制好，方便后期替換。大體的規(guī)則就是把這些文字最終都導(dǎo)入到一張（或幾張）文字表里面，后期通過替換文字表就可以直接出一個(gè)新的語言包。這里面文字圖片是比較特殊的，但是也可以通過給文字圖片加前綴的方式來區(qū)分是否要替換。
游戲中引導(dǎo)和戰(zhàn)斗模塊的設(shè)計(jì)
這兩個(gè)模塊如果一開始設(shè)計(jì)的不好，那么到后期，前者會(huì)變得很難維護(hù)，后者變得很難擴(kuò)展。
強(qiáng)制引導(dǎo)部分如果代碼出問題，那玩家基本就是直接流失了。
而戰(zhàn)斗模塊，如果一款游戲?qū)?zhàn)斗要求比較高，那么戰(zhàn)斗邏輯的擴(kuò)展性一定要非常強(qiáng)。（比如策劃突然想到一個(gè)技能："灼傷"，效果: 人物攻擊時(shí)有30%的概率，讓敵方進(jìn)入灼傷狀態(tài)：每秒扣100血，持續(xù)10秒。 程序這邊總不能說不支持這種情況，或者說要花很長時(shí)間改代碼結(jié)構(gòu)）
游戲更新機(jī)制
這也是重點(diǎn)，現(xiàn)在越來越多的手游采用腳本開發(fā)，極大的簡化了游戲的更新流程，不再需要重新發(fā)布。一般來說游戲會(huì)有c++代碼、腳本代碼、資源文件三個(gè)版本號(hào)。
更新這塊有很多細(xì)節(jié)點(diǎn)，比如：如何判斷客戶端當(dāng)前資源是否已經(jīng)是最新的，就有不少值得注意的地方（當(dāng)發(fā)布了一個(gè)新包到appstore，用戶通過更新來實(shí)現(xiàn)安裝的操作，不會(huì)清空原有的下載資源）。
圖片內(nèi)存優(yōu)化
游戲內(nèi)存優(yōu)化的解決方案，網(wǎng)上已經(jīng)很多了，這里就不展開說了。
傳輸協(xié)議
在http和socket中選通訊方式，我更加傾向于socket。通過socket來傳輸二進(jìn)制數(shù)據(jù)流是非常節(jié)省的，估計(jì)是用http來傳json這種方式的1/4~1/3。而且socket可以讓服務(wù)端主動(dòng)發(fā)送消息給客戶端，唯一值得注意的，就是斷線重連這一塊（iPhone退到后臺(tái)就自動(dòng)斷線了）。
客戶端UI的適配問題
這是一個(gè)很大的問題，不管采用哪種都不是特別完美，所以具體的方案的和美術(shù)設(shè)計(jì)掛鉤。
Android適配
由于Android機(jī)型多種多樣，我們的游戲在不同的Android設(shè)備上的表現(xiàn)可能各不相同。比較容易出現(xiàn)的大概是以下幾點(diǎn)：
- 圖片導(dǎo)致的問題：一般來說一張圖片的大小不要超過1024*1024（模型Android機(jī)型的opengl不支持更大的尺寸）
- 內(nèi)存問題
- ...
場景管理、彈窗管理
我比較推薦將場景、彈窗區(qū)分開來，用兩個(gè)管理器來控制它們的顯示和切換。
消息觸發(fā)機(jī)制
一個(gè)方便的消息觸發(fā)機(jī)制，可以讓代碼結(jié)構(gòu)更加清晰。一般來說這種消息機(jī)制會(huì)采用觀察者模式，代碼實(shí)現(xiàn)都是大同小異：
addEvent(eventType, callbcak)
trigger(eventType)
各種腳本工具
除了導(dǎo)表之類的必備工具，開發(fā)過程中還需要許多各式各樣腳本工具，來提高開發(fā)效率。如：SVN(GIT)更新以及獲取版本號(hào)、小圖打包成大圖、文字提取替換等功能，都可以通過一個(gè)腳本來實(shí)現(xiàn)。比較推薦python來寫，原因主要是跨平臺(tái)、第三方庫比較多。
本文同步發(fā)表在個(gè)人網(wǎng)站xtutu.me
