Elytra
Blog以太

《以太效应》:我们想创造一个怎样的沙盒世界?

从可编辑的体素世界、物理模拟和机械装置,到 UGC、Mod、AI 干员与动态叙事:《以太效应》试图构建的不是一份越来越长的功能清单,而是一个能够被玩家、创作者、程序与 AI 共同理解和改变的沙盒世界。

《以太效应》(AetherEffect)是一款持续开发中的沙盒生存体素游戏。

如果一定要用一句足够直观的话描述最初的愿景,它大概是:

“写实版 Minecraft” + 机械动力 / 航空学 + 物理角色 + AI NPC + UGC / Mod / AIGC。

但这句话其实很容易产生误解。

它听起来像是在一个项目里不断添加热门功能:体素、物理、载具、AI、Mod、生成式内容……如果只是把这些东西并排放在一起,那么《以太效应》最终只会成为一个越来越庞大的功能集合。

真正贯穿项目的核心问题其实更简单:

如果一个游戏世界不仅能够被玩家探索,还能够被玩家、物理系统、程序、创作者、NPC 与 AI 共同读取和改变,它最终会变成什么?

因此,《以太效应》真正想建立的,不是一份内容列表,而是一个可以持续发生变化的世界系统。

体素提供可编辑的世界结构,物理让结构之间能够发生作用,UGC 和 Mod 让玩家开始定义内容与规则,而 AI 则进一步尝试成为这个世界中的观察者、行动者,乃至创作者。

这几条路线最终指向的是同一个方向。

Loading diagram…

本文介绍的是《以太效应》的整体设计方向与当前工程基础,而不是发布版功能承诺。

截至 2026 年 9 月,项目已经拥有体素世界、程序化生成、动态体素、蓝图、JS/TS Mod、Utility AI、LLM 任务规划、AI 建造、生存经营和联机基础等系统;但其中部分能力仍处于开发、实验或需要实际游玩验收的阶段。1

1世界是游戏最重要的系统

传统游戏里的世界,很多时候更接近一座舞台。

建筑、道路、山脉和房间决定玩家可以去哪里,却通常不是玩家真正能够操作的对象。即使场景看起来非常真实,它仍然可能只是围绕角色搭建的一套静态背景。

体素世界最重要的改变,是让“世界”本身成为数据。

一面墙不再只是模型。

它可以被挖掉、填补、复制、替换。

一座山不再只是远景。

它可以被切开、贯穿,甚至成为机械结构的一部分。

于是,地图不再仅仅承担“承载玩法”的职责,它自己开始参与玩法。

1.1为什么从体素开始?

很多人第一次看到体素游戏,首先想到的是“方块”。

但对于《以太效应》而言,体素首先是一种世界表示方式,然后才是一种视觉表现。

当前工程将世界划分为可流式加载的体素区块,负责体素数据、网格、碰撞、修改与持久化;Overworld 则通过连续的气候与地形采样生成海陆、山地、岛屿、洞穴、群系、矿脉与地表装饰。1

这意味着世界中的地形不是一张预先烘焙好的巨大 Mesh,而是一份可以查询和修改的数据。

可以把它抽象为一个空间函数:

V(x,y,z)→VoxelDataV(x,y,z) \rightarrow \text{VoxelData}

给定一个世界坐标,我们能够询问:

  • 这里是不是实体地形?
  • 它属于什么材质?
  • 是否能够挖掘?
  • 上方是否有足够空间?
  • AI 能否站在这里?
  • 建筑蓝图能否放置在这里?
  • 一次爆炸应该影响哪些区域?

一旦世界能够被这种方式查询,它就不再只是渲染结果,而成为其他游戏系统共享的公共事实来源。

1.2“写实体素”并不矛盾

因此,《以太效应》里的“写实版 Minecraft”并不是要把 Minecraft 的方块换成更加高清的方块。

“体素”与“方块美术风格”并不是同一个概念。

底层世界可以仍然由离散数据组成,而最终表面通过网格重建得到更加连续的形状。

Loading diagram…

玩家看到的是山坡、洞穴与岩壁,而游戏系统看到的仍然是一份结构清晰、能够查询和修改的世界数据。

这一区别非常重要,因为它决定了后来很多系统为什么能够连接起来:

体素不是世界的外观,而是世界可以被程序理解的基础。

1.3程序化生成的意义也不只是“地图无限大”

程序化生成经常被理解成一种节省人工制作地图的方法。

但对于沙盒而言,它更深层的意义在于:

开发者不再描述每一块土地长什么样,而是描述“什么样的土地可以出现”。

传统关卡更接近:

这里有一座山。
那里有一片树林。
这里放一个矿洞。

程序化世界更接近:

在这些气候、海拔、湿度与噪声条件下,
山脉、岛屿、洞穴、矿脉和植被应该如何产生?

开发对象从“结果”逐渐转变为“生成结果的规则”。

而这恰好也是《以太效应》后面 UGC、AI 与动态叙事不断重复出现的设计思想:

与其制作更多结果,不如制作能够产生结果的系统。


2从体素沙盒走向物理模拟

世界可以修改,并不意味着世界就已经“活”了。

如果玩家挖下一块东西之后,它只是从数据库里消失,那么我们拥有的是一个可编辑世界,却未必拥有一个能够产生复杂互动的模拟世界。

因此,《以太效应》的第二层是物理。

2.1“写实”首先意味着行为可信

这里的“写实”并不主要指照片级画面。

项目目前使用 Unity 6 与 HDRP,但视觉保真度只是其中一部分。1

更重要的是:

一个东西看起来是什么,应该尽可能与它能够做什么保持一致。

如果一个结构悬空,它是否应该掉下来?

如果一艘由体素组成的船进入水中,它能不能根据自身结构获得浮力?

如果在它后方装上推进器,推进力能不能真正推动这个结构?

如果继续把结构挖断,原本的一整个物体能不能拆成两个独立的刚体?

这些问题开始把“建造系统”和“物理系统”连接起来。

2.2从静态世界到动态体素

《以太效应》目前除了固定的世界地形,还拥有独立的动态体素体积。

这些体素保存在对象自身的局部坐标中,因此整个结构可以作为 Rigidbody 移动和旋转。

这意味着同一套体素概念开始出现两种状态:

Loading diagram…

于是,“世界”和“物体”之间原本坚硬的边界开始变得模糊。

一座固定在地面的结构,未来可能成为一个动态装置。

一个动态结构也可以保存成蓝图,再重新放回世界。

2.3机械不是预制载具,而是世界规则的组合

项目已经存在推进器、气球、绳索、驾驶舵等可装配装置,并能够通过锚点连接到世界体素、动态体素或其他实体。

这件事真正有趣的地方,并不是“游戏里有一个推进器”。

而是推进器不必只属于某辆开发者提前做好的载具。

如果玩家可以:

  1. 建造一块结构;
  2. 给它增加浮力;
  3. 安装推进器;
  4. 安装控制装置;
  5. 再通过物理系统让整个结构运动;

那么我们得到的就不再只是“船”这个游戏内容,而是制造船的规则。

同样的规则以后还可以继续扩展到汽车、飞机、机械结构以及更复杂的动力系统。

这也是机械沙盒和传统载具系统之间最根本的区别。

2.4沙盒真正的复杂度来自关系

假设游戏中有 nn 个彼此完全独立的系统,那么玩家得到的体验大致仍然只是 nn 种玩法。

但如果这些系统能够两两发生作用,潜在关系数量就已经变成:

(n2)=n(n−1)2\binom{n}{2}=\frac{n(n-1)}{2}

这当然不是一个可以拿来计算“游戏乐趣”的公式。

它只是说明一个重要的设计现象:

沙盒的深度更多来自系统之间的乘法,而不是功能数量的加法。

地形可以影响建筑。

建筑可以转化成动态结构。

动态结构可以装上推进器。

能源系统可以限制推进器。

AI 可以驾驶或建设这些结构。

蓝图又可以保存它们。

当系统能够互相引用时,开发者并不需要亲手设计每一种结果。

很多玩法会从规则之间自然产生。


3从玩家到创作者

当一个游戏允许玩家越来越自由地修改世界时,会很自然地出现第二个需求:

既然我已经可以改变世界,为什么不能把这些改变保存、复用和分享?

这就是沙盒开始走向 UGC 的地方。

3.1从手工操作到创作工具

当前工程已经包含一套运行时开发与创作工具。

例如:

  • 体素笔刷;
  • WorldEdit 风格的 /we 命令;
  • 选区、填充、替换、复制、剪切与粘贴;
  • 实体选择与 Transform 操作;
  • 蓝图捕获、预览与放置;
  • Minecraft 建筑格式导入;
  • JavaScript / TypeScript Mod;
  • 可扩展命令系统。

这些工具的价值并不在于“游戏里也有一个编辑器”。

真正重要的是它们逐渐建立了一组操作世界的标准接口。

Loading diagram…

玩家的权限随着这条链条逐渐上升。

最开始只能改变某个具体对象。

后来可以保存一组对象。

再后来可以描述行为。

最终,甚至可以改变游戏规则本身。

3.2蓝图为什么重要?

蓝图的本质并不仅仅是“复制建筑”。

一次普通建造行为的结果只存在于这个世界的某个位置。

蓝图则把它变成一个独立的数据对象:

从世界状态中提取出一个可以再次实例化的结构。

当前蓝图能够捕获一块轴对齐体素区域及符合条件的实体,并重新预览、定位和放置;同一套数据还能够进入 AI 建造流程。1

于是一个建筑第一次从“结果”变成“语言”。

玩家能够使用它。

AI 也可以使用它。

Mod 同样可以引用它。

这为后面的 AI 创作提供了非常关键的中间层。

3.3为什么还需要脚本和 Mod?

蓝图很擅长回答:

这个东西由什么组成?

但它不擅长回答:

这个东西应该怎样运行?

这就是脚本存在的意义。

当前项目通过 PuerTS 执行 JavaScript,并允许 TypeScript 经过工具链编译为可加载脚本;Mod API 则向脚本暴露物品、实体、配方、命令、任务、事件、资源与表现层接口。1

于是扩展能力开始从数据进入逻辑:

体素:改变世界

蓝图:保存结构

脚本:描述行为

Mod:扩展规则

开放并不意味着没有边界。

当前 Mod 系统的目标是提供受项目 API 约束的 JS/TS 扩展能力,而不是允许发布版任意加载新的 C# 程序集;Minecraft 世界导入目前也主要处理 Overworld 地形方块,并不意味着完整兼容原版生物、容器物品和玩家数据。1

这些边界是有意存在的:UGC 系统不仅要考虑“能不能做”,还必须考虑版本兼容、存档稳定性、安全边界与未来维护成本。

3.4真正稀缺的不是内容,而是产生内容的能力

如果一个沙盒长期依赖开发团队制作:

  • 更多房屋;
  • 更多载具;
  • 更多任务;
  • 更多地图;
  • 更多玩法模式;

那么无论团队效率多高,内容生产速度最终都会成为瓶颈。

另一种思路是:

把开发者自己使用的一部分创造能力逐渐交给玩家。

这也是《以太效应》为什么同时需要编辑器、蓝图、命令、脚本和 Mod。

我们真正希望建设的是一个层层递进的创作栈:

Loading diagram…

一旦这个循环成立,世界就不仅能够被消费,也能够持续生产新的世界。


4AI 应该怎样进入一个沙盒世界?

生成式 AI 出现之后,把 LLM 接到 NPC 对话框里已经不是一件特别困难的事情。

真正困难的问题是:

为什么一个能说很多话的 NPC,仍然可能一点也不像一个真正生活在游戏世界里的角色?

答案通常不是语言能力不足。

而是它与世界之间缺少联系。

4.1AI NPC 不应该只是聊天机器人

假设玩家刚刚:

  • 砍倒了 NPC 面前的一棵树;
  • 把房子炸掉了一半;
  • 偷走了桌上的物品;
  • 引来了一群敌人;
  • 又在门口造了一辆奇怪的机器。

如果 NPC 仍然只是等待玩家点击“对话”,然后根据一段固定人物设定开始聊天,那么无论模型有多强,它依然只是一个被放进游戏里的聊天窗口。

真正生活在世界里的角色至少需要一个闭环:

Loading diagram…

语言只是其中一部分。

4.2玩家和角色应该是两个不同的概念

《以太效应》目前采用一个非常重要的结构:

玩家(Player)和角色 / 干员(Agent)并不是同一个实体。

玩家可以附体某个干员直接控制角色,也可以退出附体进入观察状态。

当角色没有被玩家直接控制时,它又可以交给 AI。

Loading diagram…

这个设计看起来只是程序架构上的拆分,但实际上改变了很多东西。

角色不再天然等于“玩家的身体”。

它可以同时作为:

  • 玩家角色;
  • AI NPC;
  • 队伍成员;
  • 可切换角色;
  • 世界中的独立行动者。

这让“角色自主性”从一开始就进入了架构。

4.3LLM 不应该负责每一步动作

一个常见误区,是让语言模型直接决定 NPC 的全部行为。

例如不断询问:

我下一帧应该往哪里走?

这既昂贵、缓慢,也没有必要。

传统游戏 AI 在很多问题上已经非常成熟:

  • 寻路;
  • 移动;
  • 动画;
  • 战斗;
  • 资源选择;
  • 行为中断;
  • 状态维护。

因此《以太效应》目前采取的是一种分层方式。

底层使用 Utility AI,根据感知上下文和行为评分,在跟随、拾取、采集、战斗、吃饭、工作、闲逛等动作之间进行选择。

寻路则直接查询体素世界并进行局部 A* 搜索,而不是依赖固定 NavMesh。1

LLM 更适合进入上层:

Loading diagram…

可以把分工简单理解为:

层级更适合处理的问题
LLM意图、自然语言、目标、高层规划、角色表达
Planner把开放目标转成有限的游戏步骤
Utility AI根据当前环境选择和调度具体行为
游戏系统寻路、移动、动画、采集、战斗、建造等确定性执行

核心思想是:

LLM 决定“我想做什么”,游戏系统负责“这件事具体应该怎样完成”。

这种结构还带来另一个重要好处:

AI 最终能够做什么,不再由模型“会不会幻想出来”决定,而由游戏明确提供的能力决定。

模型不能凭空获得一个世界里不存在的动作。

4.4从说话到真正做事

当前工程已经能够通过 @干员 形式向角色下达自然语言请求。

模型产生 Goal 后,本地代码将目标展开为 Plan,再执行有限步骤与重规划;目前任务可以连接聊天、采集、交付、合成和建造等行为。1

于是:

“帮我找一些木头。”

不再只是触发一句:

“好的,我去帮你找木头。”

而是可以逐渐转化为:

识别目标
→ 查询资源
→ 寻路
→ 采集
→ 更新库存
→ 返回 / 交付

这才是 AI NPC 真正开始产生价值的地方:

语言与世界行为之间建立了因果关系。


5AI 建造:当语言开始改变空间

建造尤其适合观察这种变化。

传统 NPC 可以很容易播放一段“正在工作”的动画。

但真正让 AI 在体素世界里建造一栋房子,需要解决完全不同的问题:

  • 建什么?
  • 在哪里建?
  • 结构是否合法?
  • 使用哪些材料?
  • 需要多少材料?
  • 按什么顺序施工?
  • 多名角色怎样避免互相冲突?
  • 世界在施工过程中发生变化怎么办?

《以太效应》目前有两条不同的 AI 建造路径。

一种是使用已经登记的蓝图,让 AI 按照已有结构逐格施工。

另一种则是自由造型,通过独立规划器产生受到约束的体素操作。

登记蓝图还能够让多名干员参与协作建造。1

这也说明了为什么前面的 UGC 系统如此重要。

Loading diagram…

如果 AI 和玩家使用的是完全不同的内容系统,那么两边的发展很难互相促进。

但如果 AI 能够使用玩家已经拥有的工具,那么每一次 UGC 工具的增强,都可能同时增强 AI。


6当 AI 也成为创作者

这让 UGC 和 AIGC 出现了一个非常有意思的交汇点。

通常谈到游戏里的 AIGC,人们首先想到的是:

  • 生成一张图片;
  • 生成一段音乐;
  • 生成一个模型;
  • 生成几句 NPC 台词。

这些能力当然有价值。

但对于沙盒游戏而言,还有一种可能更加重要:

AI 能不能生成“真正属于游戏系统的东西”?

例如:

  • 一份蓝图;
  • 一套体素建筑;
  • 一段任务逻辑;
  • 一个 Mod 脚本;
  • 一组角色行为;
  • 一段能够实际改变世界的事件。

区别在于,前者生成的是媒体内容,后者生成的是可执行的世界结构。

6.1AI 最好不要拥有“魔法”

一种非常诱人的做法,是为 AI 开放一个无所不能的内部接口:

CreateAnything()
ModifyAnything()
DoAnything()

这样 Demo 很容易做出来。

但问题也很明显:

AI 的能力与玩家、世界规则和游戏系统完全脱节。

更有意思的方向是:

Loading diagram…

也就是说:

AI 尽可能使用与玩家相同或至少同构的工具。

如果 AI 想建造,它使用蓝图或体素操作。

如果 AI 想获取物品,它通过库存与任务系统。

如果 AI 想改变世界,就通过受约束的命令。

这样生成式 AI 不再悬浮在游戏规则之外,而真正进入游戏机制内部。

对于沙盒游戏而言,AIGC 最值得探索的方向可能并不是“自动生成更多素材”,而是:

让 AI 学会使用游戏已经存在的创造能力。

当 AI 能够操作蓝图、脚本、实体、任务和世界状态时,它生成的不只是内容,而是新的因果关系。


7从 AI NPC 到动态叙事

当 AI 能够观察世界、理解事件并执行动作之后,另一个问题自然会出现:

故事一定要在玩家进入游戏之前就全部写好吗?

传统任务系统通常可以抽象成:

Loading diagram…

这种方式最大的优点是可靠。

作者知道玩家将看到什么,也能够精确控制戏剧结构。

但沙盒越自由,作者越难预测实际发生的事情。

玩家可能炸掉本该保护的建筑。

重要 NPC 可能已经死亡。

玩家可能根本没有按照设计者预计的路径生活。

于是传统剧本与动态世界之间会产生越来越大的张力。

7.1从“播放剧情”转向“理解发生了什么”

《以太效应》目前已经存在一套轻量的叙事编排实验。

NarratorContext 可以向 LLM 提供近期事件,/narrator run 则允许模型在命令协议限制下生成叙述以及部分世界操作。1

这还不是完整的 AI Director,也不是可以替代传统剧情系统的成熟方案。

但它验证了一个方向:

Loading diagram…

传统方式更接近:

作者先写故事,玩家再触发故事。

动态方式则可能逐渐变成:

世界先发生事情,系统再判断其中有什么值得成为故事。

例如:

  • 一座重要基地在战斗中被摧毁;
  • 玩家长期与某名干员共同冒险;
  • 某名角色多次救下另一名角色;
  • 玩家搬到了极远的地区;
  • 一个意外的机械事故改变了聚落结构。

这些事情原本只是模拟系统中的状态变化。

但如果角色能够记住它们,叙事系统能够理解它们,那么它们就可能逐渐获得“故事”的意义。


8一个真正持续存在的世界

如果世界中的状态越来越多,多人模式也会变成一个比“同步玩家坐标”复杂得多的问题。

《以太效应》目前已经拥有基于 Mirror 的 Host / Client 联机基础以及 Steam 账号、大厅和加入流程,但当前工程仍然以单机 / Host 开发和验证为优先,部分多人行为需要逐项验收。1

真正需要共享的最终可能包括:

Loading diagram…

这也是为什么沙盒多人游戏的网络问题最终很难只被理解成“联网功能”。

当玩家可以永久改变世界时,服务器实际上需要回答:

哪一个世界状态才是真实的?

当 AI 能够继续行动时,又会出现:

没有玩家附近时,世界是否仍然运行?

当动态体素发生断裂、物理结构不断运动时,还要继续面对:

哪些模拟应该实时同步,哪些应该重新计算,哪些可以降级?

因此,多人并不是《以太效应》外面再套一层网络代码。

它最终会反过来约束世界、实体、物理和 AI 的架构。


9“以太效应”究竟是什么?

到这里,其实可以重新回到这个项目的名字。

有意思的是,《以太效应》的技术方向和它的世界观并不是两条完全独立的线。

游戏机制一直在讨论:

如果世界是一套可以被读取、模拟和修改的数据,会发生什么?

而故事最终讨论的,也是同一个问题。


10公元 2064:现实世界的尽头

故事发生在 2064 年。

地球资源逐渐逼近极限。

人类发现了一种能够连接并解析宇宙底层“零点场”数据的技术。

这项技术被称为:

Aether Effect —— 以太效应。

研究者发现,人类无法直接理解这些信息。

但它们可以被映射成一种介于物理现实、信息结构与模拟空间之间的世界。

人们称它为:

析构世界。

进入其中的人看到山川、物体、生命与空间。

但从另一个角度看,它们又可能只是某种更底层宇宙信息的可理解表达。

而人类真正想得到的,是来自宇宙最极端区域的数据:

黑洞引力奇点。

如果能够获取并解析奇点的数据,人类也许能够进一步补全关于宇宙底层结构的方程,并寻找突破现实资源极限的方法。

问题在于,以太效应并不稳定。

大量早期实验者在连接过程中死亡。

极少数幸存者则被抛入析构世界。

玩家便是其中之一。


11第一部:奇点 · Singularity

第一部的核心问题是:

宇宙的边界在哪里?

玩家作为最早进入析构世界的实验体之一醒来。

最初的问题非常原始:

如何活下来?

玩家需要探索、采集、制造、建造,并理解这个陌生世界的规则。

但所有这些行为最终都指向一个更遥远的目标:

抵达黑洞,取得奇点数据,并将其发送回现实世界。

只有成功取得这些数据,现实中的研究者才能继续完善以太效应,让更多人安全进入析构世界。

于是第一部的结构,本质上是一场不断向未知推进的旅程:

Loading diagram…

最初玩家只是想理解:

我怎样才能在这里活下去?

但随着旅程深入,问题会逐渐变成:

这里究竟是什么地方?


12第二部:演算机 · Algorithm

如果《奇点》追问的是:

宇宙的尽头在哪里?

那么《演算机》进一步追问:

宇宙为什么会按照现在的方式运行?

随着对析构世界的研究继续深入,人类逐渐发现:

我们平时称为“自然规律”的东西,也许并不是世界的最底层。

在规律之下,还可能存在更加基础的结构:

数据,以及处理数据的规则。

于是宇宙开始呈现出另一种可能性。

如果物理规律可以被描述为状态的演化:

St+1=F(St)S_{t+1}=F(S_t)

那么真正决定世界未来的,或许不仅是某一时刻的状态 StS_t。

更根本的问题是:

函数 FF 本身来自哪里?

换句话说:

宇宙拥有数据,那么它是否也拥有算法?

“演算机”讨论的正是这一层。


13第三部:湮灭 · Oblivion

而一旦人类开始理解那套算法,危险也随之发生。

问题不再是:

我们能不能理解世界?

而变成:

如果已经理解,我们是否应该修改它?

对演算过程、熵与零点场的干预,最终把问题推向真空湮灭。

到了这里,最初“解决地球资源危机”的工程问题已经消失。

取而代之的是一个更加根本的问题:

如果宇宙最终仍然会归于虚无,那么所有存在过的东西还有意义吗?

Oblivion 因而不仅意味着毁灭。

它真正指向的是“消失”。

不是一座城市被毁灭,也不是某个文明结束。

而是:

如果最终连记录、观察者和宇宙本身都不存在,那么曾经发生过的一切,还算存在过吗?


14游戏系统与世界观其实在讨论同一个问题

到这里,《以太效应》的系统设计和世界观开始重合。

游戏机制世界观中的对应问题
世界由结构化数据表示析构世界是否也是某种信息映射
世界可以被查询人类能否解析宇宙底层数据
世界可以被修改宇宙规律是否可以被干预
蓝图和脚本描述结构与行为世界是否存在更底层的规则
AI 读取世界状态智能是否能够理解这套系统
AI 操作世界理解规则之后是否能够改变规则
系统组合产生不可预测结果对底层规律的干预是否存在不可控后果
动态叙事解释已经发生的事件意义是否来自事件本身,还是来自解释它的观察者

所以《以太效应》并不是先有一套沙盒玩法,再在上面附加一个科幻故事。

两者最终都在追问:

如果世界本身是一套可以理解、计算、重构甚至改写的系统,会发生什么?

这也是体素、Mod、AI、演算机和奇点能够出现在同一个项目里的原因。

它们并不是几个彼此无关的主题。

它们只是从不同方向接近同一个问题。


15这不是一张已经完成的蓝图

讲一个仍在开发中的游戏,最容易出现的问题之一,就是把“我们想做什么”和“现在已经有什么”混在一起。

《以太效应》的长期方向很大。

但“方向存在”并不意味着问题已经被解决。

因此,更准确的方式是把项目分成几个不同层级:

状态含义例子
已有实现工程中已有代码和数据路径体素世界、蓝图、Mod、Utility AI、LLM 任务、AI 建造、生存与经营
已有但仍需验证 / 完善已有实现,但组合、体验或平台覆盖仍需实际验收多人同步、部分载具、动态体素复杂编辑、远景 LoD
实验性方向已经存在 Prototype 或有限实现,但远未形成最终玩法LLM 叙事编排、自由 AI 建造、语音交互
长期愿景用于指导架构和研究方向,不代表具体版本承诺更完整的 AI Director、AIGC 创作、机械动力与航空学、完整三部曲

例如,远景地形 LoD 已经存在实现,但当前默认关闭;动态体素断裂是可选能力,并仍有规模限制;多人模式拥有 Mirror 与 Steam 基础,却不能因此推导出“所有玩法已经完整支持多人”。1

同样,目前已经可以让 LLM 根据上下文生成受命令协议约束的叙事操作,但它仍然是一个轻量实验,而不是一套已经解决开放世界动态剧情问题的完整 AI Director。

对于长期研发项目,“能运行”与“已经成为成熟玩法”是两件完全不同的事情。

一个功能真正进入游戏,需要同时经过:

技术实现 → 系统整合 → 内容支持 → 交互设计 → 性能验证 → 实际游玩 → 发布平台验证。

因此本文所说的“已有”,主要描述工程能力,而不是对所有组合场景做发布级保证。


16今天的《以太效应》已经是什么?

即使暂时拿掉那些更遥远的愿景,今天的《以太效应》已经拥有一个相当明确的基础:

玩家可以进入一个程序化生成并能够持续修改的体素世界。

可以采集资源、管理库存、制造物品、经营工作站和基地,并通过任务与科技系统推进。

世界中的结构不仅能够静态存在,还可以形成带有浮力、推进器、绳索等装置的动态体素实体。

玩家能够捕获蓝图、快速放置建筑,通过 WorldEdit 风格工具编辑区域,甚至导入部分 Minecraft 建筑和世界数据。

Mod 可以继续注册新的物品、实体、配方、任务与命令。

角色并不只是玩家的一具固定身体。

玩家可以控制干员,也可以让干员交给 Utility AI;AI 能够在体素世界中寻路、采集、战斗、工作、社交,并接收由 LLM 转换而来的高层任务。

有些干员甚至已经能够根据蓝图协作建造。

这些功能仍然有大量需要完善的地方。

但它们已经让项目开始出现最初想要的那种结构:

Loading diagram…

世界不再只是所有系统共同站立的舞台。

世界本身成为了它们交流的媒介。


17我们最终想创造什么?

回到文章最开始的那句话:

“写实版 Minecraft” + 机械动力 / 航空学 + 物理角色 + AI NPC + UGC / Mod / AIGC。

现在应该可以看出,我们真正感兴趣的并不是把这些词全部实现一遍。

它们背后其实存在一条更加稳定的主线:

体素让世界可以被修改。

物理让改变能够产生后果。

机械让规则可以被组合。

蓝图和 UGC让结果能够保存和传播。

脚本与 Mod让玩家开始定义规则。

AI NPC让角色能够理解和参与这些规则。

AIGC进一步尝试让机器也获得创造能力。

动态叙事则尝试理解这些系统最终共同制造出的历史。

Loading diagram…

因此,《以太效应》最终想创造的并不是一个拥有“很多东西”的游戏。

而是一个:

  • 玩家能够改变的世界;
  • 物理能够作用的世界;
  • 创作者能够扩展的世界;
  • NPC 能够理解的世界;
  • AI 能够参与的世界;
  • 并且能够因为这些参与者的共同作用,不断产生新结果的世界。

对于传统内容型游戏来说,最理想的结果可能是:

玩家终于看到了开发者精心准备的那一刻。

但对于《以太效应》这样的沙盒,我们更期待另一种时刻:

玩家做了一件开发者没有安排的事情。

一个系统对此产生了反应。

另一个角色理解了这个反应。

世界因此发生改变。

而后来发生的一切,连开发者自己也没有事先写下答案。

如果这些事情最终能够真正发生,

那么《以太效应》才算逐渐接近我们一开始真正想做的那个游戏:

不是制造一个已经完成的世界,而是制造一套能够让世界继续发生的规则。

注释

  1. 项目内部能力索引 Docs/Project-Features.md,《Aether 已有功能特性》,更新于 2026-09-26。该文档依据仓库代码、资源与子系统文档整理;其中“已有实现”表示工程中已有对应能力,不等同于所有组合均经过发布版游玩验收。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

CONTINUE EXPLORING

沿着这篇文章继续

在地图中查看

On this page