游戏分工

这个篇章不涉及技术相关内容, 主要说明开发游戏内部分工情况, 约等于开发商业游戏的杂谈:

• SDK接入: 负责运营后台|第三方接入, 包括后台活动|物品发放|公告发布|授权登录等
• 游戏服务端: 负责维护游戏网络架构功能, 对接策划|客户端|后台等处理同时, 还有的需要兼任服务器运维部署等相关
• 服务器运维: 负责管理公司内部云服务器, 有时候需要搭建内网在线版本库和部署测试服|正式服|数据库等
• 游戏客户端: 负责实现游戏玩法, 有时候需要开发客户端工具给策划验证游戏内部数值等, 同时有时候需要处理安卓/iOS商店上架发包等
• 产品策划: 负责游戏玩法开发和数值调整防止在线游戏内部投入产出奔溃, 有时候需要和运营协调节日活动促进玩家回流在线等
• 原画美术: 负责游戏美术和 UI 绘制, 有的公司会本家预留 2|3 个美术人员剩下采用外包美术, 拿到外包美术资源之后由本家美术做资源差分等修改
• 市场运营: 负责游戏上架之后统计游戏流水和玩家在线分析用户流程, 对接策划分析怎么推出游戏内部活动, 客服收集反馈|BUG移交运营来移交技术解决
• 法务财务: 目前国内上架游戏需要公司主体用于报税和申请版号, 游戏内购支付SDK主体也只公司不对个人开放, 还有美术版权|和谐|报账等问题

只要做游戏商业化上面都是绕不开的点, 需要清楚知道内部流程和应该负责的要点, 而且游戏公司都是以工作室单位来针对自己产品线独立开发( 也存在互相工作室 ‘外借’ 技术人员帮忙开发 )

项目管理

如果需要把控项目, 那么需要对整体项目可以没精通所有流程但必须有所涉猎整体, 因为需要把控项目 deadline(最后期限).

这里需要说下之前所在游戏公司项目管理就比较灾难, 那时候公司把控项目由产品经理担任; 不过由于产品经理缺乏经验导致外包美术延误几个星期, 期间产品经理和美术外包扯皮没协调好这个版本服务端/客户端应该做的事, 也由于没穿插时间去申请版号|商户导致整个项目组上线都跌跌撞撞.

项目管理协调是重中之重的事, 而主程要么客户端要么服务端担任要么两者都有各自担任, 只有接触到最前线才能用自身经验解决问题.

项目开发一般分 小版本 和 大版本 发布版本:

• 小版本: 节日临时活动|限时活动|日常周期赛季奖励发放
• 大版本: 游戏玩法更新|客户端换皮资源|内核组件更新

小版本更新 常规来说 1-2周(最长3周) 内处理即可, 比如简单临时节日需要让美术更新资源和追加简单可以复用玩法等只需要热更新即可的小补丁.

大版本更新 则是底层自下而上改版, 这种方式没办法通过热更新修复并且强硬要求玩家重新安装更新, 如整体游戏策划的数值大变动|追加内部玩法和系统.

这里说下怎么具体的游戏开发上线流程:

1. 市场运营|产品策划: 根据自身|市场|玩家需求规划设计系统|玩法|活动
2. 产品策划|服务端|客户端|SDK端|原画美术: 产品按照策划案设计初版上线内容, 会议需要多方整合意见确认是否能够实现和实现时间
3. 产品策划|主程: 这时候策划|主程需要多线推进, 而不是针对单个处理:
   1. 主程|SDK端|法务财务: 如果涉及内购充值|应用上线, 需要申请 版号|商户号|第三方接入 等材料则需要尽快去申请
   2. 主程|客户端|服务端|产品策划: 设计 csv|xlsx 表格用于产品策划导入游戏数值公式, 服务端|客户端需要按照表格公式开发系统|玩法|活动
   3. 产品策划|原画美术|外包美术: 原画美术出初版设计稿如果人力不足需要找外包美术, 外包美术水平层次不齐所以需要公司原画美术进行不断微调
4. 产品策划: 上线功能进行测试数值到符合预期, 上线美术若有内测服需内测反馈; 这时需细心处理, 毕竟主导上线是 产品策划
5. 客户端|SDK端: 第三方接入需要在测试是否调通, 常规就是接入账号|支付体系关联到自己公司玩家数据库上
6. 产品策划|客户端|服务端|市场运营: 整体流程在测试服跑通, 验收全部需求通过, 如果没有通过就打回重新再来一遍流程
7. 客户端|SDK端: 调通第三方之后可以准备将游戏版本上架商店平台( Android|iOS|H5 ), 国内常规商店平台需要提交商户和版号证明
8. 市场运营: 上线完成之后就是等待市场反馈和统计玩家在线, 确认版本BUG和在线率从而确认新版本拉新和回归玩家比例

以上是比较常规的项目管理流程, 可以参照下优化自己的项目管理流程( 按照自身项目优化, 没必要硬套 ).

策划导表

如果是独立|单机游戏大概率是没有数据导表功能, 甚至有时候客户端会给引擎附加上对应功能给策划手动调试, 为什么要这么复杂? 需要知道目前开发的是 商业在线游戏, 商业游戏具体有以下特质:

• 游戏长线经营: 网络游戏需要做长期经营准备, 属性客户端服务端都需要同步( 地图编号成表格, 服务端推送客户端编号切换 ).
• 游戏资源平衡: 游戏内部资源如果没设计的话会使游戏内部经济系统崩溃, 内购购买资源也变得毫无吸引力.
• 游戏数值平衡: 如果游戏内有攻击|防御数值( MMO之类 )需要对其数值同步服务|客户端来调整, 数据需要测试大量版本才上线.
• ……

术业有专攻, 以上方式如果让 客户端|服务端 设计出对应公式是极其麻烦; 想象下程序又要负责游戏功能实现又要设计游戏内部经济系统, 还要维护数值公式设计|测试多版数值系统的情况, 这么多工作堆积下来直接会压垮程序.

也就是基于这种情况, 产品策划 也兼顾分出 数值策划 功能, 采用日常统计工具的好伙伴 xlsx/xls/csv 表格将数值表格同时同步服务端和客户端, 只需要 svn|git 同步自动更新最新表格同时服务热加载出最新数值就能所见即所得, 不需要程序浪费时间处理这些数值相关的问题.

当然如果你开发相对简单业务的游戏, 可以不引入导表功能节约开发时间

本地运算

现在有些游戏大部分采用服务端运算服务, 但是也有直接本地运算提交给服务端状态的情况, 所以看到这种客户端运算没必要太过惊讶; 这种本地运算之后提交服务端同步状态大部分都是 H5小游戏 类型, 其中以 微信小游戏 最为突出.

因为微信小游戏都是把游戏包提交微信端, 代码基本托管到微信平台端, 而用户只能通过微信媒介访问到入口对象; 这时候玩家抓包作弊需要抓包重新将状态封包推送, 常规来说突破成本很大且容易被日志捕获抓取封禁.

也基于这种情况, 所以有些 微信小程序 直接在运算代码放置在本地端节约服务端运算, 结算加密推送给服务端结算保存即可.

这种游戏主要收益来源都是 看广告收益 和 微信内购支付, 开发成本上尽可能已节约为主, 压缩服务器成本从而达到营收正常.

脚本语言

H5 游戏对代码业务热更新的需求没有那么高, 主要大部分H5游戏追求短平快, 所以允许游戏重新刷新再登录; 基于这点, 对于服务器直接重启服务加载的情况也比较普遍, H5端只需要做好重新连接即可.

如果真的要挂载脚本语言 JS|Lua|Python 之类的, 最好也是 服务端 和 客户端 共享同种脚本语言.

之前最难受的是公司 Unity + skynet 的游戏, 中途客户端换人说是为了性能采用原生 C# 编写业务并移除原 xLua 业务代码, 最后客户端对接策划编写好本地游戏逻辑之后丢给服务端要求 ‘翻译’ 成 Lua 代码, 这个人工翻译逻辑的过程费时费力且客户|服务端无法代码合一( 客户端改动业务都要通知服务端重新翻译 ).

所以要明确, 脚本语言大部分处理方向是代码业务不停机热更新和服务端客户端代码复用, 剩下情况可以按照自身要求不采用脚本语言方案.