D2 论坛淘宝 FED 展台游戏「氪金弹头」制作始末
作者: 发布于:

「氪金弹头」游戏,是淘宝 FED 团队互动小组为 D2 开发的展台游戏,也是互动技术的一片试验田。这款游戏的设计类似经典的「坦克大战」,每个玩家控制一辆坦克,在一篇草丛中作战(互相攻击)。基本玩法是,使用一台大屏电视显示战场和坦克,玩家使用手机扫码登录,手机「变身」为遥控器,控制大屏幕上属于自己的坦克。目前,这款游戏已经部署在淘宝 FED 博客上,亲可以点击下面的按钮进入游戏。

D2 当天,承载这款游戏淘宝 FED 团队展台成为了最火爆的展台,吸引了大量 D2 的参会者游玩这款游戏。

大清早就聚集在展台前的同学们

午间高峰期盛况

里面的会议开始了,但是小朋友还在专心致志地玩耍

夜场开始前

BOSS 们愉快地交往着、玩耍着

这款游戏的策划、设计、实现、部署全部是由互动小组完成的。趁着这款游戏的热度还未完全消退,本文对这款游戏的策划、设计、开发,以及当天的「运营」过程作个总结。

游戏策划

在确认「承包」了 FED 团队展台之后,我们互动小组就开始思索展台的创意。在若干个最初的灵感中,「手机遥控,大屏互动」的创意获得了所有人的赞同。之后,互动小组通过一次周会讨论了具体的游戏形式,又从若干个经典游戏(贪吃蛇、炸弹人、飞机大战、坦克大战等)中选出了「坦克大战」,作为我们游戏的原型。

我们将这款游戏命名为「氪金弹头」。

「氪金」是 MMRPG 「魔兽争霸」的「燃烧的远征」资料片中的一种稀有金属,后引申为(调侃地)形容某种高档材质。

我们不是专业的游戏策划,很难在策划阶段就产出完整的游戏方案(即使产出了,多半也是漏洞百出,在实现的过程不得不推翻重来)。我们的做法是,有了比较具体的想法后就动手开始设计和实现,并在其过程中根据实际体验,敏捷地改进和修正。

  • 比如,初期手机模拟遥控器的摇杆,体验很差,用户很难准确地控制坦克,我们改进了摇杆的实现原理。
  • 比如,初期坦克出现时没有「无敌」效果,当场地用户较多时,容易出现「出生在敌人枪口上的情况」。
  • 比如,初期飞行的炮弹是可以互相穿过的,「互相开炮,同归于尽」成为主流的情形。我们增加了炮弹互相抵消的机制,大大增强了可玩性。
  • 当天的游戏仅有一块大屏幕,后来我们增加了房间功能。每块大屏幕是一个独立的房间,左下方的二维码(扫码加入对战)中即包含了房间信息。

游戏设计

由于没有专职的视觉设计师,@一位 承担了全部的视觉设计工作。由于缺乏手绘功底,我们最初的方案是,直接使用 Sketch 绘制游戏元素:坦克、石块、树林等。初版设计稿如下:

后来,我们发现另一款 3D 建模软件 SketchUp 更加适合。SketchUp 能够导出 PDF 格式的矢量数据,并导入 Sketch 进行二次编辑。前者相比后者,有以下优点:

  1. 能够明显增强游戏元素的质感。由于光照的原因,物体不同表面的颜色是不一致的,这种「不一致」是影响质感的关键因素。在二维平面直接进行绘制时,难以把控元素的质感。
  1. 能够生成特定光照条件的非常真实的阴影,而且是矢量格式的。在二维平面绘制时,阴影只能凭着「感觉」来。
  1. 而且能方便地输出和更新需要四向图的单位,比如坦克。在二维平面绘制时,四向图元素需要绘制四遍,如果有修改,也需要改动四处。而在三维建模中,只需一次建模,便可导出四个方向的图。
  1. 能够方便地生成海报,比如本文的题图就是 SketchUp 渲染出来的。

我们的方案是,在 SketchUp 中进行建模,然后将模型导出成二维的矢量数据 PDF,再导入 Sketch 进行微调,最后导出成 PNG。在 SketchUp 中的模型如下所示:

最终导出的设计稿,如下所示。这也是游戏最终呈现给玩家的样子。

制作这款游戏的过程中,我深深地感受到 Sketch 导出切片的方便之处。我的感觉是,如果视觉设计的下游是前端开发,需要将元素分块导出的,那么使用 Sketch 而不是 Photoshop 的效率也许会高一些。后者也许更适合下游直接出单张图片的情形(比如制作海报)。

游戏实现

游戏的开发主要由 @叶斋 完成。开发分为三个部分,大屏幕(战场),手机端(遥控器),服务器(转发)。具体的思路是,手机端和大屏幕端同时 socket 连接到服务器,服务器将玩家手机上的状态实时同步到大屏幕端,游戏逻辑在大屏幕上计算,并把一些关键事件(击毁坦克)传回服务器。

手机与大屏幕端,都是典型的单页面应用。服务器使用 socket.io 实现消息的转发。

大屏幕端

大屏幕是游戏的主战场,坦克间的「爱恨情仇」都发生在这里,大部分游戏运行时运算也发生在这里,仅把一些关键信息传回服务器。大屏幕端的开发量占到整个开发量的 60% 以上。

因为主要运算都发生在大屏幕的浏览器端,所以我们在服务器端作了控制,同时仅允许一个大屏幕连接到服务器。

将游戏运行时的运算放在服务器进行,确实更加「理所应当」,不仅更安全,也允许多个大屏幕存在(每个玩家有自己的视角)。几乎所有的网络游戏都是这样做的,但此时我们必须考虑多屏同步的问题。

显示器的帧率是 60Hz,但是服务器和客户端怎么也无法确保每 1/60 秒就通讯一次,所以必然存在一些客户端「推测」出来的中间状态,客户端会在收到下一个服务器响应时验证和修复。何况我们还要考虑网络短暂阻塞的情况(你总不能客户端 1s 没有响应,就判定其掉线吧)。如果你玩过「魔兽争霸」或「魔兽世界」这样的联机游戏,你肯定会遇到这样的情况:你自己还能动,但周围的人都不动了,两三秒(也许十几秒)之后,其他人都瞬移到了不远处的其他地方,而你,也许已经死了。这是因为你「卡」了,网络恢复后,客户端同步了服务器的最新状态。

完成上述功能需要一笔可观的学习和时间成本,但当时的情况并不允许。后续,我们也许会把运算移到服务器端,然后推出远程分屏联机模式的。

大屏幕端作为典型的单页应用,我们使用 webpack 组织项目代码。除了玩家排行榜、在线玩家等功能区域是用 DOM 结构,游戏的主场景是用 Canvas 渲染出来的。游戏使用的 FED 团队产出的游戏框架 Gama,有以下一些小的技术点,也许可以关注下:

  1. 状态机。逻辑稍微复杂一点的游戏应用,如果不用一点状态机的思想,全靠异步回调和事件来实现逻辑,那么代码很快就会变成不可维护了。
  1. 分层 Canvas 渲染。由于 Canvas 绘制的元素很多,但是需要绘制的帧率却不一,如果全部绘制的一个 Canvas 上,性能肯定会大打折扣。这个坦克大战场景虽然不复杂,但也分了 4 层 Canvas,石块、松树这些一动也不动的元素,其实仅仅绘制了一次而已。
  1. 素材与声音的合并。虽然现在带宽不是什么大问题了,但是该做的优化还是得做(尤其是在移动设备上)。大家也许已经习惯了合并图片资源,其实声音也是可以合并的。(推荐 audiosprite)。

手机端

手机端引导用户登录,然后显示遥控器界面,用户在遥控器上滑动手指,控制大屏幕上属于自己的坦克。

我们希望,用户在横置手机的情况下进行操作。当用户扫码打开页面后,如果是竖屏,则提示用户将手机横置过来。

模拟摇杆

手机通过模拟遥控器上的「摇杆」,方便用户控制坦克的行进方向。

最初的方案是,把手机屏幕左侧划分为四个部分,监测用户手指滑动:手指滑动到哪个位置,就是那个方向。

然而我们发现,在不看手机屏幕的情况下,这很难精准地控制方向。在尝试了几个其他方案后,我们确定使用以下方案:

手指按到屏幕上时,确定一个基准点,之后滑动手指,依靠这个基准点计算方向。

这一处优化是由 @文龙 完成的,该优化大大提高了手机模拟遥控器的体验。

声音反馈

与传统意义上的遥控器不同,手机模拟的遥控器没有实体按钮,无法把遥控器的状态通过触觉反馈给用户;更糟糕的是,用户玩游戏时眼睛始终是盯着大屏幕的,遥控器状态也无法通过视觉被反馈给用户。

很多动作类手游也会模拟摇杆,但至少玩家会盯着手机看!

退而求其次,我们利用浏览器播放声音的能力,在遥控器状态发生变化(如由「向上」变为「向左」)时播放「咔嗒」声,通知用户(您的操作成功了)。

服务器

服务器的功能比较简单,主要包括:处理登录,转发 socket 请求数据:包括将遥控端的状态同步到大屏端,以及把大屏端的某些重要事件(坦克被摧毁)转发到遥控端,以及记录下来。服务器是基于 socket.io 实现的。

游戏数据

基础数据

事件次数人数人均
登录7703911.97
游玩585720728.29

细分

时间:高峰与低谷

如下图所示。访问登陆页的高峰出现在 9:00 和 13:00,低谷出现在 10:00~11:00,游玩的高峰出现在 9:00 和 13:00~16:00 和 18:00,低谷出现在 10:00 和 17:00,与会议安排基本一致(会议举行时为低谷,会议休息区间为高峰)。

按平台细分:

平台登陆人数登录占比人均登录次数游玩人数游玩占比人均游玩次数
iOS27770.8%2.1516278.2%32.46
Android10326.3%1.674722.7%12.7

按浏览器细分

平台登陆人数登录占比人均登录次数游玩人数游玩占比人均游玩次数
微信12933.0%2.438239.6%32.46
无线 Safari10125.8%2.056531.4%28.5
Android 浏览器10125.8%474722.7%12.7
无线 Mozilla246.10%2.0000%N/A
UC215.37%1.31102.46%5.8
其他51.27%N/A31.45%N/A

游玩得分情况

统计到的玩家 ID 数量为 282 个。得分分布如下:

50 分以上:12 人,最高 867 分。深度沉迷游戏的「骨灰玩家」。
10 分到 50 分:49 人。资深玩家。熟悉游戏玩法,并掌握了一定技巧,在游戏中获得了较大乐趣的玩家。
3 分到 10 分:90 人。主流玩家。基本熟悉游戏玩法,对游戏很感兴趣。
1 分到 3 分:70 人。浅尝辄止的玩家,稍微尝试了一下游戏,便离开了。
0 分:61 人。扫码后由于各种原因直接离开的玩家。

评价

游戏具有相当的可玩性。有 61 人(21%)的得分在 10 以上,这部分人已经被这款游戏所吸引,并认真地参与到游玩的过程中去。有  151 人(53%)的得分在 3 分以上,这部分人基本熟悉了游戏的玩法,对这款游戏很感兴趣。对资深玩家的访谈也印证了这一点。

游戏的火爆程度超出预期,即使在 10:00 这样的低谷(会场内正在进行分享活动),游戏依然保持着一定的热度。

问题:为何登录页流失率接近 50%?

登陆页访问人数 391 人,而进入到游玩页的则仅有 207 人。流失率 47%。有几点原因:

  • 统计策略失误:微信扫码后,引导用 Safari 打开,这部分实际上也统计到流失里面去了。
  • 其他原因:如用户不愿切换横屏模式,用户 GitHub ID 泄露,用户对游戏不感兴趣等。

实际的流失率准确值已不可考,但是通过统计到各个浏览器的流失率(也不准确):大约在 30% 左右。

总结

总得来说,「氪金弹头」游戏是比较成功的。这款游戏的意义在于:

  • 探索了多屏互动的玩法新模式,并实际应用在具体的场景中,积累了的实战经验。
  • 成为一块极佳的互动技术实验田,便于实践新兴的、极具想象力的 Web 互动技术,如体感技术、虚拟现实技术等等。
  • 在没有专业的策划、设计团队下,完成这个项目,能够实实在在地锻炼团队成员担当「多面手」的能力。

未来,我们互动小组会将项目中用到的技术和方案沉淀下来,思索如何利用这些技术与方案增强互动相关业务的体验。