分析敏捷遊戲開發很困難的4個原因

Facebook Fanpage

       敏捷遊戲開發很困難

  我花了數周時間寫了一篇關於遊戲敏捷開發為何比其他軟體更困難的博文。我搜索了一些基本原因,例如遊戲是藝術作品,或者遊戲具有娛樂性,或者遊戲更難測試,或者任何關於其獨特天性令遊戲開發不同于其他軟體發展的原因。

  我還是找不到一個合理的解釋。相反,我想出了一些依情況而定,紮根于商業模式和開發環境的原因。遺憾的是,這正是我們所處的情況;所幸的是,我們可以改變它。

  敏捷遊戲開發很棘手的4個原因

  第一:基於盒裝遊戲的瘋狂商業模式。連續數年開發一款遊戲,然後推廣、發售、獲利,如此反復。加班加點是家常便飯,破產情況也時有發生。每年越來越少的遊戲在爭取更大的市場份額,開發預算也攀升至成百上千萬美元,以便維持這一模式。這真是太瘋狂了,所以那些更為理智的開發方法,例如基於敏捷原理的方法就無法興盛了。通常它們甚至難以立足。不要低估這個問題的深度。我們已經有了一代只知道這種模式的高管和行銷人員(以及開發者),試圖向他們解釋你究竟有多需要發佈的靈活性和反覆運算性,以且在測試中進行開發,無異于對牛彈琴。

  第二:我們將Scrum等同于敏捷方法。敏捷方法包括一系列原則,但我們已經將這些原則等同于一系列(有限的)工具:Scrum專案管理方法(在之前的例子中你可以用Lean和Six Sigma取而代之,這並非遊戲獨有的現象)。如果你試圖向一個美術團隊實施Scrum方法,你就可以看到有多悲劇了。我們不是選擇敏捷或Lean原則並提問「還有什麼看重這些原則的好方法嗎?」,而是制定了一些Scrum形式。我見過許多人因Scrum方法失敗而鄙視敏捷方法,這真令人遺憾。像Scrum一樣,我還看到一些毫無靈氣的看板法(Kanban)執行方式(因為它不支援看板法的原則,例如限制工作和進程,管理流,以及理解約束條件)。

  第三:遊戲開發過晚引進敏捷方法。商業和消費者應用、網站等軟體已經有15年應用敏捷方法的歷史。雖然遊戲中已經出現「鬆馳的Scrum方法」,這也是最近才出現的情況,再加上在這個所謂的「敏捷」工廠的多年開發迴圈,行業還沒有足夠支援敏捷方法的經驗和反思。除此之外,敏捷方法現在正處於成熟階段,並且正被專案管理所挪用,所以在方法領域很難創新獲得替代類似于eXtreme Programming這種運用於遊戲開發的方法。

  第四個原因很有趣:遊戲續作並非反覆運算產品。現在因發佈一款遊戲而負債累累,之後就棄之不顧並因續作而重寫原代碼的情況極為普遍。這種方法之所以可行是因為續作通常更具分裂性而非創新性,所以具有更多重寫的可能。這一點我們可以想想從1993年至2006年,微軟Office UI幾乎保持原樣的情況。隨著現在的遊戲進入了一個鬆散定義的「軟體即服務」模式,我們的開發重心也應該有所變化。我們應該在相同的代碼庫上進行月複一月的反覆運算,並推動專案進展。這是我們必須開發的一系列新技能。

  這裡有一系列更小且較不重要,但仍然需要指出的注意情況:

  *遊戲開發尚未接受開源方式,並且它是在Windows平臺完成。我所遇到的許多開發者和高管不信任OSS(開源軟體),並且多數遊戲開發是在Windows平臺展開。敏捷方法深深紮根于OSS和Linux,所以除了兩個社區間的文化差異(這一點不可低估),Windows平臺的遊戲開發者和Linux平臺上的敏捷開發宣導者之間缺乏互動。

  *遊戲開發重複工作。許多出色的開源中介軟體已經讓非遊戲開發者佔據上風,關注自己的核心產品即可。如果你得開發自己的產品和網路伺服器,你就不僅僅會遭遇因分散關注點而產生的開發成本。遊戲開發傳統上對中介軟體的使用並不充分,並且經常白費力氣做重複工作。這通常是由於開發者希望最大化運行表現的心理,以及荒唐的截目上日期和商業模式所致。有了更多的硬體,我想這種情況會發生變化,我們也將看到諸如HTTP等東西而非定制RPC棧使用於用戶端/伺服器之間。

  敏捷遊戲開發並不麻煩的理由

  最後,這裡還有一系列我考慮過並否決的爭論,其中包括:

  *遊戲是藝術,而藝術無法像其他軟體一樣進行反覆運算。

  *遊戲需要太多「基礎設施」令一切具有可玩性。

  *遊戲想讓使用者花時間而非節省時間。

  *遊戲是幾乎不可能,或者至少是難以測試的東西。

  *難以分配多功能用戶端。

  *頻繁的發佈會讓傳統上具有大量內容的遊戲令人困惑。

  行動號召

  這些問題都有相應的解決方案,但它需要向敏捷原則的核心,甚至是更為基礎的Lean原則取經。遊戲開發所需要的是一系列更適合我們的技術問題,履行相同原則,並且能夠修復,以及同現有的敏捷做法和方法匹配的一系列新做法和工具。我們將在未來博文中探索這些話題或理念。

Comments are closed.