[譯] 創建一個像科幻小說同樣的虛擬世界：設計一個全球性的虛擬世界

• 原文地址：Building a Virtual World Worthy of Sci-Fi: Designing a global metaverse
• 原文做者：Reto Meier
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：LeeSniper
• 校對者：IllllllIIl、Wangalan30

在 Build Out 系列的第二集裏面，Colt McAnlis 和 Reto Meier 接受了設計一個全球虛擬世界的挑戰。

看一看下面的視頻，看看他們想出了什麼，而後繼續閱讀本文，看看你如何從他們的探索中學習創建你本身的解決方案！

視頻梗概：他們設計了什麼

兩種解決方案都描述了一種可以生成讓用戶經過 VR 頭盔就能夠體驗的 3D 環境的設計，使用不一樣級別的雲計算和雲存儲來給客戶端提供虛擬地球的數據，而且實時計算用戶與之交互時對世界環境的改變。

Reto 的方案專一於使用數百萬個無人機獲取實時傳感器數據，建立一個對現實世界的虛擬克隆。他的虛擬空間本質上是和現實世界聯繫在一塊兒的，包括幾何形狀和當前的天氣條件。

Colt 的方案充分利用了他的遊戲開發經驗，設計了一個徹底隔離虛擬世界和物理世界的系統。他的架構詳細描述了建立一個 MMO (或者其餘大型合做空間)後端服務所須要的框架。

建立你本身的全球虛擬世界

這些設計裏面最大的區別在於虛擬環境的氣候和幾何信息的來源。Reto 的設計方案依賴於分析現實世界中的傳感器數據，而 Colt 的系統使用藝術家來提供人造景觀和建築物。

若是你想要一個包含真實世界幾何圖形和紋理的系統，你能夠從 Google Map 上面找點靈感。

他們的系統使用圖像和傳感器數據的組合來生成 3D 模型以及這些模型的紋理信息。這使得他們可以生成很是真實的城市環境三維再現，而不須要僱傭一大羣藝術家來從新建立相同的內容。

讓咱們來生成一個十分類似的具備表明性的東西來反映這個過程。咱們可使用衛星數據，LIDAR（激光雷達）輸入，還有來自各個角度和來源的無人機圖片，並把他們放到一個 GCS bucket 裏面。

另外，咱們還要生成工做信息並將 work token 推送到 pub/sub。咱們有一批搶佔式虛擬機，負責收集這些 pub/sub 請求，並開始製做 3D 網格和紋理圖集。最終的結果也被推送到 GCS bucket 裏面。

爲何要用搶佔式虛擬機（PVM）？ PVM 容許本身被計算引擎管理器終止。所以，與一樣配置的標準虛擬機相比，它們提供了很是便宜的折扣價。因爲它們的壽命是不穩定的，所以它們很是適用於執行可能會中斷而沒法完成的批量工做。

Pub/sub 在這方面與 PVMs 攜手合做。一旦 PVM 收到一個終止信號，它能夠中止工做，並將工做負載推回到 pub/sub，以便另外一個 PVM 稍後拾取繼續工做。

或者，對於這種算法失效的區域，你能夠容許用戶爲圖標式地標提交自定義模型和紋理，而後將其插入到生成的 3D 環境中。

存儲和分發虛擬世界數據

當咱們全部的網格和紋理數據都處理完畢的時候，結果將是數以 TB 的虛擬環境數據。很明顯，咱們不能一次將全部內容都傳輸給每一個客戶，相反，咱們會根據地理邊界打包模型數據。

這些 『區域性 blob』 被編入索引，包含元數據，而且能夠存儲在多層壓縮存檔中，以便它們能夠流式傳輸到客戶端。

要計算這一點，須要使用與生成 3D 網格相同的離線構建過程；具體來講，你能夠爲 pub/sub 生成一堆任務，並使用一羣搶佔式虛擬機來計算和合並適當的區域 blob。

將區域檔案分發給客戶取決於用戶在虛擬世界中的『實際』位置，以及他們面對的方向。

爲了優化客戶端的加載時間，給他們常常訪問的區域添加本地緩存是很是有意義的，以此來幫助他們避免每次進入一塊新的區域都須要下載大量數據的狀況。

爲了圖表清晰起見，咱們能夠將整個過程封裝起來做爲一個離線系統，咱們稱它爲『自動內容生成器（ACG）』。

隨着時間的推移，本地緩存將會失效，或者須要將更新推送給用戶。爲此，咱們制定了更新和分期流程，客戶能夠在登陸或是從新進入他們最近訪問的區域時接收更新的環境數據。

爲何用 GCF？ 有不少種方法可讓客戶端檢查更新。例如，咱們能夠建立一個負載均衡器來自動擴展一組 GCE 實例。或者咱們能夠製做一個能夠根據需求進行擴展的 Kubernetes pod。

或者咱們可使用 app engine flex，它容許咱們提供咱們本身的圖像，只是圖片大小相同。或者咱們可使用 app engine 標準，它有本身的部署和擴展。

咱們之因此選擇 Cloud Functions 的緣由是：首先，GCF 加強了對 Firebase 推送通知的支持。若是發生了什麼狀況，咱們須要通知客戶有緊急修復補丁，咱們能夠直接將這些數據推送給客戶。

其次，GCF 須要最少的工做來部署功能。咱們不須要花費額外的週期來配置圖像，平衡或部署細節；咱們只需編寫咱們的代碼，並將其推出確保可使用。

爲你的虛擬世界提供模擬數據

隨着你的用戶移動而且和虛擬環境交互，他們所致使的任何改變都須要和其餘的周邊數據同步，並分享給其餘用戶。

你須要一些複合組件來確保用戶操做不違反任何物理規則，而後是一個用於存儲或向其餘用戶廣播這些信息的系統。

爲此，你能夠利用一組名爲 『World Shards』 的 App Engine Flex 組件，它們容許地理上比較接近的客戶端鏈接並交換位置和移動信息數據。所以，當用戶進入遊戲區域時，咱們會計算出他們最近的區域，並將它們直接鏈接到適當的 World Shards。

**爲何用 App Engine Flex？**對於 World Shards 而言，咱們能夠輕鬆使用一組共享一個圖像的實例化的 GCE 虛擬機來實現，可是 app engine flex 爲咱們提供了相同的功能，且不須要額外的維護開銷。一樣的，一個 GKE Kubernetes 集羣也能夠作到這一點，但對於咱們的應用場景，咱們並不須要 GKE 提供的一些高級功能。

咱們還須要一組獨立的計算單元來幫助咱們管理全部二級世界互動項目。諸如購買商品，玩家間通訊等等。爲此，你能夠啓動第二組 App Engine Flex 實例。

全部須要分發到多個其餘客戶端的持久性數據將存儲在雲端 Spanner 中，這將使得區域比較靠近的用戶在有須要時可以儘快共享信息。

**爲何用 Spanner？**咱們之因此選擇 spanner 是由於它的託管服務，全球容量以及擴展能力來處理很是高的事務性工做負載。你也能夠用 SQL 系統來作到這一點，可是這樣的話，你就得爲得到相同的效果作不少繁重的工做。

因爲咱們的代碼須要常常改動，咱們須要增長咱們的更新和臨時服務器以將代碼分發到咱們的 world-shards。爲了實現這一點，咱們容許在暫存代碼中執行計算級分段，並將圖像推送到 Google Container Registry，以便根據須要支持各類 world shards 和遊戲服務器。

繪製你的虛擬世界

除非您戴上 VR 頭盔，不然虛擬世界就不是一個有意義的虛擬世界。爲此，你能夠利用 Google VR 和 Android Daydream 平臺在徹底身臨其境的 VR 體驗中呈現咱們巨大的虛擬世界。然而，Daydream 自己並非一個合適的渲染引擎，所以你須要利用像 UNITY 這樣的工具來幫咱們繪製全部模型，並表明咱們與 Daydream 系統進行交互。

描述如何在 VR 模式下每幀正確渲染數百萬個多邊形是一個很大的挑戰，但這已經不在本文的討論範圍以內了;）

賬戶和身份認證服務

咱們將添加一個 app engine 前端實例，利用 Cloud IAM 對用戶進行身份驗證和識別，並與賬戶管理數據庫通訊，這個數據庫可能包含賬單和聯繫人數據等敏感信息。

爲何用 App Engine 標準？ 咱們選擇 app engine 標準做爲 IAM 系統的前端服務的緣由有不少。

首先是它的管理，這樣咱們就沒必要像 containers、GKE、App Engine Flex 那樣處理配置和部署的細節了。

其次，它內置了 IAM 規則和配置，所以咱們能夠用更少的代碼來得到咱們所需的安全保證和登陸系統。

第三，它直接包含了對數據存儲的支持，咱們用它來存儲咱們全部的 IAM 數據。

---

想要了解咱們技術選型的更多詳細描述，能夠在 Google Play Music，iTunes，或者你最喜好的播客應用或網站上關注咱們的系列播客，Build Out Rewound。

若是你對咱們的系統設計或者技術選型有任何問題，請在下面留言，或者在咱們的 YouTube 視頻下面留言。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。