遊戲研發的設計規範（三）：場景型別化製作

前文回顧：
拒絕“散漫”與低效  遊戲研發也需要一套設計規範
遊戲研發的設計規範（二）：成長的積澱——從臨摹到再創造


這篇想從場景型別化探討場景製作的方式，當然主題是說明場景製作的設計規範，自然根據不同的遊戲功能或表現形式而言，會有著截然不同的場景設計規範原則。因此本篇所提及的設計規範方式僅是由曾經的專案經歷的原則，而這種規範性的內容往往取決於團隊的研發能力，只有適合的製作方式沒有唯一的解決方法，以至於不見得通用於各型別的專案。

關卡設計的內容是相當貼近於玩家遊戲體驗的，以ARPG專案來說場景美術資源的表現實際上是要規範於遊戲系統或玩法之內(卡牌類、回合制RPG遊戲的限制就相對少)，才能夠確保遊戲體驗在符合玩法下產生最好的遊戲效果。有些遊戲專案多半都是初期對於美術資源毫無規範、姿意創作，一旦到了中後期發現遊戲包體巨大才開始想辦法優化內容，實際上都已經為時已晚或必須付出巨量的時間成本(可以參考「價值工程」的內容)，這就體現出遊戲專案在預研期的重要性，但也聽說過很多專案是不存在預研期的過程，這會讓研發後期相當乏力且效率低下，迴歸題旨「設計規範真的很重要」。


場景設計規範的擬定與遊戲玩法是直接影響的，比如上篇討論過的話題MOBA遊戲中角色的攻擊範圍，這就與玩法、角色大小產生重要關聯。研究過幾款MOBA遊戲的場景與角色攻擊範圍、移動、鏡頭等影響遊戲體驗的細節，便可以知道遊戲在設計規範程度上的差異。

場景規範的基礎尺寸

以2.5DARPG的場景地圖而言，由於固定視角的關係許多場景物件的高度就需要受到因應視角所產生的規範，而場景的平面尺寸更受到了角色單位引數的影響，比如角色本身的尺寸、角色動作、角色位移速率等等。藉由這些擬定好的基礎設定後才足以推展場景的設計規範。圖一的內容是設定場景的基礎單元尺寸，且藉由這類尺寸推算出角色在場景格中的估算位移時間，以控制遊戲副本在場景移動上的體驗時間以及場景大小的規範(小型副本、中大型副本)。場景的基礎單元定義了各種通用性的路徑，以便後續的排列組合運用(基礎原則可以參考《空間型別演譯:以平面圖探討彩虹六號:圍攻》)，這裡為了滿足遊戲功能而沒有設定所謂的囊底空間，會藉由編輯器配置的方式生成。這些基礎單元尺寸使得路徑有著統一的寬度銜接，之後得以快速而多樣的擴充套件場景內容，至於複雜性的變化可以交給編輯器的引數配置生成，這篇就不多討論。

暴走的巫師：空間型別演譯：以平面圖探討《彩虹六號：圍攻》


場景型別的分組

圖二，同樣的L型轉角路徑其實可以倚賴場景裝飾物妝點產生不同的場景氛圍，即使都是相同的路徑功能也可以區分多元的型別，且將其分組為Corner01、Corner02、Corner03等資源以待後續呼叫。由於ARPG的關卡場景複用率難以與卡牌遊戲或回合制RPG遊戲相比，因此製作獨一無二的場景在部分型別的遊戲系統中是缺乏意義或研發成本較高的作法，比如《永遠的7日之都》、《輪迴訣》這類多副本推進的遊戲型別。因此藉由場景型別化的方式產生多樣路徑的關卡場景成為相對有效率的方式之一，當然只是製作方式的一種選擇。


場景型別的組構範例

配合各型別路徑以及各規模廣場的搭配即可產生多樣態的關卡場景，當然由於遊戲機制的關係，這裡並未使用基礎單元格直接生成關卡。圖三，而是比較傾向Roguelike型別的偽隨機的地圖組構，產生二級的路徑型別來使後續匹配更適用於遊戲玩法的需求，比如BOSS戰需求開放的廣場或根據各副本的劇情、挑戰需求產生特殊路徑形式等等。其實有些探討Roguelike的文章和模型未來有機會可以方想。


其餘許多的場景型別物件根據遊戲玩法所產生的需求額外配置，這就符合多數編輯器的配置規則內容就不特別說明，場景物件的型別分類的原則其實也可以通用基礎單元尺寸的概念規範，最大的優勢在於清晰好配置，而且可以讓放置於場景中的美術資源的規範得當滿足每個場景的運用，也就是在《空間型別演譯:模擬遊戲地圖探討》中所提及網格系統的規範但不體現於玩家的視野中，但底層設定的網格系統卻可以有效率的控制著各種需求的單位UI按鈕。這種概念同樣適用於三轉二的場景製作方式，下次會以海綿寶寶的三種二等角檢視繼續探討三轉二的場景製作，參考《空間型別演譯:等角檢視探討戰棋關卡製作》。
https://zhuanlan.zhihu.com/p/74086307


結語

場景型別化的製作方式並不通用各種2.5D的ARPG遊戲專案，但藉由前期有場景設計規範的製作可以讓後續資源利用或修正較為高效率，因此設計規範的擬定可以使專案步入正軌。初始的基礎尺寸必須有效的定義好，若中後期大改遊戲玩法等底層的規則依然會製造許多困難，當然這種大改遊戲玩法的研發專案基本上本身就已經產生巨大的問題了。

下次想要分享專案管理的內容窗體分類及執行的議題，如何從數以百計的工作程式窗體中擬定設計規範並有效連結各窗體工項，當然這只是個提案並非實際操作的內容。因為就是專案操著相當不人性化的專案管理窗體而想根據這議題進一步討論，其後在追根源頭探討專案整體規劃到專案工作的窗體落實，從下而上的推演。

來自知乎專欄“巫師的遊戲場域”


作者：暴走的巫師
專欄地址：https://zhuanlan.zhihu.com/p/77290164