《开物天工》：编程语言开发者的独立游戏尝试

本文系用户投稿，不代表机核网观点
 《开物天工》（英文名Craftica）是一款基于亚体素的下一代创造类沙盒游戏，它用完全程序化生成的亚体素模型构建了近乎无限大的开放沙盒世界，支持创造和生存两种基本游戏模式。这是一款完全由一个人开发出来的国产独立游戏。它部分地受到了《我的世界》（Minecraft）的启发， 但用多尺度的亚体素把游戏世界的体素表示提升到了一个新的高度，并衍生出更强更精致的建造玩法。
开发缘起
我是《开物天工》的作者，但我原本不是游戏开发者，只是因为机缘巧合的原因，我从大约两年半前才开始考虑开发一款沙盒游戏。那时我正在开发一款可视化编程语言及其集成开发环境，并尝试在此基础上开发一款面向STEM教育的产品。
这款可视化编程语言是在我自己以前开发的 Dao 语言基础之上开发的，而那个面向STEM教育的产品项目则是基于虚拟机器人，希望通过虚拟机器人的组装和可视化编程控制，达到对用户编程能力的训练和创造力的开发。

尽管当时编程语言和开发环境的主要部分已经基本完成，但要做到完善和稳定，我估计还需要一年多时间。另外Dao语言是我大约从2006年我还在读博时开始用业余时间开发的，后来在做博后以及工作后还持续用业余时间开发了很久。尽管这门语言开发的时间比较长，也比较稳定了，但是除了在早期语言还不太成熟时，我过早地做过不太成功的宣传外，后来因为时间和精力等原因，就基本没有做大的宣传了。所以Dao语言现在基本没有什么知名度，这点对基于此语言的全新可视化编程语言基本起不到什么宣传方面的帮助。因而我有些担心这款产品的推广可能会比较困难，就寻思怎么解决这个推广问题。然后我就想到开发一款支持可视化编程且支持创造力开发的游戏，以游戏作为媒介来推广这款可视化编程语言和产品。但是我还是没想出开发个什么样的游戏。
另外当时虚拟机器人的项目主要由我一个同事负责，他已经摸索出了一套比较方便制作虚拟机器人组件的方法，能够比较容易地制作出多种样式的组件。不过那时虚拟机器人的使用环境还只支持很小的虚拟场景，我觉得是完全不够用的，也想给它增加个更加完整的虚拟环境。加之我多年前（当前这波人工智能火爆之前）就有个在虚拟环境中训练人工智能算法的模糊想法，觉得给虚拟机器人项目添加完整可控的虚拟环境，对于将来扩展这个项目是很重要的也很有意义的一件事。这样就基本确定先尝试做个虚拟沙盒环境或世界了，然后就开始研究怎么做。
初步尝试
后来通过一番琢磨和调研，我觉得《Minecraft》这种游戏里的体素类型的虚拟沙盒世界应该比较好开发（现在回过头来看并不完全是这样）。但我又不想开发一个跟它差不多的，并且老实说，我一直觉得《Minecraft》那种风格比较丑，地形和建筑物太多锯齿、太不平滑。我觉得再做个这样的既没意思也不够有挑战性。所以我就琢磨了两方面的主要改进，一个是亚体素，另一个是球形世界。然后我从2017年五月底六月初开始用了一个星期的完整时间加上两三个星期的零碎时间做了些原型开发。

在开发我的可视化编程语言的集成开发环境时，我就以插件的形式给它集成了一款叫Atomic的游戏引擎（Urho3D引擎的一个分支），我还用我之前开发的一款基于Clang的工具，在很短时间内成功地做了个Dao语言的封装。另外当时开发的虚拟机器人项目也主要是基于这款游戏引擎开发的，并且我对这款引擎还做过不少修改，以方便游戏引擎跟编程环境的集成。因此我对这款引擎也相对比较熟悉了，就直接选用这款游戏引擎做原型开发。
原型开发我一开始只做了亚体素方面的尝试，这个尝试很顺利，很快就做出了一个基于亚体素的沙盒世界原型。但是我一直没有琢磨出一个合理可行的球形世界实现方案，感觉它跟体素和亚体素还是太不兼容了，因此就有些犹豫究竟要不要继续做这样一款沙盒世界。
那段时间我一直在继续可视化编程方面的开发，并且进展还不错，但是原来担忧的完善度和推广难度问题还是继续存在。同时我也对这个沙盒世界原型做了些评估，觉得如果不做球形世界，在这个原型开发基础上，应该可以用半年时间开发出一个基本版本的沙盒游戏，可以作为抢先体验版上Steam平台发布。而且我觉得如果这款游戏能够成功的话，把这款游戏和之前的可视化编程和虚拟机器人项目进行集成也是很容易的事，这样对于这个可视化编程和虚拟机器人项目的推广也是大有帮助的。所以到了十月底，我基本确定有必要开发这样一款沙盒游戏，并计划把它定位得跟Minecraft差不多，属于创造类沙盒游戏。我后来把这款游戏命名为《开物天工》（Craftica），以向明朝的科技名著《天工开物》致敬。
正式开发
我把我这个新的想法跟我那个做虚拟机器人的同事商量了下，发现他也很赞同我这个想法。于是从十一月开始，我拉上他，先把手头的项目暂时放一放，正式开始全力开发这个游戏。我用C++语言负责底层开发并封装出Dao语言接口，他用Dao负责上层UI和游戏逻辑开发。不过由于兴趣和经验等原因，他在春节过后没多久就退出了游戏开发。于是我决定全部采用C++语言开发，省去了接口封装的麻烦，等到将来准备支持Modding开发后再封装Dao语言接口。
这个决定一定程度上还加快了游戏开发速度，一方面不再封装和维护Dao语言接口确实省了不少时间，另一方面一个人开发时，我可以更好地选择不同特性和功能的优先实现顺序，也就能更好地保持比较好的开发状态。另外比较出乎我的意料的是，用C++开发UI比用Dao开发UI似乎还方便些，之前我同事在UI开发上面遇到的一些困难，在C++层面就很容易解决。这主要原因是Atomic引擎的UI模块使用了一个第三方的UI库，引擎对这个UI库的封装比较不完整。因而Dao语言对引擎UI模块的封装相对于这个第三方UI库也是个不完整的封装，使得UI库的某些功能在Dao语言层面用不了，也使得UI控件的定制更困难。而直接使用C++开发的话，这问题都不是问题了，这使得我可以用不到一个月的时间就把所有的UI功能实现了。
尽管游戏开发速度更快了，但我对这款游戏的开发工作量的估计有严重偏差。当初预计的半年开发时间很快就过去了，而游戏离完成仍然还有很大的距离。到了差不多六月份，我开始觉得可能还是在有外部资金的情况下开发比较好。当时经过一些考虑，我比较倾向于通过众筹的方式获取一些资金。但是要上众筹的话，没有合适的Demo是不行的，而要做Demo，又有必要搭建一些场景。
作为创造类沙盒游戏，虽然我可以在游戏里直接搭场景，但这样难免会花很多时间。而且由于游戏存档格式还没定型，直接搭场景也存在一些存档丢失或变得不可用的风险。于是我决定给游戏增加从外部导入并体素化模型的功能。这个大约花了我一个月的时间，而在这一个月里我对当时游戏众筹的状况有了更多了解，觉得上众筹的作用不大，确信还是避免分心和分散精力，全力把游戏开发出来比较好。
在接下来一年左右的时间里，我基本上都在全力以赴地开发这款游戏。不过我当时还是没能预计到游戏离基本版本的完成都还有一年左右的时间。除了对工作量方面还是有不少低估外，我在后面的开发中还加入了些规划之外的内容或玩法，其中最耗时的有两个：一个是中式建筑，另一个是村庄系统。
《开物天工》要体现作为亚体素沙盒游戏的优点，最直接了当的方式就是展现它对中式建筑的良好支持。玩过Minecraft的人都知道，玩家不可能在它里面建造跟现实中建筑有一比一比例的建筑，更不可能建出中式建筑里那种飞檐等结构。但在《开物天工》里这个是完全可以的，于是我对中式建筑做了点基本的梳理，把中式建筑里比较具有代表性的结构加以分割和简化，定义出一套组件物品（Item），这样通过这些组件的组合即可建造出中式建筑。

而村庄系统则主要是为了游戏的可玩性加入的。《开物天工》里的村庄系统跟Minecraft里的村庄还是有些明显的不同。目前游戏里的自动生成的村庄基本都是由中式建筑组成，一般都包括房屋、工坊、哨塔或堡垒，以及牌坊等。村庄一般也会生成勇士和不同类型的村民。勇士会自动去哨塔或堡垒里，并驻扎在那里守卫村庄。村民则会间隔性地在一些地点间来回走动并执行一些任务（如果有的话）。玩家跟村庄之间的关系由亲和度表示，正的亲和度表示友好关系，负的亲和度则表示不友好和敌视关系。当正的亲和度高于一定的阈值，玩家将可以自由出入村庄的建筑（包括哨塔和堡垒），甚至还可以取用村庄存储箱里的物品。不同的建筑物和箱子可以有不同的亲和度阈值，只有在亲和度达到这个阈值后，玩家才可以进入建筑或开启箱子。当玩家和村庄的亲和度低于一定负数阈值时，村庄的勇士将主动攻击玩家，并且村民可能还会躲避玩家。
趟坑经历
开发过程中踩的坑主要集中在物理模拟和路径导航等方面。物理模拟的坑主要来自于我对物理引擎的使用不太熟悉导致的，后来变熟悉后在这方面浪费的时间就比较少了。路径导航方面则主要是因为游戏引擎的导航模块有一定的局限性，不能很好地适应我这款游戏里的一些状况，导致我不得不考虑一些临时性解决办法来解决一些问题。这两方面的坑算是无法回避的吧。可回避的坑我倒是踩的不多，主要就两个吧：一个是地形生成；另一个是模型导入。其实这两个都不是技术上的坑，而是决策上的坑。模型导入这个说是坑，主要在于时间花的不少，但后来发现实际用处并不大。
地形生成这个坑则实际上是由于太晚引入多线程导致的。当时地形生成还是在主线程中完成，存在一些效率问题。但这个问题又不严重，所以我觉得可以不引入多线程就能解决。并且我也有点担心引入多线程会让这部分变复杂，所以我也有意要避免在这里引入多线程。这样在一段不短的时期里，我不时地对地形生成部分做些改进，以增加地形生成的效率，或降低地形生成对主线程的阻塞影响。
但一方面随着游戏功能的增多，游戏对计算需求的增多，地形生成的优化效果很快就被抵消了，以至于地形生成部分对主线程的影响反而越来越明显了。另一方面地形生成的优化也越来越复杂，以至于它不时地出现一些奇怪的问题，浪费我不少时间去调试修改。最后我还是决定引入多线程，在专门的线程里生成地形，结果我发现这样处理更简单，不但基本解决效率问题，也不再出现各种奇怪的问题了。
开发尾声
到了2019年11月份，《开物天工》基本版本的开发总算接近尾声了。从12月开始，我终于开始准备搭建Steam页面了，并计划在过年前正式发布EA版。在这期间，我开始做更细致的测试，并开始录制宣传演示视频。这过程中，我发现了游戏里更多细节性的问题，并做了大量改进和修复。当然这些都不可避免地花费了我大量的时间，直到离除夕只有两天，我才把游戏改进得基本满意。由于过年期间，我要回岳阳几天，不方便开发，并且感觉过年期间发布也不太合适。我决定还是把游戏往后推迟再发布。
过完年我初三晚上就立即回深圳继续游戏开发。当时那么早回深圳，一方面是因为提前买返程票时没买到晚于大年初三的高铁票，另一方面是春节三四天里疫情急剧恶化。虽然疫情恶化后高铁票反而更好买了，有更晚的班次可以改签，但岳阳附近一些地市封路的新闻传闻时有耳闻。当时甚至还有传言说高铁站被封、高铁被取消之类的，但是我通过查看12306 App上的高铁票，确认这些是谣言，实际上只有武汉首发的高铁被取消了。但是我还是比较担心疫情会更近一步恶化，再晚的话会离开不了岳阳而被迫滞留在家里，到时候滞留多长时间也不确定，会严重影响游戏的发布。所以我跟父母商量还是初三动身回深圳比较好。
我回到深圳后大部分时间都是宅在家里开发《开物天工》，仅在刚开始几天去附近河边散过两次步。后来小区封闭管理后，我就几乎不再出小区了，一方面是出去有点不方便了，另一方面我又只剩一两只两年前因为感冒买的口罩了，所以就尽量能不出门就不出门了。我大约又花了两个月改进游戏后，才在Steam上把游戏发布了。虽然这次发布相较于最初规划的年前发布已经晚了两个多月，但实际上游戏的发布时机还是不太成熟。尽管游戏的内容比最早规划的基本版本里的内容多了不少，但还是不太够，理想情况下应该再开发个半年再发布就比较好了。不过这也是没有办法的事，游戏的开发时间已经大大超出我最初的预期，已经没有资金可以支持更久的开发了。
后记
《开物天工》的开发总的来说还算顺利，除了在开发工作量方面的估计有严重的偏差外，基本没踩过大坑也没走过大的弯路。这大概跟我之前做过较长时间的编程语言开发有很大关系。编程语言的开发除了极大地提升我的编程能力外，也让我在为这门语言开发或封装一些模块的过程中，接触并熟悉了多个开源3D引擎和游戏引擎。这方面积累的经验也让我有能力，在需要的时候可以对所用游戏引擎做必要的修改或修复。
不过在宣传方面我还是有些失策，宣传的太晚了点，导致游戏曝光严重不足。不过这也跟国内某游戏巨头有一点点关系吧，主要是在2018年上半年，我发现这家公司也在开发一款沙盒游戏。该游戏明显借鉴了 Minecraft 和 Portal Knights，也许还借鉴了国内某款类似的游戏。我有点担心《开物天工》的亚体素等方面的东西也可能被借鉴，所以不想过早地宣传，就把宣传往后压了很长时间。当然这个只是一方面的因素，另一方面我之前在Steam平台的使用方面也完全没有经验，不然我可以更早地建立游戏的Steam页面，这样也会比较方便宣传游戏。
现在《开物天工》虽然已发布，但它还需要持续的改进，以实现更多已规划的内容，增加更多科技元素，使它更符合创造类沙盒游戏这个定位。除此之外，我也希望能尽早地把之前开发的可视化编程等方面的东西跟这个游戏集成起来，让它可以在STEM教育方面能有所作为，使它成为一个超越游戏的工具或平台。