撰写了文章更新于 2020-06-07 17:42:10

《千手英雄》开发手记

大家好！我是 Retro Daddy （群名字一般用 Harrison），这次给大家带来我们的新游戏《千手英雄》的制作手记：

孙悟空大战机器金刚

2019年1月发布了《孙悟空大战机器金刚》后，我就开始准备制作下一个游戏。

当时想要做的是一个生存游戏：一家人在末日的故事。

美术跟不上，先搁置~

星界战场

后来改为先做《星界战场》，一个回合制战棋游戏。到现在为止进入了开发泥潭。

其实所有的主要问题都解决了，已经可玩了，甚至还能联网，但就是到最后感觉开发流程到了后期变得很迟钝，这个锅主主要甩给 Unity，关于 Unity 的坏话我估计能写另外一篇，非常后悔选择这个引擎，现在正转回 Godot 进行制作。

千手英雄的初期概念

游戏的制作和准备过程很的很漫长，长期项目应该是什么？该做怎样的游戏，这些我都一直在思考。我将各种想法记录下来，同时也会扩展以往记录的想法。

2019年的夏天的时候，我正思考一个讲述一个架空时空里小学生冒险的 RPG，里面会有一个集邮系统。想着邮票有各种不同的大小尺寸，玩家可以自行编排摆放位置，不知怎的，画成了下图的样子：

大概就是一个类似画廊或者杂志拼图的的样子，当时我想里面画各种不同的游戏类型。

我想这也许能变成一个手机游戏吧，点击类型的，一个画面同时有很多个小游戏，你需要不停的点击各个格子完成格子里的小游戏。

当然跟很多其它想法和概念一样，先留在了硬盘的某个目录和笔记里。

后来我开始跟一个朋友合作做他们公司的项目，所以我白天做他们的项目，其它时间继续自己的项目。

修炼

《孙悟空大战机器金刚》用的是 Construct 3，当时做完已经觉得有一大堆弊病了，最首要的一条：订阅制软件一旦过期，可能原来的项目就无法打开和修改。

后来的《星界战场》和合作的项目用的都是 Unity。《星界战场》用 Unity 主要是合作的程序员只会 Unity，同时也想着以后移植到主机的时候能简单些（想多了）。

但是 Unity 真的不适合我，很慢很慢，所以这一段时间我都是跟 Unity 在搏斗，过程比较痛苦，也算是一种修炼。

启动

2019 年底了，想调换一下心情，恢复到一种比较轻松的开发状态，于是就把这个项目拿出来在晚上的业余时间玩一下。

不过游戏的目标平台变了，打算放在大屏幕上，不再首先考虑移动平台了，操作变为手柄，概念图大概是这个样子：

改为手柄操作之后，需要考虑如何操作多个游戏的问题，我决定使用一个切换键，每次只能操作一个游戏。

然后要扩展更多不同尺寸和类型的游戏，我先出草图，美术由老伴代劳。

有了部分美术资源后，我从自己比较喜欢的牛仔游戏开始，这个游戏的操作机制源于 FC 的《荒野大镖客》，这是 2019 年11月初的时候做的效果：

接下来是一个固定位置的 360 度射击游戏：

控制飞船 360 度旋转，发射加号和减号两种子弹，子弹发射器有过热判断，敌人是飞过来的数字，加号和减号分别会让数字增加或者减小，减小为零或者增加到10可将其消灭，越小的数字靠近得越快。

子弹时间

为了降低难度，增加可玩性，我加入了一个重要的机制，就是非当前操作的游戏要进入慢速运行状态。

概念有点点像一部电影：

《盗梦空间》

其实在游戏里面实现子弹时间已经不是什么稀奇的事情，最早的《马克斯佩恩》，到比较近的《Super Hot》:

不过在千手英雄里，每个游戏都要要求有自己的时间线，除此之外，每个游戏都需要在不同的时刻可以进行不同速率的无级变速。

要做到这点，必须解决两个技术问题：

多个游戏在不同的窗口中运行，不互相干扰；
游戏能够随时进行变速

变速的具体实施需要照顾很多方面，听起来好像很简单，但是当这些东西按照原先速率播放到一半的时候这才是变速的重点：

Timeline 动画时间轴的变速
Timer 的变速
Tween 缓动动画的变速
物理系统的变速（这点无法实现，所以不能使用物理系统模拟运动）
Sprite 和其它动画需要能够变速
逻辑的变速
游戏本体中的所有物体和组件都要遵守变速规则，粒子动画除外。

以下是 2019年11月时的测试效果：

这个游戏的主要美术形式是像素，如果只使用帧动画的话那么在慢速模式下人物动作的变化就会有明显的卡顿感，所以我们尽量在动画中加入元件的运动，这样一来慢速模式下能够产生一些帧与帧之间的细微变化（也并不是所有物体都能做到，有些还是帧动画）。

解决了这个技术点，剩下的事情就好办了。

组队

因为研究 Godot 的关系，我加入了一个独立游戏 QQ 群，认识了 Alexar。他原来是个 Love2D 的高手，后来开始研究 Godot，他经常在群里里面发自己做的各种类型和机制的游戏 Demo，我觉得很有意思，觉得也许千手英雄这个项目会适合他，于是我邀请他加入，他也爽快答应了。后来我知道他的孩子还跟我的孩子差不多大。

所以这个游戏主要的设计由我来完成，美术由我的老婆 PQ 润色把关，程序交由 Alexar 负责。

游戏类型

我们想了很多游戏类型，大多数以动作为主。当然，游戏就是各种 clone 了：

Gun Hat 模仿荒野大镖客，画面纵向卷轴，射击游戏，两个按钮实现3个方向的射击，有最终 boss；

Cyber Puck 模仿吃豆人，但是机制改了很多。红蓝药丸用的是黑客帝国的概念，迷宫实现了黑客帝国的文字流动画。吃豆人最先叫做 Puck Man 而不是 Pacman，这个估计很少人知道；

Jump Man 是一个跨栏游戏，吃了香蕉可以加速，踩到香蕉皮就会滑倒；

Candy Box 就是一个平淡无奇的俄罗斯方块，目标是消灭所有的灰色方块，但是放到挑战里面动静结合就很有意思了；

Star Num 前面已经介绍过，发射+-两种子弹来消灭接近的数字陨石，灵感来自早期矢量游戏 Asteroids；

Well Diver 这个是 Alexar 提出要做一个 “是 xx 就下100层” 的游戏。机关类型都是马里奥里面的。既然有一些尖刺，我就将主人公设计成一个气球人，被尖刺戳到就爆掉了。因为触及屏幕上下方都会挂掉，所以下方设置了火焰，上方设置的是移动的锯盘；

以上 6 个游戏就是 EA 正式版所包含的游戏。

其它还在计划/制作中的还有：

一个 RPG 战斗；

一个宠物培养游戏；

一个格斗游戏;

一个模仿 Flappy Bird 的 Flappy Clock，这个游戏的设定很早期就有，没想到后来的游戏设计得都更精美，这个得风格和复杂度已经不在同一个级别，所以后期打算改成 GB 的4色风格

一个塔防
一个赛车
一个煎鸡蛋的游戏

最终版本的游戏有 10 个或以上，不排除砍掉已经做了但是不适合的游戏。

我给小游戏顶下的制作原则是:

完成时间控制在 1 分钟左右；
游戏需要不断前进，不能有等待和要求连续输入；
抽象游戏类型的特征，简化流程；

现在游戏里达到一定的分数或者条件会得到星星，星星可以用于产生特殊效果也可以用于复活失败的游戏（就像游戏币一样）。挑战模式的分数指标主要就是完成后的用时和星星数。 Alexar 有提出过更多的游戏间的互动方式，我觉得比较复杂所以暂时没有实施。现有的游戏机制已经有足够的卖点了，如果这个游戏类型能够被人接纳，我们才能考虑进一步的进行扩充。

进化

作为主打的挑战模式，开始主要想营造一种画廊感和杂志拼贴感，所以前期的设计是这样的：

后来发现不少游戏内容都是紧张刺激和火爆的，所以我感觉要更换一下配色风格，所以改成了这样：

画廊模式

开发前期我们主要聚焦于单个游戏，我们要保证单个游戏的游玩体验是完整的，所以设置了画廊模式，可以单独游玩这些游戏，同时这些游戏会放大到两倍的大小。UI 用的是 Cover Flow 的形式：

界面 UI 方面我们采用上下左右的 XMB 式的导航方式，尽量取消次级菜单。

每个游戏的操作方式都有不同，我们设置为四个方向键加两个动作键。玩家者需要训练自己熟悉这些操作，另外我们在屏幕下方会放置当前操作游戏的简单操作指南。

关卡编辑器

关卡编辑器一开始就是两个作用：一个是我们自己用于挑战模式的关卡编辑，还有一个就是给玩家自己用了。

有了关卡编辑器，让这个游戏的可玩性大增。我们还制作了分享码系统，生成纯文本字串（类似以前 FC 炸弹人和类似的关卡密码），可以将关卡分享给别的玩家进行挑战。

性能问题

《千手英雄》中的小游戏都是非常简单的，可是当我们进入到挑战模式开发，可以同屏放置多个游戏时，性能问题就出现了。特别是放置多个 star num 数字陨石游戏时，帧数一度掉入低谷。所以我们关掉 vsync，排查了瓶颈所在：物理系统。为此我们还重构了一些底层的系统。另外我们发现 Cyber Puck 中药丸动画占用了大量 CPU 时间，最终的解决方法是通过 Shader 来实现药丸的浮动动画。资源方面，每个游戏其实只用到一张 Atlas 贴图，但是场景生成其实是需要一定时间的，所以一度进入挑战模式会使用较长的时间。现在我们加入载入过程让整个游戏的流转更流畅了。最终的结果是在一些满载的关卡里，帧数能够在 270fps 左右，这样一来，配置较低的机器也可以达到 60fps。