一款优秀的游戏产品，客户端所需要考虑的一些问题

前言

前一段时间，我换了一份工作，来到了一家新的公司一个新的项目组。这个项目是一款有IP的卡牌类游戏，客户端所采用的引擎是cocos2dx 2.X的C++版本，所用的UI编辑器是cocosbuilder，通讯协议是http。其实是一款蛮不错的产品，但是整个客户端的架构有很大的问题。所以就想着写这样一篇文章，谈谈自己对于一款游戏产品客户端架构的想法。

---

注意项

下面就罗列一些，客户端开发需要注意的地方。有一些是需要在最初始阶段，就需要考虑的。也有一些是可以在开发过程中，慢慢调整优化的。

客户端引擎的选择

首先要谈的是引擎的选择，虽然现在游戏引擎已经非常多了，但是实际上在引擎的选择上，并不是特别多。

1. Unity3d：3D手游首选
2. Cocos2dx-js：2D手游首选（其实Lua也挺好，在C++绑定上更加方便，但是个人比较喜欢JS，而且很多引擎都支持JS作为开发语言）
3. Egret、Cocos2dx-js：2D页游首选（Egret有时间没关注了，不知道现在功能如何，之前看了它的功能，其实并不够强大，但是它的配套工具做的不错，我对它的印象还是挺好的，）

---

开发流程

开发流程关系到整个项目人员的工作安排，如果流程不规范，效率会特别低。比较靠谱的流程大体是下面这个样子：

---

策划方案->美术效果图->拼UI（最好有专人负责拼界面）->客户端功能开发
一般来说服务端会在看到美术效果图之后确定协议，确定完协议之后，客户端就可以开始写协议相关的代码（所以程序基本是在美术效果图之后开始动工，如果策划发现功能不对，只需要在美术效果图这一步进行修改）

---

还有就是策划方案最好能领先游戏好几个版本。比如：
1.0 要做基本养成
1.1 要做装备升阶
1.2 要做工会系统
1.3 要加一个新的杀时间玩法
不用特别细，但是一定要领先当前版本，游戏制作人必须清楚的知道要做一个什么样子的游戏。不然需求不明确，美术，程序会反复的修改，耽误效率更影响士气。

---

美术、代码资源管理

游戏用到的美术资源，客户端代码，服务端代码，最好放在不同的仓库下。这样做的原因是：

1. 可以把每个人的权限区分开，比如美术可能，只需要美术仓库的权限
2. 不会因为美术资源、策划文档的改动，影响到客户端SVN版本号
3. ...

---

多语言版本的考虑

现在游戏行业竞争特别激烈，某一题材的游戏，在大陆不火爆，但是可能在东南亚，或者北美就很吃香，所以很多游戏都有语言版本。
游戏多语言版本的考虑，会增加非常多的工作量，所以在游戏早期，一定要考虑好。
多语言版本中文字方面主要包括：

1. 代码中的动态文字
2. 策划表里面的文字
3. UI编辑器编辑的文字
4. UI中的文字图片。
   （可能还有其它文字，比如运营活动之类。同时UI布局样式也是需要考虑的）

这些文字的规范一定要定制好，方便后期替换。大体的规则就是把这些文字最终都导入到一张（或几张）文字表里面，后期通过替换文字表就可以直接出一个新的语言包。这里面文字图片是比较特殊的，但是也可以通过给文字图片加前缀的方式来区分是否要替换。

---

游戏中引导和战斗模块的设计

这两个模块如果一开始设计的不好，那么到后期，前者会变得很难维护，后者变得很难扩展。
强制引导部分如果代码出问题，那玩家基本就是直接流失了。
而战斗模块，如果一款游戏对战斗要求比较高，那么战斗逻辑的扩展性一定要非常强。（比如策划突然想到一个技能："灼伤"，效果: 人物攻击时有30%的概率，让敌方进入灼伤状态：每秒扣100血，持续10秒。 程序这边总不能说不支持这种情况，或者说要花很长时间改代码结构）

---

游戏更新机制

这也是重点，现在越来越多的手游采用脚本开发，极大的简化了游戏的更新流程，不再需要重新发布。一般来说游戏会有c++代码、脚本代码、资源文件三个版本号。
更新这块有很多细节点，比如：如何判断客户端当前资源是否已经是最新的，就有不少值得注意的地方（当发布了一个新包到appstore，用户通过更新来实现安装的操作，不会清空原有的下载资源）。

---

图片内存优化

游戏内存优化的解决方案，网上已经很多了，这里就不展开说了。

---

传输协议

在http和socket中选通讯方式，我更加倾向于socket。通过socket来传输二进制数据流是非常节省的，估计是用http来传json这种方式的1/4~1/3。而且socket可以让服务端主动发送消息给客户端，唯一值得注意的，就是断线重连这一块（iPhone退到后台就自动断线了）。

---

客户端UI的适配问题

这是一个很大的问题，不管采用哪种都不是特别完美，所以具体的方案的和美术设计挂钩。

Android适配

由于Android机型多种多样，我们的游戏在不同的Android设备上的表现可能各不相同。比较容易出现的大概是以下几点：

1. 图片导致的问题：一般来说一张图片的大小不要超过1024*1024（模型Android机型的opengl不支持更大的尺寸）
2. 内存问题
3. ...

---

场景管理、弹窗管理

我比较推荐将场景、弹窗区分开来，用两个管理器来控制它们的显示和切换。

---

消息触发机制

一个方便的消息触发机制，可以让代码结构更加清晰。一般来说这种消息机制会采用观察者模式，代码实现都是大同小异：

addEvent(eventType, callbcak)
trigger(eventType)

---

各种脚本工具

除了导表之类的必备工具，开发过程中还需要许多各式各样脚本工具，来提高开发效率。如：SVN(GIT)更新以及获取版本号、小图打包成大图、文字提取替换等功能，都可以通过一个脚本来实现。比较推荐python来写，原因主要是跨平台、第三方库比较多。

本文同步发表在个人网站xtutu.me