NO IMAGE

有時候確實是能夠感覺到,一個專案的成敗往往在專案早期就可以預測得到。如果說每個具體的技術點、工具的選擇、策劃的想法、美術的風格這些都是戰術的話,那麼專案的戰略就是這個專案的上層架構了,包括專案成立之初的意圖、版本進度的控制、各個功能單元的安排和配合。

近年來的大部分專案並不是亡於技術細節這些戰術上,而是亡於系統的內耗上,也就是亡在戰略上。這就好比一部機器,木頭做的螺絲、木頭做的輪軸,只要配合合理,就能夠搭出水車、風車、投石車,它們中的有些直到今天還合用。但是如果各個部件配合不合理,螺絲拿去配了齒輪,那哪怕用黃金也做不出來好的機械。系統工程的關鍵有兩點,一個是系統的組分,一個是系統各個組分之間的配合。時至今日,但凡走了一段時間的公司,系統的組分水準都不會太糟糕,至少是合用的,問題往往產生在組分的配合上。在下見過不少專案組,程式和策劃只能說做到了配合,卻遠遠沒有做到有效的配合,雙方互相經常性否決對方的提案,甚至干涉對方的工作……

最近見到一個專案,全面介面化、全面元件化、設計思想不可謂不先進,專案組主要角色也都是4、5年經驗的開發者,但是似乎仍然到最後陷入了“焦油坑”中:元件開發過細,明明適合放到一起的卻都分到子元件中去了,導致元件間的互動瞬間增長、變得異常複雜、從而喪失了元件最大的優勢。專案組一直重構,卻怎麼重構都衝不出這個焦油坑。導致一個明明研發了很久的專案,看起來完成度卻並不高——並不是表面的完成度,而是系統的完成度,遠遠沒有到達工具化和調細節的層次,內容的提供和儲備嚴重不足。策劃乾著急沒辦法,程式則苦於系統修修補補,要解決的問題太多……

私以為,這個團隊最大的問題,是在於程式人力太多,整個專案基礎玩法剛剛定性,就已經長期維持了數十人的規模。如果一個團隊剛上來就來上十幾二十個程式,那每個人水平再高、再怎麼努力就都沒有意義了。

表面上看起來,人員數量多的團隊,解決問題,哪怕是解決重構索要花的時間總要優於人數少的團隊,可是這種思路有一個先入為主的出發點錯誤,就是假設軟體開發過程是建立在重構之上的。否則,大家都懂的,系統的前期結構設計越完善,才能真正減少後期堆功能時所耽誤的時間。專案級別的重構,生命期內兩三次已經足夠大動盪了,再多那隻能說明這個專案的初始設計太糟糕。套用《最後期限》裡的話,“通過評審了!他們歡呼著把之前的設計束之高閣。然後開始編碼了,然後從這個時候才開始真正的設計!這個時候,才開始真正的設計!”

軟體開發拼人力一直是最大的忌諱,與軟體規模和當前開發階段相應的人力數量往往並不是無限增長的,如果人力數量超出了當前開發階段所需要的人力數量,那麼問題往往並不是浪費人力這麼簡單。

從管理者而言,能做到“韓信將兵多多益善”的管理者舉世都可以說罕見,五人團隊和二十人團隊和一百人團隊,消耗在管理上的成本絕不是一個數量級的區別,而軟體開發還偏偏不是一個藍領工作,並不是簡簡單單擰擰螺絲就完了的,如果無法調動起人的積極性,那麼這個人很可能自己擰不好螺絲,還會搞得別人一起弄不好螺絲。

從技術層面而言,前期人員太多,又要保證這些人有事情做,很多系統核心設計必然是隻有個大概的方向,甚至都不能囊括整個遊戲開發期所有可能出現的需求和預測(一般都只考慮給老闆看的第一個Demo),就開始堆人力了。做過系統設計的應該都清楚這意味著什麼——這樣的設計根本就不能稱之為設計。

而且,堆人力的時候,因為人多,又開始出新的狀況了:一開始,A負責數值這方面的工作,由於此時沒有完善的頂層系統設計,所以所謂的數值就是一個獨立元件,全面與戰鬥繫結。而第二個版本後,A去做更重要的事情了,B奉命過來在A的數值體系裡增加升級相關的功能,由於發現A的數值是戰鬥數值這個現實,於是B自己又寫了一套專門處理升級的元件。而此時,C在寫技能相關的功能,發現A和B的數值都有沒考慮到自己的部分,於是做出了一個艱難的決定——在技能系統內部再加一部分技能相關的數值。

於是到最後,明明一個很簡單的概念,發現有三個系統的三套不同的人馬在維護……而遊戲數值這種東西,追根究底地問一句,該是程式Cpp到工程裡的東西嗎?

沒有最頂層的設計,每個具體的點設計得再好也沒有意義,因為你很可能不需要在這個點上去設計。

前段時間看到一篇講敏捷開發的帖子,其中一個最重要的觀點就是,敏捷開發是在優秀設計基礎上進行的,並不是說敏捷開發了,就不要設計了,否則再怎樣也無法真正敏捷起來。哪怕有最好用的重構工具,重構本身仍然是需要花大量時間和精力的。而且,每重構一次更大的意義上是對團隊信心的考驗,如果總是重構不到位,老闆會開始懷疑這種做法,而底層員工則也會否認這種出力不討好的工作。重構很可能並不是用來解決這種問題的最好方案,特別是對於專案開發週期本身就被更上層的領導和市場壓力不斷壓縮的中國遊戲專案而言,一次重構動輒半個月一個月的工作量讓人望而卻步,而同時,重構無論如何對於團隊而言,都是對現有流程和方法的破棄,對士氣造成的影響,人少、有核心還好說,人多,本身就誰都不服誰的情況下,很難說會造成什麼好的效果。

核心設計為什麼叫做核心設計,恰恰就是要少數菁英突破性地完成整個遊戲的上層設計,而前期來那麼多人,根本對此事沒有任何助力,相反的,為了給這些人找事情做,大概齊這塊兒有個什麼什麼東西,你去做吧,大概齊那塊兒有個什麼什麼東西,他去做吧,設計云云根本就無從談起。

可是為什麼這樣有百害而無一利的戰術會得到認同並且執行呢?為什麼很多遊戲專案拼命前期搶人,而且搶過人來就發現有東西能做呢?因為,看似,遊戲的工作就有那麼多。

一方面分配給程式的工作量,很多時候我們在用專業程式設計師的CPP在做一些老外的Game Designer用LUA、Python和工具來做的東西,而且,本土Game Designer更喜歡扮演指揮者的角色,但指揮的效果……是否能有人告訴在下,如果一個指戰員從未到過一線,他的指揮到底靠不靠譜呢?客觀上來說,專案的開發中經常出現程式修正策劃需求的情況,這應該足以表述這種方式的結果到底是如何的了。而如果一個策劃跟程式的交流過於緊密,又容易產生策劃被程式綁架的情況……也難怪似乎中國的專案組裡很難出現歐美那種程式和策劃相互融洽的將相和結局,策劃和程式簡直就是互為天敵的存在……任何一方的強勢帶來的結果往往是不受控的。在下不幸見過這個也做不了,那個也做不了的程式,同樣不幸見過這個沒考慮到,那個沒考慮到的策劃。沒有指責誰的意思,其實沒有任何一方是勝利者。

另一方面就是進度壓力,一個核心玩法還沒有決定下來的專案,就要求所有的表面功夫都要做到位:要聊天、要組隊、要團隊、要工會、要幫派、要結婚……這麼一堆做完以後,發現核心系統慢慢健全了,於是這塊兒開始改,那塊兒又開始改……

在下竊以為,這樣的研發觀念已經足夠多地證明了自己的落後了。歐美的遊戲研發能夠在這幾年發力並且迅速超越日本,在於它有一個低內耗的產業環境。對比歐美的引擎思路和日本的引擎思路就發現這種區別了,很長一段時間裡,日本的遊戲每一次新做,整個底層到上層就會幾乎全部廢棄重來,而歐美的引擎呢?看看Unreal和Unity能做到的程度吧,即便是稍差一點的CryEngine,卻也能通過指令碼,在沒有引擎程式碼的情況下完成自己的Mod。很多人都認為,這是歐美遊戲能在最近幾年大舉發力逆轉日式遊戲的關鍵之處:這種模式培養起了大批經歷過一線風雨的菁英力量。

而一些中國團隊的研發觀念又是什麼呢?只能說具有中國特色,專案前期,只知道我們大概齊要做成(shan zhai)個什麼樣的東西,中期和後期則開始一會兒山口山,一會兒鬥戰神……總體戰略如此,每一個戰役過程自然也高明不到哪裡去:

既然前期這麼鮮明地明白了目標,自然就是儘快堆著人力往上衝了,設計?我們的需求都明確了,還要什麼設計啊。

然後,為了應付版本,“時間緊,任務急,是不是把這塊兒繞開?”“我看行”。版本結束後,這事兒就束之高閣了,幾個月後有人做到這裡,突然才想到哦當時這塊兒有個坑。

再然後,發現這個版本老闆不滿意,老闆說那啥啥是個好遊戲,我們把那啥啥加進來吧,然後又開始緊張編碼……

再然後……

對玩家負責的心態呢?就算不為玩家負責,身為一個程式設計師,對自己負責的心態呢?身為一個程式設計師,軟體工程強調設計的原則呢?

……歸根結底,技術的強大解決不了意識的落後,莫說定遠鎮遠,就算是來條俾斯麥也沒用,因為——

幾乎沒有什麼戰略錯誤能用戰術去修正