當前位置:首頁  >  業界新聞  >  《Implosion》首席工程師以「別太敏捷遊戲開發」為題 闡述團隊不斷進化的心路歷程

《Implosion》首席工程師以「別太敏捷遊戲開發」為題 闡述團隊不斷進化的心路歷程

2015-07-25
來源:巴哈

  邀請國內外知名開發者分享自身經驗的「台北遊戲開發者論壇(Taipei Game Developers Forum,簡稱 TGDF)」今(24)日進入最後一天,雷亞遊戲技術長兼共同創辦人 鐘志遠 在本日下午以自身開發《 Implosion 》的經驗為例,透過「別太敏捷遊戲開發」這樣的主題,分享了他一路走來的心得與想法。

 
  • image

 

   鐘志遠 在《 Implosion 》中主要負責的是程式面的工作,這款以科幻題材為背景的 3D 動作 RPG,可是花費了 3 年半的時間才正式完工,遠遠高於一般手機遊戲的研發時程。
  • 《mplosion》主美術 QQ 的小孩也從嬰兒成長到要上幼稚園了

   鐘志遠 坦言一開始本來以為做遊戲只要一點企劃,再加上多一點的程式以及大量的美術就可以搞定了,但實際經歷過後便發現事情其實並不單純。往往企劃趕不上變化,程式寫好了也常常要修正,連帶影響美術量產的格式也需要一改再改,如此一來便導致遊戲發售日期無止盡地往後延後。台大電機系畢業的他,從中了解到開發遊戲與一般的軟體研發非常不同, 鐘志遠 認為遊戲可說是藝術與工程的結合,是一門高深的學問。

 

  • image

  由於經驗的不足,最初開發團隊使用了免費的 Google 表格來追蹤每個成員的工作進度,但由於過程實在太不嚴謹,導致許多成員常常故意「忘記」去填表,導致工作效率低落,每日工作進度與每週工作進度無異,專案推展的進度也總是快不起來。

 

image

 
  而當雷亞遊戲正式成立並開始執行《Cytus》與《 Implosion 》的研發專案後, 鐘志遠 發現隨著專案與團隊的規模愈來愈大,採用舊的方法已經不是一個好的選項,因此便採用了知名的「敏捷開發( Scrum )」作為公司管理專案的方法與系統。
  • image

   Scrum  是一種從 1990 年代開始逐漸引起廣泛關注的一些新型軟體開發方法,是一種應對快速變化的需求所設計出來的管理模型。 Scrum  注重團隊之間的緊密協作、面對面的溝通,以及頻繁交付新的軟體版本等。

 

  在最一開始, 鐘志遠 僅單純依靠書中學來的方法來學習在團隊中使用  Scrum  管理團隊專案的進度,如此一來比起以往,團隊成員終於有了一個專門的時間來好好坐下來討論計畫,也清楚接下來該做些什麼。團隊開始有了清楚的目標去執行,每兩個禮拜也有會成果的 Demo 展示,讓產品經理能夠確實掌握大家的進度。

 

  但事實上,一切並沒有那麼順利,在團隊跑了半年  Scrum  之後,種種問題也開始浮出抬面。

 

  • image

 

  此時 鐘志遠 開始檢討是不是自己對於  Scrum  不夠了解,一定是什麼地方錯了,因此便去報名上了認證課程。並學習了更多以往不知道可以運用的  Scrum  工具回來。雖然部分工具確實幫助了團隊的專案推展,但 鐘志遠 發現也有許多部分,為團隊帶來更多的困擾。

 

  • 貼滿  Scrum  Board 的工作室

  以「Planning Poker」來說,這代表每個成員可以輪流舉排,顯示自己對某項工作所認定的工作量需要多少點數,若是成員間所認為的點數大小差距過大,舊需要說明原因。雖然這項工具的立意看似良好,但實際上要執行卻會碰到許多難題。若以要製作一個可捲動的 UI 文件為例,程式可能會認為要 20 點,但美術會覺得這不是很簡單嗎?應該只要 3 點就好。

  • image

 

   鐘志遠 認為,因為團隊成員彼此之間,對於彼此領域的認知並不熟悉,因此常常會導致各說各話,無法準確溝通的狀況。也因此,Planning Poker 針對每項工作產出的點數往往就像擲骰子一樣,準不準得靠運氣。
 
  一般來說, Scrum  可以藉由各項被量化的數字來估算出一個專案可能需要耗費的時間,如圖下所示。但就如同上述 Planning Poker 的例子,在團隊成員專業領域差異頗大得狀況下,很多時候這些數字無法準確反映現況,也導致專案時間根本無法精算出來。
 
  • image
 
  另外一個例子,是  Scrum  裡面所使用到的「檢討會議(Retrospective)」,好好使用的話可以透過團隊成員來提出改善流程的方法,進而增加團隊效率。但實際實行起來,反而大家都避重就輕,沒辦法直指問題核心。 鐘志遠 認為這可能是華人的民族性使然,導致大家不擅長在檯面上互相檢討。
 
  • image

 

  究竟是什麼原因,導致  Scrum  無法如同書本上所說的套用在雷亞的團隊上?在尋找許多現實中的案例及方法後, 鐘志遠 發現  Scrum  並不是如同刻在石板上的真理,或是設計良好的機械,只要照著說明書去操作,把時間和錢丟進去就能夠生出成果。
 
  • image

  最終 鐘志遠 得到一個理論, Scrum  是一個成熟的敏捷開發團隊典範,但卻不是一個完全照著走就能成功的教戰手冊。團隊學習  Scrum  運作就很像閱讀偉人傳記,從中讀者並無法藉由模仿書中案例來邁向成功人生。 鐘志遠 認為團隊應該要藉由 Scrim 的作法發展出獨特的工作模式,而不是直接拷貝,因為人是獨一無二的,所以人組成的團隊也是獨一無二的。

 
  從這個階段開始, 鐘志遠 便從  Scrum  的守則中取出適合的工具,再經過調整來針對雷亞內部團隊來使用。例如讓團隊成員間彼此分享資訊,互相溝通的每日會議(Daily Meeting),或是讓大家有個共同目標,定下短期目標的 Planning 會議。
 
  • image

 

  • image
 
  在遊戲開發的過程中,製作人當然也會希望檢視開發進度與成果,辛苦工作的成員也會希望自己努力的結晶被看到,因此就有了 Review 檢視會議。
 
  • image

 

  而優秀的製作人看到成果之後,當然也會想要修改、調整,讓遊戲變得更好,這就是遊戲產業人員最害怕看到的「更改部分規格」。這近似打掉重做的過程,常常會導致團隊士氣受挫,為了避免這樣的狀況太常發生,團隊便決定要執行更多次的 Planning 與 Review 會議,其中又盡量不更動內容,這樣的過程便是  Scrum  中常用的衝刺(Sprint)。
 
  • image

 

   鐘志遠 認為,假設一個團隊沒有經過反覆試錯的過程,便直接採用上述的作法,便容易有水土不服的狀況發生。就像學生不會因為看了勵志讀物,就變成人生勝利組。但管理者常常有這樣的錯覺,一般來說管理者會相信只要採用了一套標準步驟,團隊的效率就會突然一飛沖天。

 

 

  • image

 

  但事實上團隊的每個人都要有這樣的想法,才能持續地提昇效率。若是只有團隊的領導者認同這樣的作法,那就沒有意義。
 
  • image

   鐘志遠 覺得這樣的作法,需要管理職很謹慎的看待,因為團隊中的被管理者,很有可能會與管理者產生距離,像是成員若是沒辦法吐露真心話的話,就會導致即使團隊發生問題也收不到任何回饋的狀況。 鐘志遠 以自身的經驗為例,表示身為產品經理,就算只是一個小小的指責都可能會讓團隊士氣渙散。像是之前曾經有成員提了想法,但卻馬上被他打槍。但後來才發現自己其實沒有考量到企劃、程式等等連帶影響的狀況,導致自己做了錯誤的判斷,讓團隊很有挫折感。

 

 

  • image

    持續慢慢改進方法很重要

  • 每個成員若是都可以觀察、找出問題並提出改變的建議,進而調整團隊。此時若是每個成員也都相信改變的力量,最終便能形成正向的循環,成為一個符合  Scrum  敏捷開發的團隊

   鐘志遠 同時也以動畫《閃電霹靂車》為例,表示人需要的是如同阿斯拉般,可以與主角一起進化的系統,而不是天才也無法完全駕馭的凰呀。

 

  此外為了克服合作以及溝通的問題,然後啟動改進的循環, 鐘志遠 認為建立兩好的團隊文化非常重要,因為遊戲開發大多時候的過程都會需要人與人的互動,文化才是真正能影響人與人之間的東西。而若是要建立成功的文化,則必須讓團隊中的每個成員,都必須對以下兩個問題非常了解,而且具備自我省思的能力。
 
1. 專業沒有被尊重
2. 專業沒有辦法接納來自非專業的看法
 

專業沒有被尊重

 
  以第一點來說,當程式企劃彼此信任不夠,便會給出似是而非的建議。身為專業的人知道這些建議不是那麼好,但當下無法反駁,其中也可能是因為職位差距的問題,但是如此一來便會團隊之間便會產生某些負面的刻版印象,例如「製作人就是喜歡用抄的,程式就是喜歡用舊的,怕麻煩不愛用新引擎」,如此一來便會影響團隊的速度與品質。
 
   鐘志遠 以《 Implosion 》為例,表示遊戲中的裝備可分為普通、進階與卓越三個等級。在遊戲的開發過程中,就曾有人反映最高級的武器應該可以讓主角有著超越超級賽亞人 3 的強度,砍敵人就像砍菜一樣,這樣才合理。
  • image

  雖然說這樣的建議聽起來很合理,但由於遊戲關卡有限,沒有那麼多空間江拿到卓越裝備的角色,在破關的過程中拉回適當的難度。此外由於《Implosion " target="_blank" style="color: rgb(0, 85, 170); text-decoration: none;"> Implosion 》的重點是戰鬥中帶給玩家的挑戰,若是武器設計地太強,後面關卡躺著也可以過的話,就違背遊戲本身的主軸,也會降低遊戲體驗。

 
   鐘志遠 認為尊重專業看起來很簡單,但其實很難。大部分的問題都像冰山,真正浮出抬面被檢視到的不多,只有在做事的人才能發現冰山下面較難被發現的東西。
 
 
  • image

 

  因此 鐘志遠 認為,尊重專業不是了解到「我要尊重」而以,而是要深深地輸入到潛意識中才行。
 

專業沒辦法接納來自非專業的看法

 
 
  以上的影片是《 Implosion 》最早針對 Xbox 平台所打造的版本,雖然畫面不錯,但與廠商交涉的過程不是那麼順利。就在當時,團隊也剛好經歷手機遊戲崛起的時間點,因此製作人便提出想要改成在手機上製作的想法。
 
  但當時擔任主程式的 鐘志遠 認為兩個平台特性相差太多,這樣的作法根本不可行,便強力否決掉這項提議。為了改變 鐘志遠 的成見,團隊中的主美術 QQ 利用手頭上僅有的資源,打造了一個在手機上運行的 Demo,證明即使在手機上也可以呈現不錯的效果,也因此讓 鐘志遠 發現自己下的決定太過武斷,狠狠地被打臉。現在回頭, 鐘志遠 非常感謝有了 QQ 的建議,否則便不會有手機版《 Implosion 》的誕生。
 
 
  以剛才的例子來說, 鐘志遠 認為當初在討論的時候應該好好去分析前因後果,而不是依賴直覺去下決定,這樣容易產生盲點。很多人常常說專業是如何地不被尊重,但其實專業也是有盲點,檢討自己也最困難。
 
  另外一個導致專業無法運作的,則是太過專注會導致專業人員無法接受或了解外來的有效建議,或是無法做出比眼前結果更好的決定。以下圖來解釋的話,若是從起點開始往右,若是只專注在局部,那最多可能只能停留在 A 點,而無法更上層樓至更高的 B 點。

 

  • image

許多人往往都只看見自己跟眼前那一部分

  企劃、美術與程式都有各自想要追求的東西, 鐘志遠 認為這就是所謂的「局部最佳問題」。他認為一款好的遊戲不一定要在每個環節都追求到極致。但當專精不同領域的成員在討論一件事情的時候,彼此之間提出的問題卻可能會激怒對方,衍生出「專業 vs 非專業」的狀況。
 
  這時為了找到平衡點,了解到什麼樣的問題「我」才能夠提出建議? 鐘志遠 認為團隊成員應該要有共識,了解到「當非專業的人發現妳的問題時,並不是因為他們比你厲害,而是因為你正在解決眼前正前方的問題,你把背後留給他們掩護」。有了這樣的信任,團隊才能啟動改進的循環,讓團隊愈來愈好。
 

總結

 
  一個優秀的團隊並不是遵守  Scrum  的教條與規則就好,而是需要可以不停地改進自身運作效率,一切都操之在團隊的手中。
 
  • image

  遊戲開發沒有真理, 鐘志遠 表示只要能讓遊戲變得更好,任何方法他都願意去嘗試。同時他也希望藉由這次的分享,讓更多的台灣團隊在下週為自己的專案所努力的時候,可以思考改進的方法,進而讓台灣遊戲產業更加進步。

 
  • image
  • image
  • image

 

 
 

 

 

Facebook Slider