今天，我做了最后的检查测试，我按下了发布按钮，长舒了一口气。

耗时俩月的开发，耗时俩月接steam……老实说还是做游戏本身比较开心。

既然是发布的日子，我就写篇日志回忆一下开发过程吧。话唠流水账叙事，只为给自己看。

作为游戏从业者，到这一刻才真正拥有自己的游戏，说来不容易，其实也挺简单的。做了这么多年的积累，真正要自己做的时候会发现一切都是水到渠成的，没什么难度。

去年10月辞职后，我花费了大约1个月的时间熟悉Construct2这款无代码编程的游戏开发软件（有兴趣请加入站内的Construct2/3小组）。简单做了一些小案例尝试了一下，就决定做一个完整点的游戏。

团队开发和个人开发的区别

正式开始前，我花了一周的时间自己和自己磨合。为啥要磨合？因为是一个人做游戏。

我之前做过美术和策划，程序写过脚本语言，管理过团队，带过项目，但从来都是团队开发。

所以第一周的工作，就是让不同分工下的自己互相磨合，理解什么东西该交给美术potion，什么东西应该交给程序的potion。

这听起来很扯，但实际情况是，在合作开发中往往会有分工上的扯皮。例如一个小功能，是程序写代码实现动态效果好，还是写死好，或是美术直接用动画效果来做，亦或是设计上妥协更换需求效果。

在合作开发中往往会因为这些问题先讨论功能需求，分工，时不时还因为工作方法的不同互相扯皮。

但在独立开发中，一切问题都消失了，自己和自己的合作，一切都以最优解为最终导向，所有分工的目标一致，互相“商量”得到最优解。

最终的成果令人惊讶，实现功能的效率估计比合作开发快4-5倍。一些非常有效果的小功能，在团队中可能会因优先级的问题直接移后一直拖着直到开发完成都没实现。个人开发却可以在几分钟内就实现，再几分钟就完善了效果。

所以当我只花了一个月的时间就把游戏完成了，我表示自己也很惊讶。（第二个月为了上Steam大改了UI）

开始制作的几次设计完善：

    最初的原型

最开始，这是一个仿照BB弹的练习。我爱死BB弹这个游戏了，一看到就沉迷其中并且真的玩了很久很久。

这是开发第一周的版本：

简陋的不行对不？这不重要。

我在这一周学习了大量的东西，并把这个粗糙的游戏原型做到了“可玩”。

你可以看看当时的版本，这个版本至今还有地址保留：

http://1.potionc.applinzi.com/bbbound/index.html

在这个过程中，我遇到了一些问题。比如BB弹的小球很小，上面的方块又很大，如果把两者都换成一样尺寸的人类和僵尸，是否还能像原作一样有很好的手感和碰撞的空间感？只能尝试了。

    泡泡龙

我在网上买了像素绘图软件Aseprite，开始一边绘制，一边思考游戏该做成怎样。

这时我突然想起，很久以前我也曾经做过一个带有攻防数值的泡泡龙LIKE的设计方案，于是就想出来这个新玩意。

我将敌人做成了像泡泡龙一样错位的出现，同时将僵尸的实际碰撞尺寸修改的很小，这样终于解决了碰撞问题。

但这还不是关键，消除类游戏的特有爽快感在泡泡龙式的“同色相消”规则添加后出现了。

    像素精度

与此同时，第一版角色出炉：

是不是看着还挺像回事的？然后我就发现我把自己坑了——做为像素游戏我绘制的太精细了，导致根本不像像素风格。与此同时场景在这个精细度下根本没法画。于是我重新绘制了几乎所有资源，缩小到了原来的1/2尺寸：

    感染

经过一番的努力，我把游戏的基础框架搭了出来，并将试玩版给一些朋友体验。

有一天，群里有人突然说：僵尸为什么不做感染？

我说：一开始打算做限制僵尸个数+感染获得新僵尸的，但现在不是这个玩法了，做感染的僵尸会给人获得僵尸的错觉。

然后我突然灵机一动，让僵尸感染后直接继续弹不就得了？场面越混乱越好。

实际也是这样，随机产生的感染让游戏充满不确定性和爆发性，甚至有可能因此一次消除全部敌人。

开发日志

因为是辞职自己做游戏，媳妇很快就问我啥时候去上班，不能这么一直吃老本儿，所以响应号召我给自己定下了春节后就上班的期限。

在我开始做独立游戏开发之前，我就比较担心自己的开发状态。因为在家太舒服了，随时可以床上一躺，或是泡杯咖啡，叫个外卖享受一下。而做之前也听闻很多业余团队或网络团队效率低下，导致研发周期非常漫长，节奏缓慢。

所以我恢复了之前的工作习惯，RunningDead的开发期间，每天我都会写Review。从11月13日到12月4日，游戏核心内容的开发期间每天我都会将当天的开发内容，以及第二天打算解决的问题都列出来，这使我的开发效率大大提升，每天都知道该做什么，而不是浑浑噩噩的做一天算一天。

设计思路上的转变

在行业里问一下，游戏行业里有多少策划知道什么是FSM（有限状态机）。

我在行业里这么多年，很少有见过策划理解这个，甚至和程序区讨论FSM的设计。

在独立开发的过程中我发现，FSM其实根本不应该只是程序的工作。作为提出需求的策划，如果无法理解和设计状态机，就是在乱提需求。设计逻辑可能自己都说不清，说不通。

事实上国内大部分策划提的需求也都是仿某游戏的某个玩法逻辑，好一点就是去尝试罗列这些逻辑或规则。

罗列的坏处就是往往逻辑规则之间会产生冲突无法自洽，这个时候很多人就会用新的逻辑去补坑。最终产生的结果就是一个多重条件多重判断的需求。我能体会程序大哥们此时万匹神兽踏过的心情以及想要丢给策划让他自己去写if else脚本的冲动。

自己做开发的过程中，以策划的思路去设计，以程序的思路去再设计。直至打磨出思路清晰效果完善的设计方案，再执行开发。

对我来说，这是本次自己制作游戏的最大收获。