[翻譯]如何成為更好的遊戲企劃/How to be a Better Game Designer

原文連結

作者：Phil O’Connor(已獲得原作者同意翻譯並公開)

“不論你正在做的是哪一種遊戲，企劃的領導能力才是決定成功或失敗的關鍵”，遊戲企劃顧問Phil O’Connor說。他曾經參與過極地戰嚎3(Far Cry 3)和閃擊點行動2(Operation Flashpoint 2)。以下是一些他的實用建議，可以幫助你成為一個更好的遊戲主企劃。

“好的判斷來自於經驗，而經驗來自於壞的判斷” - Rita Mae Brown, Alma Mater

幾年前我寫了一篇文章《如何雇用好的遊戲企劃/How to Hire Good Game Designers》，很榮幸Gamasutra刊登出來了。這篇文章所獲得的正面回應令人驚奇而且鼓舞人心，所以在此我再提供一些其他的建議，這次主要是提供給與我一樣在企劃這一行的朋友們。

這不是一篇教你遊戲企劃技術(Game Design Techniques，譯註：大致上是如何規劃好玩的遊戲玩法之類的技術)的文章，因為企劃技術這個主題太廣，每個企劃又有各自不同的領域，一篇文章可能很難真正搔到癢處。此外，我覺得有趣的東西你不一定覺得有趣，每個人都喜歡不同的事物，而且做為一個好的遊戲企劃，你應該做你自己。只嘗試別人的點子(或公式)其實很難成功。我想，對於遊戲企劃技術的建議是：做你所知道的事，跟隨你的直覺。

這篇文章真正的重點是：如何在開發團隊中成為一個有影響力的主企劃。這只是一篇我個人在這些年觀察所記錄下的列表。這不是一篇嚴謹的聲明，也不是每個人都應該達到的標準；這只是我這些年學到的經驗。你可以用它們，或是忽略全部或其中一部份，忘記它們或分享它們，都隨便你。

我生命中大部份的時間都在設計遊戲，其中16年都在遊戲產業。我從來不覺得設計遊戲本身很困難。我的意思是，想一個遊戲點子或概念，是最有趣的部份，我覺得也是最簡單的部份。在我的經驗中，困難的部份是如何在開發團隊中工作，尤其是與不同專業的開發人員合作。

作為一個企劃，你不是在一個封閉狀態中工作。你所做的每件事都會影響團隊中其他人的工作，所以了解這些影響並且成為這方面的專家，將是實現成功企劃的關鍵。關於這個主題，這篇文章就是我在娛樂軟體產業工作了十幾年所得到的結論中選出的一些重點。

不論你正在做的是哪一種遊戲，企劃的領導能力才是決定成功或失敗的關鍵。每一間遊戲公司都有自己一套方法去管理遊戲設計工作，但以下的建議應該可以用在大部份的情況裡。

成為一個有影響力的企劃之關鍵在於你要了解你就是所有工作流程裡的中心，影響著所有其他專業的開發成員。企劃的決定影響著美術、聲音、技術、開發計畫、預算、行銷等等。假設你已經有了好的遊戲設計直覺、新鮮的點子、以及創作的能力，主企劃的成功關鍵就是，首先你要了解你的工作在團隊中有著比較高的視野。

首先你該想到的是，你必須尊重、或是謙虛，就像Kim Swift最近寫的一些文章中所提到的。你的職位有著非常巨大的權力，也非常敏感；你將對專案的成敗有著最主要的影響，不論你在團隊中的職權有多少。

而且就算你有這種職權，這種職權也應該非常少動用。請尊重專案中其他專業和他們的所扮演的角色。他們的工作不是執行你的想法；你應該與他們一起工作，並且創造一些有趣的東西。你應該為他們工作，如同他們為你工作一樣。那種自大威風的企劃，只知道用口頭講講丟出他們模糊的”願景”，或是給一大堆文件就希望團隊成員可以實現非常具體的遊戲性，這種人一定會讓團隊失敗的。

一旦團隊失去了對你的尊重，接下來就是抗拒—雖然並不一定很明顯。團隊成員如果不像是伙伴，就會質疑你所有的決策，並且在他們開始執行工作後，長期對你在遊戲性上的選擇感到悲觀，而且通常在整個專案中不想好好合作。這種氣氛最後將會毀掉這遊戲的一切；開發工作拖延、有潛在價值的功能被砍掉，因為超出預算，然後最後就是最慘的事：不斷的爆肝加班…

這不代表企劃要為了專案失敗的所有因素負責，專案可能因為很多不同的原因而失敗，但是你身為企劃的核心角色，就是會影響每一個團隊中很細微的關係，所以一定要注意這種情況，要不斷的行動來獲得團隊的尊重和信任，而且要長期持續進行。你要如何獲得團隊的尊重？以下有幾個想法：

隨時都要準備充足

不論何時你在跟其他的專業成員討論工作執行事項時，你都要確定你已經準備好最新的訊息、最新的文件、還有依據遊戲設計所想到的一些解決方案。開發團隊不會喜歡幫你做你應該做的工作；如果他們問你關於某某功能應該如何運作，你不應該把問題丟回去給他們叫他們自己去想。你應該有一個答案，或是你應該依據他們提供的資訊想出一個答案。

你要作決定

美術/動畫人員，工程師和聲音設計人員通常依照詳細的時程表和預算工作。他們必須有一個可預期的速度來生產遊戲所需的成果，並且定期更新他們的工作進度。對他們來說最可怕的就是當他們需要的時候沒有決定，或是只有一個模糊的決定。

在跟團隊討論遊戲內容需求時，企劃必須提供最確實的資訊。你提供的企劃文件不可能提供所有必要的細節讓團隊成員可以完全獨自工作。你必須解釋你的設計給他們聽，如果因為技術的問題或是製作相關的限制，你就要修改你的文件，然後給一個最終版本，並且包含所有必要的確定細節。

如果此時你必須做決定，那就決定它，記錄起來(用email)，然後就以此為準。不會有人期待你隨時都是對的，甚至有所有的答案，但是他們都會期待你做出設計的決定。如果你無法決定，你就使專案產生不確定性。冒險做出錯誤決定比起完全不做決定要好。你會做出錯誤的決定，所有企劃都會，所以這就帶我們來到下一條…

不要擔心犯錯

有些你覺得很酷的東西可能不會在最後版本出現，這就是遊戲開發的一部份。不要擔心你的點子沒辦法在最後完成；你應該擔心的是遊戲整體。有時候你的點子失敗的原因並不是因為這個點子不夠好。

有可能是因為超出了專案範疇，或是因為一些技術問題而做不出來，或因為其他功能影響等等…千萬不要因為你寶貴的點子在測試的時候被拿掉而傷心；遊戲的創造總是反覆進行的過程，你只有在真正把遊戲原型做出來才能證實這個點子是不是真的有用。在此之前，它就只是一個理論，只是基於你的設計直覺。說到理論…

文件無法取代所有的溝通

遊戲企劃文件不是做出一個超棒遊戲的藍圖，它是一連串理想中的遊戲性選擇，包含理論上有趣的目標。它在開發過程裡會不斷的修改，新的資訊會快速地改變這份文件。

這絕不是說寫文件沒意義；就算它常常被修改，你依然必須有一個起點，第一個版本的企劃文件是這個專案最關鍵的，它描述了整體的願景和策略。然而，許多人會有不同的解讀，同一個名詞可能在團隊成員中有不同的解釋。工程師可能需要更多資訊才能了解對於動畫師完全不需解釋就能了解的東西。

企劃文件是你跟其他團隊成員合作的起點；它不是你工作的最後成果。請確保當你給出一份企劃文件時，你要與團隊相關的部門主管和實際製作這些項目的成員一起全部看過一次。對，這就代表你必須在他們開始製作前，安排一個會議，然後解釋過所有的細節。

如果會中每個人都事先看過這份文件將會很有幫助。會議中你可能會聽到許多令人慌張的問題，包含很多你以為在文件裡根本就是超清楚的東西；但這很正常，事實上這才健康！

這代表你對於某些人來說不夠精確，或是一些在之前的討論中就根深蒂固的假設。這就是這個會議的目的，可以把這些問題弄清楚，然後讓每個人都有共識，了解這個設計到底想要做成什麼樣子。

這個會議也讓你可以詢問開發團隊實際要怎麼執行工作。這個會議的結果應該是把問題釐清，並且會將文件做些小修改，你要盡快地把這些修改整合到你的文件裡，然後更新給所有與會的人，一定要盡快在會議結束後就寄出—人的記憶消退得很快。

這個步驟讓這份文件從初步的草稿變成了第一版，然後現在才算正式開始製作。把整份文件討論過一次，可以減輕你許多的痛苦，並且還可以讓團隊把你的設計具體化，並且加入他們的想法。你會想要這件事發生的，相信我。最好的遊戲都來自於這種合作。你身為企劃必須有足夠的自信去…

徵求意見，並且把其他人的意見攤開檢視

隨時開放並且願意了解團隊成員是否有更好的意見，特別是在設計人員以外的成員。這不代表這是用共識決來做設計，也不是你應該要讓所有團隊成員舉行一個超大型的腦力激盪—這只會讓結果變成一團糟，而且你會看到許多不確定與懸而未決的狀況。

你才是企劃，你拿薪水來設計遊戲。這是你的責任，但是並不是所有想法都要從你的頭腦裡出來；事實上，最好的遊戲都是要整合整個團隊最好的意見。如果你適當地管理這個流程，你可以保持遊戲設計緊密結合每個人的好想法，你將會有更好的遊戲DNA。

如果你的流程太狹隘孤立，不接受外界的意見，你的設計就會變成像近親結婚生出的小孩。它可能會看起來健康及完整，但最後的版本卻會走樣，讓你的遊戲癱瘓的缺點將開始顯現。另一種極端是，如果你的設計是共識決定，你的遊戲會變成科學怪人，因為它變成每個人各自喜歡遊戲的特點的集合，然後強迫裝在一起，非常的痛苦而且不自然，所以這也不可行。

要管理保持這個平衡點需要自信與經驗，但是如果你在設計你熟知的點子(對比於別人覺得有趣的點子)，你會比較容易掌控這條鋼索。這真的是一條鋼索，因為開放讓別人的點子進來有點困難，很可能會因為你的自信不足，然後你就會看到太多別人建議的東西改變了你的想法。

如果你了解你想達成什麼目標，你很快地就可以建立在團隊中的自信，去解釋你的決定，並且讓他們看到你為什麼要做出這些決定。記得在企劃以外的團隊成員無法花他們所有的時間去想設計的問題，所以他們無法看到身為企劃可以看到的遊戲整體。對他們來說，看到一個單一的特色，很容易就會想到一個”更好”的點子，但並無法與整個遊戲連貫在一起。

這對你來說是個機會，而不是對你的想法的挑戰。這可以讓他們稍稍了解遊戲性的整體有多麼盤根錯節，而你可以有多少著力點可以了解它。你無法對所有在開發過程中跑出的的問題都有答案，這OK的，但你心裡應該有一些想法和選擇。

這個過程應該是非正式的。所有人應該都可以隨時自由的向企劃團隊提出想法，但不需強求。讓他們了解你很願意聽他們的點子，而他們不用以為他在挑戰你的工作。請開放並友善地讓大家分享設計想法，這會讓你的工作會變得更輕鬆。要好好管理這個過程，你必須要…

對你自己的點子保持客觀

因為你的設計並不表示你有所有在遊戲中最好的點子，你將需要很多幫助，而如果你把其他人都擋在這個過程的門外，你將會損失太多資源：整個團隊累積的腦力！為了培養整個團隊的合作關係，你必須學會馴服你的自我。你必須誠實面對自己與其他人的點子。

身為企劃，你很容易變得開始保護自己的點子，當你有所有的經驗以及工作職權，但某些不太相關的部門的人提出一個其實比你選擇的更好的點子。你首先必須誠實地面對自己，承認這是一個好的點子，然後對其他的團隊成員表達你是否覺得這對遊戲的整體來說更適合。

這並不會讓他們不再尊重你；相對地，這將會讓他們更信任你的決定，因為他們可以看到你很客觀，而且放下自尊。講出來也很重要—公開地稱讚並且運用這些點子是很重要的，你將會獲得團隊的尊敬。

如果你用了某個人的點子，然後偷偷的放到設計裡，你只會得到鄙視，有兩個因素，第一是因為你沒有誠實地承認你錯了，而第二是因為你把別人的點子據為己有。就算這不是真的，而你也沒有想這麼做，你也無法很快地獲得團隊的尊重。

你要能誠實的評估設計想法，並且註明著作者，這是成為好的企劃的關鍵；你永遠不可能做百分之百的決定，又百分之百的正確，所以，聽聽團隊在說什麼！所有團隊的成員都應該客觀地重視…

尊重商業

遊戲開發會變得這麼複雜，是因為要把商業和娛樂結合起來是非常不容易的。有些娛樂產業，這種結合經歷了幾十年，已經可以非常成熟的管理這種關係。即使這樣，電影產業還是有很多巨大的失敗，就算電影工作已經經歷了一個世紀的改善都會這樣。

遊戲開發也不會這麼快轉變，技術因素是其中之一，還有商業模式和市場喜好的變化；最主要的問題是來自於商業和遊戲玩家之間難以平衡的關係。

身為主企劃，透過了解你的專案的基礎，也就是商業上的狀況，你可以幫助維持這種平衡。這可能是你最重要的技能，可以讓你成為一個有效率的主企劃。這不代表你需要變成商業管理團隊中的一員；這只代表你應該知道你身在何處—也就是你的專案背後的戰略。

好的戰術家了解戰略和後勤層面才是優勢的關鍵。用開發者的語言來說，你應該可以設計出符合預算的遊戲，符合技術的範疇，以及專案發表的時程計畫。這需要很高的技巧；我看過一些企劃變成更像市場團隊而非開發團隊之一員，結果卻又變成太早就重視銷售的策略。

不要試著去做高層管理者該做的工作，但是其實你應該知道他們的計畫、預算，並且讓他們知道你也了解這些事。他們需要知道你的客觀如同你的熱情一樣。這會讓你可以知道你的遊戲內容是符合專案的範疇的，不論是50萬、5百萬、或5千萬的遊戲。

如何與不同專業的人合作

本文最後一部份的建議，是一些在我經驗中學到的與不同專業的成員合作的方法。我發現這些方法可以幫助我在開發中與各種不同”文化”的人建立良好的關係，學會從他們的角度來看這些工作，取得他們的信任及專業上的尊重。

與程式設計人員合作

當你與程式人員合作時，一定要記得他們需要用非常精確且完整的用語。不論你想到什麼內容要做，他們都要拆解到最細微的細節才能實現，當你描述出這些內容之後，他們就必須把自己埋在你的設計裡面才能工作。

在與程式人員討論實作的時候，你一定要盡可能精準。如果你可以提供數學公式會非常好。至少一定要提供所有內容需要的功能列表，列出所有機制和系統的明確細節。

條列式的訊息是這種文件最佳的格式。程式人員不喜歡從那種一大段流水帳，像是背景故事的細節、角色描述之類的文章裡面篩選他們想要的訊息。提供功能圖表，失敗和極限值的狀況處理，做不出來時可選擇的備案等等—只要他們提出需要就盡量提供。

有些程式團隊希望直接跟你一起參與設計，這當然很好！對於遊戲性的目標可以建立更多互相的了解，然後可以依他們的需求討論所有的細節。隨時與程式主管溝通，提供程式人員工作時所需的東西。千萬不要只是心情好就開始公開你的文件；跟程式主管取得一份清單，列出可以滿足程式人員工作流程中需要的東西。如果你可以精準地在他們需要的時間，提供他們需要的訊息，你們就可以合作無間了。

程式人員需要知道你提供的訊息是跟他們目前的工作直接相關的；他們不會想要在一大堆文件裡面找尋他們想要的訊息。當他們需要的時候為他們找到需要的文件，以及他們需要的那種細節程度。如果某個功能因為和其他部份相關，讓你現在無法列出細節，那你可以討論這種相關性，並且承諾會再進行相關的計畫。

這代表你必須寫2種不同細節程度的文件：整體程度的文件，可以提供整體的願景，以及整個團隊執行的範疇說明；另一種是非常細節的企劃文件，盡可能的直接與精確的描述內容與遊戲機制。程式主管可能會有一份文件格式的參考資料；盡量跟他們討論，了解什麼才是他們最需要的。

與美術設計人員合作

美術人員、建模人員、動畫人員要處理美感方面的工作，以及產生完整的遊戲內容。身為企劃最重要的部份是不要干涉他們的專業領域—美感，或者簡單說就是藝術。

在檢視美術的內容或討論美術方向時，你不可以變成一個美術人員。一定要保持你身為企劃的身份，讓美術人員決定藝術層面的問題。如果他們徵求你在美感方面的意見，你可以提供你個人各方面的參考意見—但你要知道你如果有強烈的美術評論，美術人員就會不想溝通了。如果你有美術方面的訓練，非常好，要讓他們知道你的意見有些美術的基礎，但是不要變成他們的美術指導或是創意總監。

如果你想要美術參與設計的流程，詢問他們有什麼不同的選擇或是參考資料，並且了解他們的成果是否符合遊戲需求。你會想要培養他們的美感敏銳度，讓他們可以產出更好的遊戲美術成果。如果你只是以自己個人的想法批評美術的選擇，而不是客觀上對遊戲更好的選擇，那麼你只是在開發流程中關上了溝通的大門。

當你跟美術提出美術內容需求時，要先確定你已經在他們開始工作前，就列出了在風格上必要與不可以出現的東西。在他們已經做出一個角色模型之後，才對他們說你的遊戲並不是蒸氣龐克風格的話，這絕對讓你站不住腳。一定要清楚的表示你的遊戲”不是”什麼樣的風格，這跟說明你的遊戲”是”什麼風格一樣重要。

有些美術團隊需要你提供美術相關元件最精準，細節的規劃；而有些團隊想要自己去解讀從企劃產生的美術需求。你一定要確認他們想要的是什麼方式。如果他們需要細節，那就給他們細節。如果他們想要自己去解讀美術需求來製作美術內容，那麼就照著作，並且可以利用他們這方面的創意，但是當然還是同時要注意不可以超出企劃的範疇。

動畫人員(Animators/譯註：從本文的描述看起來，這裡的動畫人員指的是製作角色動作的專業人員)需要特別提出來說明。你的遊戲需要多大成份的動畫，這對你與他們的關係來說很重要。動畫人員對於最後畫面的呈現和最後調整優化的階段來說有著最大的影響。動畫過於精緻很可能會造成超過記憶體空間，但如果太簡略，你的遊戲在畫面上又會缺少競爭力。你必須深入了解你和動畫團隊之間的需求，才能找到這兩者之間的平衡點。

你的企劃最低的需求是什麼？什麼是那種”如果有就太好了”但可能會讓你多花錢的加分效果？這兩者對你來說一定很困難，你必須一直努力去弄清楚。在整個專案開發期間，跟動畫人員保持深入的合作關係，可以幫助你維持這種平衡點。你必須從高點看待動畫方面的規劃，確定企劃和動畫人員有共識，並且依據動畫人員的需求提供明確的需求列表。確定動畫人員和遊戲系統的企劃人員是在同一個標準下工作，確定他們都了解什麼是可能會多花錢的加分視覺效果。

與聲音設計人員合作

聲音對於遊戲體驗來說有著強烈的心理影響(就跟視覺效果一樣)。我會上網去找我大約20年前玩過的遊戲的原聲帶，因為它們讓我有一種鄉愁，讓我回想玩這遊戲時的美好回憶。聲音含有非常原始的意念，因為它是建立情感記憶的關鍵角色。

你與聲音設計人員之間的關係，應該是你們都能了解遊戲裡應該建立什麼樣的情緒。你應該先告訴他們你的設計，然後請他們提出什麼樣的音樂和音效可以符合這種感覺。就好像在幫一部影片配樂一樣的重要。

表達你想要的感覺最好的方式是用影片和聲音檔。當你決定出你想創造的氣氛，其他的工作應該就相對容易了。如果你提供的是對話台詞，或甚至是直接指導錄音，你要確定你可以保持開放接受過程中隨時的修正。有經驗的聲音設計人員知道麼聲音才聽起來是對的；不要抗拒你寫的台詞被聲音設計人員或配音人員改掉，因為他們可能有不同的詮譯方式。有些在紙上看起來很正確的文字，講出來就變得很奇怪。就像對待其他的專業人員一樣，你應該非常希望參考這些有經驗的專業人員提供的創意，讓你的東西更好。

與專案管理團隊合作

專案管理團隊(譯註：Production Team在這裡指的是製作人與專案管理相關的人員，在台灣比較少這種團隊，多半是一個製作人就帶領一個專案)是在開發團隊與高層管理者之間的一個微妙角色。對兩邊的溝通都需要很有技巧，而且壓力也很大。

一個好的專案管理團隊應該把自己的角色偏向開發團隊多一點，而偏向高層管理者少一點。身為企劃，你可以讓他們參與你的企劃檢討、工作分配會議、甚至有時候參與企劃團隊討論，讓他們覺得是開發團隊中的一份子。有時候你可能會擔心製作人會不會干涉企劃的流程，但是好的製作人不會把他們自己當成是企劃，他們會把該是企劃負責的工作讓企劃來做。

他們知道得愈多，就愈能幫助你。定期提供資訊，讓他們能掌握整體的狀況。如果他們無法有一個人來參與開發會議，最好是定期的把主要的開發會議紀錄公開寄給專案管理團隊。

這樣可以讓他們反映團隊的目標和方向給高層管理者，這樣可以更加透明，並且用高層管理者了解的方式去表示。

當高層管理者可以更清楚地看到開發團隊發生了什麼事，他們就比較不會給專案管理團隊壓力，也就是說對開發團隊的壓力也會減少。製作人是你的上司，但比較像是合作的關係，而非單純的上司對下屬的關係。製作人是你的同盟；他們可以平息不同團隊之間的衝突，協助溝通，做出對專案較好的決定，並且平息各種謠言。

我來分享一個可能完全不相關的軼事，但是我覺得這個故事描述了一個好的製作人的樣子：

米高肯恩(Michael Caine, 1933~)(譯註：就是《蝙蝠俠：黑暗騎士》系列裡的忠僕阿福)，我最愛的演員之一，在他最近一次接受訪談中講了一個小故事。當他在拍攝《戰血染征袍》(Zulu, 1964)時，這也是他的成名之作，他當時非常的緊張，不確定他是否能飾演那個英國軍官。他決定要看起來更權威，所以他在畫面中都把自己的雙手緊握在背後。

不久之後就聽到其他的演員有些耳語，在抱怨他的表演，像是「他不知道手該放在哪」之類的。肯恩變得更緊張了，他跑去找他的製片(譯註：在電影圈Producer稱之為製片)，問他是不是會因為這種事被開除。當他問製片關於這些抱怨時，他得到的回應是(這裡已經把原始的對話變得比較文雅一點了)：「喂，你沒有從我這裡聽到任何事對吧？現在趕快回去演戲！」。當他知道製作就是所有人的老板之後，他開始變得有自信，投注所有的精力在他的表演上，後來也因此開啟了他一生的演藝生涯。

與其他的企劃合作

與其他的企劃合作可能是最困難的部份。為什麼？很簡單：企劃的意見最多。他們會有很多強烈的想法，會想硬是放到遊戲裡面。他們對所有事情都會有想法，而要讓這些意見很多很廣的一群人把想法實現其實很有難度！你要提醒你自己，他們跟你一樣有熱情，有著和你一樣對遊戲的愛。你和他們在同一陣線。

不論你個人的感覺是什麼，不要讓這些變成人身攻擊。這表示你將必須和所有企劃人員一樣改變和接受別人的意見。如果你真的對某個遊戲性的要素有非常強烈的想法，那就應該盡力爭取，丟出你的想法，讓別人接受你的想法。但是在”樂趣”和”個人喜好”之間有著專業上很大的差距。不要在企劃會議中變成只有”個人喜好”的人。要保持熱情，但是同時也要客觀(我知道我一直在重複這件事，但這真的值得強調)。

不要因為不是你的菜就拒絕別人的想法；還是強調，一定要保持客觀，並且從對遊戲整體的體驗是好的觀點來討論。對，你必須去爭辯—不是那種負面的方式，而是”律師辯論”的方式。你應該要能解釋你選擇和決定這麼做的益處，和其他企劃的意見放在一起測試，然後和團隊一起去評估它們。有經驗的企劃不會去一直爭辯角色的帽子應該要什麼顏色；他們會爭取重要的事，而且用理性的態度、從對遊戲整體最好的角度來爭辯。

討論的階段之後，就是決定的階段。如果團隊可以有共識決定一致的行動，那是最好。如果不是，主企劃就必須決定，並且往下一階段邁進。不論如何，一旦已經決定，就不要再隨便改變決定，不論所有人當初是不是贊同這個決定。有時候企劃必須去想出一些點子，但有時候他們必須跟隨別人的點子。一定要確認所有人都知道爭辯已經結束，然後就是要開始動手作的時間點。

企劃團隊有時候需要一點生出創意的壓力會比較好，但是要管理這種事很不容易。你必須先建立一個清楚的企劃願景，讓每個人都在同樣的基礎上討論各單一內容的選擇。你身為主企劃，必須確定你已經提出了遊戲大致的架構，給所有人一些思考的方向。千萬不要在開始討論「我們要有一幅畫」時，說出「我們要畫一張浪漫主義的田園風光的景色，我們應該放什麼進來？」你必須推動企劃設計的進展，並且在沒有共識的時候進行決策。

另一件需要控管的事是一致性。確定你和你的企劃團隊對所有人說的都是一樣的事。不要讓你的企劃團隊在面對其他部門的時候，才開始自相矛盾；這只會讓你變得像小丑而且會讓開發團隊搞不懂你在幹嘛。如果企劃團隊沒有共識，但可能花太多時間跟團隊裡其他人開會而不是企劃團隊了。

在你跟其他專業的團隊成員開始工作之前，你一定要先確定大家對遊戲內容有共識和互相確認。企劃人員可以在企劃會議時關起門互相爭論，但是開始分配工作準備實作時千萬不要還在爭論。如果你必須下決定，務必確定不要跟以後的決定互相抵觸。沒有人喜歡把已經做好的東西丟掉。如果你的文件裡面自相矛盾，或是模糊曖昧，或是沒有把你想要的結果做適當的描述，這樣的結果就是會讓一些工作損失掉，並且激怒開發團隊。

當大家如火如荼地在開發遊戲內容的時候，要記得確認不在常規Scrum(譯註：Scrum是敏捷軟體開發方法的一種)會議、團隊例會等等中的企劃。有些企劃跟不同的專業團隊工作太久，最後會”融入”他們了—最後你會發現他們變成了Kurtz上校(譯註：虛構人物，出現在柯波拉導演的電影《現代啟示錄》，Kurtz上校原是美軍，越戰中在高棉據地為王)！有時候這也沒關係。你會希望他們擁有一些主導權，但是你必須保持企劃團隊的會議持續進行，你要提醒所有的企劃成員他們是為了遊戲整體最大的利益而服務—他們不是為了某個特殊的”部落”而工作。

最後的一點建議：如果你要給你的企劃一項單獨的遊戲內容或企劃工作，讓他們跟著他們的設計直覺去做吧。假設你的方向已經很明確了，不要一直在他們背後下指導棋；如果你已經決定要交給他們做，讓他們去做決定，並且自己評估會有什麼結果。如果你給他們一項工作，但是事事都要你來決定，其實你根本沒有真正的授權，你只是讓他們走向失敗。

結論

我希望這些事讀起來比較像是「我從錯誤中學到的事」而不是「我是這方面的專家啦！….等等」。這些事都是我個人在開發遊戲時學到的經驗；它們並不是領導企劃走向成功的通用真理。我常說，經驗才是錯誤的真正解藥，但我希望這篇簡短的列表至少有一些是真理。

=============我的感想分隔線==============

老實說這是我第一次因為看到一篇文章很感動而自發性的翻譯文章。

在閱讀本文時回想到在遊戲產業十幾年來的點點滴滴，想到許多自己犯的錯誤以及學到的教訓，以及因為自己的無知或偏見跟其他人產生的衝突...

我不會說要是早點看到這篇文章就好了，畢竟有很多事非得自己經歷過才會懂。但很感謝O’Connor整理的經驗談，本文的確能給在遊戲產業中的企劃們指引一些方向；而且知道是一回事，能不能實際做到又是另一回事，仔細想想我當然是有太多不足，要再好好加油了。

另外我也覺得本文中有某些條文我並不完全認同(例如在台灣很少所謂的"專案管理團隊"，這方面和美國的文化有滿大的不同)，或是覺得寫得不夠詳細(例如企劃文件的寫法)，就如同O’Connor所說，不要把本文當成通用的準則，而是一些經驗談，更希望的是引起大家的思考與交流。當然也有很多是我比較少接觸或運用的想法，有機會會再嘗試看看。

PS1.關於"企劃"與"遊戲設計"之間的確有些微妙的不同，不過這並不是本文的重點，而且其實這兩個名詞也沒有必要去追究詳細的定義，總之我在這裡就是把Game Designer翻譯成遊戲企劃而非"遊戲設計師"，Game Designer Leader翻譯為"主企劃"(在台灣有各種不同的稱呼，例如企劃統籌、主企劃、企劃主任等等)

PS2.因為文中有提到Kurtz上校，我才發現我竟然沒看過現代啟示錄(或是小時候看過但早就忘記，但直昇機放華格納的片段為什麼我印象這麼深)，於是趕快找出來看，才發現Spec Ops The Line的故事架構整個就是向現代啟示錄致敬(甚至連最後還有直昇機放一樣的音樂)。

PS3.我並非專業的譯者，難免有文字不通順或解讀有誤之處，請不吝指教。

PS4. The Witness竟然要出在PS4上啊啊啊...