最近

这篇不算是一个开发日志或者工作复盘,就当是一篇单独的记录性质的博客吧.主要讲一下过去两周没更博客的日子发生的事情,以及接下来的计划和打算.

• CPKA 进度的问题
• 一个启发了我的视频
• 接下里的打算

CPKA 项目进度的问题

新的麻烦

一言以蔽之,这个项目遇到了些麻烦,是解决了一个麻烦之后又出现的新麻烦.

上一篇提到的一个已经发现的问题是做游戏没有银弹.任何玩法都是需要有一个精心制作设计过的关卡才能验证想法的.实践出真知.

于是接下来我的重心放在地牢随机生成物品和物品系统的实现上.地牢随机生成物品这一点其实是很简单的,只需要在原有的格子系统上简单粗暴地来个随机就可以了.真正的问题在于物品系统的实现.

但是物品系统的实现成本远比我想象中更高.高到几乎摧毁了我所有在独立游戏制作上的自信心.

放下情绪,冷静思考,我把原因总结为下面几个点.

物品系统的原型太庞大

其实一开始,我只想要一个可以捡起物品,可以使用物品的功能.物品捡起后消失,使用后被消耗.然后通过开新的房间随机生成来补充.如果只是实现这些功能,这个系统也算不上庞大.

但是我被背包英雄的 Mod 系统误导了.我做出了一个不太适用于这个系统的结论:如果一个系统能够通过配置来实现多样性,那么这个系统就是有趣的.背包英雄中核心元素是物品,玩家可以通过配置来为游戏制作不同的物品 mod.我当时觉得这是一个非常好的系统.

所以再回到我的物品系统,我认为我的物品系统需要足够的灵活性才能变得有趣.于是我的物品配置表变成了这样:

其实有些结论并不一定是错的,但是明显这个结论在我制作原型这件事情上是不适合的.

我的目的是验证"随机物品系统和地牢生成物品能否为战斗带来活力".但是出于一些不自信,我认为这个物品系统必须要足够复杂才能支撑我验证这件事.

这就背离了我本身做这个系统的初衷.

事后复盘一下,归根结底是我对自己的设计能力不够自信.

设计能力真正体现的并非是把系统搞得越来复杂来让整体的内容看起来充实,而是在有限的机制和元素之内产出足够有趣的东西.

我既对自己的设计能力没有自信,又对自己的判断力没有自信,生怕做出来"自以为好玩但是事实上不好玩"的东西.

其实这些不自信都是可以解决的.前者我相信可以通过不断的制作磨炼出来,后者为了避免主观性其实可以通过让其他人来玩来帮助我审视问题.

我发觉我很逃避把"有可能不完美"的作品给别人看,我希望给到别人的东西是尽可能完美的东西.

再衍生一下的话,游戏开发中有很多的准则,但是这些准则一定都拥有前提条件.因地制宜很重要.迷信某些放之四海而皆准的铁律有时候会害了自己.

最后的结果就是,我确实生产了一坨看起来很复杂,但是对于做原型没什么帮助的项目代码.

系统耦合的技术成本

系统间的耦合会带来更加高于预期的开发成本,而这种耦合会随着代码质量的下降变得更强.巧的是作为原型项目,我并没有刻意去边写高质量的代码.这一切的让本来就不快的开发雪上加霜.

在制作原型之前我学到的准则是:不要编写高效的,最终版本的整洁代码,应该更关注速度.

我确实是这么做的.但这么做的前提是:你是真的在制作游戏的原型.

这条准则的目标是效率.对于一个只实现玩法的原型来说,快速简陋的代码能够让你能够在一周之内便构建出一个原型.然后你可以选择扔掉它,再重新启动一个.

但是当你把战线拉长到 1 个月 2 个月甚至 3 个月的时候(就像我一样),这些为了快速而写的代码便不再快速,他会成为最沉重的累赘.

所以当我在原来就比较繁杂的游戏框架里想要引进一个新的框架,然后我已经写好的某些系统已经与之耦合很深的时候,我的开发速度进一步地被拖慢了.

举例来说,战斗模式下有两种操作模式:一种是移动模式:当你鼠标点击地面,他会移动;当你点击敌人,他会向敌人发动攻击.

另外一种是释放技能模式:这更像是 MOBA 游戏里释放技能的操作模式.

那么当我引进"物品系统"的概念时,操作的模式肯定是更多了.但是这可并不是 2+1=3 这么简单.因为根据我前面所犯的错误,我的物品可能有多重操作 .丢出,使用,作为武器攻击.....

于是单纯只是针对输入这一块,我不得不编写一套简单的状态模式来保证各个操作模式之间的切换完全正确.但是这些事实上对我的原型实现是非常低效的.我不得不花大半天的时间在这上面,仅仅只是为了让我的输入模式能够正确切换.

这件事听起来似乎没什么大不了对吗:设计功能,实现功能,天经地义.但是别忘记我事实上是在做游戏原型。任何让游戏原形偏离了重点的工作都应该被重新审视.

原型的重点在于快速和测量. 事实上,如果我没有把之前写完的游戏操作模式搞得如此复杂,代码写得如此随意,我事实上并不需要思考他们之间的关系.但很不幸我把能犯的错误都犯了一遍,所以在这个基础上制作的痛苦简直是我之前难以想象的.

沉迷系统的设计

程序员思维在制作游戏的很多时候是有害的.至少在原型阶段.

程序员会沉迷于"构建一套完备的逻辑系统".

比如针对我上面提到的物品系统.我的下意识反应会是:构建一套配置功能,使得这套系统能够支持我所需要的所有物品类型的配置.不要嘲笑我,但是事实上我真的是这么做的.

我当然明白,做原型的那些老生常谈:速度,效率,快速迭代.但事实上是,一旦我真的开始做,我会过早进行"系统设计".其实当我还在公司上班的时候,就有前辈提过这个问题:我喜欢过早设计和过度设计.

姑且不论我这种行为算不上过早优化和过度设计,但是事实上这个配置系统确实是比我最初的预想复杂很多的.并不是所有的程序思维都是有害的,事实上在软件工业中,如果你不提前设计一些逻辑系统,你会变得很难修改你的代码.

但是这个最核心的问题在于,我在制作的是原型:代码,工程,这些都是有可能随时被丢掉重开的东西.我在这个探索中设计的系统也许对我的后续修改能起到帮助,但是如果我不修改呢?如果经过探索,我发现这个系统完全没意义呢?

我们应当有一些写代码的经验和框架,这些会伴随着项目不断修正和补充.但是如果为一个随时可能丢掉的原型提前设计框架,属实是得不偿失.

摆烂

于是我进入了一种摆烂状态.我清晰地认识到,如果按照我现在的思路做下去,我的游戏可能要花 3 年以上的时间才能做完.显然这是我很难接受的.

在制作游戏的过程中,我的情绪会像过山车一般.当我解决了一个我认为很困扰我的问题的时候,我会认为阳光明媚,世界非常美好,我的游戏充满了希望!但是当我做了一周,意识到自己身陷泥沼的时候,我感觉我是世界上最傻逼的人:为什么要做游戏呢?

我尝试坐到电脑前,把剩下的 bug 改完,继续完成其他的任务.但是我发现我内心充满了厌恶和恐惧.

做游戏这件事不再使我享受,我甚至一想到要起床做游戏就会感觉无比痛苦.另外因为我有非常强烈的"如果我不努力工作就我的世界就完蛋了"的小镇做题家式的焦虑症状,单纯的摆烂根本无法让我放松下来思考,反而让我情绪变得更糟糕.

一些调整

这样的日子持续了 4-5 天之后,我终于找到了一个暂时缓解这件事的办法.就是去写另一个和其他人合作在做的游戏项目.

关于另一个合作项目其实我并没有在我的这个系列的开发日志中讲述太多,有时间我可能会单独开一期来讲一下.现在能知道的是:这个合作项目项目至少看起来是一个能够做得完的游戏.

不过比较搞笑的地方是,在经历了 CPKA 的马拉松式的痛苦之后,我发现这个合作项目给我的感觉就像是在公园散步一样轻松:需求精确,目标明确,有人反馈和讨论.我的目标就是单纯把代码实现,很简单.

这些事情之后我发现我的情绪相对来说稳定一些了,我能够有精力去面对 CPKA 中悬而未决的问题了.虽然还是不知道到底要如何搞定.

直到我看到了一个视频.

这个视频会改变你对游戏开发的视角

就是这个视频

关于怎么知道这个视频的也有一番来历.我一直敬仰的一位程序大佬离职,选择来做独立游戏.大佬不是很确定自己要做什么类型的游戏,于是就有很多人在他的推特下为他献言献策.其中我看到了这个视频的链接.

一开始我并没有去看这个视频,我只是收藏下来然后在收藏夹里吃灰了几天.直到看完这个视频,我才后悔自己为什么没有早点看到.

如果不是这个视频,我可能现在还在疯狂走弯路.这个视频我反复看了有 4,5 遍.我甚至把他加入了我的每天必看列表之中.

视频的内容非常丰富,事实上很多单独的论点拿出来都可以作为非常复杂的话题来讨论.

为了简洁期间,我不会重复解释他的观点的含义,我也不会把每个点都拿出来讲一遍.我尽量只结合我这两个月以来的经历来分析他的论点,用我的实际案例来佐证他的观点.

游戏设计就是搜索算法

这个思路算是蛮新颖的.不过对我来说,我其实一开始就知道我想要什么样子的游戏,我不知道的部分在于如何制作有趣的游戏.

搜索算法的关键就是步进和测量.步进决定了你的搜索如何前进,测量决定了你是否能够正确评估你的搜索结果.有了这两个基本要素以后,我们就能展开后面对于这个搜索算法的优化讨论.

局部最小值

我在制作地牢模式的时候遇到的第一个问题是:我发现战斗不够有趣.上一篇博客其实提到了我如何在专业策划的分析下思考战斗系统的问题.

其实这个问题也来源于我被局部最小值困住.我基本上还是按照原作山中小屋的模版在设计.但是我又很明确我不想做一个山中小屋的电子版本,我希望有所创新

这时候山中小屋这个模式其实就成为了我当前这次搜索中的局部最小值.我认为他是好的,我不敢迈出大的跨步,生怕完全偏离了这个我非常欣赏的玩法.所以在面对战斗系统的设计问题时,我无意识之中会疯狂地抑制与山中小屋想去甚远的设计.直到别人点醒了我.

那么这个点醒我的设计是一个精妙绝伦到我完全无法想到的设计吗?不是的.是因为我在这篇海域中,找到了一个我认为的局部最小值.局部最小值问题不仅仅意味着误判,他还会导致故步自封和缺乏创新.其实这也是很多独立游戏体现出来的通病,他们把原作当做是一个局部最小值.这种思维会导致开发者下意识之中不敢去做真正让自己的游戏能够在这个品类中脱颖而出的创新.

解决这个的方案是采用更大的步进.既然是原型,其实可以大胆地迈步向前.反正就算失败了天也不会塌下来的.对我的项目来说,这套地牢的地形随机系统算是一个大跨步.甚至我认为可以跨步更大一些:如果能够像堡垒之夜那样搭建地形会如何?像这样的点子其实可以想出很多,完全没必要在一个已经确定的领域里故步自封.

局部最小值还意味着一件事:如果做游戏的时候被卡住了,你完全不必惊慌失措.这只是搜索中很小的一部分.可能你只是恰好跳到了一个比较浅的局部最小值.相反,如果你对自己的原型非常满意,你仍然应该尝试大的跨步,因为你有可能陷入到了局部最小值的陷阱中而导致失去了制作更加有趣的游戏的机会.

商业游戏的成功公式:(Fun+Appeal)/Scope

我认为这个比之前那套 Hook 和 Mechanic 机制更直观,更具有操作性.Fun 代表游戏的乐趣,他决定了游戏是否能够留住玩家.Appeal 决定了游戏能否吸引玩家.Scope 决定了你的游戏能不能做完,你的投入产出比如何.

这里特别要强调下 Appeal 的公式,乔纳森提出了一个非常精妙的公式:Appeal=(presentation+fantasy)*Readability.长久以来对于这方面的总结是非常模糊的,不够精确.我模糊地把这些一切称之为"感觉".

如果用这个公式来分析我游戏的 Appeal,我更多的方面其实倾注在 presentation 上.但是像我一直以来的终极目标:<< 邪恶铭刻 >> 这样的游戏,他其实花了很多心思在 Fantasy 和 Readability 上.我不确定我在制作这款游戏的美术水平能够到什么级别,我暂时应该也不会花核心的精力在这部分上,但是我希望自己能够更多思考 Fantasy 和 Readability.因为我之前并没有像这样准确地意识到他的存在.

探索是有代价的

事实上,非常多的游戏开发者没有意识到这个问题:探索游戏类型代价远远低于在错误方向上继续做完游戏的代价.很多失败的项目,究其原因,就是他们根本没有在游戏上做任何探索.

探索是很昂贵的.几个月一直制作很多以后永远都不会再被使用的代码,这往往会让一个人害怕.但是正是这些探索,让整个游戏的方向足够扎实,也为了为了制作打下坚实的根基.

之前我的一个恐惧的点是:我害怕过长的开发周期.这没问题.但是我把原型的开发周期和整个游戏的开发周期挂上了等号.事实上这是完全不科学的.既然是探索原型,那么这注定了这个搜索过程中,绝大多数的工作最终是会被完全抛弃掉的.但是这些被抛弃掉的工作所消耗的时间,和你确定了方向以后制作整个游戏的时间是毫无关联的.

尤其对于我这样的个人开发者:我更需要做充分的探索.因为一个人的产能本身就很有限.如果在错误的方向上耕耘太久,结果是毁灭性的.

另外一点是:你失败的探索是非常有意义的.其实我前面对于自己 CPKA 中很多写的代码和做的功能都抱着"我怎么浪费时间在这个上了"的那种痛心疾首的态度,事实上也是不可取的.我一直坚信清晰的错误远好过模糊的正确 .比如我曾经想要制作一个异步战斗的模式,但是后来通过几天的制作以后我发现:这件事不太靠谱.于是我放弃了这想法.现在来看这件事对我来说很有意义,我放弃了一些东西,意味着我的搜索算法更优了,我找到了我能做的更好的方向.

想到了一个设计的小笑话:甲方经常让乙方改 20 版需求,最后用了第一个.其实这件事是有科学道理的,乍一看,好像一开始就有最优方案了,后面的 19 种都是无用功.但事实上,如果你不做后面的对比,你根本没办法知道第一种就是最好的.

当然,探索一定有代价.反反复复丢掉项目和工作也不是一件容易得事情.这就需要使用原型制作 来进行探索.从这个角度出发,原型探索最重要的两件事:测量 和快速.

如果你的游戏原形丢掉了这两个点,那么你就要小心了.

游戏原形:分开制作程序原型和美术原型

很好笑,很简单易懂的道理.我却依然犯错了.

开始我给自己的理由是:我需要在做原型的时候来摸索游戏的"感觉".现在想想真是扯淡.用视频作者的话说:如果你同时在做玩法和美术,这就不叫做原型了,这叫做游戏!

这几乎是我前面所有不安感的核心病因.如果我兼顾美术和玩法,我自然没办法很快地修改我的代码和玩法,我也没精力去做快速地,大幅度的探索.最后我的游戏就会变成一坨不明所以的答辩.

但是对于边写 Clean Code 这件事,我认为还是有些必要的.事实上有时候 CleanCode 并不会花费我更多的时间.但是修改 DirtyCode 会让我整个人抓狂.

这个方面的优化也是我接下来要做的核心内容:我要把现在的工程完全扔掉,然后摘一些我认为可能有用的代码出来,然后重新开一个工程专门用在制作玩法原型.

做决定不重要

这件事其实在上一篇文章就提到了:游戏设计没有银弹.不过我更深的体验是:踩坑这件事是没有银弹的.我过去经常看一些开发经验分享,心里有时会暗暗想"这些东西我都知道啊,是我的话一定开始就会避免这些问题的".

事实上就是,我不仅在知道的情况下还是狠狠犯了,而且屡教不改.

所以如果说现在比起两个月前,我最大的进步就是:我更能把失败和挫折当做是一种奖励了.这件事并不是一句鸡汤式的口头禅,是我真的感受到了失败的力量.所有的失败都不是最终的失败,失败只是代表"我陷入了局部最小值,我需要优化我的搜索算法".

接下来

写完这篇日志,已经是早上 7 点半了.

当下之急是拆一个玩法的原型出来,然后探索玩法.

然后继续做游戏.

写到这里还是蛮感慨的.很多时候其实我意识到了,我并不如我看起来的那样自信.很多时候我会选择逃避来维持那微不足道的自尊心.

到今天我辞职也已经 1 年 2 个月多了,这 14 个月里,真正从头开始认真做这个项目也就 50 天.(今天整整 50 天).这 50 天以来我虽然也中途摆烂过,但是我依然认为这些时间是宝贵的.摆烂也是努力的一部分

我很难想象我写开发日志和复盘的这件事会给我带来如此大的成长.甚至我觉得在公司工作那么多年都没有我这 50 天来的收获大.虽然我真的还没有做出来任何我自己满意的东西,但是我非常清楚我在做游戏这件事情上已经迈出了小小的一步了.

这件事情的神奇之处在于,它让我我真的觉得才能是可以不断磨砺的 .如果我当时没有下定决心辞职,如果我没有强行让自己像现在这样子几乎闭门不出,如果我没有强迫自己去思考,去接收,去和同道交流,我根本不会有现在的成长.我比我以往的任何时候都要更加冷静和自信.我也真的非常确信我能做出好的游戏.

其实人一辈子有多少机会能认认真真,心无旁骛地做自己喜欢的事情呢.说实话,我身边的家人朋友都非常支持我,给了我很多支持和帮助.我非常幸运能够拥有这样的机会来在这样的时候磨砺我自己的才能,这真是全天下最好的事情了.

我不知道我什么时候会做完我的第一个游戏.但是现在的我很期待那时候的我如果再回头看现在这篇日志,又会有多少新的感悟和体会呢?

我不知道

但这恰巧是最美妙的部分