3月27日，虛幻引擎Unreal Circle線下技術沙龍在深圳開幕。其中，太空FPS遊戲《邊境》的開發商柳葉刀工作室CEO李鳴渤（Frank）帶來了有關虛幻引擎使用經驗的精彩分享。

《邊境》是整個索尼「中國之星計劃」首曝的第一款遊戲，是當年國内極其罕見的小團隊使用虛幻引擎開發的獨立遊戲，憑借出色的“失重太空戰”遊戲玩法概念、以及次時代畫質，一經曝光即獲得了國内玩家的高度關注，2019年，虎牙還簽下了《邊境》代理權。根據計劃，《邊境》将是一款面向全球市場的産品，會有 12 個國家和地區的本地化内容，全球将同步上線（PS4 和 steam 雙版本）。

那麼這樣一款有口皆碑的遊戲是如何開發的呢？尤其是小團隊如何掌控難度頗大的虛幻引擎？

在演講中李鳴渤介紹，柳葉刀工作室剛剛成立的時候團隊僅僅隻有4人，在4年左右的時間裡，團隊長期保持在7-14人的開發規模。慢慢的團隊開始發展到40人左右，所對應的開發管線也逐漸發生變化，對于管線的優化幫助團隊之間更好的協同，提升項目的産出效率。

以下是演講實錄：

李鳴渤：大家下午好，我是柳葉刀的Frank，我今天分享的大概是我們過去5、6年中無數杯咖啡後，我們做的UE4開發管線曆程，這可能是一個與直接的開發技術關系不大，但與開發流程密切相關的東西。

在講之前首先介紹一下我自己，我大概是在2002年加入遊戲行業，那一年我去了英國學習，并找到了我人生中的第一份遊戲工作，一直呆到了2014年。英國的十二年期間，我做的大多都是3A級的遊戲，隻做過兩種類型的遊戲，一種是射擊類另一種是開車類型的遊戲。

我們柳葉刀做的一款遊戲叫做《邊境》，是一款5V5的多人對戰太空射擊類遊戲。公司最開始組建的時候僅僅隻有4個人，除了管線管理、項目管理、公司運營之外，我們四個人覆蓋到了整個遊戲開發産品制作的所有方面，包括技術、美術、創意以及一些音樂音效。

因為我個人是從3A工作室出來的，然後我的合作夥伴他們是從騰訊出來的，我們一直都是在成熟管線團隊中工作了很多年，可能知道在這當中如何使用管線，我們隻是使用管線中的一環，但是我們沒有獨立搭建過管線，所以當我們自己開始做工作室的時候，我們大緻能夠了解想建一個怎樣的管線，要建成怎樣？其實我們沒有任何經驗。

首先我介紹一下我們隻有7人時候的管線。那個時候的管線其實非常簡單，當時，無論是技術、美術還是設計部門都有一台電腦，電腦上所做的開發環境是一摸一樣的，要安裝所有的開發軟件，美術的軟件、設計的軟件和版本控制的軟件等。

版本控制的軟件，我們使用的是Perforce，因為在我的職業生涯中隻使用過一種版本控制軟件就是Perforce，這也是選擇它的主要原因。我們最開始設計版本控制的時候非常簡單，我們隻有一個分支，就是主開發分支，當時我們四個人都工作在一個分支下。

UE非常大的好處是，已經把這種版本控制的軟件集成在了引擎中，不知道大家平時工作中有沒有發現，UE把Perforce、SVN、Git等集成在其中，我們就是通過這樣的方式讓美術、設計部門使用Perforce，程序部門就不用說了。

開發流程這一塊比較簡單，對于美術與設計師這兩個部門所産生的資産向上提交，問題都不是很大，因為不需要改代碼，不需要重新編譯編輯器等等，不會對項目、對其他人造成緻命性的傷害。但是工程師是會對項目造成緻命傷害的，工程師往往提交一段其認為可靠的代碼時，早期的時候可能會引起巨大的混亂。

當我們擴展到7~30人規模的時候，如果繼續使用這樣的開發方法，我們發現了很多的問題。首先是一種恐懼感，相信各位美術或者設計師打開visual Studio的時候都會十分恐懼，生怕把整個遊戲弄垮了，這種恐懼可能對于美術就有天生的殺傷力。

我們當時的流程就是，當工程師将代碼提交到版本上，每一個其他的成員都需要将這一段代碼拉到本地端，然後他們做的第一件事就是，打開visual Studio然後如果引擎有修改就要編譯引擎，遊戲有修改就要修改遊戲，這對于除了程序之外的很多人是有恐懼的。其實，程序在内的人也會或多或少的有恐懼，特别是當有新的東西需要往下拉，然後去編譯的那一刹那。

UE中有一個非常好的插件叫UnrealVS，它在visual Studio提供了一個非常好的界面，在其中能夠選擇工程、設置、平台，比如就如這張圖中，我可以将UE引擎放在第一條，将項目放在第二條，這樣當你編譯的時候一切就解決了，這大大的緩解了美術的焦慮感，也緩解了一些程序的焦慮感。

對于美術與設計師打開visual Studio是需要勇氣的，為了克服這種障礙，還有一種方法，就是使用了一種命名行的形式來進行對遊戲引擎的編譯。這個時候技術部門寫了一個自動化的編譯腳本，讓廣大美術的愛好者執行這個腳本，然後選擇想要做的事情開始編譯。其實與剛才說的UnrealVS做的事情非常類似，隻不過UnrealVS提供了一個非常好的圖形交互性的界面，而這個就是純命名行，不需要打開visual Studio，隻需要打開腳本編譯。

還有一個災難，當時我們所有人都工作在一個分支下，所以工程師在工作中會遇到一些難以避免的問題，有的時候工程師在提交很多内容的同時，忘記提交一些本地已經修改過的代碼，或者修改過的資産，這個時候工程師在本地工作一切良好。因為Perforce并不負責檢查工作，隻負責管理的工作，所以Perforce實際已經垮掉，但是隐性的，誰都不知道。

美術與設計師看到後，就會拉取新的東西，可想而知那天早晨會發生什麼。美術與設計師拉取了代碼，打開visual Studio編譯了這段代碼，遊戲沒辦法運行了，甚至沒辦法編譯通過，這個時候，所有的美術與設計師就會非常緊張。

所以，我們在分支上就做了一個這樣的架構，把這種人為的錯誤通過分支的架構隔離出來。原來我們所設置的主分支就變成了最高層的分支，每次的Release就從這個分支發布，這個分支是永遠不能讓人來碰的。在這底下還有一級開發的分支，如果有新的特性開發，就在這一層級中開發，并且也在當中完成，直到有一天達到穩定可以發布的狀态就會提交到Main，在Main中足夠穩定了就會繼續發布，這兩級開發的分支是不允許任何人手工交付。

在下面，我們又開了另外幾個分支，因為我們是采取的敏捷開發方式，所以一個Spring是兩周的時間。然後我們還引入了CEO概念，兩個Spring是一個CEO，每一個CEO就會開一個類似這樣的分支，好處就在，當大家在某一個分支上開發過長時間，對于美術與設計的恐懼感增加的不強烈，但對于程序而言有強烈的恐懼感，因為會或多或少的認為這個分支被污染了。所以我們每一個月（四周）後就會完完全全的換一個新的分支，減少了一些比如資産隔離上的工作，而且會給團隊帶來一些安心感。

那麼每一個開發者是如何工作？其實每一個開發者的工作是建立在這之下的，他們會擁有自己的分支，這樣的好處顯而易見，當一個開發者工作在這個分支下，做了無數的事情，即便将這個分支弄的非常混亂，但這一級對于其他的開發者是完全隔離的，除非他把“有毒”的代碼提交上去，而這一級我們是通過人工的第二次審核隔離。如這張圖所示，程序提交“有毒”的代碼，最容易出現問題的就在這一級。

為了解決這一問題，我們引入了持續化集成這樣的成熟理念，當時市面上有四種軟件可以讓我們使用，Jenkins、TeamCity、CircleCI、ElectricCommand，當我們用了Jenkins和TeamCity後，我們認為TeamCity會更友好一些，最終選擇了這個軟件。

這時候我們的流程就會變成這樣，當工程師提交一段代碼到Preforce的服務器後，TeamCity所做的第一件事情就是先檢測，你可以将它看作是一個機器人，它會将代碼打包驗證，但僅僅隻能驗證這個包能否順利的編譯通過，它隻做這一件事。

當TeamCity認為代碼OK後，美術與設計師就可以将代碼拉取出。這樣的架構或多或少的幫助我們有一定效率的隔離“慘案”的發生，并且這樣的架構有一點好處，我們能夠根據TeamCity來檢測每一個代碼的健康性。

做UE的遊戲其實有兩件事情，第一就是如果修改代碼的話需要編譯編輯器，第二件事情如果修改代碼必須打包遊戲讓每個人去玩，剛才所做的都是編輯器，是為了讓每個人都拿到健康的編輯器版本。那麼對于遊戲的編譯，我們采取了另一種方式，美術、工程師、設計師等提交代碼到Perforce後，TeamCity進行檢查并打包遊戲後存到我們的文件服務器上，然後把我們每一次提交打包遊戲的版本存了下來。

我們在TeamCity上使用的還是BuildCookRun，以命令行的形式出現，這是我們大緻上打包的命令，包括命名方式、打包時間等。

這個是我們文件服務器所看到的樣貌，大家可以看到，每編譯好一個成功的遊戲包，在這個服務器上就會将每一個版本的遊戲一次存檔。

剛才所說的都是遊戲端所發生的事情，UE4的開發工程是由兩部分組成，一部分是遊戲端，另一部分是引擎。引擎是什麼概念，當每次有引擎升級的時候，比如從4.1升級到4.2、4.3，這是引擎端的工作。我們最早做的流程是找到UE4版本控制的服務器，拉取到本地，而後提交給Perforce。當時做這段事情的時候，中間基本是手工完成，這是非常痛苦的事情，首先國内的線路連到海外質量一般，第二個是UE4 Depot的規格非常龐大，造成了過程十分痛苦。

但是會發現，這其實是一個很簡單的問題，并不應該去用“人”來幹涉的東西，當時我們部署了TemaCity做的另一件事情就是幫我把Epic最新的代碼或者已經發布健康的代碼自動下載下來，然後我們再集成到Perforce服務器上。

這實際就是TeamCity所幹的事情，會發現在這當中有很多的錯誤，這意味着機器在進行無數次的下載，直到完成，我們就能拿到有效的代碼。雖然會花上一兩天甚至更久，但不用人為去管理，這是我們下載UE Depot的過程。

還有一個比較痛苦的事情是，我們如何把UE引擎和我們已經自定義過的一些部分的内容如何做到集成，這是一個剛開始非常痛苦的過程。大家可想而知，當UE的代碼下到本地的時候，比如4.2與4.3的代碼有多少更改内容，我是不知道的，除非要去仔細的查證。我了解的是，我們的引擎端修改了多少代碼，所以當我手工的在本地比較這些代碼的時候，可想而知，每次升級有上百個文件，都需要靠人工一個個找出來，然後還需要去詢問開發者這個代碼是我們做的還是Epic做的，這是一件很痛苦的事情。

所以我們建立了這樣的架構，首先我們做了一個UE Release的分支，隻負責拉取UE官方發布的内容，在這裡我能夠直觀的了解到有效的更新都是什麼。然後我們在中間建立了一級分支，這與我們開發的代碼分支是分開的，通過這一級的東西來集成Epic下來的東西以及我們上去的東西，通過這一分支解決沖突。好處是當用了有這一分支後，整個Perforce系統會把所有能夠自動解決的沖突全部解決掉，我的注意力就能夠集中在少數幾個有沖突的部分。

我們最早的引擎升級大概在2~3個月的時間，會發現我們早期的升級都是偶數級的升級，比如4.10、4.12、4.14等，因為我們需要花兩到三個月的時間做這樣一件事。當做完了這樣一套架構後，把我們升級的時間縮減到了一周到兩周内。

我們現在已經從去年底的20多人已經升級到了40多人的團隊，我們面臨更多的問題，所以我們正在做的事情就是，完全的讓美術與設計克服visual Studio恐懼症，将visual Studio從美術的電腦中徹底根除，這是一件非常重大的事情。

我們在下一步要做的事情是，TeamCity需要幫我們部署InstalledBuild的引擎，我們在拿到源代碼引擎後可以編譯出，可以部署、不需要再編譯的引擎，這是引擎端。第二件事情就是，TeamCity幫助我們部署遊戲端所産生的二進制動态庫，有了這兩件事後，我相信美術與設計應該可以從visual Studio的恐懼中徹底的解脫。他們所用的是一台新機器，安裝了Proforce後，隻需要在Proforce端拉取已經編譯好的引擎、拉取有效的二進制動态庫的遊戲，就能夠無障礙的進行工作。

在shader編譯還沒能實現分布式功能前，它隻能通過一個線程來編譯shader，可想而知當打開這一個editor後，會花上1~2個小時。所以我們需要通過TeamCity幫助大家編譯所有的shader，放在一個有效的文件夾中，這個我們叫Shared DDC。第二件就是把Build Lighting這件事情放在TeamCity上做。

最後，因為現在我們要打包的東西很多，所以TeamCity上花費的時間也會變長。我們是一款多人對戰遊戲，所以每一次驗證都是從editor到客戶端遊戲，再到服務器端的程序，還有不同平台上的包。所以，打包時間會變得很久，這是我們需要優化TeamCity的原因，也是我們正在做的事情。

以上就是我分享過去幾年的曆程。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!