《螺旋圓舞曲》製作人李印：遊戲開發中如何減少返工？

9月24日-26日，“BIGC 2021北京國際遊戲創新大會”在北京海淀區舉行。會議上，遊戲業內各家著名遊戲廠商、遊戲製作人、遊戲發行平臺負責人等代表就遊戲產業相關話題進行研討。其中，十字星工作室的創意總監、《螺旋圓舞曲》的製作人李印就自身遊戲開發的經驗進行了分享。


本次李印分享的內容主要以圓舞曲系列為例，就遊戲開發者在遊戲開發過程中可能遇到的問題進行了經驗分享。

以下是遊戲陀螺整理的分享實錄（有刪減）：

李印：大家好，我是十字星舞曲系列作品的製作人李印，今天在這裡是希望跟大家分享一些關於遊戲開發過程中更細更通用的技巧，希望能對大家在接下來的遊戲開發中有所幫助。

返工是一個專案裡最大的敵人

事實上，十字星工作室在幾年前還是一個非常小規模的工作室，在做遊戲的時候甚至感覺每一步都如履薄冰，因為資金限制了我們沒辦法返工和拖延，所以在做遊戲的時候規劃是比較謹慎的，或者說是以一個悲觀主義者的態度在做這件事。


當然現在我們工作室已經是一個70多人的團隊了，目前有兩個專案在開發，同時對於女性向遊戲或者換裝類遊戲來說的話，每個月需要更新的文案、美術量都是比較大的。

在這種工作量下，我們的工作狀態卻相對大部分公司來說比較輕鬆，可以說是幾乎完全不加班的狀態。

其實到了這個狀態的時候，我會反思，因為我作為一個製作人，其實我是很有危機感的，在自認為團隊沒有特別優秀和產能正常的情況下，憑什麼能做到幾乎沒有加班的狀態？

這個答案後來是在我跟同行交流的時候得到的，很大原因在於我們真的非常少返工。這個返工包括比如在專案立項上，做到中間一定程度時發現問題，再次把原先規劃好的線砍掉重做；或者是細化到每月更新的內容細節上等等，工期不斷延長。

這和“龜兔賽跑”其實是一個道理，無論你跑的多快，一旦中途停下來或者重新開跑，就極大可能比烏龜跑的要慢。所以儘管在工作時間上加班加點，如果這個時間內做的東西被砍掉，那遊戲的工期就會延長，士氣大打折扣。

還有一個影響因素，就是反覆修改。團隊不斷地做事卻又推到0，換成另外的方向開始做，這個過程會給團隊帶來非常大的壓力，而且會導致過程非常痛苦，失去耐心和目標。

但對於製作人來說，返工的誘惑力無疑是非常大的。因為這個選擇能逃避當前你做的方向，能重新規劃更好的路線，換一個玩法的話或許專案會更加賺錢。但這是一個無限的迴圈，即便重做是一個比堅持原有方向上改下去更容易的選擇，但當做出這個選擇之後，是極大可能在短時間內因難以確定具體方向而失去耐心的。

返工是可以避免的

對我來說，其實返工是可以避免的。以自身的經驗來談，我們很少返工並不是刻意去避免，而是我自己反過來去倒推的一些東西，主要從以下三點來看：


團隊的目標設立

這其實就是決策。決策這方面每個製作人對專案都有充分的看法，以我自身的感受來談的話就是面對現實：基本上你有什麼樣的團隊和什麼樣的資金，你就能做什麼樣的專案。對於我來說，立足現在的遊戲市場來看，如果一個專案在某一個方面沒有做到頂尖，這個專案其實是沒有太大存在的意義了。

當然因為不同方面的方向不同，很多的賽道也會越來越細分，包括市場買量等這些都可以說是頂尖，拿我們自己的團隊舉例，我們是以重敘事重包裝，就是以故事包裝和然後美術的創意性為基礎在堅持做這些事情。

打個比方，我們工具已經做了大概一兩年，之後我們想立項，員工需要我們有更多的方向，最後我們還是選擇了能夠繼承和發揮團隊優勢的。比如我們再繼續做2d的方向，但是不改是不可能的，這其實是個偽命題。

但更多的時候是你改了卻能讓大家感覺到在進步，原因在於我們會去傾向於持續地朝一個固定的方向去改，或是說我們在一直在給團隊灌輸的思想是我們在做同一個方向的事情，只是在不斷的積累的過程。不斷的就是修正自己方向上的能力，因此大家更多的是感覺到自己的越做越好，而不是單純的說我們在不停的先朝一個方向走，然後把一切打到0，然後再朝另一個方向，這樣子的話就是走向迷茫。


創意工作的科學規律

這能理解為創作。我們十字星工作室是一個以故事創意或者說是以創作性為賣點的公司，所以更多的時候對想法、對創作是比較鼓勵的。這也是我們覺得比如說如果我能把這些分享出來，可能大家在做創作的時候會稍微不那麼痛苦的一個點。

這個點更多可以理解為創作不是靈感的爆發，我們討論的更多的是到底這個創作形式是集體的頭腦風暴出來的，還是誰靈光一現就能寫好的？

1. 避免通過單一方案進行決策

其實我的親身經歷來說，我負責的工作很多，同時也和美術團隊、文化團隊對接去梳理他們的創意製作。所以在我的感受是，首先我們要承認創作是一項科學工作，它是有規律可循的。

一旦我們把創作的涵義上升成藝術的話，整個公司的創作流程就會非常混亂。所以一定要把創作當成一個科學的工程的方法去考慮，要相信是有方法論可以指導的。當然，大家對於不同的遊戲，不同的專案，不同的科學領域可能會有不同的的理解，但是無論是什麼領域，都要相信它是科學的，不能以玄學的態度去指導專案，這是對製作人來說的一個思考的基礎。

對於團隊來說的話，就具體的一些訣竅，特別是重大的決定，建議是避免通過單一方案來決策。

反攻裡最常見的一個特別糟糕的處置，就是“一鼓作氣，再而衰，三而竭。”，不論是團隊提交給製作人，亦或是製作人提交給老闆某一個方案、一個創意，如果中途這個方案的創意因為某些問題被否掉了，後來再提交又被否掉，第三次又是一樣結果......這樣的工作方式不管是對於提出方案的人還是老闆來說，都是一種特別差的工作方式。

所以在提創意的時候要儘可能地避免通過這種方式去提，最好的方式是，一口氣提出三個方案，這比連續被打回來三次的痛苦程度小很多。在提出的這三個方案裡，肯定是有一個自己特別滿意的，通過提出三個方案各類優缺點進行對比，才能讓自己認為特別滿意的那個方案的核心優點被放大，這樣的工作方式不僅提高了效率，還條理清晰。


2. 對完成度的理解需要統一

為什麼我經常覺得創意團隊一定是需要一段時間去磨合？因為最簡單的來說，一個創意團隊，比如在我們圓舞曲團隊裡面，我們對每一個服裝或者是每一個角色，然後以及相對應的東西，都有一個製作時候的評級——ABCD。

打個比方，這個東西當前處於工作的某一個狀態，它是設計稿，那麼草稿就是定版，後面現稿之類的每一個種階段都需要規定得非常嚴格。在這個基礎上，當我說這是一個什麼級別的服裝或是什麼狀態的稿件時，所有人都能夠立即達成一個統一的認識。

其實統一的認識是很難的，因為比如說草圖應該進行到什麼方案，或者是比如說一個遊戲的demo，到底是需要做到什麼程度，可能從老闆和團隊有完全不同的理解，而這個理解只能通過時間來磨合，當時我們為了貫徹這種完成度，我們做的其實是比較極端的。

舉個例子，比如說如果一個美術方案，我錯過了在草圖階段的一個毛病之後，它已經進行到下一個階段了，那麼我就作為團隊的管理者就要認栽，因為你錯過了修改的時間，想要反悔的話，你就需要來承擔這個成本，而不是讓團隊承擔。雖然這個方式很死板，但是這也同時讓大家對每個階段的定位都有個共同的認知。

3. 發現問題不一定要立刻修改

在面對意見和問題的方式上，比如在草圖階段，我們主要討論的是造型識別度和重要的元素。在更加細節的階段上，我們需要討論的是細節的安排方式，比如部件拆分之類的細節。

值得注意的是，很多時候你在推進一個方案或者是最簡單的一張圖，甚至一個玩法或者一個專案時，會產生大量的問題，這些問題可能是你自己發現的，也可能是集體反饋的意見。但只要你堅持的整個團隊能夠對我們做到什麼階段達成一個統一認知的話，那麼最大的好處就是大家提的意見能夠針對當前這個階段可以修改的內容來聚焦，而不是在任何時候看見一個東西都有人提出不同的意見，導致大家的注意力很分散，以及整個團隊或者說對解決的問題產生混亂。

這就引申出來的兩個點，很多時候我們發現的問題不一定要立刻修改。比如我們策劃團隊提交的一些方案其實是有問題的，我還是會選擇讓他們去做，即便我認為這可能是有問題的，但是這個問題不是在最初的階段就能夠證明或者是解決的，我反而會讓他們繼續做，無論他們做的好和不好，因為很多問題你一定要讓團隊做過之後，他們自己才能夠發現和理解這個問題，自然而然地選擇返工。

另外一個更重要的點，是當你提出一個想法之後，在想法很初級的階段反覆地推翻，就會導致團隊一直沉澱不下來。相反，在團隊嘗試去執行一個想法的時候，他們沉澱下來的東西可能是我們對當前的專案或者是方向比較迷茫的一個最好的補充。

模組化的開發結構

最後這個點就比較工程化了，也就是拆解專案的資源和模組。

其實專案是工程型施工，我經常覺得自己個包工頭，我們怎麼做才能夠讓這個工程的返工減少是需要思考的問題。我們都知道專案不改是不可能的，世界上沒有真正說不改進就能夠做好的專案，所以說開發工具非常重要。

包括即使在像我們一開始專案只有三個人在做的時候，我們都在先做開發工具，包括遊戲裡所有主要內容的編輯器和遊戲裡所有重要的美術資產的這種資源管理器等。而有這些東西才是你返工的一個基礎，因為你把整個遊戲的開發工具化和模組化也很重要。

作為一個悲觀的製作人，我一向跟別人說的是我的最重要的工作是決定什麼東西不做，做什麼東西只能是團隊的做。在時間空間各種有限的情況下，就像一個正在逃生的宇宙飛船一樣，這樣一個不停地爆破掉自己身上多餘的部件，你才能夠按時逃離大氣層。這個就很殘酷，所以說很多時候我會思考這個東西如果沒掉，會不會影響專案其他的模組的運轉？

所以說整體的專案都要儘量做成可以拆卸，可以重新組裝的模組，但是模組化的重要前提是你要有開發工具，有了開發工具才能把專案中的各種資產規格做到儘量的統一。與此同時，因為一般情況下返工是從策劃層面開始的，產品團隊對產品有不滿，那麼驅動程式團隊、美術團隊便對產品進行迭代，但是這種迭代的時候，如果你有工具的話，很多原來的美術資源、功能和程式碼其實是都可以複用的。這樣一來，只是說策劃團隊在花很少的時間在重組這些資源，相反如果你不做這些，那麼可能之前的所有的資源和設計就會直接就沒有掉。

其次是提高專案的可配置化水平。我們都知道在遊戲實際製作的過程中，一個專案的很多設定，它在程式和策劃管理的交接範圍內，就有一部分是程式的，有一部分是程式自己寫死的，有些部分是策劃要用表格配置的。其實是一個很基礎的設定，但是我會非常鼓勵團隊儘量把所有的東西都做成可配置的。

而這個過程相當於是產品團隊對專案的管理能力和認知程度的增加；其次，也因為它是可配置的，所以說很多調整的模式就會變得更容易，這樣的調整能更容易讓你去接受不同的修改，這是一個正反饋。

相反，如果調整困難的話，有時候你改一些很小的東西，都需要整個團隊進行復雜的溝通，在溝通中產生無數的矛盾，這個是剛才也提到了一個很重要的一點。


以上基本是我想要分享給大家的內容，作為一個創作者，我是特別討厭返工和修改的，特別是對小型團隊來講，時間和金錢都是十分寶貴的。希望我的分享能給創作者規避一些坑，你如果通過前置的思考，能夠避免日後的很多工作的話，這些時間是值得花的。

（BIGC北京國際遊戲創新大會每年9月底在北京舉辦，大會致力於打造遊戲行業經驗分享的平臺，通過製作人、內容、技術、硬體、發行平臺、商業營銷等方向的經驗分享，促進中國遊戲產業健康向上發展。）

來源：遊戲陀螺
原文：https://mp.weixin.qq.com/s/xr5MuGGCq7VrBmkPBcevbA