---

从小就被教育“少说多做”，我可能是这句话的极端体现——在做出来之前我是一点不说，生怕鸽了之后哪天突然被人问起来“欸你那啥啥啥做的怎么样了？”后只能尬笑。但这也有个坏处，我啥都不说就意味着我在避免了别人问出这样的问题的同时，我可以毫无心理负担地想鸽就鸽，一个项目做到什么程度全看我兴致能持续多久。

写了这么久的歌、乐评和游戏评，大概已经没人记得我其实是折腾计算机出身的。小时候算是系统学过一年 C++，而在系统学习那玩意儿的三年前我就开始写 HTML 了。我其实不喜欢写代码，算法能力也相当难看，只会靠暴力模拟解决问题。但再怎么说也好歹接触了编程快有十年了，虽然大多是无心之举，却也拓展了不少技术栈。

犹记 2019 年初，时值杭城深冬。我与同学一合计，打算做个音游出来。域名当即就买好了，官网也顺利建起来了，甚至友人还免费送了一首曲子，但游戏却迟迟未动工。一方面，我和同学均没有游戏开发经验，从何下手成为了最棘手的问题。另一方面也是升学期，闲暇时间极为有限。升学之后我与同学去了不同的学校，这个项目也就随着我们联系的中断而成为了一个悬而未决的历史遗留问题。

老朋友们大概会对许久之前的一篇博文有些印象，是我灌水 Unity 一阶段学习毕业的事（现在已经删了）。2021 年初我也向 Arcade（Arcaea 非官方制谱器）的作者 cnSchwarzer 写过一封邮件向他寻求音游开发的建议，也尝试着编写了这个项目的 Development Document。总之从 2020 年到 22 年这三年间，我无数次地想将这个项目重新从历史的垃圾堆中翻出来，却总是因为这样那样的理由又将其搁置。

这篇文章诞生在 2023 年 9 月，距离立项已有近五年。写这篇文章并不是我良心发现，觉得再这样下去不行，得“先说出来”，这样就有督促自己做的动力了。不不不，我依然是那个“不做不说”的人。这篇文章并不是音游的启程纪念，而是我终于觉得音游开发走上了正轨，现在说出来应该无妨了。故此敲下这篇半是开发日志半是回忆录的文章，算是一个小小的宣传和经验分享，也是略有自豪地宣告：“我那在太空流浪了五年的音游终于落地了。”

当我们在谈论游戏开发的时候，我们究竟在谈论什么

如果要问我游戏开发最重要的事情是什么，我会毫不迟疑地回答：“先做出来再说。”

别急，这并不是要你一次性就把游戏做完。这个“做出来”的标准其实是非常低的，你只需要完成一个原型，能体现你游戏核心机制的原型就够了。不需要精美的 UI 和美术资源，不需要想资源流动和循环，不需要搭底层框架，先把原型做出来再说。

事实上，没人能一次性从最开始就把所有的底层框架搭好，然后再开始填充功能。不说麻烦，这个迭代开发的效率是极其低下的。你或许觉得搭好了底层框架对后续开发大有裨益，磨刀不误砍柴工。这个定论单拉出来是正确的，但放到一个具体项目中是欠考虑的。或者说，搭建框架应该是在你制作完原型之后，把游戏的整个资源循环想明白了，大概知道有哪些模块了，再去做的事情。

之前和学校里搞游戏开发的同学交流过，他说的有一点我印象很深刻——绝大多数游戏是基于存档构建的。存档才是核心模块，其他所有模块本质上都是在和存档做增删改查。虽然在游戏开发初期你可能并没有想好资源循环，也不知道存档究竟应该包含哪些东西，但也请尽量确保在写存档类的时候有足够的弹性以支持后续的开发。同时尽量降低模块与模块间的耦合度，转而去与存档做交互。

有次刷 B 站的时候也刷到了一位国外独立游戏开发者的采访视频，看完只记住了一句话——“No Zero Precent Day”。他身为有家庭的程序员，每天只有孩子睡觉后的一个小时用来开发。他如此坚持了三年，最终完成了一部“足以让他辞职去做独立游戏开发者”的独立游戏。

所以如果你也在考虑自己开发一个游戏，却苦于不知如何开始，不如试着先完成一个原型，在制作原型的过程中逐渐思考游戏需要的模块与资源循环，为正式的开发做准备。有个原型还有另外一个好处——只要你不是像我这样保守且社恐，你完全可以拿这个原型去找合作伙伴，获得稳定的美术、音乐、文案等资源来源，甚至可以拿着原型四处游说拉投资。Talk is cheap, show me the code. 这句话并不是空穴来风，毕竟空手套白狼是项技术活，有个原型能让你的可信度提高不少。当然，一份可观的 Development Document 或者具有冲击力的 Concept Art 也同样有效。

我艰难的音游启程之路

正如前文所言，我在开发的是一款音游，面向的平台是移动端。在面对一个具体的游戏项目的时候，开发流程通常会有一些变化。以我正在开发的音游为例，我第一步并没有选择制作原型，而是制作制谱器（关卡编辑器）。做出这个决定是基于我的两个判断：第一，音游的关卡重复性强但数量多，给每个关卡做一个单独的场景不现实，因此需要规定一种文件格式让游戏能够读取并直接生成相应关卡；第二，制谱器与音游的核心功能是相近的，就算代码无法直接照抄，其渲染音符的逻辑是相似的，可以提前为游戏本体的制作踩一遍坑。

于是在今年四月底，我正式开始了制谱器的制作，过程中经历了不少难点。印象比较深刻的是谱面的序列化与反序列化，谱面预览，还有时间与节拍的换算、调整与显示。而由于我是第一次写大型项目，没想着做 View 和 Model 的分离，基本上是想到了需求就直接往上安，完全不考虑模块之间的耦合度。于是以极低的代码质量，我在今年 6 月完成了第一版制谱器的开发。由于期末周等一系列原因，中间并不是每天都在开发，真正的开发耗时应该不到一个月。

在制谱器初步开发完毕后的第二天，我新建了游戏本体的 Repo，准备着手游戏本体开发。同时制谱器的更新和维护也没停下。合作的谱师在使用制谱器的时候常常会遇到一些 Bug 和一些新需求，我基本上就维持这样一个双线开发的状态。

就算如此，我也暂且没有推出制谱器来寻找合伙人的打算。那时的想法很简单——把游戏核心功能写完，去约两张 CG 作为视觉效果图，然后再做概念 PV 发到 B 站上，从而起到宣传和招募的效果。八月初我写完了核心游玩功能，不过当时正在西藏旅游，就做了一些周边的辅助性工作，比如和叉鸡折腾了半个月把 Apple Developer 办了下来以便在我自己的 iPhone 上测试（后续表明 Apple Developer 只是难关的第一步）。八月中旬我的两位友人生日，我又暂且搁置开发转而把两首生贺曲写完。写完生贺曲又回了一趟故乡，待了两三天又飞回深圳——和友人约了一起去八月底广州的 CPSP。可以说整个八月我几乎所有的开发都是在动车上完成的，好在 Unity 没网照样跑。

这个过程中我试着去执行当初“简单的想法”，但各个绘画平台画师的报价令人望而却步，思考了许久，打算先在空间试试看能不能找到合伙人。未曾想列表里真的有画师对这个项目感兴趣，惊讶之余立马与对方取得了联系，相谈甚是投机。也同时联系上了以前的学长，据说对制谱颇有研究，遂邀请他来协助制谱。

而这两员大将也贡献颇大。画师是动画制作专业出身，我在与她交流的过程中讨论并确定了后续需要用到的美术资源与剧情表现形式，她也很快开始了立绘与 CG 的绘制。谱师学长在使用了制谱器之后，抛出了一系列颇具建设性的意见。刚好游戏本体的开发告一段落，我在几天内对制谱器先后增加数项功能，以支持谱师的制谱需求。截至撰文的今天，制谱器已迭代至 0.3.3b 版本，与两个月前的版本对比下来，使用体验已是天壤之别。尽管之前高耦合度且不具章法的代码令我看了就想砍了以前的自己，但也不得不承认这正是几个月下来 Coding 能力实质性提升的体现。

由于制谱器毕竟只是关卡设计工具，我暂且没有闭源的打算，你可以在 Github 上找到这个 Public Repo，这是直达链接。比较遗憾的是为了支持 Windows 原生 Dialog，目前制谱器仅支持在 Windows 上使用。

后记

这篇文章其实几乎没涉及音游本身，几乎都是在聊一些外围工作，但也正是这些外围工作贯穿了我这几个月。虽然此前没写过开发日志，但我向来希望我写下的文字不需要有专业知识也能体会到其中的乐趣。所以我无论如何都不打算涉及具体机制的详细实现，也不会分享开发中用到的的奇技淫巧。我不是个写代码的，我是个讲故事的。

当然，也正如前文所言，这篇文章多少希望能起到一些宣传作用。如果你看了这篇文章之后觉得对我这小小的音游项目有些兴趣，想参与开发，那随时都可以给我发邮件。当然，请在邮件中附上你所擅长的领域，有作品集就更好了。

那么这篇文章就到这里。希望下次我再写开发日志的时候，你们已经能在 B 站上看到这个游戏的概念 PV 了。