《戴森球计划》五周年庆开发日志及版本更新预告｜戴森球计划

亲爱的工程师们：

大家好！从2021年1月21日EA上线，不知不觉《戴森球计划》已经迎来五岁生日，很高兴能和大家携手走过这难忘的五年。在这五年里，特别感谢每一位工程师，感谢你们的默默陪伴，以及对我们开发过程遇到的困难给予的理解、支持、鼓励还有耐心的等待。正是因为有你们，《戴森球计划》才能越来越好。

过去的五年，感谢有你们一路相伴。未来的星辰大海，我们依然同行。

载具与未来规划：我们一直在路上

相信大家最关心的还是我们接下来的更新计划，比如载具系统和空间站。

关于载具系统，目前我们已经做了大量的设计和验证工作，目标是打造一套高自由，可灵活伸缩拼接的载具编辑系统，让每个玩家能够亲手打造属于自己的座驾。而且载具需要符合一定的物理规律，以契合游戏的科幻气质。

在设计上，我们希望玩家可以自定义每一个推进器的位置和键位，可以做出精细的矢量推进操作。

（然而现在翻车了）

从上面的错误示范中我们可以看到，引入了这些设计后，由于物理系统的混沌性，一点点变化都可能导致载具不可控。我们要求尽可能地减少玩家的心智负担，用尽可能简单的方案就能设计出酷炫又方便操作的载具，这需要我们花更多的时间去调试整个系统。

当然，这也需要我们开发出来一个好用的载具编辑器。

（安装部件示例）

（删除部件示例）

（放缩操作示例）

从黑雾崛起版本上线以来，这两年大家一直在关注着载具系统的开发进度，可能还要麻烦大家再耐心等一等。

我们为什么还需要更多的开发时间呢？

去年上半年，我们花了大量的心血在重构多线程系统，就是为载具系统上线前，尽可能地榨取CPU的性能，磨刀不误砍柴工。而且在过去的五年里，随着游戏的每一次更新，游戏体量也越来越大，代码的结构也越来越复杂。

◆ 每开发一个新功能，都需要保证加入后不会影响游戏整体效率；

◆ 每开发一个新功能，都需要考虑对从EA以来所有存档，以及体验的影响；

◆ 每开发一个新功能，还要全面评估新旧功能之间的影响，进行大量测试——功能之间的关联就像一个矩阵，行和列都在扩张，时间复杂度是O(n²)。

正因为这些“看不见”的底层工作，我们需要更多时间打磨。感谢大家的耐心，我们会继续推进，尽早带来值得期待的更新。

载具系统在游戏中的定位是什么？

载具系统的定位是一个高自由度的创作系统，作为现有玩法的重要扩展与补充之一。

另外，目前游戏内的战斗系统只侧重于地面部分，太空战斗尚在完善中，还有很多内容未实装。载具系统的加入，也将显著丰富战斗的整体维度与策略深度，同时也将推动我们对现有的战斗机制（地面 + 太空）进行全面优化。

为了保持系统的整体协调性与玩家的学习成本可控，我们将把载具系统与同样高自由度的空间站系统，统一整合进一个设计框架内，我们内部称其为“创建系统（Creation System）”。

除了扩展战斗玩法以外，创建系统中也会包含更多工厂玩法，将来在一定程度上还可以提升整体产量。

为提供更完整、连贯的游戏体验，我们计划在未来一次大型更新中同步推出以下内容：

◆ 载具系统

◆ 战斗系统的地面部分全面调整

◆ 空间站系统

◆ 战斗系统的太空部分

这四个系统在设计上紧密关联、相互依赖，因此我们希望它们能同时实装。这将是游戏正式版发布前的最后一次大型内容更新。

总之，创建系统的设计复杂度与开发复杂度不亚于战斗系统，我们希望它对游戏体验能够带来巨大的变化。在创建系统端上来之前，我们依然会继续带来QoL质量更新，还请大家多给我们一些时间，让我们一起期待它上线的那天，相信一切等待都是值得的！

那这次即将更新的内容是什么呢？

接下来，我们将对游戏进行一次QoL更新，这次更新将带来一系列实用功能与体验优化，以下是将要更新的内容：

全息信标

不仅是经常听到玩家们吐槽，我们自己游玩《戴森球计划》的过程中也在打开旧存档或者挂机一段时间后，对着屏幕陷入长久的沉思——我是谁？我在哪？我的产线逻辑是什么的哲学思考；或者去其他星球游历一圈后，回到起点忘记了母星的工厂布局，找不到去哪拿需要的物品；又或者千里托钛回来，却在自家地盘找不到物流站或储物仓的那种无助。

为了解决这些问题，我们加入了一个全新的建筑：全息信标。

它可以放置在游戏内的任意位置，作为地图标记与注释工具，帮助你规划产线、标注关键地点，在庞大的星际工厂中始终保持清晰的方向感。

它不仅是一个地图标记，更是集成了一个可自由书写、可随时备注的备忘录系统。

以下是全息信标的几种使用场景：

◆ 地图标记与导航

在星球表面放置信标，为重要地点（如资源点、工厂位置）添加标注，即使在行星视图(M模式)下也一目了然。

◆ 产线注释

也可以为复杂的物流枢纽或特殊的加工区添加注释，说明供需逻辑或后续规划。

◆ 行星信息和指引

信标不仅存在于地表，在行星视图、星际地图、甚至星空背景中也能清晰显示，指引你跨越深空找到目标，指引方向。

备忘录

一个融合在游戏界面中的备忘录系统。你可以在星球、星图、蓝图中直接创建带有图标、颜色、勾选框的备注，让复杂的工厂规划与跨星系探索更加直观、有序。

备忘录的功能除了应用于全息信标外，也被整合进了更多的系统中。

◆ 蓝图说明

在蓝图中插入输入输出注释，让分享和复用蓝图时逻辑更加清晰。

◆ 个人备忘录或待办清单

你还可以直接在星球面板上写下你的星际待办事项或是个人备忘录。备忘录支持勾选框、图标、文本颜色等富文本内容排版。

多线程逻辑优化：让CPU加速运转

在之前的开发日志中（“新多线程系统”全面解析 - 哔哩哔哩：

）我们曾提到，AMD 慷慨借给我们一台搭载线程撕裂者 9985WX 的整机，用于测试游戏在高度并行状态下的表现。这不仅填补了我们在“神级装备”测试上的空白，帮助我们发现并修复一些在普通消费级平台上难以触达的 Bug，也为各模块在不同线程数下的并行效率提供了宝贵数据，让我们能更清晰地感知潜在的性能瓶颈。

基于此，我们在这台设备上进行了一次“深度优化”。请大家放心，此次优化不仅能让拥有高并行性能设备的玩家进一步释放硬件潜力，对使用中低端配置的绝大多数玩家而言，同样会带来帧率与体验上的显著提升。

◆ 先说结论

就结论而言，本次优化的效果如图所示：

这张梗图似乎玩了太多次了，但是这次在这台线程撕裂者身上是真的帧率翻倍。以下是680万糖的极限存档在9985wx + 64g ddr5 5600MHz×8 + win10系统上的测试结果：

优化前(非关键帧95~100ms)：

优化后(非关键帧43~46ms)：

而这个存档在4P8E的Intel i5-14400F上非关键帧的开销则是从290ms降低到了205ms。另外30万糖的存档每帧开销则是从14.5ms降低到了11ms，10万糖的存档开销从8ms降低到了6ms。对于一般玩家的存档而言，5万糖规模以下最终帧耗时的优化差不多是5%~10%，对于10万糖规模以上的最终帧耗时约20%~30%。而对于像9985wx这样的顶级平台来说不仅680万糖从最开始的单帧接近100ms优化到了两帧加在一起不到90ms，120万糖存档的单逻辑帧耗时也从22ms下降到了11ms。

◆ 具体细节

本次优化我们主要针对的是动态任务分配的算法和缓存命中率(降低内存瓶颈)。接下来将简单介绍一下优化的思路和经验。

◆ 动态分配逻辑

在 9985WX 上运行原版游戏逻辑时，一个显著特点是在很多并行阶段结束后都会出现一段暗红色的区域。这部分开销被我们标记为“程序调度”，主要用于安排、分配任务，并提供线程间协同所需的数据。

对于使用一般消费级平台的玩家来说，这部分开销本应几乎不可见，在14400F上以16线程运行时每次并行阶段中此开销平均不到0.001ms，而在9985wx上，随着线程数的增加，这部分开销会爆炸性地增长。

原因在于我们原先采用了常见的“工作窃取”策略：线程完成自身任务后，会找到剩余任务最多的目标线程，并取走其一半任务。为了避免多线程同时竞争同一目标，我们设计为同一时间只允许一个线程执行窃取操作，其他线程必须等待该线程更新剩余任务数据后才能继续。

这套逻辑在线程数量不高时表现良好，但当线程数增长到一定程度时问题便随之而来。为方便大家理解，这边举一个贴近游戏的例子，我们这套系统可以类比为这样一个情景：在某处有个冒险者公会，每当有冒险者完成自己的任务时，就可以回到公会去任务栏中寻找下一个自己认为最有价值的任务。为了防止两个冒险者争抢同一个任务，公会采用摇号的形式，每次只随机在大厅中找一人去挑任务，一个人挑完后才能随机下一个人。在公会规模比较小时，大多数人的大部分时间都在外执行任务，公会里基本最多同时只有一人，极少数情况下可能同时有两三人。

但当规模扩大，任务和人数增多，挑选任务的时间变长，大厅等候的人也增多。处理器跨 NUMA 或跨 CCD 的架构类似公会不得不开设分会，但所有分会仍共享同一任务榜，且一次仍只允许一人领取任务。一个分会在开始或结束领取时，还需电话通知其他分会同步状态。这导致领任务的时间占比急剧上升，甚至出现 A 领完任务回来等候时，B 仍未被摇到号的情况。若 B 运气不佳，等待时间便会大幅延长，于是就出现了线程数从 16 增至 128（8 倍），而最大等待时间从 0.001ms 增至 5ms（5000 倍）的极端现象。

从整体来看，当线程完成初始平均分配的任务并开始“返回公会”寻找窃取目标后，在 16 线程环境下，平均仍有约 15.9 个线程处于工作状态；而当线程数升至 128 时，同一时段内可能平均只有三五个线程真正在工作，其余线程都在“等待摇号”，效率反而下降。

为解决这一问题，我们重构了任务动态分配系统。我们允许小概率下出现两个线程同时窃取同一目标的情况，并规定前者取走一半，后者再取走剩余的一半。以“窃取目标的剩余任务未必最多”为代价，换来的是多个线程可同时挑选各自认为最有价值的任务。

同时，我们将线程以 32 个为一组，窃取仅限组内发生。这既限制了单个线程挑选目标的时间，也减少了线程数过多时出现“前面有n个线程时仅获得预期的0.5^n份任务”的极端情况。在开启线程亲和性绑定的情况下（游戏默认设置即启用），这还大幅降低了数据跨 NUMA/CCD 同步的概率。

沿用“冒险者公会”的比喻，现在允许多名冒险者同时挑选任务；如果两人选中同一任务，则严格按先后顺序，后者只能领取前一人剩余任务量的一半。原先所有分会共享同一任务栏，领取时需相互通知；现在则改为最多 3～4 个相邻分会共享任务栏，从而大幅降低了通信成本。

最终优化效果可以直接从新图中看出——原本明显的红色调度开销区域现已基本消失。

◆ 优化内存瓶颈

谈到这一点，我们首先要感谢玩家社区的关注与热情。自游戏发售后，已有不少敏锐的玩家注意到内存性能对我们游戏帧率表现的影响，甚至有 Mod 作者专门推出了面向内存优化的 Mod，为我们提供了宝贵的思路和经验。

戴森球计划对内存的需求高于其他类型游戏，其实并不意外。由于游戏中存在大量独立运行的实体，每个实体都需要处理自己独有的数据，为了保持性能，我们一直刻意避免在玩家可能大规模建造的实体中加入过于复杂的逻辑。因此，大多数情况下实体的逻辑都非常简单，计算机的工作流程基本是“读取数据 → 稍作修改 → 读取下一个数据”，处理器与内存之间的通信自然十分频繁。

此外，游戏本身具备不错的并行程度，在数据存取和遍历时也特意遵循了内存连续读写的顺序。这在较新的消费级平台上，内存性能确实容易成为拖后腿的一方。

有的玩家可能好奇自己的设备究竟是哪一块在拖后腿，这里我们可以提供一个大致参考：在消费级平台中，对于近几代较新的处理器（如 12 代以后的 Intel 或 Zen2 架构之后的 AMD），由于核心数、缓存大小及预读取能力的提升，性能瓶颈往往偏向内存带宽；而对于一些缓存较小、核心数较少的早期处理器（如 7~10 代 Intel 或 Zen1 架构前的 AMD），则可能因缓存不足或并发读取能力有限，使瓶颈更偏向内存延迟。至于更早的平台，处理器性能本身可能已成为主要制约。

我们在设计程序数据结构时，自然也考虑了内存与性能问题，会尽量避免明显的缓存不友好设计。但另一方面，也必须兼顾代码的可维护性与可扩展性。毕竟硬件市场在不断发展，过早优化不仅会拖慢开发进度、增加维护成本，还可能因技术迭代而失去优化价值。因此，在开发中期，我们仍将重心放在实现功能与保持开发效率上，待版本稳定后再系统性地推进优化。

在本次更新中，我们优化了各种生产设施、分拣器等常用建筑的数据结构。具体来说，我们将一些不常用的数据分离出去，使结构体“瘦身”，从而降低顺序遍历时的带宽压力。对于大量建筑共用的数据（如配方数据），也进行了合并处理，让连续访问同类型建筑时，相关数据更有可能已存在于缓存中。同时，对一些高频访问但存储位置较远的数据，在成本可控的情况下也做了缓存处理，并尽量避免不必要的远端数据访问。

由于处理器对缓存的实际管理对我们而言是完全的“黑箱”，很多优化是否有效必须通过实际测试才能验证。甚至有些改动在一部分设备上略有提升，在另一套设备上却可能导致性能下降。为此，我们前后尝试了二十多种不同的调整，打包测试了二十多个版本，最终选择了其中十几项有明显优化效果的改动，纳入此次更新。

◆ 一些其它优化

在上述两项优化之外，我们也针对后期存档在线程撕裂者上的表现中有优化价值的其它部分进行了优化。比如已建成的戴森球实际上每帧并不需要那么多的计算。以及部分多线程在多者读、一者写的逻辑中的锁换成读写锁。电力系统耗电需求预计算的逻辑替换到了更适合多线程并行也更适合缓存命中的位置，大大减少了可能的伪共享造成的问题。

◆ 未来的方向

优化工作永无止境。目前我们仍有一些优化目标列在未来计划中（例如货物系统，或解决极限存档下物流系统的突发卡顿等）。但这些修改涉及范围广、逻辑复杂，若出现意外，风险及影响也较大，每次改动都需要投入大量测试时间，因此未列入此次更新。

同时，对于一个长期项目而言，过早优化往往会影响后续开发节奏，增加团队对代码的理解和维护成本。我们将在未来版本稳定、时间充裕时，对这些优化方案进行充分思考和验证，再稳妥地引入。

文字组件重制：为未来铺路

Unity的原生文字组件（Text/TextMeshPro）对中文排版的支持有限，它最初是为拉丁字母文字（尤其是英文）设计的，其底层机制没有考虑到中日韩（CJK）等非字母文字的复杂排版规则。

最核心的缺陷在于原生文字组件以空格为基准的布局完全不符合中文习惯，换行逻辑基于空格、连字符等分词符号。由于中文等语言不需要空格分隔单词，原生组件无法准确判断在哪里断行才是合理的，它只能在字符超出行宽时，简单地在最后一个字符后换行。所以，会经常出现如“，” “。”等标点符号经常会出现在一行的开始，而像前括号 ”（“ 等符号又经常出现在一行的末尾等排版问题。

为了解决这些问题，也为了支持我们的各种设计（例如备忘录中的各种富文本），以及能够更好的排版新加入的语言，我们对Unity引擎中的文字组件进行了重制。虽然这一项工作耗费了极大的精力和心血，但是我们相信，文字组件的重制，不仅是团队的一次技术沉淀，更有助于《戴森球计划》迈向更广阔的社区。

重制后的文字组件实现了以下功能：

◆ 自定义字符间距与混排间距

新组件开放了各种字符的间距以及中/英/数字混排间距，可以根据实际文本对这些间距进行修改，保证排版的美观。