Clarus Victoria

計畫

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

Nexus 計畫 — Clarus Victoria