建築師解構遊戲關卡——遊戲研發中的場景需求

曾經參與的專案上線了，特別看了玩家的各方評價，雖然對於個人關注的內容上少有評價但根據遊戲截圖也能評斷些許。對於當時專案的美術需求工作流仍不斷反思，當前遊戲研發的作業流程分工細膩而繁複，然而這樣過於細膩的流水線與KPI繫結時則產出了異端卻人之常情的工作心態。

現代工序的專業分工將以往眾多工項由單一僱員憑藉經驗累積所能完成的過程，拆分為眾多工項分別由眾多僱員單一專職完成，以此大幅降低多工項經驗門坎且專精於單一工項的技術累積。工作流本身的理念沒有問題，問題在於如何實踐工作流，中間產生了多樣態的可能性，也會憑藉著各團隊不同的條件限制而有著不盡相同的匹配模式。在管理學中有著系統思考的課程，專門藉以工作的狀態以問題核心本身提出適合的解決方式，管理學所衍生出來的學門眾多然而實踐上仍相當考驗性格與觀念。

總歸而言，我認為當時所運作的美術需求工作流程擁有許多阻力，導致「一群跑車跑起來像蒸汽火車一樣」，舉個例子也是曾經參與某個專案發生的狀態，實際的內容就是《遊戲研發的設計規範03》這篇文章。這篇文章的內容是沒有被採納的方案，乃因於當時的部分人員認為工作量巨大以及包體巨大。當時就知道這兩問題都不存在的，一是結果論來說工作量是極度縮減，頂多起步需要多些累積，或者對方的擔憂是工作被取代了，而實際上為了滿足多樣性仍然有適量且技術含量的工作需要推進；二是當時所運用U3D而言這樣的製作流程並不會增其包體大小甚至大幅縮減，何況當時為2.5D遊戲模式，以製作流程來說總美術資源包體可以降至一半以上都綽綽有餘。最終無法推行的原因自然而然是前述所提及的「異端卻人之常情的工作心態」，於是我只能讓步了，導致後來工作進度推展一直受限於資源匱乏而迭代緩慢，每每想起這些過往都只能閉目思索曾經學習專案管理課程的彭湃然後輕輕嘆息。

暴走的巫師：遊戲研發的設計規範03

場景需求規範

通常專案中的策劃提出場景需求是具有規範的，然而部分中大型廠商會額外設定美術中心的部門統一著手多專案的資源需求時，我認為美術需求規範的標準格式理當由美術中心發起，乃因於個別專案的美術需求不盡相同但對口於美術團隊分工卻是一致的，比如原畫、模型、UI或特效等等。由個別遊戲研發團隊各自發起，糟糕的狀況是有多少個策劃就有多少種需求規範；正常的狀況是有多少專案就有多少種需求規範，當然針對不同遊戲專案的特殊需求也需要具有一定的開放性，但起始的需求標記理當是統一規範的，否則對於美術團隊都具有一定程度的理解成本，導致好似專業分工了，個別工項的進度也有顯著的效率，但時間通通被溝通成本稀釋了，次數一多就會發現原先個別工項的高效進度也漸漸失效，而後「螺絲釘」言論就會灑滿了全專案組，這時候最糟糕的形式大致就是開始打雞血吧，因為治標不治本更導致人心渙散。

對於小團隊而言，好處就是溝通成本並不算高，雖然前述上線的專案也是小團隊，但糟糕的工作流仍然發生了，初始問題也正是流程規範乃自於繫結KPI引發的劣化狀態，實際上研發的工作繁多也並非每種型別的工作出現的延遲或偏差就會導致研發失當，依然可以倚靠其他優勢彌補，工作中失誤很正常的，踩坑後學習併成長並彙整經驗，可能比起不曾踩坑來得更可貴。當然也有聽過相當規範的工序，多發生在運營已久的專案以及目前的專案(富強、民主、文明、和諧、自由、平等、公正、法治、愛國、敬業、誠信、友善)。

參考與型別組構

以下內容是早上製作的，藉此論證《遊戲研發的設計規範03》中所提及的部分內容，先引用偶像的名言做為開場「巨大的建築，總是由一木一石疊起來的，我們何妨做做這一木一石呢？我時常做些零碎事，就是為此。」


想製作一個金拱門式的場景需求，於是乎尋找了金拱門的參考圖片，曾經在歐洲拱結構的橋樑被稱之為「魔鬼橋」，因為當時的人們不知道拱結構的力學原理而懷疑這是魔鬼的力量，拱結構在部分古文明中都有類似的紀載，當時的建築技術多半為垢工，乃自於拱結構的運用改變了承重牆的限制，建築的出發點終究是優先於滿足功能的，當然有部分老百姓不明所以，以為建築設計就只是美美的。然而悲慘如我，尋找的參考圖都是當代混凝土的建築因應造型本身而製造，也或許是百度圖片實在不給力。

根據偶像的名言，想利用這些參考圖製造出場景白模進去走走，因此將所尋找到的參考圖片解構為可用的一木一石，我們何妨做做這一木一石呢？所以零碎事通常都是我來做，我就根據參考圖中的拱結構大致區分為幾個可用的物件，為了滿足這些物件可以通用，所以改變了些尺寸比例，當中自然可以發現伊東的多摩藝術大學圖書館的結構方式較為繁複，並不適用於此次的內容，因此有了較多的簡化。


運用參考圖所分析出的型別進行簡單的排列組構，這裡可以根據不同遊戲型別的需求可以有進一步的規範以滿足玩法上的規則限制，這裡就不多討論。當排列組構完成可以匯入引擎中往前走走，或者一開始就將各物件匯入引擎中搭建場景，理論上這才是較為嚴謹的作法。在初始定義尺寸比例時便應該相當規範，才足以保證後續各型別物件量產時都通用，而制定規範通常各型別遊戲即使是換皮遊戲都應該有套自身量身訂做的基準表，畢竟研發條件及水平其實都有不小的差異，這些初始內容也沒打算詳加說明。


引擎中體驗與優化

雖然前文強調著製作規範的重要性及工作流程中的影響，但是實際研發過程中也很有可能是不斷迭代更新的過程，自然有時候會因為初始設計的限制而窒礙難行，這也是每每設計過程考慮後續發展及擴充套件性對於經驗與技術積累的重要性。因此快速體驗並迭代可以有效避免隱性的失誤，這時候搭建模型走走便是有效的方式之一，如果可以讓搭建的流程精簡而高效時，也許可以多少減少《彩虹六號：圍攻》中謎之裂縫的產生，將場景物件型別化的優勢在於快速捕捉部分誤差的成因。


UE4在不同軟體中轉換上提供了相當良好的外掛，以減少了轉檔中可能遇到的問題，實際上良好的研發流程是所有僱員在相同工項中所運用的軟體及版本皆為相同是較為良善的方式，否則工作流也可能產生轉檔或操作過程許多難以避免的失誤，這問題看似邊緣實則影響巨大，如果將版權議題納入將相當能體現出軟體與操作平臺一致性的重要性。

因此在引擎中執行走走，看看一木一石怎麼迭起來的，藉此可以論證草稿上的假說，修正理解並優化規範內容，隨著研發過程與規則的日漸明確也會有諸多調整，但理當都能保有定質的產出。


結論

當代工作中的專業分工本身是整體社會飛速進步的要素之一，但是這是對於客體而言如此，也就是工作容器本身。對於僱員而言，專業分工的目的是服務於工作，而非個人成長，因此往往會產生畫地自限的思維，這是對自我最大的鄙視，甚至產生專業鄙視鏈，這都是相當糟糕的結果，更可怕的是專業分工的思維是至上而下的推行。

前文所提及的專案的狀態是預研期時研發團隊與美術是分開作業的，導致當場景需求推匯出的製作規範在初期等於是閒置狀態，理論上需求與製作是密不可分的，否則都可能有其中一方完全返工。因此在研發初期對於參考乃自型別組構中都應該是迅速的團隊參與後迭代，好讓溝通成本降低，否則一旦蒸氣火車開始奔跑了，很多時候已經承受不起太大幅度的改善了。

相關閱讀：
建築師解構遊戲關卡——以垂直動線探討射擊遊戲視野訊息
建築師解構遊戲關卡——以平面圖探討《彩虹六號：圍攻》
建築師解構遊戲關卡——以剖面透檢視探討《輻射避難所》
建築師解構遊戲關卡——以平面圖探討空間訊息
建築師解構遊戲關卡——《王牌戰士》城寨關卡佔領據點地圖探究
建築師解構遊戲關卡——引數化關卡設計的思考
建築師結構遊戲關卡——以等角檢視探討《Block’hood》
建築師解構遊戲關卡——引數化關卡設計探討佔領據點地圖

作者：暴走的巫師
來自專欄：“巫師的遊戲場域”
地址：https://zhuanlan.zhihu.com/p/103349983