寫給想轉做遊戲的主播和新人——項目管理篇


3樓貓 發佈時間:2024-01-26 17:32:38 作者:Hakumen Language

前言

這一篇文章是上篇講開發的文章(點擊跳轉)的後續,這裡提到的2個概念“主播”和“新人”上次也有提到,主要是財務狀況和遊戲理想類似主播,心態和經驗上是新人的一類人;這裡的遊戲項目團隊成員,要麼出錢、要麼出技術、要麼出設計,不覆蓋完全零經驗的新手。(個人從0開始開發,可以聽聽機核的系列節目)
另外,上一篇的評論裡有很多討論用成熟的Mod編輯器練手的話題。我認為從成熟的Mod開始搭遊戲對於遊戲設計師練手很好,但是轉商業化是很難的,容易為他人做嫁衣——最近的例子比如DOTA2的自走棋。
說點感性的話,人在參加工作3-5年期間,會有大約人生僅有一次“拼一個項目”的機會:在之前會顯得太菜經驗完全不夠,而過了之後可能經濟、生活狀態、心態都變得不允許了。我個人已經消耗自己的存款用掉了這個機會,好在有很多幹貨可以拿出來分享一下,希望讀了的各位能儘量避避坑;後續會舉幾個中小規模遊戲的例子,講講其各自的開發團隊。

1 團隊起步

(圖中是誰就不用說了吧。但落到自己開發不能指望天降大神,我們還是要以凡人的視角把項目拆開細化,逐步做成)

(圖中是誰就不用說了吧。但落到自己開發不能指望天降大神,我們還是要以凡人的視角把項目拆開細化,逐步做成)

項目管理從宏觀看,主要就是兩點——開發週期人員構成。這裡聊的主視角還是以項目創始人展開,假定項目創始人是一個偏遊戲設計(策劃)的位置,那麼首先找到一個合適的核心程序員是很重要的。
如何找到這個人我沒法給建議,但可以簡單談談這種規模的項目裡主程序的基本要求——個人認為應該熟悉引擎較新版本的主要開發用功能(內置功能及主流插件),並且能夠開發一些常用的編輯工具,最好是獨立完成過一個小型項目框架;至於渲染開發,至少要能熟練運用引擎內置的渲染管線的PBR (Physicallly-Based Rendering) 渲染模型,瞭解前向渲染(Forward)延遲渲染(Deffered)的優劣勢和運用方式,更進階一點最好能實現一些渲染效果(如自定義管線、風格化渲染等),起到部分TA (Technical Artist 技術美術)的作用。
如果是3D項目,個人認為達不到這個要求是不行的;如果是2D項目,可以更聚焦在功能實現上,放低渲染能力的要求。整體來說這個規模的項目需要大家都是“多才多藝”的,從主程序開始就要如此。
有了這一步之後,理論上就能以工作室的形式進行原型開發了。個人建議一開始就最好有一個獨立於自居室的辦公場地——工作有點儀式感總是好的,統一的上下班時間也容易讓人區分上班與下班狀態;混淆工作與生活時間也不利於多人團隊的管理。
隨著原型階段的進行,可以按需補充一些人員,一般初期主要補充程序、策劃和概念原畫美術,原型階段結束後則需要補充美術人員,並最好有一個核心的美術人員。如果是3D項目,需要視規模來決定招聘的人員製作內容和外包的內容之間的比例。
策劃招聘這裡要多提一嘴,因為其實國內是沒有正式的遊戲設計師高級教育的,但網上的方法論與案例又非常多,最容易出現高談闊論、眼高手低的人;個人覺得有一個合適的評價標準,就是——能寫好文檔,邏輯分析能力強,會用引擎,能有獨立的DEMO最好。
實際運作過程中招人也需要有提前量,這個就要結合當年的情況具體來看了(不是說候選的人多一定就是好事,有時候篩選很很耗費精力)。
如果初始成員的主程序希望以公司的形式進行運作,則有必要儘早註冊公司(可以覆蓋一些交個稅之類的常規職能);無論如何,一旦開始鋪量開發,還是應儘早註冊公司,可以掛靠在一個創業孵化機構,例如在杭州之前就有天使小鎮這樣的孵化基地,有統一的財務託管之類服務。
原型團隊成立後就應時刻有成本意識,例如核算一下人員的薪資、辦公場地租金等,計算一下現金流、人員構成與項目週期三者的關係;之後進行週期變更或人員變更都要重新核算。
如果讀過《DOOM啟示錄》《社交網絡》或看過《獨立遊戲大電影》之類的熱血沸騰的創業故事,或者聽了各種硅谷創業在倉庫起家之類的故事,可能人的想法會陷入一類浪漫主義的敘事裡。我必須要說那個時代已經過去了;不止是疫情原因,還因為開發遊戲的利潤空間已經大大不如當時了。那些成功創業故事裡的“一起玩某款熱愛的新遊戲都不工作”的狀態,個人覺得可以審慎的進行保留,但每月最好不要超過2天處於這種狂熱狀態中。 萬事開頭難,但對於做遊戲項目來說,後面更難。

2 優化溝通

團隊合作里人與人的溝通是如此的重要,但對於現階段的世界來說,又變得比之前更困難了。好在面對面的溝通其實沒有改變太多,拋開繞彎子說空話的模式不談,個人認為真誠的工作溝通主要需要做到——專業性、專注力與廣泛涉獵知識
~專業性首先是由團隊成員自身的資歷保證的
假定招聘時承諾過成做的事情都是可以達成的,那專業的程序就可以針對一個需求提供更多或更優的方案(或避開一些大坑需求),專業的美術可以繪製或製作更多風格和性能更優的素材,專業的策劃可以寫出邏輯鏈條更完整、更可行、可讀性更高的設計文檔,並有一定的玩法設計能力和數值能力。
同時,持續學習與增長自身專業性也是需要的,畢竟商業引擎和遊戲行業都在不斷發展,人也需要不斷學習。
~專注力需要團隊有穩定的工作紀律和就是論事的討論氛圍
雖然遊戲開發可以區別於傳統的死板的“上班”,但團隊也最好不要有彈性工時的狀態,否則會減少需要溝通的人員之間的溝通時間。策劃、美術崗位往往會有需要體驗其它遊戲找參考的時間,但總的來說工作時間內還是應以“幹活”狀態為主,尤其是策劃更多可以考慮成為全棧式人才——學點項目用的上的簡單美術或程序,或者用編輯器搭一點小功能的原型,而不是在完成了設計文檔之後、在大規模配置工作還沒來臨前一直處於“玩遊戲”的狀態。
形成專注在項目本身的氛圍,也可以避免團隊漸漸走入“看別人的都是好的,自己的產品卻特別漫長看不到頭“的喪氣狀態,因為項目的階段、工作的內容和要解決的困難都是很具體的,需要共同攻克的。
~廣泛涉獵知識這個是我個人比較看重的一個方面
這裡的知識可以指項目專業知識以外的所有認知世界需要的知識,從歷史、人文到物理、天文,從最早的黑白電影到最新的美劇等等,當然還可以包含所有其它的遊戲產品的體驗。除了讓自己成為一個有深度的人之外,還可能不知何時就能提供項目用得上的信息——例如項目裡需要一些甲骨文的圖案,如果恰巧有人研究過甲骨文,就可以既用其圖案還能使其符合表意;再例如項目需要維多利亞時代的服飾,如果有人能指出一些當時的畫作的名字作為參考,其可靠性就會好於從二手的遊戲或劇集中的服裝作為參考等等。(聽機核的各位可以想想重輕老師,他是不是幾乎啥都能聊)
總結來說就是提高個人在溝通上與他人兼容的能力——畢竟親和力、耐心等等很感性的方面沒法要求人人做到,但是“能表達、願意聽、聽得懂”是一個好的團隊成員該有的素養。只要招聘沒有太大偏差,人員構成合理,這種氛圍是可以漸漸形成的;團隊的Leader也需要不斷保持並強化這種良好的氛圍。

3 制訂可行的計劃

(圖中是《幻獸帕魯》中的生產流水線。當然,實際的項目計劃比這複雜多了)

(圖中是《幻獸帕魯》中的生產流水線。當然,實際的項目計劃比這複雜多了)

基礎的項目計劃只需要加法和乘法就可以做,某種意義上這也是對的。實際上項目計劃的難點不在最後算的那一步,而是估計工時優化並行工作的效率;進階的還會引入2個話題,分別是階段目標的制訂與修正,以及QA和優化的時間估計
~估計工時
在原型階段,往往只能估計一些時間節點,沒法太細緻的針對人員估計工時;在進入鋪量開發階段,並且程序和美術都有相應Leader的狀態下,會相對更容易對功能點和製作資源進行估時;後續開發中再對估時進行驗證,如果基本符合,就可以制訂相對更長的項目計劃,並制訂一些並行開發和並行資源製作的計劃。
~優化並行工作的效率
項目管理上是有一個老的名著叫《人月神話》,從中可以總結出需要審慎的看待並行開發,不是所有模塊所有項目都適合並行開發。例如地圖編輯器、核心玩法、視覺效果之間可以並行開發,不同的美術資源也可以並行製作,但單獨玩法模塊有時不適合並行開發,否則可能反而增加溝通成本,核心的模塊也最好是核心程序員完整的來做。
一旦有了並行開發的成功案例,項目的週期就相對更可控了一些。但中小規模的團隊不適合並行開發製作太多子項,可能程序和美術分別並行2-4條工作序列比較合適,否則可能會分散主創和Leader 的精力,導致做出一堆無法整合的東西。
~階段目標的制訂與修正
儘量細化項目節點,併為之分配合理的時間;之後定期按時驗收並調整。
如果在項目進行了一段時間後還出現了重大的時間偏差,則需要檢討原因並調整。假如是設計了超出開發製作能力的功能導致無法實現,則需要重新審視功能的必要性和替代的可行方案;假如是為打磨某個細節投入了計劃外的時間,則需要討論是堅持細節繼續投入時間還是放棄這個細節特性——繼續投入時間還要考慮是砍其它功能的開發時間,還是延長整個項目的開發週期。
一些單機或獨立遊戲製作人往往都會選擇針對某個細節扎進去大量時間,可以說這既是這些遊戲獨特的原因,也是這些遊戲逐漸成為開發地獄的原因。我只能說,實在想要這個特性那就延期吧,只要有資金來源;否則就應該修正後續內容的優先級,保證能在時間結點以較完整的Early Access狀態先發布。
~QA和優化的時間估計
我必須說遊戲行業的QA幾乎已經是軟件工程範圍內最不規範、最玄學的了。近些年大公司項目做不完壓縮了QA時間,導致產品爆炸的已經非常多了,這也是一個行業變化的縮影吧。
最“原教旨”的軟件測試人員,是要從項目設計定版後就針對功能設計測試用例(Test Case)並寫成測試文檔的,這類似於一系列檢查點的清單。有些測試項可以自動化進行的,就可以編寫一些自動化腳本工具;有些場合需要測試性能的,就可以編寫一些壓力測試工具,或向程序人員提出GM後臺的功能需求。總的來說,預留給測試人員的時間越充足,測試效果肯定是越好的。
但轉頭看看近年的遊戲開發,尤其是“敏捷開發”的項目,這方面就完全不行。一方面可能根本不會招常駐的QA人員,另一方面是沒辦法留出足夠的測試時間,往往最後的結果就是先行發佈讓玩家幫助測試,但就會帶來口碑的損失。假設團隊對這個事還有所追求,這裡提供一個大概參考時間——開發人員5人左右的團隊,開發時間3年的遊戲,最好至少預留3個月以上時間進行QA(參與人員5人以上)。
如果團隊還有餘力進行功能或性能優化,由於是加分項,還是應該定好計劃,量力而行;優化單個界面交互相對容易,優化項目底層的性能結構則往往很難。實際上只有極少數“優等生”能有這個餘力,大部分可能都要陷入“來不及交卷”的焦灼之中。

4 團隊主創的作用

(圖中是大河劇《怎麼辦家康》中的武田信玄教育家康的戰前宣言:打仗要確定能贏,才能真正開打啊)

(圖中是大河劇《怎麼辦家康》中的武田信玄教育家康的戰前宣言:打仗要確定能贏,才能真正開打啊)

就像前面講溝通提到的一樣,團隊主創自己也要表現出專業且有計劃,這有利於團隊人員的關係和睦和項目正常推進。主創自己即使是出資人,也應積極參與和投入團隊的項目計劃與設計討論之中——在這種規模的項目中是沒法指望抽身一旁事情就能自然運轉好的。
但是也要杜絕類似“兄弟會”模式的辦公室文化,因為這又容易讓不善於社交的同事感覺被邊緣化,也會對就事論事的氛圍有損害。
最重要的是作為出資人要對項目的整體計劃有把握,如果能在計劃內做完,可以優化成本細節進行迭代開發(做新版本等);如果因為打磨細節而無法在計劃內做完,則權衡利弊工時、必要時引入新的投資都是需要考慮的重要事項。但即使資金不愁,延期也不宜太久,否則會讓團隊產生倦怠感,也容易增加技術迭代帶來的時間風險(要升級引擎版本之類)。
這裡推薦機核文章區轉翻譯的一個系列——講的是約翰羅梅羅的《大刀》項目的失敗,其中能看出的一個核心點就是,主創不能假設新團隊能像之前待過的有經驗磨合好的團隊一樣自行運轉。文中的羅梅羅雖然對項目很投入,但是並沒有參與調和不同部門之間的矛盾,也沒有更多在一線開發人員面前經常露面,給人一種疏離感。升級引擎上他們也踩了坑,為了提高畫質付出了慘痛代價。這些方面的教訓都是值得警惕的。

5 案例分析

例子1——幻獸帕魯
原文地址:點擊跳轉
遊戲《幻獸帕魯》上線當天我就碰巧看到了一篇分析他們公司人員構成的文章,原文是他們社長髮的,大概意思就是做這個項目太不容易了,能做出來簡直是奇蹟。雖然說也有點軟文的性質,我看了以後的感覺是,他們項目初期找到的人確實很奇蹟(但這也是他們的第3個項目了,之前2個半成品的項目多少積累了這方面的經驗)。這裡挑幾個分析一下:
——FPS部分是一個沒遊戲經驗但是做了大量槍支動畫和開槍射擊DEMO的遊戲宅,20歲初中文化
——核心程序是一個不會Git但是熟悉虛幻引擎的大佬,既將項目遷移到了虛幻平臺也負責組建了程序團隊
——動畫部分招到一個”資深模型動畫師“,能用插件量產動作
——原畫美術設計是一個應屆女生,可以畫別人4-5倍的速度,完成了100個怪獸的設計
雖然這個遊戲處處透出山寨的氣息,這篇文章也不能全部照單全收,但我也不得不說這個小作坊最後拿出的成品還是挺驚人的,實際付出的成本肯定也比大多數玩家想像的要多。按文中說的,這個團隊初期原型只有4個人,花3個月做到了預告片裡的演示內容;後續除了以上核心人員外,3年內一共招了40多人並有大量美術資源外包。據社長自己說是至少花了10億日元,按現在匯率就是 近5千萬人民幣 (當然這個數量可能有點誇張成分,但這麼多美術資源肯定是成本千萬量級的項目)。
另外,我預感國內大廠的《幻獸帕魯》like遊戲說不定已經立項了。
例子2——《空洞騎士》與《波斯王子 失落的王冠》橫向比較
(圖中是《幻獸帕魯》開發商公佈的一款新的《空洞騎士》like遊戲,額..)

(圖中是《幻獸帕魯》開發商公佈的一款新的《空洞騎士》like遊戲,額..)

如果打通了最新的《波斯王子》,會看到一系列漫長的工作人員列表。我看羽毛直播最後感嘆說,真要這麼多人麼,是不是稍微參加了一點也寫上去了。這裡我要說:雖然協力的確實都寫上去了,但是核心團隊成員的數量依然比很多人想象的要大很多(核心程序近20人,開發及美術團隊近200人規模,音樂十幾個,轉場動畫另有十幾個人的團隊),可以說這就是做大型3D項目的實際情況,因為要把畫面做得風格化又好看就是很費人力的。開發週期從整體規模和對應開發組的狀態來估計,密集開發應該不超過2年時間。
而遊玩時長接近,內容量感覺也相仿的《空洞騎士》,初創團隊只有3個人,後續似乎也始終沒有大規模擴招,開發持續了6年。可以說《空洞騎士》這種產品更多的會給想入行的人希望,而《波斯王子 失落的王冠》這種工業化的精品無疑是勸退新人的——但事實就是好的3D畫面效果遠比2D難以實現。如果以3-6人規模想做一個3D銀河城類遊戲,可能需要選擇合適的目標參考——個人覺得類似《帕斯卡契約》的地圖規模和視覺效果是一個可以達成的目標。
可能也由於沒有怎麼擴招的原因,《空洞騎士 絲之歌》被玩家調侃為是一款長期放鴿子的產品。但是考慮其前作用了6年時間,並且新作除了底層模塊以外全部要重新做,其實2024年能發售就真不算慢了。
例子3——《湮滅線》的製作組
(圖中是1月25日推出了正式版的《湮滅線》)

(圖中是1月25日推出了正式版的《湮滅線》)

在杭州雖然我也認識一些前同事去了《黑神話 悟空》或是《永劫無間》這種規模比較大的項目(更多的是去做手遊了),但這個《湮滅線》的製作組是唯一一個以原同事組了團隊做獨立遊戲的一批人,作為我目前談的這個話題最有些參考性。
這個團隊在前公司做過一些練手的沒發佈的橫板動作DEMO,獨立後的初期做過一些預裝手機遊戲的外包,後來做了一款上線了的單機手遊《九黎》,6塊錢買斷的那種。這個產品的流水後續支撐了他們團隊繼續開發新作。上次線下見他們團隊的人也是4年以前了,當時正好看到了這款產品的DEMO,能跑跳爬牆之類的,第一印象就是一款賽博風格的《死亡細胞》。這款產品的賣相非常不錯,但確實也是那種要熬很久才能出來的遊戲——因為細節打磨、開發方向調整、發行方需求等等各種原因。
他們最初的發行找的是騰訊極光計劃,後來換到了心動來發行(期間可能發行方也注入了一些資金,大概百萬規模的)。當年的人員規模是含主創以內2個策劃、1-2個程序、2個美術、1個行政,後續似乎也沒有大規模擴招,最多可能多了1-2個人吧。然後項目的整體開發週期是6年。這些信息其實網上都能查到,也不算是我在八卦。
這是一個主創是策劃及出資人的團隊,他們的薪資給的相對較低,打磨功能的方式也可能不是高效的,我不知道他們團隊除了主創的其他人是怎麼想的,但我希望產品的完工能讓他們團隊感到欣慰和自豪。大家可以去steam上搜搜這款產品,正好1月25日發佈了正式版(只是順帶提一下,不算給他們打廣告)。

結語

《空洞騎士》或《神之天平》那種人員少週期長的模式可能不太適合國內,有一種一個事做了半輩子的錯覺,往往很消磨人,團隊很可能會堅持不下去。無論是從實際分析還是案例中的人員構成看來,有經驗的Leader+有絕活的新人都是一個比較靠譜的公式(畢竟全招資深人員成本Hold不住);6年的項目如果能以加人的方式摺疊到3年的開發週期,既是可遇的一種境況,又對團隊中的成員會友好很多。
以國內實際人員和薪資情況來估計,假設要做一個簡單的3D銀河城遊戲或箱庭關卡遊戲,最低成本至少是500萬人民幣,最低人員6人左右(符合之前提到的人員構成比例,並預留一部分量產美術資源外包),能維持大約3年的開發週期,靠譜的話應該能開發出一個能找到發行商的版本。
最後,祝願所有還對單機或獨立遊戲有夢想的人能開創或參與一個讓自己滿意的項目!
(圖中是日劇《Atom》之子的段落,這部劇雖然魔幻但也能窺見遊戲開發的冰山一角)

(圖中是日劇《Atom》之子的段落,這部劇雖然魔幻但也能窺見遊戲開發的冰山一角)



© 2022 3樓貓 下載APP 站點地圖 廣告合作:asmrly666@gmail.com