Lisp与游戏创作:游戏创作的心态与体验谈

最近几天生病了,不过直到身体出问题的时候,我也终于开始反思为什么我总是做不完游戏了,和朋友讨论了下个人开发游戏应有的心态和体验,打算通过这篇文章整理下自己的心得。

虽然标题是Lisp与游戏创作,不过实际上我打算讨论的内容是更广泛适用于各种游戏创作的心态和思路的整理。

写在前面

最近几天生病了,不过直到身体出问题的时候,我也终于开始反思为什么我总是做不完游戏了,和朋友讨论了下个人开发游戏应有的心态和体验,打算通过这篇文章整理下自己的心得。

虽然标题是Lisp与游戏创作,不过实际上我打算讨论的内容是更广泛适用于各种游戏创作的心态和思路的整理。

做游戏开发者,不做引擎开发者

虽然这个标题是很有误导性,毕竟很多游戏开发者同时也是引擎开发者,但我其实想强调的是,游戏开发和引擎开发的心态其实是完全不一样的。

实际上,前一段时间我整理我的日志的时候,我才意识到,从2021年底开始开发第一款游戏,到现在2026年,不知不觉已经投入游戏开发近4年的时间了,即便如此,这4年还是几乎没有任何一款游戏真正做出过成果。

而且直到最近,我还是一味地重复之前走错的道路,一味地想要自己造轮子,一味地专注于开发游戏引擎,而忽视了我应该是一个游戏开发者,而非游戏引擎开发者的主次。

就是说,其实开发游戏,和开发游戏引擎的心态和成就来源,是完全不同的。

如果把开发游戏比作做蛋糕的话,开发游戏引擎就像是制作做蛋糕的工具,虽然同样是做蛋糕,但我想应该没有多少人会为了做蛋糕刻意自己从模板开始制作一个做蛋糕的工具吧。

开发游戏其实最重要的是游戏的玩法和迭代深度,以及游戏本身都靠内容堆量和堆料做好,量变产生质变。

尤其是我个人的思路其实更倾向于从剧情和世界观塑造开始设计游戏,所以其实我更适合开发偏剧情向的游戏。

虽然我同时因为受从小最喜欢玩Minecraft这个游戏的影响,又倾向于开发灵活和可扩展的游戏,但这个程序游戏设计的思路本身和开发剧情向游戏的思路也是有一定矛盾和张力在的。

因此,如果我为了开发一款游戏,花费几个月甚至几年的时间来制作和准备开发游戏必备的工具链的话,实际上本身就已经偏离了开发和设计游戏的初心。

我创作游戏的初心,其实很简单,只是想要做一个能和梦暮暮一起玩得开心,能表达个人想表达的东西的游戏,塑造许多不可思议的情境,当年第一个游戏的灵感就是看少女终末旅行得到的。

由此可见,现在一直以来这种不断切换工具,不断实现功能和在游戏引擎上造轮子的思路,算不上健康,也不应该是正确的游戏开发思路。

说得不好听就是,这5年,我基本上大部分时间都在做的事情是造轮子,制作工具,然后幻想着做好之后就能用工具轻松做游戏,回避设计和迭代游戏玩法本身的复杂性与难度。

哪怕是在切换到Trial之前,用Godot做游戏引擎的时期,我做的事情,说白了依然只是在做工具,而不是做游戏。

就像是我们同人社团的社长之前告诉我的经验一样,制作游戏应该用最好用,能最快做出原型并验证自己设计的工具来做。

因为游戏设计的本质,从来都与程序无关,是将自己的体验和想表达的事物凝聚,并分享给他人。

况且,现在绝大多数游戏的玩法,其实就算没有引擎,依然可以用纸面原型等方式模拟出来。

而且,写程序的思维方式,和做策划的思维方式,是完全不一样的,做游戏的成就感更多地应该是来自亲身感受游戏的趣味,体验游戏的内容并玩得开心。而开发游戏引擎,成就感更多地是来自实现功能,让功能成功运行起来。

此外,制作游戏引擎和制作游戏,解决的问题也不一样。

制作游戏引擎解决的问题是重复性、经验性的问题,如果没做过完整的游戏,没有开发游戏的经验,自然也不明白该如何制作游戏引擎,相反,如果先专注于开发游戏本身,那么也可以将游戏本身抽象和可复用的逻辑抽离出来作为引擎层的功能。

因此,停止做引擎开发者,制作游戏的正确步骤绝对不是从制作游戏的工具开始,然后将所有时间花在工具上,而应该是,先专注作品本身,将游戏本身的玩法迭代好、将游戏本身的剧情设计好,等模型固定下来后,在寻找最适合做这个玩法的工具。就算是Shinmera,实际上也是先做了Kandria,再从中逐步脱胎而出Trial引擎的。

要做到这两者的工期也相当不同,游戏引擎通常比开发游戏本身工期更长,甚至更难完成,制作它需要付出更大的代价和成本,虽然未来也可能带来更多的好处。

也许,大部分开发游戏引擎的开发者,都是做出了某种程度的觉悟,也就是愿意牺牲自己生命最重要的大部分时间,并能乐于从开发引擎的过程中获得成就感和乐趣的人吧。

最近和朋友的讨论点醒了我这一点,这里我也非常感谢那个一直以来支持我,并能在我走火入魔的时候把我拉回来,非常关心我的身体健康的朋友。

游戏设计师与程序员

最近这段时间,我其实是摸索着用了两个月的Trial引擎,使用Trial开发游戏的体验本身其实是有史以来最好的。固然,使用最顶级的开发工具和最纯粹的编程语言来开发游戏,是我这种技术派游戏开发者的终极梦想和追求!

但是很可惜的一点是,游戏设计和程序员的思维和设计逻辑是完全不一样的,某种意义上甚至可以是冲突的,截然不同的两个路,所以我必须抑制我心中的程序员,才能更好地发挥游戏设计师的特长,同时让心中的游戏设计师得到成长。

太过专注于游戏程序本身的开发,并抱着快点完成工具才好做游戏的心态,说白了只是找了个借口,用程序开发短期的成就感回避游戏开发长期的迭代和测试罢了。

这样来看,对游戏设计师来说其实是有害的,因为它不仅仅会让你忽视身体健康来过度透支,还容易让你陷入一种习得性无助,导致动机和热情大幅度被消磨,逐渐忘记初心。

主动限制与被动限制

用Trial开发游戏的时候,我其实总是想用自己给设置限制,避免游戏的规模超出预期,避免游戏立项设计脱离现实,以及用Godot易用性更差来安慰自己,仿佛用Trial引擎就是给自己设置了限制一样。

但其实,这是有害的,因为Trial引擎的限制是来自社区功能和文档欠缺,它不像PICO-8 TIC-3这类虚拟主机,以及EasyRPG这类引擎那样,是主动选择的限制,而是来自文档和社区欠缺,缺乏足够经验,被迫重复造轮子的被动限制。

因此,我们应该分清楚主动选择的限制和被动选择的限制,同时应该避免将自己做不出好游戏的原因怪罪于工具不好用,事实上工具不好用不会影响自己做游戏,就像RM这样对程序员来说非常难用的工具,同样也有很多人会用它做出非常优秀的作品, *真正优秀的游戏开发者擅长在给自己主动设定的资源限制内完成作品。*

糖霜还是蛋糕坯?

这是一个很著名的比喻,来自 Lisp: Icing or Cake? — dthompson ,大意是说用Lisp开发程序的两个选择,是拿来做蛋糕坯还是糖霜,做蛋糕坯更为艰难但是会带来更大的好处,做糖霜能够直接带来回报但是会受限于底下的坯体。

从要用Lisp开发游戏的视角来看,也许糖霜流派才是最明智的选择,这其实是我用Trial开发游戏的亲身体会。

因为,游戏引擎的技术复杂度,和一般的程序是完全不同的两回事,其它普通的程序解决的问题都是单一的,线性的问题。

而游戏引擎需要解决的问题,不仅仅是游戏本身的逻辑问题,更像是一个多面向性的,更广泛,更综合的问题。做蛋糕坯这个流派固然非常艰难,但制作游戏引擎将蛋糕坯的难度放大到个人几乎无法承担,就像是画了十年孤独坚守的勇士Shinmera那样,我要向这位勇士致敬。

实际上我也压根无需证明Lisp能不能做游戏,因为Shinmera已经做过了,我需要证明和解决的问题是,用Lisp做游戏究竟是否会比一般语言做游戏更优雅,更轻松,这次是我使用Lisp的初心,我想要用Lisp作为我的游戏的Modding语言,并且让任何人都能更轻松用S表达式写游戏的剧情、关卡等定义,同时还能让他们更灵活地开发游戏。

其实我最大的愿望是,总有一天,即便是不懂Lisp语言的人,也能用着Lisp方言写的DSL来定义游戏剧情,或者用Lisp方言写的DSL来定义类似RM事件系统的逻辑那样,而不是流行所有事件逻辑全用鼠标点,或者逻辑系统连线乱七八糟这种心智负担超高,效率也超低的玩意。

或许,我也完全可以直接只专注于写一个能兼容各个游戏引擎的Lisp DSL,允许大家用这个DSL来做剧情之类的。

仔细想,这个理想,其实压根也没必要走蛋糕坯流派,哪怕蛋糕坯流派技术上更优雅,而且理论上也会更灵活。

但是,也许用Lisp做蛋糕坯的这个思路,也就只有当出现强有力的社区的时候能实现了吧,目前依然还是糖霜思路最适合且最通用。

社区的力量

在这里,我要说出一个残酷的事实,那就是,技术本身并不重要。没错,重复一遍,技术本身并不重要。

实际上,玩游戏的人也没人会关心技术实现,选择贡献什么开源软件,更多的人也会倾向于观察这个开源软件的生态怎样,支持面多广,有没有人解决了自己遇到的额外难题,而不是技术实现本身。

因此,技术本身并不重要,这就是一个残酷的真相。

哪怕理论上,开发游戏最好的选择还是用Lisp来开发游戏,但Lisp因为没有社区生态的问题,因此在主流应用领域长期被边缘化,这也就导致技术本身并不重要。

那么真正重要的是什么呢?社区和生态!

之所以开源软件和自由软件能蓬勃发展,都离不开强有力的社区和众多的志愿者和贡献者们共同维护。为什明明自由软件的选择更好,大部分人还是会倾向于选择商业闭源软件?也是因为这部分商业软件的社区更加成熟和稳健,用的人更多。

由此可见,软件领域里面,其实技术和程序本身从来都不是最重要的,最重要的是社区,一个自由软件项目只有拥有强大的社区基础,才有可能成为主流。

所以,Lisp哪怕理论上是编程语言的终点,大部分人还是因为缺乏足够的社区生态而对其敬而远之,因为Lisp本身缺社区,大部分人也不愿意折腾,从而导致更多人对其更加敬而远之和产生畏惧感。

或许,正是这个原因,才会使得将Lisp编译成别的语言的实现反而更为流行,从而催生出像是Clojure、fennel、hy、chicken scheme这样的lisp编译为其它语言脚本的Lisp设计流派吧。

冷知识:其实Fennel才是最适合用来开发游戏的Lisp语言,毕竟一开始Fennel一些人就是为了用lisp优雅地开发游戏才被发明的。

看似选择很少?

其实,我之所以要用Trial引擎,是因为Trial是Lisp写的,而我一直认为用Lisp开发游戏才是游戏开发的终极选择,因为理论上Lisp天生就是最适合开发游戏的语言,只是因为某种特别的原因最终没能被大量使用。

还有一个原因,是因为我总是觉得Lisp开发游戏的选择很少,除了Trial之外,好像只有Chickadee?但是Chickadee这个Guile写的游戏软件似乎功能实现也没Trial强?

其实,这些都是表象,之所以看似选择很少,大概率是因为我的认知都被限制在了只能用Lisp做蛋糕坯的那些选项中,而且我只看了网站上放的文档,并没有深度调查和我一样用Lisp做游戏的那些人的社群,从而导致我觉得自己选择很少。

其实,无论是自由游戏还是用Lisp游戏,这两个流派,都有非常多的选择,只是因为信息差的缘故,导致我并不知道很多人还是在用Lisp开发游戏,而且Lisp开发游戏的社群也是很大,反而我选的Trial是Lisp开发游戏的各个流派里面社群最小的。

根据我最近的了解,Lisp做游戏最主流的社群其实都集中在Fennel,因为Fennel本身就是一个可以编译成lua的lisp方言,据说TIC-80主机就能用Fennel编写。

搞清楚你的受众,而不是担心经济

初入独立游戏开发这个坑的时候,我经常因为看B站上讲述独立游戏开发者生存率多低的视频,从而对经济产生担忧,越是担忧,越是会影响到开发游戏的心态。

这几年我发现,我心情都比较急躁,反而急着快速完成专注于眼前的开发,失去了对游戏开发过程的享受。

但实际上,游戏开发本身就是为了放松心情,如果为了眼前的游戏开发而过于担忧,或者因为一些游戏开发的方向比较冷门,哪怕感兴趣也不会选择,那实际上也是偏离了我想要玩游戏开发的初心。

而且,游戏开发其实更重要的,难道不应该是搞清楚你的受众吗?

实际上,长期来看,只要有足够的受众,能长期获得被动收入来源,即便不需要大量的积蓄,也能创造出超过积蓄的财富。

因此,经济问题其实并不重要,恰恰相反,能否赚钱往往都取决于你能给他人提供和创造多大的社会价值。

由此可见,搞清楚你的受众群体,比起一味地对发行商妥协,并幻想做出什么惊天动地的大作在Steam上卖得很火,反而是最好的选择。

所以,最重要的还是,游戏创作应该是一个自己玩得开心,朋友也能玩得开心的,同时受众们也能玩得开心的劳作,如果觉得自己做游戏不开心,很痛苦的话,还是反思下自己目前的设计思路是否是哪里搞错了比较好。

最重要的还是,想清楚自己最初为什么开发游戏,为什么想要选择这条路线,也许走游戏开发这条路就是需要不断的检查和反思自己呢。