计划
1. 概述
1.1. 关于文档
本文件旨在阐明 Clarus Victoria 对我们想要制作的游戏以及实现路径的立场与意图。
工作室在未来几年将开发的游戏被视为通往名为 Nexus 的更大、长期项目的阶段性步骤。
本文件不是技术规范、需求文档或对具体时间与结果的承诺。随着项目发展和新想法出现,它可能会更新与修订。
本文面向对 Nexus 项目总体愿景和 Clarus Victoria 工作方向感兴趣的玩家,也面向希望更好理解新系统原则与机制的开发者。
1.2. 关于项目
Nexus 是一款通用的电脑游戏,玩家可以在其中创建并配置自己的游戏,混合类型、设定与机制,并与他人分享。
不同于传统游戏,Nexus 不提供预设的类型或单一的剧情线路。在这里,游戏类型是规则与情景的集合,玩家可以在游玩过程中选择、组合并调整。
Nexus 不是另一个 Roblox 或 Garry's Mod。在大多数类似平台里,世界由脚本和编辑器拼装而成。而在 Nexus 中,世界建立在一种接近人类语言的“语言”之上,它形成意义、规则与内容。这种方式让玩家在选择玩什么、怎么玩上拥有更大的灵活性与自由。
1.3. 文档结构
文档以编号章节组织,便于导航与分享链接。
总体结构包括以下部分:
- 第1节为导论,包含关于 Nexus 项目和本文档的总体信息。
- 第2节描述 Nexus 项目在实现后可能呈现的构想与想法。
- 第3节包含使项目得以在技术上实现的理念与方法。
- 第4节为路线图:构建项目所需的步骤序列。
- 第5节为挑战:项目的风险与限制,以及应对方案。
除第3节外,所有章节面向大众读者。 第3节更偏向专业人士与游戏开发者。
文档采用模块化结构,可选择性阅读,无需严格按章节顺序。
1.4. 关于作者
本文作者为 Clarus Victoria 的创始人、游戏设计师与开发者米哈伊尔·瓦西里耶夫。 本文反映作者的主观视角,并不声称完整或终极正确。
2. 概念

2.1. 本节目的
展示 Nexus 项目在实现后可能的样貌及其功能。在本节中,我们讨论形成一种“类型”的理念——通用电脑游戏,其中之一应为 Nexus。
部分想法可能看起来难以实现,但它们被视为参考点和发展方向。本节只关注游戏机制的概念与整体形象。规则设计与技术实现的问题移至第3节。
2.2. 开始游戏
主菜单呈现一个略似 YouTube 的界面,但这里显示的不是视频,而是游戏情景。 屏幕核心是推荐区块与历史记录区。 还提供附加功能:被标记为喜欢的情景列表,以及用户计划稍后返回的情景列表。
2.2.1. 通过推荐创建游戏
如果这是你的第一次启动,游戏会提供不同类别的趋势与热门情景。 如果不是首次启动,游戏已了解你的兴趣,并在推荐中显示你尚未体验但可能喜欢的情景。 例如,如果你喜欢古罗马、太空与赛车,推荐中可能出现以下主题: “图拉真皇帝”“罗马的陨落”“古日耳曼人”“火星殖民”“蒙扎赛道”“喷气发动机”。 你可以选择任意主题。
2.2.2. 加载游戏
你可以打开历史记录并继续先前创建的游戏——这是熟悉的存档与回到过去游戏会话的呈现方式。 存档可以与其他玩家分享。
2.2.3. 情景配置
选择情景的基础想法后,你可以进一步定义未来战役的性质。 如有需要,可设置起始条件:世界与角色的特征,以及故事开始时的关键特质。
2.2.4. 生成游戏
基于所选情景生成与主题相符的游戏世界。 即使是相同的推荐,起始条件也可能不同,因此每一次开局都独一无二。 如有需要,你可以设置“游戏种子”,以在新的周目中复现类似的起始条件。
2.3. 世界
2.3.1. 规则
世界的通用规则是一组共通的规律,在理想形态下适用于角色扮演与策略游戏。 借由它们,还可以描述其他类型——动作、体育、竞速、冒险及其子类型。 这里讨论的不是具体机制,而是能表达多数游戏世界逻辑的原则。
2.3.2. 类型
游戏没有僵化的类型来限制机制。相反,类型作为模块存在,可像积木一样组合与配置。 其基础仍是角色扮演——这是人类与世界互动最自然、最易理解的方式。
如果你想要策略体验,例如体验凯撒的一生,你会以人的身份统领军团,置身事件之中,以第一人称参与战斗。 如果你需要纵览全局,你可以跳出人类角色,赋予自己特殊能力,从高处观察战场,获得战略视角。 在角色扮演模式中,命令不会立即执行:它们通过信使和军官的链条传递,可能延迟、被扭曲,甚至完全丢失。然而你也可以跳出角色,赋予自己直接传达命令的能力,如同心灵传输,使其立即且无条件执行——即便需要牺牲。此举会逐步把体验从角色扮演转向经典策略,在那里命令立即且准确执行。
在常见动作游戏中,胜负取决于分秒间的反应;而在这里,结果由角色技能水平决定。对于特别敏捷的英雄,时间可能被感知为变慢。 在竞速中,高速过弯的成功体现为诸多因素的结果:驾驶者的技能与状态、车辆性能、路面质量、抓地力、附近对手以及随机性。
2.3.3. 知识作为游戏基础
通用游戏的世界依赖知识:过去与现在的事实、对未来的想象,以及虚构与幻想。这些知识以游戏实体、属性和关系的形式呈现,供你互动。
生物群系、装备、生物、自然现象、行星与整个世界都被视为这些知识的对象。在其基础形态中,这样的世界接近现实:动植物、季节、地质与历史时代、科学技术发展。人们有技能、长处与短处、个人历史与动机。他们会生病、受伤,在缺乏帮助时会死亡。 奇幻、科幻、另类以及末世设定叠加在这一基础之上,改变世界的某些方面而不破坏其完整性。
2.3.4. 事件
事件不会凭空发生,它们是其他过程的结果。干旱导致草枯死,草的缺乏导致草食动物死亡,饥饿的捕食者失去猎物后可能开始袭击人类。世界以因果链条发展,每一次变化都会触发新的过程。
世界不会等待你介入。它的历史不是预设的,也不是基于脚本。它由你的选择、其他实体的行动、世界规则与随机性共同塑造。如果情景具有历史基础,事件重复不是因为“被编程”,而是相同的原因再次导致相同的结果——例如由气候变化引发一连串变化而导致的青铜时代崩溃。
2.3.5. 玩家决策的后果
玩家的行动会触发留在世界中的事件链。例如在关键时刻,团队领袖可能决定牺牲成员并玷污名誉,从而在其余生留下印记。
影响越强,后果越大。你可以改变河道并将时间加速一百年,以观察地貌变化。你可以完成壮举、消失一千年,并在新的时代回归,你的名字已化为传说。
世界会保留自身历史,保存关键事件、成因及遥远结果。你可以在数百年后通过书籍与考古研究自己的过去游戏会话,观察当年决策如何塑造当前世界。
2.3.6. 动机
任何实体——人、动物、组织或国家——都在其角色与动机中行动。它们不依赖于你而追求自身目标。梦想、爱情、攻击性、贪婪——这些状态影响角色行为并推动其行动。例如:
- 长期与爱人分离会严重影响角色状态并改变其决策。
- 法老可能命令维齐尔建造金字塔,对维齐尔而言这成为决定性任务。
- 鹿寻找食物、繁殖并避开捕食者。
- 犯罪集团试图扩大影响并夺取新的领地。
2.3.7. 戏剧性
在完全模拟的世界中可能存在很长的“静默期”。如果你扮演农夫,可以十年没有战争、灾难或重大变化。 如果目标是诚实地过完角色的空白日子,世界可以保持原样。
但如果你感到无聊,戏剧性可以被强化。这会改变整体感受:节奏变快、事件更密集,平静与紧张时刻的平衡在不破坏世界逻辑的前提下被调整。 在这种模式下,世界会变得更难预测:出现小事件、意外相遇和罕见命运转折。模拟不会崩坏,但角色的生活会更电影化——例如一个普通警员会逐渐卷入包含追逐、调查和戏剧性转折的故事。
如果你想要最高动态性,戏剧性还可以进一步增强——此时几乎每个转角都会产生新的故事,发生的事情更像动作大片。
2.3.8. 改变游戏规则
你始终可以跳出所选角色并改变正在发生的规则。例如,当你扮演日本办公室职员时决定成为超级英雄,这不是世界内的常规行动,而是改变叙事逻辑的一步。
你可以改变世界及其法则:加入魔法、改变物体和生物的性质。在这样的世界里,水可以像木头一样燃烧,鸽子也可能变得聪明。之后世界仍按新规则发展并保持一致。
你可以实验基础本身,创建违背熟悉逻辑的世界:悖论世界、镜像大陆、拥有自身物理与现实结构的其他宇宙。 这种方式融合玩法、模拟和世界编辑,开放近乎无限的可能性。即使改变法则,世界仍保持一致,因为因果原则在新框架下持续运作。
当前世界的快照可以成为新游戏的基础。一名玩家以“神”的身份创建一个让他人生活的世界。这类似模组或地图编辑器,但内置在通用游戏的逻辑中。
2.4. 玩法
2.4.1. 角色扮演
想成为最富有的人吗? 获得超能力并长生不老? 征服太空? 带着当代知识回到过去?
你可以立即以想要的角色开始,或从零起步,逐步扩展角色能力与边界。 角色扮演不仅限于人,也可以扮演事件、抽象或概念:一场火灾、一场瘟疫、一个组织、一种宗教、一种语言。 初始情景只设定起点,后续发展完全由你的选择决定。
2.4.2. 游戏目标
游戏目标可以由情景设定、由你设定或两者结合,也可以完全不存在。它可以是从日常任务到时代性成就的任何事——获得理想工作或发明“哲人石”。 达到目标不会结束游戏:世界继续运转,你可以在其中停留任意久。
2.4.3. 动态切换角色
你可以在任何时刻更换角色,从同一世界中另一实体的视角继续故事。这样的切换不会中断正在发生的一切,并让你从不同角度观察事件。 例如,你可以轮流扮演一个家庭的不同成员,或在战场上扮演不同士兵。除非游戏本身围绕“转世”的理念构建,这种体验超越了普通的单一角色扮演。
2.4.4. 玩家行动
你可执行的行动与当前情境及角色特征相匹配。它们由正在发生的背景以及你当下是谁来决定。
例如在火灾中,通常会出现预期选项:逃离、灭火、帮助他人。然而你也可以采取不同的行动,例如助长火势。 可选行动的差异反映了角色的本性——他们是谁、倾向如何行事。对于纵火狂而言,火灾情境的感受与普通人不同。
2.4.5. 自动与手动控制
默认情况下,世界中的每个实体都自主存在,按照自身性质、动机与目标行动。你的角色也是如此,直到你接管他们。 如果你选择领导者角色并与一群实体互动,控制不再被视为直接操控,而是请求、命令与期待的体系。
其他实体可能回应你的命令,也可能拒绝执行——取决于它们对你的态度、可用资源、恐惧、疲劳或身体限制。
2.4.6. 观察
你也可以不直接游玩。创建一个有趣的角色,把他放在不寻常的情境中,设定期望的戏剧性水平(见 2.3.7 戏剧性),并观察事件如何发展。 这种体验类似观看一部自动展开的电影。
观察的结果可以通过保存与传输世界状态分享给其他玩家。也许某人的故事会成为新的大片。 这种模式不仅适合娱乐,也适用于建模:例如,你可以创建一个“海龟文明”,并观察它如何从石器时代发展到太空飞行。
2.5. 玩法交互
2.5.1. 镜头与呈现
游戏中发生的事情可以以不同方式被感知:第一人称、第三人称、俯视,甚至文本。呈现方式会随语境和选择的角色而变化。例如,对人来说以第一人称看到世界是自然的,思考可能以文字呈现,而当你扮演国家或行星时,视角会转为战略俯视概览。
通用游戏不绑定单一呈现方式,可在当下以对你最方便的形式呈现。 即便是盲人,也能通过声音与描述感知对象和事件并进行互动。
感知范围始终对应当前角色。如果你是人,就受限于感官能力。如果你赋予自己特殊能力,感知会扩展,可看到隐藏或遥远的事物。
2.5.2. 图像与声音
界面、视觉风格、动画、音乐与声音强化游戏体验,帮助你感受所选角色。 在古代与魔法思维的世界中,视觉与声音强调人与神的双重性,营造一种额外维度的感觉,其中每个行动都具有神圣意义。 在末世设定中,图像与声音传达生存的脆弱、失落感以及难得的新开端。 在蝙蝠的世界里,空间以不同方式被感知:尺度与形态更多通过声音而非视觉被感知。
2.5.3. 地图
世界或其地图可以是任何表面——行星、区域、船只,甚至人体——取决于所选角色。例如,当你扮演蚂蚁时,地图会变成溪边的林间空地。 空间感知会随尺度变化:视角可能放大或缩小,观察角度也会改变。
放大时细节显现;缩小时细节消失,取而代之的是更大的结构与联系。
2.5.4. 时间
时间流速取决于所选角色与偏好。战斗中可能以秒为单位流动。在全局模式下,当模拟地质过程时,一秒游戏时间可以对应数百万年。 当扮演对时间感知不同的生命——植物或长寿生命体时,加速尤为合适。
时间可以停止、加速、跳过或倒流。如有需要,你可以以回合制游玩而不必匆忙决策。 在某些情况下,时间只在控制特定角色时推进,而当你思考下一步时停止。
2.5.5. 在线游戏
在线玩家可以在同一世界中同时扮演不同角色与实体,并预先商定时间流逝规则。一人可能是拿破仑指挥军队,另一人是掷弹兵在战场上攻击敌人。玩家也可以处于对立关系:有人是村民,有人是袭击定居点的掠夺者,还有人是追捕匪徒的赏金猎人。
2.6. 通用性
2.6.1. 意义
Nexus 能在规则与交互层面表达并复现大多数既有游戏的逻辑。这不是对具体实现的字面复制,而是复现其核心玩法逻辑。
之所以可能,是因为任何游戏都是一组规则,而规则可以通过简单的语义陈述(三元组)来描述。
示例: 《黑暗之魂》(以规则为角度):
- 死亡 -> 导致 -> 灵魂丢失
- 篝火 -> 是 -> 复活点
- 敌人 -> 难度 -> 高
- 攻击 -> 依赖 -> 耐力
《文明》(以规则为角度):
- 回合 -> 持续时间 -> 取决于时代
- 城市 -> 生产 -> [单位,建筑]
- 胜利 -> 条件 -> [科技,军事,文化]
《模拟人生》(以规则为角度):
- 角色 -> 需求 -> [饥饿,睡眠,社交]
- 需求过低 -> 导致 -> 心情不佳
- 行动 -> 满足 -> 需求
2.6.2. 类型混合
由于规则以模块组织,它们可以被组合。这使得你可以用已知规则集合组装新的玩法形式。
示例: 《黑暗之魂》+《文明》:
- 你统治洛斯里克王国,作为一个文明。
- 战斗与遭遇遵循《黑暗之魂》的规则(技巧、时机与危险)。
《模拟人生》+僵尸末日:
- 模拟人的日常需求(食物、睡眠、社交)。
- 在此之上叠加生存规则(庇护所、武器、危险)。
通用性的原则:如果游戏逻辑可以用语言表达,就能在 Nexus 中实现。
2.7. 示例
2.7.1. 世界中的情境
玩家是伊万,扎列奇耶村的一名农夫。他很饿,他的妻子怀孕了,邻居彼得丢了一头牛。雨即将到来。
2.7.2. 系统如何理解(triplets)
在系统内部,这一情境由一组简单陈述描述:
- Ivan -> 是 -> 农夫
- Ivan -> 饥饿 -> 30%(或 Ivan -> 饱腹 -> 30%)
- Ivan -> 位于 -> 扎列奇耶
- 玛丽娅 -> 关系 -> Ivan_妻子
- 玛丽娅 -> 怀孕 -> 8个月
- 牛 -> 属于 -> 彼得
- 牛 -> 位置 -> 森林
- 天气 -> 接近 -> 下雨
每条陈述都是一个知识原子。它们共同构成世界的当前状态。
2.7.3. 玩家如何看到
逻辑与可视化分离,并保持不变。 同一组三元组会根据显示模式以不同方式呈现。 关于 UX 语言的更多内容见 3.9。
2.7.3.1. 文本模式
“你是伊万,一个农夫。你的肚子在饥饿中咕咕作响。你的妻子玛丽娅即将分娩。你听到邻居在喊——他的牛跑了。地平线上笼罩着雨雾。”
2.7.3.2. 六角地图图标模式
- 村庄格包含对象:🏠(房屋)、🏚️(谷仓)、💧(小溪)
- 角色:👤 伊万 [🍞30% 红色]
- 家庭:👩 玛丽娅 🤰 ~30 天
- 事件:🏠 彼得 🔊,踪迹 🐾🐾 -> 🌲
- 效果:🌧️ 接近
2.7.3.3. 3D 模式
一个完整的村庄,伊万的模型捂着肚子,玛丽娅坐在屋旁,远处传来喊声并能看到破损的篱笆,地平线乌云密布。
2.7.4. 玩家行动
玩家形成意图:“帮彼得找牛” 该行动被转换为三元组:
- Ivan -> 意图 -> 帮助
- 帮助 -> 谁 -> 彼得
- 帮助 -> 任务 -> 找牛
系统进行解读: 1. 伊万能帮忙吗?-> 可以(身体健康、距离近) 2. 需要时间吗?-> 需要(约 1 小时) 3. 会影响饥饿吗?-> 会(饥饿上升) 4. 会发生什么?-> 在森林搜寻,有机会找到牛
2.7.5. 结果
一小时游戏时间后:
- 牛 -> 位置 -> 在溪边找到
- Ivan -> 饥饿 -> 20%(上升)
- 彼得 -> 与 Ivan 的关系 -> 感谢 +10
- 彼得 -> 义务 -> 帮忙修屋顶
视觉上:
- 玩家看到牵着牛回来的动画
- 🍞 20%(更红)
- 弹出提示:“彼得很感激。他承诺帮忙修屋顶。”
2.8. 从概念到实现
2.1–2.7 节描述了 Nexus 在玩家视角下的理想形象:他们看到什么、如何与世界互动、能获得哪些可能性。
关键原则:
- 任何游戏情境都可以用语言描述。
- 语言可以被形式化为三元组(简单陈述)。
- 三元组可以被解释(可进行推理)。
- 结果可以以任意方式可视化。
3. 实现思路

3.1. 本节目的
本节讨论 Nexus 项目在技术上的实现思路以及内部结构方式。 它不描述具体技术方案,而是使该游戏成为可能的原则与方向。具体实现预计将在开发过程中确定并在实践中完善。
本节不把游戏概念视为理念本身;重点完全放在实现方法上。 本节主要面向专业人士与计算机游戏开发者。
3.2. 灵活的方法
经典的电脑游戏开发方法围绕预先设计的、严格的游戏系统,玩家只能在其中行动。即便是高自由度的沙盒游戏,本质上也是一组独立系统的集合。这带来了多样性的感觉,但架构的刚性并未改变。随着时间推移添加新系统,主要导致开发和维护复杂度增长,而非玩法体验的质变扩展。
要实现真正的灵活性,必须重新思考这一基础方法。新增游戏机制不应增加项目架构复杂度。相反,游戏的基础元素应被组织为原子——最小、通用、彼此兼容的单元,其他一切都可由此构建。
Minecraft 是这一方法的良好例子。它允许创建极其复杂的结构——由数百万方块组成的城堡、城市或整座太空站。同时,对象数量的增长并不会导致内部架构复杂化:系统从一开始就为扩展性而设计。
在深度通用的游戏中,同样的原则可应用于整体架构。游戏机制数量可以无限增长,但它们必须被组织得能够彼此协同、组合,并构建任意复杂度的世界,同时不损失系统完整性与可控性。
3.3. 语义网络
实现灵活方法的一种可能方式,是将游戏数据表示为原子逻辑单元——三元组。 三元组是“主语 – 谓语 – 宾语”格式的简单陈述。例如:
- 苹果 – 是 – 可食用
- 苹果 – 有营养 – 5
- 人类 – 可以吃 – 水果
- 草 – 生长 – 在一定湿度之上
- 鹿 – 是 – 食草动物
- 辛迪加 – 控制 – 城区
通过三元组可以描述一切:对象、它们的属性与状态、它们之间的关系、可能的行动、游戏规则、技术或魔法。 这是一种不绑定具体游戏实现的知识表示方式。它不仅是数据存储格式,也是描述世界意义的方法。
要让世界深邃且一致,需要大量数据——从世界结构的总体原则到具体游戏事实。 这些数据被填充为具体内容:动物、技术、物品、建筑、历史事件与其他实体。
3.4. 解释器
在数据层之上运行解释器。它可以基于逻辑系统(如 Apache Jena)或神经网络方法。 它的任务是处理三元组并进行逻辑推理。例如:
- 苹果 - 是 - 水果
- 人类 - 可以吃 - 水果
- 结论:人类可以吃苹果
解释器通过组合多个事实得出结论。推理链可以更长。
在游戏中,解释器用于填充世界并确定允许的行动。它回答诸如:
- 哪些树可以在阿拉伯的热带沙漠中生长。
- 在史前石器时代和现代,人们可以对狗采取哪些行动。
- 当前时刻玩家可感知的对象有哪些。
解释器将这些问题分解为更简单的数据查询,并转化为统一的语义表示,在此基础上形成答案。 解释器处理的是已形式化的查询,并不直接与自然语言交互。
3.5. 语义 ECS
要让通用游戏世界基于语义、逻辑和大量事实运转,需要一种能尽可能灵活描述对象及其属性、而不依赖硬编码的架构。
这一问题可通过语义 ECS 解决——这是经典 ECS 的一种变体,适用于表示知识与实体关系。在此语境中,ECS 更像数据模型而非系统更新循环,并被视为实用的入口点而非最终架构。
世界的基础是实体:角色、物品、动物、组织、船只、植物。与经典 ECS 相同,实体本身不包含逻辑或数据;它只是标识符,组件附着其上。
关键区别在于组件结构。在传统 ECS 中,组件是包含字段的结构体;在语义 ECS 中,使用谓词组件取代大型组件:如“是”“拥有”“包含”“能够”“关联”等。每个谓词表达一条关系或陈述。
例如,实体“苹果”可以拥有谓词组件“是”,指向实体“水果”和“可食用”。同时,“可食用”也是实体,拥有其自身属性:“拥有 - 营养”“拥有 - 口味”。每个值组件仅保存一个值,例如:“营养 = 5”“口味 = 甜”“重量 = 0.2”。
这形成了属性网络或树,每个连接仍保持原子性。世界中的任何对象、属性或关系都通过单独的最小事实来描述。由此,规则与交互不再硬编码,而以数据形式存在。
为保证性能,需要缓存、索引与细节层次(LOD,见下文)机制。 这使得系统可以在保持性能、逻辑一致性与可管理性的前提下,模拟包含数百万事实的世界。
3.6. 游戏规则
数据及其处理逻辑本身不是游戏。要产生玩法,需要额外的一层——游戏规则。它们不依赖硬编码,而是扩展语言的基本规则,并可按需连接。就像语言游戏一样,它们的作用是设定边界:什么被允许、什么不被允许,目标与角色是什么,以及玩法如何发展。游戏规则将语言的近乎无限可能性收束到一个有限空间,在其中产生玩法。
在游戏行业中,通常每款新游戏都从零构建规则,从基础层开始。与此同时,游戏之间的差异往往并不根本:大多数 RPG 与策略在概念上相似,只在机制细节、画面或 lore 上不同。这种方法成为事实上的开发标准,玩法体验的同质化被视为正常。多样性主要通过视觉风格、氛围与叙事获得,而非能力上的根本差异。
通用游戏规则意味着对已验证机制的系统化与统一。这让开发者无需每次重建基础,而可专注于更复杂、更高层的内容。规则可组织为模块,并按需连接以形成具体的玩法体验。
这种方法有点像游戏引擎的结构。例如 Unity 或 Unreal 引擎消除了开发者实现底层功能的需求。然而这里讨论的不是技术实现,而是通用游戏规则。类似思路可在桌面系统如 GURPS,以及复杂沙盒如 Minecraft、Dwarf Fortress 或 RimWorld 中找到,其中部分规则已具有通用性。
默认情况下,“规则”是空结构,只有连接模块后才获得内容。模块的组合决定世界行为:伤害如何计算、先手如何定义、经济如何运作、实体如何互动、事件如何处理、以及适用哪些限制。此方式让你像积木一样拼装世界机制。
模块可自由组合并混合类型。如果你把战斗模块加入回合制模块,棋子就会成为拥有生命值与技能的角色;如果再加入平台跳跃模块,实体就获得跳跃能力;连接经济模块则引入资源生产。规则配置成为游戏的一部分:情景、设定与类型都像世界的其他元素一样被配置。
总体而言,规则模块化把游戏逻辑从固定约束集合变为灵活架构。这让同一系统通过规则与数据组合即可支持 RPG、策略、模拟、竞速等类型,而无需改动代码。正是模块化使通用游戏真正通用。
3.7. 抽象与 LOD
3.7.1. 有限感知与抽象的必要性
通用游戏的世界可能包含大量过程:从动物迁徙、城市增长到微生物行为或恒星系统动力学。对所有空间与尺度进行完整重算既不可能也不必要——玩家始终在主观且有限的范围内感知世界。因此系统使用抽象层,使世界在不失去逻辑的前提下保持可扩展性。
在高细节不会影响玩法结果的地方使用抽象。在微观世界、行星生物圈或恒星系统层面,会使用与尺度相适配的不同实体与规则。因此系统不会模拟每个单独实体的行为,而是直接考虑过程的整体结果。
3.7.2. 时间与空间的缩放
当时间快进时,游戏不会重算每一个被跳过的瞬间。相反,系统会分析世界当前状态,在聚合尺度上应用因果关系,并插值推断可能结果:人口如何变化、哪些趋势会增强、哪些事件最可能发生。这让你在保持世界一致性的同时前进数十年或数千年。
空间缩放不会改变世界结构,但决定模拟处理的实体与过程层级。在大尺度下考虑聚合实体与过程——气候、迁徙、政治结构。当切换到局部尺度时,世界展开为单独实体及其属性。在所有情况下,统一的因果逻辑都会保持。
抽象使游戏容纳任何尺度的世界:村庄、行星、生态系统或银河。细节只在对玩家或事件逻辑重要时出现,其余部分以简化形式描述,同时保留因果关系。
玩家可以深入世界结构,像参考系统一样研究实体并导航其属性。此处唯一限制是可用数据与世界规则。
3.7.3. 世界的具象化
世界在被探索时形成。在玩家访问某一地点之前,它以数据与规则形式存在,没有具体对象。对象仅在玩家与世界互动时才具象化。这类似于 Minecraft 的区块加载:世界并未完全计算,但主观上被视为已存在。
事件的生成就像世界在其复杂性上完全存在一样,即便超出玩家观察范围。
当与地点或实体的互动结束后,其状态会被存储为关于世界的新知识,并不再参与活跃计算。该方法允许世界向外与向内扩展——从微观世界到银河——无需存储与重算不必要的细节。
对于较长时间区间,使用统计趋势。例如,已知公里级小行星大约每百万年与地球相撞一次。也有模型评估技术文明在数千年范围内消失的概率。这些估计不设定精确结果,而是确定可能的场景范围。因此,当玩家前进一千年时,系统会选择一个合理未来——文明遗迹、稳定发展或其他一致场景。
3.7.4. 在线游戏
在在线模式中,同样使用“通过互动具象化”的原则。服务器不存储完全计算且固定的地图,而是基于数据、规则与已显现的事实——玩家发现或改变过的内容。
当一个或多个玩家与同一区域互动时,服务器会形成该区域的共享具象状态,并在所有参与者之间同步。该状态仅存在于实际被观察和使用的细节层级。
在互动区域之外,世界不会持续重算,而是保持在由规则、统计趋势与累积事实描述的潜在状态。这允许维护一个大而连续的世界,并仅同步实际观察与游戏相关的内容。
3.8. 代理与世界模拟
世界中的任何实体——人、动物、组织或国家——都被视为具有目标、动机与状态的代理。代理:
- 在其知识范围内感知世界。
- 评估可用的行动选项。
- 基于其目标与世界规则做出决策。
- 触发改变世界状态的事件。
世界整体作为多层模拟运行:
- 自然在气候与资源影响下变化。
- 生态系统响应环境变化。
- 人类与社会回应自然、技术与政治的变化。
- 玩家以世界实体之一的身份进入这一过程。
世界历史不是预设或手工编写的。它是许多代理在共享法则与因果关系下互动的结果。
例如,干旱导致草减少,草减少导致草食动物饥饿,饥饿导致迁徙,迁徙导致与捕食者或人类的冲突。这样的链条基于事实与规则形成,决定了在当前条件下自然会发生什么。
3.9. UX 语言
与游戏的交互语言建立在接近人类语言的逻辑之上。通过该语言,玩家与游戏有效交流。该语言有一套规则,可在其中构建几乎任意复杂度的有意义结构。
界面或地图的每一种状态都可被视为一个问题:“我现在看到什么?”,而可用行动集是“我在当前情境能做什么?”这一问题的答案。游戏通过分析世界状态、玩家角色位置以及预期交互对象,以新的世界状态与界面呈现作为回答。
在最简单层面,该语言是对世界中事物的指称:“树”“母亲”“太阳”。 在下一层面,语言允许描述它们的属性与状态:“生气的人”“很多星星”“强壮的狮子”“300 斯巴达人”。
在游戏中,这些概念可以被字面表示为具体实体,或通过象形图来表示。 每个词或概念对应一个图标。
对象属性通过视觉手段表达:
- “生气”“糟糕”“负面”——图标红色背景。
- “许多”“300”“数百万”“无限”——表示数量的小型图标,带具体或抽象数值。
- “强壮”“危险”“强大”“等级 3”——独立的等级小图标,带数值。
- 边框颜色可表示实体归属另一位玩家或阵营。
可在主图标上添加额外图形、动画、光效等,以表达常用属性或情绪色调。 对于更复杂或罕见特征,使用辅助图标,放在实体旁或嵌入其中的小比例位置。
图标可动画化,增加另一层信息。例如,当生命值极低时,图标上的心脏会不规则而微弱地跳动,表示危险状态。
语言还反映角色的有限知识。如果角色遇到来自其他文化的代表且不理解其语言,图标可能被扭曲或变成不可读符号。如果只知道部分信息,相应元素会被隐藏:玩家可能知道敌人类型,但不知道数量。
不同文化的实体可能看起来不同。古埃及人看到象形文字,而机器生物看到技术化、数字化符号。
当玩家执行行动时,他们与世界中的对象互动。在直接模拟中,这可以是实体的第一人称动作,在抽象模式中则是图标选择。 行动本身由基本语言结构形成。
其核心,游戏语言依赖语义三元组:主语 - 动作 - 宾语。
示例:
- “我 - 想要 - 一个苹果”
- “我们 - 宣战 - 对你”
- “我们 - 攻击 - 白羽部落”
在界面上,这表现为选择一个主体(玩家化身或其他实体)、选择对象并指定动作。
结构可通过修饰语复杂化:时间、形容词、条件。 例如:“奴隶(主语)- 建造(谓语)- 金字塔(宾语)- 快速(谓语修饰语)”。 修饰语“快速”表示会应用特殊规则:工作更快,但事故风险上升或结果质量下降。
如果行动不是针对化身自身,而是针对另一个主体,则被解释为请求或命令。
4. 路线图

4.1. 战略愿景
本节描述 Nexus 项目的实现计划。
以开发单一项目后再进行抢先体验的方法在此不合适。 更合适的是逐步开发一系列项目,每个项目实现并验证具体想法与方向,使项目逐步接近 Nexus 的最终愿景。 每个阶段项目都将结合反馈与批评,评估项目与初始概念的一致性以及所选方向的正确性。 随着时间推移,这些项目将变得更复杂、更高质量,其中一个最终可能成长为第2节描述的完整 Nexus 项目。
Nexus 的开发分为一系列阶段项目。 离当前时刻更近的阶段,其目标与任务会更清晰、具体;更远的阶段则在总体方向与想法层面描述,不进行详细展开。 阶段顺序并非严格固定。路线图提供项目发展的整体方向,而非详尽计划。 随着开发推进,阶段与任务可被细化并补充。
4.2. 阶段
4.2.1. 阶段 0. 形成对通用游戏的理解(已完成)
自 2013 年以来 Clarus Victoria 的工作、六个项目的发布,以及多年的研究、实验和原型制作,使我们得以形成对通用游戏可能形态及其原则的基础理解。本阶段的结果是形成了本文档。
4.2.2. 阶段 1. ECS 与实体统一(已完成)
- 在 Next Run 项目上验证了 ECS 架构。实体被表示为空容器与一组组件,从而能灵活构造世界对象:物品、生物、生态群系、事件与效果。
- 验证了与通用游戏机制相关的多项想法,包括不做硬划分的 RPG 与策略融合、通用行动、时间流模型与小队控制。
- 工作室首次实现并测试六角地图,使得快速创建与组合不同类型的游戏世界成为可能。
- 工作室首次加入通过 Steam Workshop 的模组支持。
关于此阶段的更多内容见文章:https://clarusvictoria.com/blog/almost-ten-years-of-search
4.2.3. 阶段 2. 现实世界玩法(开发中)
Next Run 项目验证了许多通用游戏想法,但其局限在奇幻设定与假定的世界法则中。第二阶段计划转向模拟真实世界及其自然与社会规律。 该阶段目标是基于真实世界逻辑及其自然、社会规律建立现实主义的玩法基础。
计划实现的特性:
- 社会演化:从与动物并列、遵循相同生存规则的原始人,到最初文明的出现。
- 生物群系与地块生态系统:饥饿、迁徙与资源竞争。植物、动物与地形直接影响人类生存。
- 由游戏规则产生的情境与事件,而非预设脚本。例如资源短缺可能引发人群冲突与捕食者攻击。
- 单位行动的自动化或手动控制——由玩家选择,包括通过共享行为规则的群体控制。既可主动游玩也可观察。
- 可扮演单个角色或群体。
- 同一地图上的多名玩家相互竞争。
- 回归 Clarus Victoria 过往游戏熟悉的科技树。
- 可配置的游戏世界:地图尺寸、时代、气候与区域特征。
- 代理模型的初步版本。
- 可能的世界设定:石器时代与青铜时代。
4.2.4. 阶段 3. 语义架构(计划中)
降低 Nexus 项目风险的关键步骤之一,是转向游戏架构的语义基础(见 3.3–3.5 节)。
在此阶段,所有系统以基础层级引入,功能最低限度:
- 语义三元组作为描述游戏世界实体的方式。
- 解释器。
- 从经典 ECS 向语义 ECS 的转变。
- 新架构的基本规则。
- 可能的世界设定:早期文明之一。
从玩法机制角度看,此阶段不计划引入新的复杂性。主要任务是将已验证的解决方案与机制迁移到新的架构基础上。
4.2.5. 阶段 4. 代理模型(计划中)
本阶段计划实现在阶段 2 过于风险的关键系统,即在代理模型内深入刻画主体。阶段 2 为其奠基,但在阶段 4 代理将被完全实现。 游戏架构开始支持更复杂的现实过程,从而可模拟比阶段 2 更高复杂度的社会。
计划实现的特性:
- 完整的代理行为模型:实体获得目标、状态与动机。
- 对主体的请求与命令系统,执行不保证,取决于当前状态与上下文。
- 世界内容更丰富,系统与对象逻辑更复杂。
- 主体拥有个人背包、物流链与运输系统。
- 将部分游戏逻辑从硬编码移到 Lua,以便玩家创建复杂模组。
- 可能的世界设定:古代世界。
4.2.6. 阶段 5. 抽象与 LOD(计划中)
语义架构与世界复杂度的增长将提高对玩家设备计算资源的要求。本阶段计划引入抽象规则,以将玩家行动范围之外的实体排除在活跃模拟之外(见 3.7 节)。 这应使游戏世界显著变得更复杂而不成比例增加负载,并使这些游戏可在低端和移动设备上运行。 阶段的实现顺序可能在开发过程中调整。
4.2.7. 阶段 6+:Nexus 引擎关键功能(计划中)
阶段 1–5 形成 Nexus 的基础功能。自阶段 6+ 起,项目发展将转向扩展引擎能力,添加 2 与 3 节描述的可扩展功能、细节与内容。
计划发展与实施的方向:
- 时间与空间缩放、细节层次与抽象。
- 网络游戏。
- 游戏情景与配置生成。
- 支持不同可视化模式:从第一人称到全球尺度。
- 针对不同玩法与沉浸程度的自适应界面与声音。
- 2 与 3 节描述的额外功能。
4.2.8. Nexus 1.0(计划中)
Nexus 1.0 的发布时刻取决于 2 与 3 节所述关键想法与功能达到基础实现。
5. 挑战
5.1. 计算复杂度过高
挑战:拥有大量三元组的语义架构可能过于沉重,无法在实时运行且难以在可用硬件上扩展。
应对:通过抽象规则与 LOD 解决。只计算玩家在某种程度上互动的实体,详见 3.7 节。 语义化的世界表示并不意味着所有游戏查询都通过逻辑推理处理;对常用操作使用直接数据结构与缓存结果。
5.2. 玩法焦点模糊
挑战:Nexus 的通用性可能导致缺乏清晰的玩法焦点与目标感,玩家不得不决定自己到底在玩什么。一切皆可,但不清楚为什么。
应对:Nexus 不要求严格定义的目标。方向由情景或世界逻辑及玩家角色形成。通用性并不等于缺乏结构——世界本身限制规模。玩家获得的控制与信息量正好与其角色相匹配。例如,若玩家扮演统治者,就不需要直接管理成千上万村庄——这由助手与大臣处理。
5.3. 项目无法完成的风险
挑战:由于 Nexus 规模与复杂度,项目可能长期处于开发而无法达到明确的完成状态。外部可能将其视为需要大量资金与大型团队的 AAA 级项目。
应对:Nexus 作为单一产品通过连续阶段发展,并定期发布具体结果,每一步都将项目推向 1.0。开发不是“长期原型”,而是稳步推进的过程,包含完成的中间版本与可验证的成果。成功标准与玩家反馈帮助项目保持既定方向。
5.4. 调试与逻辑控制的复杂性
挑战:语义架构与解释器可能带来逻辑链与推理的高复杂度调试,这会复杂化开发、平衡与世界行为控制。
应对:语义逻辑调试的复杂性被视为架构不可分割的一部分,而非副作用。在 Nexus 中,对因果链、推理来源与状态的控制被作为基础要求,因为缺乏可解释性与可观察性会使这种世界模型不可控。
5.5. 早期缺乏焦点的风险
挑战:Nexus 概念在早期阶段的广度可能使形成清晰的 MVP 变得困难,难以对特定受众测试兴趣,也难以理解项目面向谁,从而增加在验证玩法价值之前投入架构资源的风险。
应对:Clarus Victoria 拥有既有的领域与受众,工作室已与其合作十余年。我们不使用单独的抽象 MVP,而采用拥有清晰、熟悉玩法的独立项目。每个新项目都逐步扩展并使该玩法更复杂,朝 Nexus 1.0 迈进。成功标准是玩家反馈以及结果与既定方向的一致性。
文档最后更新:18.01.2026
