在AAA專案各種限制下夾縫求生存的scripting案例分享

需求：Script一個能提前在一樓廣場或大樓住家其中一個樓層等待玩家的雙門電梯

但AAA專案常常就是一堆自己的嚴格規範，講難聽一點就是很多毛。電梯不難，但必須克服在此專案架構下所面臨的諸多限制：

限制一：由於Unreal World Partition和in-house level scripting tool的種種先天限制，這個電梯必須只能是自己一個Blueprint來大幅降低script和地圖之間的依存關係，也不能有兩個Blueprint互相溝通。

限制二：電梯作為銜接玩家住家和城市廣場兩個data layers的角色，必須方便在電梯移動時stream in & out這兩個data layers(城市廣場和大樓住家不能同時存在)，但也必須考量電梯所屬data layer被unload的情況。

限制三：不支援child Blueprint，因為build時PS5會哭！

限制四：in-house的moving platform component只能移動其所屬的整個Blueprint Actor，不能只移動某一個child。

限制五：in-house的interaction component只支援單一一個互動點，意味著電梯兩側門的開關都只能仰賴一個互動點。

Okay, 這些聽起來好像都還好，但其實很多限制都是在嘗試後的反饋發現的，就算把Confluence相關資訊都翻過一遍，還是很難提前探知解法的可行性。筆者的第一個嘗試是在電梯起始時生成trigger box存入變數然後再detach，如此一來就能繞過只能使用一個Blueprint的限制。但這一做法被打槍，理由是這種生成方式難以監控，很難過程式那一關。

筆者的第二個idea是用一個超大trigger box來提前判斷玩家是否從大樓或廣場來，這完全是受限於trigger box會連同電梯一起移動才有的解法。這麼大的box縱許碰撞只檢查玩家，理當不會額外多出許多運算，但由於trigger box有機會超出原本一格world partition cell的範圍太多，而增加地圖streaming時不必要的loading。所以這個做法當然也被打槍。筆者也因此學到業界一個普遍比較乾淨的做法是使用紙片般薄的gate。

接著筆者大改作法為將電梯預設停留在一樓廣場，只有當玩家經過大樓住家要道時才來update電梯位置。然後預先存好trigger gate的起始位置，在每次電梯移動完都將gate reset回去原本的位置。

此前，筆者已經通盤檢查過在大樓住家和廣場間的所有任務、劇情、和過場動畫的流程，以確保沒有edge case發生。一個rule of the thumb是所有可能的紕漏都得防堵，因為在一個龐大複雜的主城大地圖容錯率是相對低的。但偏偏，在大樓住家的某一次過場動畫後，玩家竟然破例會直接被傳送到"電梯"前的lobby而導致"跳過"了檢查gate。這也帶出另一個因為先天限制所導致的潛在風險。

限制六：in-house的moving platform component不能強制將電梯snap to指定樓層，而只能加快速度實際"移動"過去。

這限制大大地挑戰了電梯"門"的設計。由於電梯只能是一個Blueprint的緣故，筆者簡化成只有跟著電梯跑的內門。也就是說，在電梯還沒"趕到"之前，樓層的電梯口是沒有門擋住視線的。

好在最後的共識是，這個過場動畫後的玩家起始位置太詭異了需要再重新檢視，所以可以先忽略這個edge case。於是這個電梯做法就正式被greenlit。

支線任務：

由於整個電梯Blueprint只支援一個互動點，且筆者也認同在兩扇電梯門各自顯示出互動prompt會比起統一一個按鈕更為直覺且人性，引導玩家只需要面向前方，這以至於筆者需要因應在開不同電梯內門時去不斷update那唯一一個prompt到下一個正確的位置(共有前門內、前門外、後門內、後門外四個位置)。

更可怕的是，玩家互動時的按鈕動畫，竟然會無視prompt的位置，被無條件snap to這個Blueprint actor的pivot原點！！且在播動畫時唯一能調整角色transform的參數偏偏又不開放在runtime時調整！！

臥槽又是你X的in-house工具限制！！

雖然筆者會常感嘆到AAA專案可以為了效能和畫面表現，犧牲掉整套Unreal native的解決方案不用，而另外研發一整套客制化工具這種壯觀的規模，但在遇到更爛或更不直覺的客製化解決方案時，也只能眼角泛淚的把苦吞回去。

雖然這個task還是進行式，但筆者深知現在不寫下來以後一定會忘掉很多細節。目前暫可以整理出以下幾個takeaway：

• AAA專案在production code的嚴謹程度和風險管控超乎想像，這些都是自己獨自prototype時學不到的做法和思維！
• AAA專案的規模之龐大，著實會影響寫Confluence pages的方式和風格。這在TDD(Technical Design Doc)的閱讀體驗上特別明顯。
• 3A的Tech之所以複雜，就是因為除了追求完美之外，還要同時joggle好幾百人的需求，同時要maintain它。但永遠沒有完美的工具，只有最適合該專案需求的工具。
• AAA設計師門檻之所以高，是因為連最一般的執行都帶有一定程度的技術含量且極為複雜容易出錯。所以要進這行人脈才會顯得格外重要，因為要嘛做事要非常靠譜且有人能替你擔保、要嘛要有百分百即戰力不需要手把手教；前者可以透過connection來間接給予一定保證，後者解釋了為什麼科班訓練出來的人甚至比傳統大學更容易直接卡位AAA。所以素人外人才更難有機會進來…筆者從手機遊戲轉過來，感觸非常之深！同樣是關卡設計但隔行如隔山，那個難度與需要付出的努力遠遠大於筆者一開始的想像。