在設計遊戲時，如何避免陷入具體執行細節中而忽略了整體設計？
有一種說法是，在設計遊戲時具體的執行者和系統的設計者最好分開，以免設計者陷入思維陷阱造成過度設計。誠然，對於大項目的商業遊戲的確會有如此分工，但對於一些小團隊，獨立遊戲開發者來說，就很難做到設計和執行完全分開。那麼，設計者在進行系統設計時，往往容易陷入到「這個系統具體實施起來會有哪些細節需要注意」這樣過分深入的思考中去，而對於整體方案上的把握思考不夠。另外，在設計時設想好的方案，轉換到執行者角色時難免會因為方案的一再修改而出現倦怠、疲勞的情緒。
各位同學在進行小項目或者獨立遊戲的開發時，如果出現以上兩種情況，是如何解決和避免的呢？PS: 「那麼乾脆就多招聘幾個專職策劃」之類的答案恕我無法接受，我更關心的是「如何避免陷入執行細節中，而忽視了整體設計」及「如何避免在兩種角色切換時產生倦怠、疲勞情緒」這兩個問題。
在如何分配精力上，我是吃過大虧的。這幾年創業，總結了一些經驗，同大家分享。
目錄
一.為什麼會有整體設計和執行細節的切換
二.如何避免陷入執行細節中，而忽視了整體設計三.如何避免切換產生疲勞情緒
四.其他心得
- 一.為什麼會有整體設計和執行細節的切換
在大型遊戲項目的策劃部門，是由製作人→主策劃→執行主策劃→高級xx策劃→其他策劃組成，整體設計工作是自上而下逐步開展與傳達，在整體設計與細節執行之間，由執行主策劃or高級xx策劃來負責協調與製作。一般來說，不太會出現某個成員頻繁的在兩種狀態切換的情況。
而在小項目組，如5人以下策劃團隊中，尤其是某些成員能力不足時，這種情況就會大量發生。作為策劃團隊的leader，如果天天沉浸在執行中無法自拔，還要為各個成員的設計擦屁股，就很難投入足夠的精力到更重要的整體設計上去。
- 二.如何避免陷入執行細節中，而忽視了整體設計
個人定位方面
時刻提醒自己，自己的職責是什麼。不扯什麼勿忘遊戲初心之類的P話，直白的說，策劃leader的工作職責就是
a)
確保產品的整體設計方向正確且優秀b)
帶領團隊按時、保質保量將產品完成c)
確保產品能夠達到公司的目標d)
帶領團隊不斷學習、總結經驗教訓，時刻做好準備
這四個職責中，只有第2、3兩點才會牽扯到細節設計，所以一個leader如果全身心的投入到2、3上去，忽視了1和4，一定會為項目埋下極大的風險。
產品設計方面
要從上到下五個層級來考慮遊戲整體，每一個下層都要滿足上層的需求，這樣遊戲才是一個邏輯自洽的整體，而不會是充滿矛盾的集合體。這五層分別是
1、
行業層面：市場環境如何（行業變化，競爭對手等），遊戲行業上下游的關係（發行商、應用商店等），目前發展近況、前景（正版意識崛起、海外發行情況等）等。
2、
用戶層面：目標用戶分析（2次元、SLG愛好者等）、用戶畫像
3、
產品層面：團隊優勢劣勢、遊戲類型，畫面風格（油畫、剪紙、像素等）、遊戲題材（後啟示錄、龍與地下城、劍與魔法等）、遊戲亮點（乾死黃旭東等）
4、
玩法層面：核心玩法（即使只有這個玩法也足以讓用戶玩的樂不思蜀）、整體感受傳達（畫面、劇情與玩法的配合，用於展示給用戶孤獨、男人之間的情誼、背叛等）
5、
細節層面：各項玩法（輔助玩法），細節設計（UI、動畫、交互、攝像機移動、音樂等）
明確了這五個層級，就足以描述清楚一款產品，而其中的前四層，就是策劃leader所要著重考慮的。在初始設計時，一定要大膽假設，小心求證。每一層在設計時，可以任意發散考慮，但最終一定要收回到一點：不會與上面的層級發生矛盾。如果發生矛盾，比如某個題材實在是太過優秀，那就要同步修改產生矛盾的上一層級，從整體重新構思遊戲的設計方案。
這樣帶來的好處就是，第一你所有的工作，一定是在一個穩固的基礎上進行，不會輕易的因為某個人、某句話、某個新聞、甚至是某個程序的問題而隨意拍腦袋推翻前期的工作。第二，你可以輕易的知道自己、團隊中每個人所應該負責的層級，明確知道自己最應該保證的是什麼。
具體執行方面
1、
在每個玩法、每個系統、每個劇情or音樂or美術素材設計時，都先按上面流程梳理一次，要嚴格把關。
2、
如果出現不符合上層設計，就要重新構思是修改下層，還是修改上層。必須時刻確保5層保持一致，絕不能拖延。當每一個矛盾都拖延解決時，用不了一個月，你就會發現自己的項目已經大大偏離了初始的設計軌跡，甚至沒有人能描述出來你們遊戲到底是玩什麼。
3、
定期（如一周或半個月），leader個人要翻過頭來重新從頭考慮一下目前的設計情況，時刻檢查是否偏離了軌道。
4、
1-4條落實到文檔上，重點部分用便簽貼到電腦上，時刻提醒自己。尤其是核心玩法與整體感受傳達這兩點，強烈建議能用一句話精準表達出來，時刻背誦。
整體管理方面
1、
設計初期就與程序、美術溝通，明確團隊的優勢與劣勢，找到最符合團隊風格的技術和美術方案，避免在開發過程中某個重要點上卡住，團隊不斷妥協導致產品定位模糊。
2、
儘早製作Demo，敲定核心玩法與核心體驗。大膽假設，小心求證。一旦敲定，絕不輕易變更。
3、
高頻、定期給團隊講解，讓所有人都明確產品的方向，避免因不同人的理解偏差引起項目搖擺和返工。
4、
在團隊中灌輸每個成員（策劃、美術、程序）都要對產品本身負責，而不是對工作計劃和工作量負責的態度。
5、
強調細節的重要性。一個所有人都關注細節的團隊，會大大減少策劃負責人在低層次的執行細節漏洞上所投入的精力。
6、
培養團隊中自主學習、願意分享的好習慣，尤其是技術和策劃團隊。
- 如何避免切換產生疲勞情緒
1、
最好的方法永遠就是找到高水平的，能幫你執行的策劃、美術和程序。他們可以大大節省你的時間和精力。
2、
強制自己留出最少40%的時間來考慮高層面的東西。做正確的事要重於正確的做事。
3、
盡量降低切換的頻次，想辦法留出大段的時間來做一類事。要麼就全是細節，要麼就都是整體思考，不要一天切換幾次。
4、
當自己做到合理分配精力時，適當慶祝，不斷強化與自我激勵。
- 其他心得
1、
五層模型不是說定好了就不能改，而是必須確保時刻遊戲的整體邏輯是一致且自洽的。我見過太多的大型項目，做了2、3年，玩法推翻了幾遍，到最後沒人能說明白到底是玩什麼，上線後一塌糊塗的事了。一個偏激但精準的產品，遠好於一個混亂的大雜燴。
2、
細節很重要，尤其是對於小而美的產品來講。即使單純的美，或樸素的情感，也足以吸引一部分玩家。
3、
但細節不能決定一切。日本偷襲珍珠港，幹掉再多美國軍艦，也只不過是延緩了自己被美國暴兵干趴的時間而已。當所有人都撲到細節上時，請記住：死扣細節一時爽，產品上線火葬場。
癥狀分析
其實如果你是全棧式的，這種問題特別常見：1，一開始想好了產品想怎麼做，到了詳細設計，比如UI設計的時候開始想想某些功能並不應該這樣，因為UI設計出來可能不好看。2，你細節設計好了，結果開始coding的時候又開始想了，當初這樣設計，實現起來似乎很累，如果我換一個設計，這樣實現起來多好。病理分析
這是一種典型存在的問題，即使在項目合作中也很常見——當面對問題的時候，如果換一個需求相對解決當前需求的問題看起來更加簡單，就會不去思考解決問題，而是想著改變需求，一旦需求改變，可能解決方法就會變得「看起來更簡單」。這個合作中的典型例子就是：策劃設計了一個UI，是技能的UI，需要顯示的是主角的技能，問題來了，技能都在一張表裡面，哪些屬於主角技能呢？正確的做法也是相對複雜的做法是，為了UI新設立一個表，表所描述的是那些技能出現在這個UI，以及他們的出現條件。為什麼這麼做是正確的？因為這樣的依賴關係是順暢的，沒有任何耦合。但是這時候程序可能為了偷懶， 提出一個想法——在技能表加一列哪些是需要顯示在這個UI的技能，並且再追加一列就是顯示的條件……「解決」了一個看起來麻煩的問題，但帶來了一個致命的問題——依賴關係混沌。治療方式
這裡只是一些偏方，是我自己14年遊戲開發中積累的一些小經驗，也許並不適合於所有人：1，養成一個習慣，把要做的功能核心設計目的和要解決的問題清楚地記錄下來。當你在遇到設計或者實現困難的時候，拿出來看一看，究竟現在的設計要解決的是什麼問題，服務的是什麼環境，然後再想一想現在想要做出的「改動」，是否還能符合這個目的。如果不符合就告訴自己Cancel掉現在的想法，因為他的大方向就是錯誤的。2，放鬆一下，干點別的，回頭重新來過。獨立遊戲和商業遊戲的區別是什麼？我在GameRes提出過（【深入思考】獨立遊戲路在何方？），既然是獨立遊戲，時間上都沒有壓力，你可以嘗試一小段時間（幾個小時到幾天，這因人而異）不去碰這個東西，然後過幾天，複習一下這個需求和設計目的，並且重新設計手上這塊。當然這並不一定是只有獨立團隊可以這麼做，如我們一樣的歐式思路的團隊也可以這樣做——休息是為了走更遠的路。3，設計完之後別忘校驗，看看是否還符合當初的期望。這個很可能會忘記，或者又一次懶惰，但是你真的想做好產品，也是一定要做的，在完成設計和實現功能之後，再回頭看看是否還符合初衷，是否和其他塊能夠貼合的起來，如果不行，打翻重來。至於高贊貼說的什麼多招點人之類的，我就笑笑，如同上面我的分析——改變了需求而非解決了問題，而這樣做法更有甚者——「用一個詛咒換來另一個詛咒」，企業管理並不是那麼簡單的事情，人並不是越多就越好的，所以解決問題前，先思考清楚——方案解決了什麼（目的）和方案要解決什麼（問題是什麼，問題就是你要努力去克服的東西），當把問題列出來的時候，就已經解決一半了。我正好正處於這個階段。可以分享一下。
我採用了最為笨重的方法，從上往下設計。即先從表象需求設計到完整後，封閉設計。在此期間程序可以認為是不動工的。單個的系統執行方案在討論時，程序自己備份執行想法，設計組暫時不過問。在設計組確定了第一版本框架及部分內容後，看情況繼續往後粗略延伸版本。完成後與程序討論，程序思考後提出執行方案，解釋 程序可擴展性，設計 討論 程序的可閉合性。確立後，開始執行。設計 填寫內容。這種方式呢，問題在於，時間成本會擴大。人數如果特別少，時間消耗更多。對人員素質要求比較全面，需要程序
本身遊戲的經驗要大，要求
設計 對程序執行要有一定的理解能力，並且程序邏輯要清晰。基本是可以認為是需要一些真正有經驗的遊戲製作團隊。而且就算在這種情況
也是非常消耗時間的。就不如抄。
說的都沒錯，其實就是所有細節都是為項目目標服務的
就好比說目標是樹榦，計劃是枝叉，執行是綠葉，細節是紅花。
不論你如何考慮，只要目標方向正確，那麼才輪得到合理計劃來蓬勃整顆大樹，樹榦是可以通過迭代變粗的，但是終歸得是直的，綠葉紅花是可以逐漸繁茂的，但是終究要長在枝杈上。
首先工作就是工作，計劃就是計劃，不論你要增加多少細節，都是可記錄 可迭代 和可動態添加的。
當細節工作列出後，就可以對工作進行篩選
如果細節對項目目標有價值，就保留，如果沒有價值，就摒棄。
這樣剔除後，剩下的所有的細節工作就可以根據所能帶來的品質提升排序，也能根據所需要的工作量排序
根據品質/工作量 即可獲得最有價值甚至優先順序最高的一部分細節工作，然後根據項目的時間安排，可以很簡單的確定哪些細節是接下來具體要考慮的。
也能保證你知道 現在該做什麼。思考 創造 執行 這些事情，人需要規則去約束自己的。如果沒有，就自己建一個。
人的大腦沒有自己想像的那麼強，為什麼會累，因為沒有路就會打圈子，結果總是想太多。推薦「單文檔體系」，說白了就是整個幾百頁的策劃案都放到一個WORD文檔裡面。
見樹不見林，見林不見樹。
這貌似是人類大腦思維結構的必然結果。我在遊戲圈十五年，沒有見過一個能夠同時看到樹和林的「天人」。^^我的方法就是使用一個文檔來管理所有的設計方案，WORD本身可以插入各種圖片和表格，可以作為設計方案的匯總工具，它有很好的文檔編輯功能。
文檔結構圖其實就是豎行的「腦圖」啦，不管你在編寫哪個局部的細節，都能夠隨時看到你在編寫的整體是什麼。
WORD有黏貼鏈接的方式，可以將某個內容在文檔的多處進行複製，但是只需編輯一個初始點就好了。對於從不同維度來進行說明是非常便利了。
下面是一個我手頭正在弄的新案子的文檔結構圖的局部。
首先，要弄清楚整體和細節的關係，分為五個層面：戰略、範圍、結構、框架、表現。建議閱讀書籍《用戶體驗的要素》，書中詳細描述了每個層面的內容。看過之後，就知道現在在做的工作屬於哪個層面，以及它與上下層的關係，然後才能分析它的作用有多大、改動對目標實現的影響有多大、代價或性價比高不高。總之，策劃設計需要全局統籌，《用戶體驗的要素》這本書是啟蒙必讀。
我曾對一些經典遊戲做了界面拆解，瀏覽器搜索關鍵詞：UI信息架構和導航 （這些內容就是屬於結構和框架層面，往下可以分析範圍和戰略，往上可以做視覺設計）。做新設計時可以借鑒，添加原創內容，重新組織這五層，以實現你的戰略。
把項目分層並嚴格執行可以避免在設計階段陷入細節設計。
小團隊沒辦法避免角色角色切換時的倦怠、疲勞，可以把全棧的滿足感作為補償。
另外失敗幾次後如果能吸取教訓，自然就會明白整體設計和具體細節分開的重要性了。如何避免陷入執行細節中，而忽視了整體設計
個人覺得這是策劃的基本功「如何避免在兩種角色切換時產生倦怠、疲勞情緒當基本功足夠，意志力，責任心就是避免這些負面情緒出現。
其實這與遊戲設計方法沒有關係，而是設計者個人素質問題。做為一個教書7年，兒童教育遊戲行業幹了20多年的美術設計師，老張對老李的經驗分享要說：受益匪淺
一個冷靜的旁觀者。無論這個人是你的上司，同組的同事，其他部分的同事，或者是你的小弟。人走進死胡同是很難自己走出來的。這個時候需要一個旁觀者把你拉出來，這也是遊戲開發除了技能合作外的另外一個點。
由初心發起，然後花大量時間自上而下進行設計，先從商業模式、核心理念著手，再設計核心玩法、配套數值系統理念。之後再設計細節和數據架構等等，再到具體執行。
閹割
推薦閱讀：
※你對大富翁4中哪個角色或者哪句話印象最深, 為什麼？
※是什麼使得各大FPS遊戲不一樣？
※手機遊戲中常見的「首沖禮包」的作用是什麼？為何多為個位數金額？
※應用UI和遊戲UI哪個前景好？
※遊戲中有哪些鮮為人知的隱藏關卡？