跳转至

我的Ballance相关工程今后的去向

前言

做滚球死路一条

我很长时间都已经不再涉及Ballance的内容创作了。实际上自今年年初开始，我就已将Ballance社区建立者身份移交给了Chris，同时退出了一些Ballance群组。并在几个月后更进一步，彻底退出Ballance社区管理，并完全离开大多数Ballance群组。在这个过程中，我不断尝试Ballance以外的事务，并将兴趣转移到属于自己的游戏的创作上。这一切都是在为我我退出Ballance社区做准备，而现在我在这里正式退出所有Ballance社区。

本文原本是想写在我制图教程和插件发布后的，但奈何Ballance群里几日前有人询问起TAS编辑器项目存档一事，并表示原本还想要几个功能的。因此我决定将这个通告的时间提前一点，也在此陈述一下我今后的方针。

虽然这么说有一种把可能存在于自身上的错误归咎于外部因素的嫌疑，但事实如此：Ballance已经耽误了我至少两年的学业生涯。无论是现实情况还是心理感受，都使得放弃Ballance是一项正确无比的选择。许多人看着我反复仰卧起坐般的退吧说明和回吧行为并以此为乐，甚至调侃每年发一个退吧声明是我每年必做的事情。我不否认我确实发了很多退吧声明，而我反复回吧的原因也并不是因为我个人情绪发泄完了。相反，是因为各种各样的偶发事件，让我觉得Ballance又有未来了。去年年初我被61问及我的新游戏何时可以开工，我的回答是立马开工，因为我不想被群友当成只说不做的人。当即抛下所有Ballance项目转头开始做自己的游戏，由于那时候我与Ballance有关的工作已经到一个发展阶段的末尾了，因此立刻抛下很容易。在几个月后，我自己的游戏已经实现到程序生成可游玩的地图的阶段了。然而三月的一次众所周知的会议打断了我的计划，那次会议过后，相信无论是Ballance老玩家还是新玩家，都或多或少地看到了游戏原制作组回归游戏创作的渺茫希望，并期待所谓四月会议的到来。我也不例外，我当即又回到了对Ballance的开发中去。然而事实是，四月会议并没有到来，取而代之的是一整年的杳无音讯和年末Ziggurat的越俎代庖。而我则用了一年的时间去实现了libcmo，以及相关的在Blender中原生导入导出NMO文件的功能，并在此期间一直苦苦等待那个镜中花水中月的四月会议，最终新一代Blender制图插件得以完成，但四月会议始终没有到来，我也又一次失去了学业上的前途。

我本身是很敬重原制作组的，我想多数Ballance玩家也是如此，大家都很感谢原制作组给我们带来了这样一款陪伴我们同年和现在的质朴的游戏。但原制作组做下承诺，却又不遵守它，这真的很让人失望。不过相较制作组在过去20年内一直毫无音讯的表现而言，原制作组能与玩家进行一次交流已经实在难能可贵了。而Ziggurat粗制滥造的再版无疑又打击了本就失去4月会议承诺的玩家。Ziggurat的再版完全就是将原版Ballance以一种拙劣的兼容性手段重新包装以试图赚一笔情怀钱的行为。它完全无视玩家社区过去20年内所创造的各种内容，包括自制地图，新的性能更好，提供更多选项的游戏启动器等。跟着这样的公司怎么能发展好Ballance呢？

许多人会诧异，为什么我会愚蠢到选择用学业换取游戏这种行为，包括一些群友也在知道我这种行为后以极其严肃的语气批判道。许多人不知道的是，我迄今为止所掌握的所有技术，都是我在Ballance里持续参与10多年得来的。许多我掌握的技术，都是Ballance社区里有什么需求，我才去学什么，然后有针对性地解决问题，才能掌握的相关技术。这也就是我为什么一直不愿意离开Ballance社区的原因，我生在Ballance，长在Ballance，Ballance教会了我那么多知识，我又有什么理由要抛弃它？但这一切都该结束了，因为事实已经证明，继续呆在这里只会更糟，我必须离开。

目前Ballance技术开发区对于Ballance相关开发有两派，一派是认为应当完全反编译Ballance所用引擎Virtools及各个附属插件的代码，修复反编译的代码的错误，然后再将整个引擎带到其它平台（例如Linux）与架构（例如x64）上。另一派则希望将关键内容，例如游戏文件结构，物理引擎源码，游戏脚本连线等反编译出来，然后在更加现代的游戏引擎上重现Ballance，继续在Virtools上进行工作不值得。我是坚定的后一派的支持者，所以你会发现我所作的都是一些有关迁移Ballance的项目，例如Virtools的OBJ文件导出器，Virtools文件的原生读取写入库等。因此，我选择后文中放弃的工程的标准是：只要是为原版Ballance服务的工程，全部都放弃；而那些有助于将Ballance迁移到新平台，维护起来不是很麻烦的工程，基本上都保留了下来。

我继续更新的工程和放弃的工程都会列在下面，正好你也可以看看有哪些你知道的，又有哪些你不知道的。

这些工程会继续更新

  • BallanceBlenderHelper

这就是我一直在推荐的使用Blender制作Ballance地图所需要的Blender插件。插件已经迭代了3次，每次迭代后我都会制作一张自制地图来确认插件的每个部分都没有问题，且确实服务了制图。第一张是斯卡布罗集市，第二张则是要素超载，第三张图仍在制作。最新的即将发布的插件是Ballance制图流程的颠覆之作，因为它完全实现了Blender内读取写入Ballance地图的功能，使得不涉及内嵌脚本的地图的创作可以完全抛弃Virtools，将Virtools的使用度降到0。

我之所以不愿意放弃这个插件，主要原因的我在其上付出了过多的心血，以及我放不下那些期望使用这个插件的人。这个插件不仅见证了我学习Blender建模和Ballance制图的每一个阶段，还帮助我对Blender和Virtools进行更深刻的理解。

许多人还会记得我之前承诺的制图教程。是的，制图教程会有的，而且很快就会推出。制图插件，制图教程，和我的新地图，我都会力图在6月之前完成，这样我就可以在6月之后专注于我自己游戏的创作和我自己的学业问题了。事实上，我现在一想到我还有那么多Ballance收尾的事务要处理，我就很烦躁，从而不愿意去做，主要是因为我已经对Ballance提不起任何兴趣了，觉得继续在这个游戏上浪费时间，还不如去继续创作自己的游戏。我前几个月一直在犹豫，还要不要出制图教程。尽管大家看到我拿出的成果后，都在说未来会学Blender制图。如果是几年前，我或许会被这些话语激励，进而更加奋发努力地去改进制图插件，让它更加完美。而让现在的我来看，我倒是觉得这更多是一种奉承的话语。许多曾今说过这些话的人，从来都没有拿出Blender制图的成果。就算是极度热爱Ballance的人，被刺激那么多次，却丝毫没有见到反馈，也会失去动力吧。不过思前想后几个月后，我还是决定完成制图教程和制图插件，为我的Ballance工作画上一个句号。我还是放不下那些曾今对我制图插件表达过兴趣的人。它们有的在春节期间咨询我制图插件的事情，有的表示高考完就学习制图。无论他们是真的已经开始学习，还是简单的奉承，我还是想把我所能做的事情尽善尽美。

你可能会对“画上句号”和“继续更新”感到矛盾，事实上这并不矛盾。即将发布的是这个插件的最后一个大更新版本了。以后的版本中我只会根据大家都需要，添加一些BME预设和小特性，修复Bug等。不会大动干戈地从头重构整个插件了。

  • libcmo21

赋予各个程序原生读取写入Ballance地图能力的库，也就是Ballance制图插件的底层部分之一。因此会继续开发。

同时这也是我写过的最大的C++工程了，无论是从获取维护经验，还是编写经验上，这个项目在未来可以为我带来更多。留着这个项目继续开发是理所当然。

  • BallanceStalker

一个只存在于纸面上的，计划中的项目。原计划是用Godot引擎实现Ballance地图浏览器的功能；同时可以在其中实时观看联机影子球，离线影子球的功能；也提供类似于Minecraft Aperture Mod的制作地图宣传视频的功能；以及支持Ballex那样的天气系统，和对Ballance贴图的PBR渲染。

但现在一切都变了，这个项目的最终目标太过宏大，而完成它所需的工作量远不及它的回报。虽然我将它列在这里，但很难等到这个工程重开了吧。

  • bmmo-protocol-compiler

原本是为BMMO协议编写的类似于Google Protobuf的序列化反序列化代码生成器。也是我练习使用Flex和Bison的项目。但后来由于BMMO协议并不完全遵守我总结出的序列化准则，这个项目就转为了纯粹的练习项目，并可能会在未来作为我自己设计的游戏的协议的生成器。

BMMO的协议在设计上就是完全手写的，完全没有规律可循。不知道什么时候加入的可选性字段破坏了这个程序对BMMO的兼容性。尽管可以用补丁的形式预先修复消息体来继续使用这个项目，但并不能掩盖BMMO实际上并不与这个项目保持一致的事实。

  • VirtoolsTranslation

一个Virtools界面翻译项目，也是我练习Antlr的项目。实际上我并没有使用中文界面Virtools的需求，这个工程的初衷是为Ballance吧里那些新手使用Virtools服务的。保留这个工程的唯一原因是它足够简单，维护起来不消耗太多时间，仅此而已。

  • vtobjplugin

Virtools的OBJ文件导出器。比vt2obj强上不止几百倍。

似乎无论我强调和宣传多少遍，总有人愿意去使用老旧的vt2obj，并乐此不疲地询问Virtools 5安装失败的问题，因为vt2obj只能在Virtools 5上使用。我已经放弃了。我不想对这些人说什么，该说的词我已经不知道说了多少遍了，听不到不是我的事情。

不得不说的是这个插件的代码架构非常垃圾，也许未来某个时候我会重构一下它。我保持其继续更新是因为它服务的是Virtools而非Ballance。许多人用它在Virtools中为其它一些老游戏导出模型，我也非常乐见这一点。

  • VirtoolsScriptDeobfuscation（fork自BearKidsTeam/VirtoolsScriptDeobfuscation）
  • SuperScriptMaterializer

VirtoolsScriptDeobfuscation是2jjy和Chris写的Virtools内破解加密脚本的插件。他们负责主要核心部分，我只是把这个工程中的一些硬编码数值改为相对值，同时改进了它的日志系统和编译体验而已。之后我使用这个插件破解了Gamepiaynmo编写的一代BML，并引起了Gamepiaynmo的注意。几年后，Gamepiaynmo推出了大家众所周知的真正的BML。

SuperScriptMaterializer实际上是对VirtoolsScriptDeobfuscation的一个拙劣模仿。它试图用一种不同的方式来获取，解析并呈现Virtools脚本。由于VirtoolsScriptDeobfuscation的设计原因，在当时其仅可用于对Ballance对应的Virtools版本的脚本的解析。因此SuperScriptMaterializer试图通过一个Virtools插件，将其脚本数据导出为一个SQLite数据库，然后用外部程序分析并展示脚本。这样就可以去分析所有Virtools版本的脚本了。

Virtools 5上的vt2obj脚本的内容是通过SuperScriptMaterializer分析得来的。在分析脚本内容后，我才写出了vtobjplugin。

SuperScriptMaterializer在功能稳定后又曾继续改进了几次，试图将其变得更正式，例如可以将解析后的脚本信息部署到网站上，而不是本地查看。以及使用更加高效地语言去重写脚本分析部分。然而这些改进大多无疾而终。也许之后哪天空闲了，会继续做下去也说不定。

  • ballance-discord-rules

Ballance Discord社区的一些社区规则和常见问题解答工程。在我离开Discord管理后就陈述了：如果有人愿意接受这个工程，我可以添加贡献者或者直接转让工程，Fork也是一种选择。然而至今仍未有人对此有任何回应。在我离开的状态下，我是不会去主动更新这个工程的任何内容的。我只是会去处理工程转让的事务。这就是所谓的“继续更新”，并不指内容上，而是指所有权上。

以上就是所有我会继续更新的工程了。虽然我说了以上这些工程仍会继续更新，但是这并不意味着我仍会像以前那样抱有极大地热情和动力去更新它们。相反，我只会在编写其它工程感到厌倦时，或有人支付报酬要求我尽快处理时才会继续更新这些工程。像BallanceBug以及众多为Ballance奉献技术力的吧友一样，将Ballance当作一个兴趣，而非职业。

这些工程将永不更新

  • BallanceModLoader（fork自Gamepiaynmo/BallanceModLoader）：为了解决Gamepiaynmo发版过慢的问题而创建的具有Nightly Build功能以及方便GitHub Action调用的Release页面的发版专用项目。
  • BallanceModLoaderPlus（fork自doyaGu/BallanceModLoaderPlus）：为了解决doyaGu从来不在GitHub发布BMLP版本的发版专用项目，与BML项目初衷一致。
  • BallancePlayer（fork自doyaGu/BallancePlayer）：同样是解决doyaGu不发版，不打包新Player的问题。

既然我都离开Ballance了，不如把我现在对Ballance的开发的不满喷个爽算了。

BallanceModLoader的设计是极好的，但是发版问题上是个败笔。很多时候许多非常紧要的功能和修复合并之后，应当立即发布一个小版本，让用户（玩家和Mod作者）可以享受到这些特性和修复。然而BML却迟迟不发版，看起来似乎是只有大的代码更改的时候才会发版。这就导致BML在版本体验上非常差，用户在急需解决某些致命错误，或需要一些特性的时候，只能自己下载编译来获取，没有任何可供公开使用的包，这也是我后来Fork项目，创建Nightly编译和自己的Release发布页的原因。

BallanceModLoaderPlus在技术原理上相较于BML更加优异，然而还达不到瑕不掩瑜的程度。BMLP败笔还是发版，似乎极客总是完全不考虑终端用户的体验一样。BMLP的发版比BML更加糟糕，BML还会偶尔在Release中发布用户可用的包，而BMLP则完全不在Release页面中发布，甚至连Tag都完全不打，且只通过QQ群这种不可持续存储的工具来发布相关包以供测试，主打一个随心所欲。更不应该发生的是，BMLP的开发对于Bug修复和新功能的加入混为一谈，有时候一些紧要的Bug修复和特性，却需要等一些完全新写的，无关痛痒的功能写完才能一起发布，而结果通常也是旧Bug解决了，新写的部分反复崩溃。BMLP反反复复修改安装方法，以及在是否添加ImGui链接库的问题上的翻来覆去也使得版本体验更加糟糕。连续几个BMLP版本在两种安装方法之间改来改去，ImGui加进来又踢出去，搞到最后弄出了两个同号版本，内容却完全不一样。

要我说，BMLP用户不会用你所谓的Universal loader去加载除了BMLP以外的什么模块，它们要的只是一个Mod加载器，为什么不直接静态链接在一起呢？一个限制FPS的功能，分不清应该是加在BMLP里还是Player里，这种非Mod玩家也需要，不涉及BMLP的功能就应该放在Player里。还有将BMLP和Player合在一起的设计，我是完全欣赏不来，毕竟我当初喜欢BML的原因就是它的非侵入式，不需要修改游戏文件，只需要新添加文件即可。当然现实也有不少游戏是通过改启动器来实现ModLoader的（比如星露谷）。这些糟心的问题也是后来我一直在提我想重新把BML拾起来开发的原因，因为BMLP一直以来不让我满意，除了技术上的创新以外。BMLP折腾来折腾去，最终结果就是玩家和Mod开发者的耐心被耗尽，没有人去愿意升级和测试新写的版本。

  • BMLMods：我的BML和BMLP的Mod工程，包含下面几个Mod
    • BallanceOptiFine：给那些没有路面阴影和不断柱子的上古地图修复路面阴影和不断的柱子的Mod。
    • BaseCmoCfg：操纵base.cmo文件里两个原开发组用于测试游戏的字段的Mod，比如测试模式和上帝模式等。
    • Coredump：一个未完成的Mod，原设计是可以在游戏任一指定时刻将游戏当前状态导出为CMO文件方便分析游戏状态。
    • FontCraft：修改游戏字体的Mod，你们最常用的。
    • ExtraSector：999小节加载器，玩1-13连体图用的。从2jjy的原版，到Gamepiaynmo的那版，再到我这版，999小节加载器倒是我印象最深的东西。
    • BLinguist：Ballance多语言支持Mod，其实就是之前2jjy & jxpxxzj汉化版的技术原模原样用BML Mod实现了一遍，然后把文本改为可以按需读取了。
    • BallanceBBOR：一个未完成的Mod，原设计是可以显示游戏内变球器，死亡区，风扇等物体的作用区域，方便精细操作的。

说到我的Mod，我就不得不再说一下新BMLP的问题了，新BMLP用ImGui重写了所有游戏UI元素，这固然是好事，因为原版游戏UI经常错位。但问题是，BMLP完全没考虑到对外暴露接口的问题。我说的不是FontCraft失效的问题，BMLP如果提供了字体修改功能，并暴露了设置，这是皆大欢喜的结果，因为这样所有Mod都可以从BMLP那里获取字体设置了，彻底杜绝了一个Mod一个字体的情况，界面也会更加美观。我要说的实际上是BLinguist，也就是多语言Mod的问题，BMLP似乎并没有给按钮等物件的名称修改留下任何接口，这就导致了整个多语言模块全部报废。尽管可能有解决方案，但我已经懒得想了，一是我不想为一个侵入式的方案设计解决方案，另一是我都不服务Ballance了我想这个干什么。

  • BallanceTASEditor：Ballance TAS文件编辑器。

很遗憾这个工程位于永不更新部分中。主要是TAS必须在原版Ballance中实现。因此按照我的标准，它理所当然不可能存续下去。更重要的是，当初写这个编辑器的时候，虽然我思维上考虑了要处理大文件，但由于我没有算法上的经验，实际写出来的代码只能说勉强可以工作，你也注意到了这个工程有一个单元测试工程，这就是为了确保我写出来的垃圾核心代码不会出错而专门创建的工程。

事实上TAS编辑器经过一次大的重构，在重构之前的各类编辑操作，例如插入，剪切，粘贴等经常出现错误，导致编辑后的文件和窗口上显示的不一致，极大地影响了编辑体验。因此我重构了一版，并添加了单元测试来确保核心操作正确无误。然而重构后的代码也是一团糟，究其原因是我没有系统地学习过文本编辑器所用的算法，例如Gap Buffer等，因为编辑器需要数据在空间上连续，又要使得插入操作的消耗尽可能常数化，相当于结合std::vector和std::list。对于当时的我来说，我只能按自己的理解，用类似于Chunk的算法实现了一遍，但效果不甚理想。也许之后我学习了编辑器算法之后，会回过头来用这个工程来练手，不过大概是希望渺茫吧。

  • ScoreManager-Magic：2019年吧赛用竞速系统

说来感慨的是，ScoreManager-Magic原本期望的就是建立一套线上排行系统，像osu!那样，甚至当时代码已经开始写了，但是由于种种原因，这个项目死了。这个项目当时用的还是jxpxxzj搞的ScoreManager的那套分数检测方式，侵入式的分数检测器。在项目死之后，BML横空出世，改变了Ballance，接着就是BMMO大放异彩，几年前的线上游戏梦想照进了现实，然而却没有人继续搞线上排行系统了。如果ScoreManager-Magic制作的时机再晚那么一两年，也许一切都会不一样。

  • NewBlcPlayerSetupTools（fork自Xenapte/NewBlcPlayerSetupTools）：魔改的BallanceBug的Ballance安装器，魔改为适合新Player和BMLP的。
  • BallanceSkybox：一个在保证连接处无缝的情况下，从单张图片生成适合Ballance天空盒图片的程序。同时附带有天空盒浏览功能，可以加载天空盒图片，拖拽移动视角，360°观看天空盒效果。
  • WhispersAbyss：一个将BMMO所用的GNS协议转为TCP协议的转换器，这样一些需要接入BMMO的程序就不需要链接麻烦的GNS库了。然而这个程序有Bug，那就是有一定几率断连，无论我几次重写，这个Bug都很顽固，无法消除。随着我退出Ballance，这个工程也没有存在的必要了，就当对GNS练手了。
  • BallanceVirtoolsHelper：原先作为制图工具链的一环，是服务于Virtools制图的插件，随着Blender插件自身就可读取Virtools文档，抛弃BM文件标准后，这个插件失去了其作用，因此决定不再更新。
  • nmo2escn：将BM文件转换为等价ESCN（Godot场景）文件的转换器，原本预期服务于BallanceStalker工程，现在废弃了。因为LibCmo赋予了原生读取NMO文件的能力，未来这个插件中的部分代码会作为参考，变成BallanceStalker的一部分，并借助LibCmo原生加载NMO地图文件。
  • BBFG：给Ballance生成字体贴图和Virtools表格数据的程序，用于自定义游戏字体。功能早就已经合并到FontCraft中了。
  • BetterWindow4Ballance（fork自Ghomist/BetterWindow4Ballance）：增加了禁用IME的功能，防止在Ballance中意外弹出输入法，原本想合并入原工程的，但是Ghomist没理我。
  • BallanceMapEditor（fork自jxpxxzj/BallanceMapEditor）：BME地图编辑器的改版，改为英文界面，并增加Blender输出。服务于最初一版制图工具链，现在已经用不到了。
  • bmv-ass-subtitle：一个给梨栠washing制图教程制作中英文字幕的项目。
  • ballance_tools：很久之前写的Ballance工具箱的源代码存档。与ScoreManager-Magic类似的是，当时这套工具箱里甚至有联机页面，尽管只是用来展望未来的未完成面板。而当真正的联机到来时，这个工程已经死了五六年了。
  • bpm和bmp_wiki：未完成的工程。一个试图用包管理器来拯救Ballance各种组件安装困难的解决方案。

这些工程没那么有名，就那么一笔带过吧。

当然，这些工程的结束也并不是绝对的。支付的报酬合适，提出的要求在我能力范围内，我会继续尝试有限地支持这些工程。然而像以前那样免费，无限期地支持，甚至是添加新功能就不要奢望了。当然，这些工程都是自由的项目，你可以在遵循许可证的情况下自由地Fork并改进它，我不会对此做任何约束。不过我想，对于Ballance这样一个小社区，不会有人愿意拿报酬来付到一个行将就木的游戏中去，也不会有人空闲到为了一个游戏认认真真学习一遍如何编程。所以这些工程大抵是死了吧。