GameRes發布，文/顧露
內容製作篇：設計和創造（Content Design & Creation）
聊完了程序方面的內容（最下面閱讀原文連結可查看上篇程序篇），我們來簡單講講超大規模世界在設計和製作方面的一些情況。這方面因為我不是專家，只是做一下簡單的介紹，不足之處，還請專業人士指正。
1. 隨機地圖類遊戲 (Diabloz II) 中地圖的拼接
在暗黑二，暗黑三和類似的遊戲「火炬之光」等遊戲中，通過巧妙的拼接，理論上可以通過組合，生成近乎無限大的地圖。
這是暗黑三第二章裡所有地圖的可能的部件形狀：
這是拼接之後的樣子：
除了拓撲結構上可以任意排列組合以外，在每一個分片上預留足夠多的通用接口也很重要。比如一扇拱門，可以是閉合不可交互的狀態，也可以通向下一個直角走廊，也可以是通往一個副本的入口。
要注意標準化的組件如果太多也會讓玩家覺得單調和重複感過強，火炬之光在這一點上就做得不錯。下圖是火炬之光生成好的地圖樣貌：
可以看到效果還是很不錯的，一眼看過去已經不太有重複感了。
2. 無縫大世界 (World of Warcraft) 中區域地圖的拼接
無縫世界類遊戲的區域拼接和上面的隨機生成類遊戲的區域拼接是很不一樣的。
可以看出，不同的區域之間有著很長的接壤線和完全不規則的邊緣。在這種情況下，為了簡化製作，大部分邊界區域以高山作為阻隔。你幾乎不怎麼會看到有建築橫跨兩個不同的區域，原因也是在此。
在沙盤製作時，通常的做法是在整個世界地圖（對應的世界編輯器）中規劃好每個區域的範圍，也就是分區分塊。每個區域由不同的設計師在場景編輯器中分開製作。在製作當前場景時，與該場景接壤的幾個場景的最新版本都會加載上來，編輯器中可以提供一些方便的工具，便於在接壤處對齊。主要是高度的對齊和貼圖的融合。前者通常的選擇是高度上用 Smooth 工具平滑過渡到鄰接場景，後者通常最簡單的處理方法是真正的過渡點兩邊使用同一種貼圖即可，實際的美術風格過渡（如果需要的話）在鄰接地圖的接壤線附近完成。
一些貫穿不同地圖的元素（如河流等）可能需要世界編輯器的參與來指定水平面的高度和區域範圍之類的參數，但這一類元素通常不會太多，因為它們沒有明顯的 Gameplay 貢獻，反而加劇了不同場景之間的耦合。
如果遊戲有動態的天氣/環境氛圍系統，那麼不同場景之間需要做一些平滑的過渡，這些程序用普通的插值實現就可以了，設計師一般只用關心當前場景內的表現即可。當然有的遊戲這個過渡做的不好，玩家體驗非常生硬，也是有的。
總得來說，這一類無縫大地圖的複雜度主要是在編輯器的協同方面（後面我們會再提到）,實際的創作複雜度較前面的隨機地圖生成為低。
3. 衛星地質數據的導入，規整化和再加工（一些飛行模擬類遊戲）
超大規模的開放性世界地圖，還有一類是直接使用衛星地質數據以加強整個世界真實性的。據我所知，育碧出品的 Tom Clancy's H.A.W.X. I & II （就是國內翻譯的 鷹擊長空 I & II）就是使用了 GeoEye 的商業級高解析度衛星地圖。
既然用了真實的衛星地質數據，這一類遊戲同樣能生成非常震撼的效果，也就不用多說了。找兩張截圖大家感受一下吧：
這一類的缺點是不能模擬真實世界中沒有的環境（當然拿去再創作的不算）。
這種真實數據的數據源就沒什麼好說的了，我簡單說一下導入後的處理。通常導入後的貼圖需要美術在色彩和明暗上二次加工一下，得到和遊戲匹配的整體氛圍。需要提供比較精確的工具給美術進行高度圖和高解析度紋理的擬合。此外通常這一類地質數據是沒有 NormalMap 的，需要提供工具生成一下。
還有就是，河流和湖泊這一類水體的處理，3D遊戲通常在渲染效果方面對水面特效照顧得比較多。如何生成跟真實環境相匹配的河流和湖泊是一大難點。因為一般遊戲裡是有一個絕對水平的特效面片的，而如果給真實環境中得來的高度數據上配一個這種特效面片，通常無法跟真實的貼圖相吻合（尤其是在山脈和峽谷等地形中的水體）如何提取真實的高解析度貼圖中的水面信息，自動生成對應的3D水面，也是一大話題。當然，如果不怕費事，也可以由美術直接做出來了事。
4. 超大地圖的協同編輯：並行操作，數據同步，手動和自動鎖的運用
現在咱們回過頭來聊一聊在 wow 這一類超大地圖裡，如何在多人團隊內協同編輯的問題。
對於美術（這裡專指負責場景的設計師）來說，常見的最簡單做法是每人一塊（或多塊）區域地圖，團隊內維護一個公共的物件和貼圖庫。（物件和貼圖可以由專門同事製作，需要時也可外包）在這種情況下，美術的並行化程度很大程度上取決於團隊自身能力，對場景編輯器沒有特殊的技術上的需求。
超大地圖的場景編輯器在加載周邊鄰接的區域地圖時，需要顯式地標示出其版本和上次修改日期，這樣可以把鄰接區域的修正工作量降到最低。最好的做法是能夠通過版本管理軟體，在有同事修改了鄰接區域以後自動更新並重新加載（當然可以稍有延時，不用那麼即時），這樣的並行工作效率可以達到最高。
真正的難題通常發生在策劃那邊，當需要編輯跨區任務或事件時，如果對 Ownership （也就是場景實體的所有權問題）管理不善。跨區系統可能會產生各種層出不窮的 bug。比如同一個 npc 承擔了多個跨區職責時，其中的狀態就可能會互相干擾，在殺掉某個 npc 這一類任務中更易出現，造成難以重現的 bug。這就需要提供明確的所有權管理機制，明確跨區訪問的一般規則，提供簡單的全局狀態檢測工具，在設計時就能提示出絕大多數潛在的衝突。當然，這些的先決條件是所有的區域數據，要麼提供中央資料庫管理，要麼工具做到在團隊網絡內實時同步。
最後我們來說一下真正有趣的實踐，就是「真正的」協同編輯。也就是任意個美術和任意個策劃可以工作在任意個區域裡。是的，你沒看錯，這才是終極的開發自由度。其實如果這是一個如典型的 WOW 那樣的 MMORPG 的話，這就跟「所有的玩家登錄到同一個伺服器一起遊戲」是同一個概念了。所不同的是，這裡的「玩家」實際上全部是開發團隊的成員，而且他們是有能力創造和修改這個遊戲世界的。
只要想通了這個概念，實踐上並不像想像中那麼複雜。由於美術和策劃對同一個地圖關注的焦點不同，我們只要把他們工作有交集的部分處理好，他們就能一起愉快地玩耍了。實踐上來看，兩者的交集通常是 a. 整個區域的邏輯高度圖和 b. 所有的相對碰撞關係。也就是說，美術和策劃的工作內容裡，只要不涉及到這兩者，都可以隨便搞，但如果影響到了這兩者，編輯器需要有能力提示正在修改的人會影響到什麼（或按默認行為自動處理），通常是不難做到的。舉個例子，策劃放好 npc 後，美術去調整高度，把 npc 站的廣場弄成一個山坡，那麼要麼提示美術這麼幹可能會影響到策劃的設計，要麼自動把對應的 npc 都重新調整位置，吸附在新的地表高度（一般編輯器允許設置為吸附到地表）。
當兩個美術在修改同一區域時，就涉及到鎖的問題了。鎖有兩種，一種是在編輯時自動觸發，場景地表以區域為單位，物件以 Instance 為單位，當編輯時自動把 Owner 設為當前編輯者，提交改動到伺服器時可以選擇繼續鎖或是釋放鎖。一種是手動鎖，就是美術框住一片區域，主動加鎖，這樣有些時候更方便。編輯器製作者需要考慮的一些細節有：鎖住的區域在其他開發者的機器上，需要比較顯眼的提示信息；保險起見總是多鎖一定的範圍，以方便地表平滑等工具編輯時對周邊區域的影響，等等。
（待續）
最下面閱讀原文連結可查看上篇程序篇