- 原文地址：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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。