標籤:

遊戲物語 - 開發團隊構成

遊戲物語 - 開發團隊構成

來自專欄 遊戲與後端技術

遊戲的開發團隊經過了若干年的發展基本上已經固化了下來。其形式變遷也完全是為了滿足遊戲本身的變化需要。縱觀近十多年的遊戲產業發展,各種類型,無論是social game、web game還是mobile game,都在從遊戲循環的單一性向複雜化演進,功能模塊也日益複雜,不同類型之間也成融合之勢(比如社交成為了遊戲中不可或缺的元素)。而對應的團隊結構也從之前類互聯網產品團隊演變為製作人體制。「遊戲物語」這個系列的開篇,就先來八一八團隊構成。

團隊分工

首先需要知道的一點,一個遊戲的最小核心職能只有3個:策劃,美術,程序。因為遊戲的全部產出幾乎都由這3個職能完成。換句話說,組建一個最小的但完整的遊戲開發團隊,只需要3個人。甚至如果同時具備以上技能於一身,1個人也夠。這樣的案例並不是沒有,比如大名鼎鼎的Minecraft,或者是我非常喜歡的夫妻檔開發的Battle Heart,以及許多在taptap上很成功的獨立遊戲。

策劃

策劃其實就是產品經理,其主要的工作就是設計遊戲的整體循環,各功能模塊,並文檔化。內容策劃一般做功能設計,故事情節等,而數值策劃是遊戲這種產品特有的一種職能。遊戲中有大量數據化的工作,比如經濟系統,角色成長系統,都需要有一定數學功底的策划進行設計。其設計結果的合理性決定了遊戲一個很重要的要素:平衡性平衡性對遊戲的品質和生命周期都有很大影響。星際爭霸能暢銷20年,和其完美的平衡性有很大關係。

不客氣的講,策劃誰都能做,因為這個工種是唯一一個不太需要專業技能的工種。一個玩過遊戲的人,就能夠根據自身經驗給出一個基本設計。但是,要想成為一個優秀的策劃,難度非常之大,對人員素質也有很高要求,比如創造性,合理性,完整性,平衡性,其工作內容是思維的產物且極難量化。毫不誇張的說,一個遊戲的成功與否,和策劃團隊的能力有最直接的關係。

我個人認為國內遊戲行業優秀的策劃人員非常少,這也就是我們很少能看到令人驚艷的作品的原因。

策劃通常是美術和程序共同的敵人,需求變更會導致其他人做無用功和無休止的加班,一個功能自己沒想明白改來改去是常有的事,而啥也不懂卻指手畫腳的嘴臉更是讓碼農痛恨不已。

美術

美術主要的工作是對遊戲內容進行包裝和藝術化,根據遊戲類型的不同,一般分為原畫、2D、3D、動畫4種。原畫美術主要負責過場畫面,為3D提供原型,角色設計等。通常一個遊戲推向市場時各種炫酷的海報等都是來源於原畫。2D主要負責界面的總體風格和布局設計,遊戲中道具、武器等部件的繪製。3D顧名思義,就是做3D場景、角色,沒啥可解釋的。動畫一般是製作遊戲中需要的動態效果,屬於錦上添花,比如技能釋放時的動畫,角色戰鬥中的動態等等。

功能比較單一的小遊戲(如早期的socialgame),團隊里通常沒有固定的美術人員,而是由統一的美術部門進行支持。比如互聯網公司的美術需要負責頁面或其他產品的設計,遊戲部門有需要就請求調派人手協助。現在即便是在純粹的遊戲公司,依然有美術團隊作為獨立部門存在的情況,同時負責多個遊戲,進組幹活,完成後再去其他組。這和美術的工作產物是一次性產出有關,確定之後基本不需要後續維護,所以獨立性也更強。

值得一提的是,對比較複雜的遊戲來說,美術的工作量是非常大的,所以通常一部分工作會尋找外包團隊去完成。

美術是促成遊戲成功的另一個主要因素。優秀的美術風格甚至有扭轉乾坤的能力。比如我之前參與開發的卡牌遊戲《靈異陰陽錄》,大量死忠玩家都是為了收集畫師的作品而持續的進行時間和金錢的投入,遊戲的生命周期也得以延長。

美術人員只和前端程序有交集,和後端程序完全沒交集,通常情況下都比較融洽。

程序

碼農大家都很熟悉了。現在基本上絕大部分遊戲都要聯網,所以有前後端之分。前端主要負責頁面端或App端的展示邏輯,或者是和展現相關的物理特性處理邏輯,如尋路、碰撞、同步插值計算等等。後端一般是業務邏輯代碼的持有者,但其實無非是對數據進行操作和讀寫而已。有些邏輯是可以選擇寫在前端還是後端的,要根據情況去判斷,保證其合理性。

我個人認為,程序的好壞,不能決定遊戲的成功,只能決定遊戲的失敗。代碼質量的區別,只有性能、穩定性、健壯性、擴展性的區別,而沒有功能上的區別,在功能覆蓋點上是一致的。遊戲早期,大量用戶湧入之前,程序的質量很難被檢驗,用戶完全不知道程序寫的是好還是爛,因為不能直觀的看到和感受到。而一旦遊戲成功了,DAU全面飆升,程序的重要性才逐漸顯現出來。爛代碼會導致有大量bug、並發能力弱、遊戲響應慢等等,這些因素超過一個閾值,就會讓遊戲走向失敗,或者加大用戶流失,縮短遊戲生命周期。一個很好的例子就是《我叫MT》在恰當的時間點推出並大獲成功,而後才暴露出程序無法支撐大用戶量的並發操作,CEO本人居然在微博上告誡玩家避免在高峰時期登錄,這和現在12306的分時分段放票的行為沒什麼區別,可笑至極。

程序是整個團隊中最苦逼的一群人,班加的最多,黑鍋背的也最多,出了問題也是第一個要出來解決的。前端碼農通常比後端好一點,每個release遊戲打包完成就沒什麼事了,而上線之後後端的噩夢才剛剛開始。你在地鐵上,公交上,馬路上,席地而坐處理線上問題的一定是後端碼農。儘管Backend沒法決定遊戲成功,但一不小心就能毀掉一個遊戲甚至是整個公司,工作風險極大,需要有強大的心理素質。我之前就遇到過有欠缺經驗的同事操作線上資料庫忘了加where子句,導致經濟系統崩潰,遊戲生命周期提早結束,令人唏噓不已。

支持部門

音樂音效:這部分其實也是遊戲實體的一部分,好的音效錦上添花的作用非常明顯。沒有單獨拿出來說的原因是一般都是外包。大的公司有自己的音效師在各團隊間共享。

QA:測試常駐開發團隊的情況比較少,除非是公司就只有一個遊戲項目。通常都是所謂的central QA進行支持。遊戲和其他的互聯網產品不同,很難進行完全的自動化測試,大量的功能點需要人肉測試,比如跑地圖刷副本。另外遊戲存在大量功能交錯和耦合的特點,單個功能點正常的情況下,組合後就難免出現問題。QA是遊戲質量保障最重要的環節,我很難想像沒有完善測試的遊戲在玩家手中會是個什麼樣子。前陣子騰訊倉促上線的吃雞遊戲就因為bug太多不得不回爐重造,這種例子在以前單機和console game上時有發生。QA也是比較苦逼的一個工種,每個release前基本上都是連軸轉,夜裡報bug,白天碼農來修,一對難兄難弟。

LiveOps:運營是讓遊戲利益最大化的重要手段,沒有合理的運營活動,遊戲在收入上會停滯不前。webgame時期有這樣一種運營人員,俗稱托,假裝是個大R玩家,在遊戲初期領跑,等遊戲服的生態和用戶穩定後立即退出。我在做webgame運營支持的時候就干過這種事。運營人員主要的工作還是設計活動內容,拉新或者召回。通常節假日的活動都是收入的高點,而合理的運營行為也是保證遊戲留存、降低流失、延長生命周期的重要手段。

另外,數據分析的相關工作一般也劃入LiveOps,他們主要是根據已有的BI數據,分析和給出各個指標,比如DAU、首日、7日、30的留存、收入,充值、道具消耗等等,對運營工作提供決策參考。

運維:很多小公司是沒有運維的,反正就是伺服器、工具維護,苦逼的後端碼農就兼職幹了。國外遊戲公司一般會細分出來,讓後端更focus在業務邏輯開發上。

市場:BD的作用也不能小視,談渠道,談植入廣告,有時候抓住機會就能拯救一個團隊。

組織結構

說完了每個工種的具體職能,下面來說說依附於職能體系下的團隊組織結構。下圖是一個比較典型的製作人體制團隊。

製作人

製作人從某種程度講,其實是策劃的一種職能延伸,其工作依然是以遊戲設計為核心,決策和把控遊戲的方向、主旨,貫徹自己的設計意圖到團隊。在此之外,製作人必須還是能全面掌握從研發到運營知識體系的總負責人。製作遊戲在某種情況下和製作一部電影很類似,而製作人更像電影的導演。

我並沒有考證過,但製作人這種體制應該是從日本發展起來的(如有錯誤請指正),比如著名的製作人小島秀夫、宮本茂等。和傳統互聯網團隊不同,製作人體制下,所有的團隊成員均report給製作人,即便製作人不懂美術不懂程序,也是唯一的決策者。我個人認為,這是由遊戲這種項目的特殊性決定的,雖然這會出現所謂外行領導內行的情況。遊戲項目有個很大的特點就是團隊耦合大,要求高度內聚,換句話說,就是團隊成員必須上下一心,勁往一處使,對遊戲的認識也必須一致。這種高內聚團隊,一是必須要高效的貫徹製作人的設計意圖;二是協作非常頻繁,需要將溝通成本降到最低。試想如果各個職能都平行不相交有各自的彙報人,一旦遇到問題,碼農會說我做不了你去找技術總監,美術說我改不了你去找美術總監。。。這樣的情況下執行力可想而知。

其他

以現在的手游為例,一般MMO、SLG、RPG這種較複雜類型的遊戲,我認為40-50人的開發團隊是比較合理的。即保證了工作壓力不會太大,也可以使單位人員創造的利潤最大化。再回頭看圖例中的職位,策劃方面主策一定是有的,無論團隊大小,產品總監倒不一定存在,很多情況下製作人直接領導主策更合理。美術方面,根據遊戲需要,上面提到的4種職能都需要有自己的主美,美術因為分支較多,設置一個總監還是比較有必要。碼農方面,前後端主程是必須要有的,代碼要責任到人,必須得有人站出來背黑鍋。技術總監這樣的職位在任何公司都需要,遊戲公司也需要一個high level的人去制定整體的技術方向和架構。

有些團隊可能並不設置項目經理這樣的職位,由製作人兼任。主要工作內容是協調、溝通、進度、任務分配等。PJM也是個比較尷尬的職位,只管項目不管人,只有建議權沒有決策權,很多時候成為夾心餅乾,上下不討好。

開發方法

沒有統一標準,初創型的小團隊可能直接就作坊式的加班加點往死幹了,成熟的公司一般也是以敏捷方法為基礎,根據自身情況進行裁剪。Scrum現在依然是主流。我個人認為,遊戲的業務特點是需求變更頻繁,且要求快速響應,所以精簡化的敏捷方法是最適合的。畢竟線上一個嚴重的bug要立刻hotfix,等你重新design、review,再層層審批上線,可能早都玩家流失遊戲go die了。任何一次上線,特別是數據層面的更新都要特別小心,但遇到問題必須用快准狠的原則快速解決。

最後,再特別的提一下Valve,非常神奇的一家遊戲公司,上面所說的理論可能並不適用於它,至於它到底是如何神奇而偉大,我們從它直接在官網給出的新員工手冊就可見一斑(valvesoftware.com/jobs/)。暴雪的偉大在於他們追求完美的勇氣和十年一劍的作品,而Valve的偉大在於他們的工作方式令人神迷。最後的最後,以Valve所追求的理念來結束此文:「在無人為你指路時,你要無所畏懼繼續前行」。


遊戲物語 - 引子


推薦閱讀:

反編譯C#代碼來看看協程是什麼
unity3d在android使用sqlite
Unity使用C++作為遊戲邏輯腳本的研究
Dice (EA) 工作室遊戲開發技術概覽
像素鳥跳跳跳!(什麼鬼 ×

TAG:遊戲開發 |