← #802

用 Rust 和 Bevy 打造的自运行太空经济模拟器

文章摘要

The Space Project 是一个用 Rust + Bevy 写成的「零玩家」太空经济模拟器：没有剧本、没有任务线、没有胜利条件，只有几百个各自独立决策的自治体在一个太阳系里做生意、破产、迁徙和重建。作者 Kalcode 的说法很直白——这不是游戏，而是一个沙盒；他一直想折腾经济模拟，又痴迷太空题材，于是就做了出来。

模拟的核心机制相当扎实。每艘船跑自己的 GOAP（目标导向行动规划）planner，在「跑最优贸易航线」「接一单运输合约」「去加油」「到船厂改装」「回港让船员休息以免士气崩盘」之间自行权衡，并且会在飞行途中因为出现更好的机会而重新规划。每个空间站都有自己的订单簿市场，为 13 种商品定价，采用带「短缺紧迫度乘数」的覆盖率模型，而且供给是真的靠飞船在站与站之间搬运产生的。合约系统有六种类型（配送、快递、载客、补贴、供应、船员任务），带完整生命周期、声望门槛、自动续期和随时间递增的报酬。设施会按配方生产（冶炼、精炼、农业、采矿），会随时间损耗、用工具自修、可升级到 10 级，长期亏损则会被废弃并腐烂。派系收税、针对短缺发布补贴合约、在有需求的地方出资建新设施，彼此还维持两两关系。人口消耗食物和燃料、产出劳动力，压力大时发合约，情绪长期恶化就直接举家迁往更幸福的星系。长期短缺会催生建造工地，逐步累积送达的货物，最终实体化为一座新设施。

技术上，作者把「纯模拟」和「渲染」拆得很干净：sim_core 用自己的 hecs ECS，完全同步、无 IO、不碰 async 和数据库，因此可单测；Bevy 客户端直接把它当库嵌进来，模拟与渲染共享同一个世界，零序列化开销。整个工作区分五个 crate（sim_core / sim_db / sim_server / sim_protocol / client_bevy），跨实体影响统一走命令缓冲（SimCommand）以保证确定性。持久化用 sqlx + 内置 SQLite，单个原生二进制、无运行时依赖，存档就是二进制旁边的 <universe>.db，重启后从上次那一 tick 精确续跑。渲染侧有手写 WGSL 着色器做程序化行星、日冕、星云和星场，egui 做检视面板，bevy_hanabi 做 GPU 粒子尾迹与爆炸。目前规模约 485 个活跃自治体（282 艘船、93 座设施、27 个人口群、8 个派系、60 个天体），tick 的 p50 在 10–20 毫秒，预算是 125 毫秒，架构目标是冲向 10 万+。

项目还有一段有意思的前史：最初是 Elixir/Phoenix 原型，但 BEAM 调度器在 Windows 游戏 PC 上表现挣扎，于是整个引擎被重写成 Rust；早期的 Godot 客户端还留在版本历史里，但已经不再维护。作者坦承相当大一部分代码是与 Claude 结对写出来的——正是这一点让他能在业余时间把项目推到这个体量。代码 MIT 开源，他明确欢迎任何人 fork 接手，「或者它就停留在某种 AI 产出的半成品状态也行」，但他觉得作为一个可供各类游戏复用的模拟引擎，现在的状态已经不错了。

HN 评论精华

kalcode（作者）：Show HN 原帖里坦白全盘：一切都不是脚本化的，几百艘船各跑各的 planner；市场按供给和短缺紧迫度定价，派系征税与补贴，人口不满就迁徙，破产的站被废弃并腐烂。他强调这是沙盒不是游戏，没有目标，也不打算推向「可发售」，任何人都可以接手。关于规模，他说推到 10 万很挣扎，但推到几千是能稳跑的。
sulam：这类项目明显是被 LLM 辅助「解锁」的——没有它们大概根本不会启动。虽然 LLM 的炒作周期似乎已过顶点，但他确信软件开发这块还处在早期。唯一的问题是这类项目可能会多到爆；他自己已经做了至少 5 个原本没时间做的玩意儿，就算只是挠自己的痒也无所谓。
kalcode（回应）：确实，有了辅助编程，晚上和周末就能啃下那些以前不敢碰的东西。理想情况下这类项目应该更多，这个转变会很有意思。
awhitty：他在做基于 Escape Velocity 系列的类似概念，追问派系组织结构和信息流：agent 对价格和挂单是全知的吗？他自己的做法是把「站内信息」变成一种可以在 agent 之间买卖的商品，但没把这个机制做透。
kalcode（回应）：不是全知，但他允许飞船在一个站更新整个星系的信息——因为信息太受限时，目标权重算出来的结果几乎总是死守已知航线、不去探索。他后来也觉得「一站只知一站」在技术设定上不太合理。派系系统是他对「怎么让飞船和星球的目标超越眼前需求」这个问题的答案：派系想赚钱，就用补贴之类的激励去改变优先级。他期待派系能升级到封锁、垄断、供给管制、价格暴涨，甚至为争夺咽喉要道而触发战斗事件，这样 agent 的状态机专注于目标导向行动，飞船兼顾自身与派系激励，船员需求负责即时需要。
lantry：他也在用 Claude Code 开发 Rust + Bevy 游戏，效果很好——Rust 的严格性帮模型把代码写对，ECS 架构让模型容易推理（一次只需在上下文里装几个 system 和 component）。他好奇 ECS 会不会流行到游戏业以外，虽然不确定它适合 Web SaaS。
lantry（谈 Bevy 实操）：Claude 处理 Bevy 没问题，只是在「怎么组织 component 才最好」上会有点吃力，仍需人类把关；强调要「idiomatic Bevy 代码」很有帮助，在设计与 review 上多花 token 也很值。他还提到 Bevy Remote Protocol 可以通过 HTTP 检视 Bevy 状态，对 agent 调试极有帮助——他让 Claude 加了个包装层，可以注入鼠标键盘事件并触发截图落盘，于是 Claude 能自己驾驶整个游戏做端到端验证。
kalcode（谈 ECS）：游戏和某些特定应用天生需要这种单向数据流 + 海量「独立」实体的组合。ECS 不是「会不会流行到游戏业外」的问题，它是针对典型游戏问题的特定解；很多应用底层其实也在用类似架构，只是这跟问题域绑定，不是万能解药。
Sharlin：一句话概括——ECS 本质上就是列式存储，只是把这套思路从数据延伸到了行为。
digilypse / kalcode（Godot vs Bevy）：被问为何不用 Godot，作者说他其实更熟 Godot，但撞上性能问题，绕过节点场景直接用渲染 API 之后，感觉已经算是抛弃 Godot 了。他想少操心渲染、多专注经济模拟的扩容，而实体越多渲染越吃力；Bevy/Rust 在每个线程/进程的开销更小，更容易靠蛮力把规模顶上去。
hersko：建议把模拟托管起来供在线观众围观（当然要关掉上帝模式），再让一个 agent 把里面发生的有趣事件写成报纸或新闻简报。
nine_k：所以这就是个太空版鱼缸——你坐着看，偶尔挪挪石头，或者投放新物种。
dangoodmanUT / Sharlin / Cthulhu_ / ivanjermakov：一片「把我自己的 spec 文档扔了」的哀鸣，好几个人都刚有过同样的点子。Cthulhu_ 说他的灵感来自 Rimworld + Eve Online + 《苍穹浩瀚》，但承认点子廉价、执行才算数，而作者是真的做出来了。ivanjermakov 则做了三个月才意识到自己造的是「又一个电子表格模拟器」——点子在脑子里总是闪闪发光。
greenleafone7：唱反调的一票——本来挺兴奋，看到「用 Claude 做的」就没劲了；他本想研究代码，但对他而言读 LLM 写的代码没什么意义，跟看 LLM 画的画一样。
qwertyastronaut / natebc / thomascountz / spacecadet：一串同好推荐——X4: Foundations 刚发了大更新（aliasxneo 抱怨官方只顾战斗，自动化与经济端被冷落，NPC 会完全无视你精心设置的物流规则）、Steam 上的 Warp to Sector One（有当年 Tradewars 的味道）、SpaceTraders.io，以及另一个 AI 写的零玩家模拟 simcraft。