怎麼寫好一份遊戲策劃案？
把哪幾個方面寫清楚、摳明白算及格？你見過的最好的模版是哪個？
其實這個東西不應該由一個策劃來答。
一個策劃的案子寫得好不好，永遠只能是和他介面的人員（程序、美術、測試）說了算。僅從工作角度來看，遊戲策劃案有以下三個作用：1.讓程序美術明白需求。2.留檔，防止出了問題找不到原因和負責人。也可以看到一個功能經過了哪些修改，這些修改是好是壞。3.給測試讓測試寫用例或者給其他合作策划了解你的功能。
因為上面這個原因，策劃案也沒有什麼固定的模版，有的程序只需要幾句話就可以開工，有的程序不玩遊戲就需要你給個表然後講上半小時。
一份策劃案，通常就包含三個部分：給服務端看的、給客戶端看的、給美術的需求。這三個部分具體應該寫清楚哪方面，是無法用很短的篇幅來形容的，如果真那麼容易就講出來，策劃的工作經驗就不值錢了。比如很簡單的一個背包，就需要寫清楚：橫向幾格，縱向幾格，如何翻頁，能翻多少頁，是否分欄，分幾個欄，背包格數能否擴展，欄目能否擴展，背包滿了的時候撿取、交易、完成任務如何處理，要不要做自動排序，如何自動排序，單物品疊加上限多少，篩選怎麼做，在不同的功能NPC處有哪些功能按鈕，處於不同的功能下有什麼樣的特殊顯示方案等等等等……
+++++++++++++++++++++++++++++++++++++++++++++++++++++下去抽了根煙，想了想還是再補點東西吧，
關於如何讓你的介面人喜歡你寫的東西：後端就畫好流程圖，寫好表格式（你的表要幾列，這些列會不會再添加，每列里寫的東西最大幾位最小几位，是不是有負數、小數等）前端把交互說清楚，在這裡推薦一個軟體AXURE，這東西產品經理用得多，但是遊戲策劃拿來做前端交互說明稿也是相當不錯的。
美術就是你給需求的時候最好把樣例給出來，百度搜幾張圖不費勁。還有就是千萬要記住，給美術的文本必須要是可複製的，美術比較痛恨的事兒就是經常需要扔下手寫筆然後在鍵盤上自己輸入文字。如果這些想不全，那麼不是一個經驗豐富的策劃；如果完全想不到，那還是好好地當個遊戲玩家吧，做遊戲不是個好玩的事情。手癢，把工作先放一邊，簡單列一下提綱和要點，細節恕不展開。
首先，在寫策劃案之前，我們應該先明確一點：為什麼要有策劃案這種存在。原因有以下：
1、有助於規整設計者的思路。2、可以準確傳達設計者的意圖。3、幫助開發人員準確理解和評估開發工作量。4、可以據此進行工作分配，明確權責。5、開發完成後，可根據策劃案內容進行驗收及測試。6、後續開發時可反溯最初設計並進行修改及二次開發。明確了這些基本目的，你就把握了案子的內容、層級及邊界。
其次，「遊戲策劃案」這個說法太籠統，細說來，系統案子和活動案子有區別，數值案子和美術案子也不相同。但都需要包含以下部分：
1、設計目標、預期效果和實現方向，2、具體的需求細則、功能流程、表現原型，3、與其他部分的關聯，所佔比重、可能造成的影響，4、可能涉及的資源調配及人員配合，5、基本的測試用例。（以下的內容偏向系統案，其他的策劃案要點相似，細節和表現上有區別）
有關「設計目標、預期效果和實現方向」。這是開篇明義，讓閱讀文檔的人掌握基本要點，簡單即可
1、為什麼要進行這個設計，它的目的是什麼？2、完成之後你希望他是什麼形態？
3、這個開發是已有改進還是全新開發，準備如何實現？4、補充：如果涉及多個模塊，請附上結構圖，標明相互關係。有關「具體需求」。這是策劃案主體，要意圖清晰，不啰嗦；要一目了然，不繞彎，要便於量化執行
1、細緻闡述功能，客觀描述，簡練，避免歧義，2、分條羅列需求，盡量細分，盡量全面，避免重複，3、功能附上流程圖，存在選擇的情況要有判定流程，4、前端表現附上頁面遷移圖，5、新增數據的，設計好數據表格，5、頁面設計附上原型圖及期望的風格概念圖。有關「與其他部分的關聯」。遊戲是一個整體，各部分是相互關聯的，要有全局觀。
1、新增部分與原系統是否有所關聯，改動會造成何種影響，在具體需求中是否已解決，2、新增部分對於數值體系的影響在哪，如何進行分配，3、新增部分與原有部分的相互配合方式。4、新增部分對整體的影響，計劃在遊戲生命周期的哪個階段著力表現。有關「資源調配和人員配合」。事前明確權責好過事中扯皮事後推諉，如果大家合作愉快這條作罷。
1、完成開發需要哪些資源，2、完成工作需要的組間配合，3、各自的工作內容及完成時間。有關「測試用例」。其實，如果需求寫得夠明晰，這部分其實很簡單，就是比較煩。
1、實現度
2、表現是否正常3、數據存儲調用是否正確4、分步拆解糾錯5、關聯繫統對接是否通暢Tips。（喂！不是說好不展開了嗎）
1、流程圖有助於梳理設計思路，條件判定有助於查缺補漏，請細心。2、遷移圖可以理清你的操作邏輯，在保證功能的基礎上，適當減法。3、原型圖可以簡陋，但要點和你期望的焦點功能和布局方式，請凸出。4、認真設計數據表格，這些都是日後你要自己填的，請善待自己。5、策劃案要標題明確，層級清晰，方便通過文檔結構圖進行查閱與檢索。
6、關聯其他開發的部分給出對應文檔的名稱和所在位置。7、在策劃案里留下歷次的版本修改記錄與遊戲實際情況保持一致。最後，一些輔助工具
1、Mindmanager，思維導圖，可以很好展現整體的樹狀系統結構，也可以詳細闡述一個功能，2、Axure，頁面原型，頁面遷移跳轉，快速製作可進行操作體驗的頁面原型，3、excel、visio，基本工具，博大精深，4、知乎，嗯，開小差的時候不至於有太多負罪感。最後，我這一篇回答，換個視角就是一個基本的策劃案框架思路。以下，來自1997年Tzvi Freeman關於遊戲文檔的梳理文章，標題很宏大，叫Creating A Great Design Document，非常詳實，且相當有邏輯
我必須做出一個遊戲。就在不知失措、頭昏眼花之時，我一頭撞在了電腦顯示屏上。接著，古銅色的燈里輕煙似地冒出了個燈神，許諾我三個願望。我不假思索地說：「我想要……
*一支有才能、有技巧、有獻身精神的程序師和美工組成的團隊（包括非常善解人意的老婆一枚）且個個擅長人際交往。
*足夠的時間和資金允許搞砸一兩次。
*一流的設計文件。
很久以前，編寫一款遊戲只需要一名程序師（和一名美工）加上接了就做的預算和寬鬆的開發期限，所以大家對文件編製沒必要太上心。你知道想要什麼就去做什麼。因此，如果在這過程中發生了個把重大變故，你只能責怪你自己。現在，一份周全易讀的設計文件意味著什麼呢？就是迅速地墜入一文不值的地獄和平穩地飛升到富麗堂皇的天堂之間的差別。
如何展開工作？
大多數遊戲的開發從概念到製作完成需要經歷三個階段，即「產生靈感」、「紙上計劃」和「身體力行」。
在第一階段，概念文件不僅是一封寫給自己的信——提醒你不要忘記它們；還是一個應對投資商和營銷商的銷售工具。有時候，還要在這個階段製作一個微型原型，這樣你就可以用它做實驗並修改自己的創意。
第二階段是和一大堆美工、動畫師、音樂師和編程人員討論——實驗想法，然後找出組織辦法，最後敲定主意。
在最後階段，管理製作過程的工作通常交給一些擅長處理流程和衝突的行家負責。原創意的設計師可能只允當團隊的主要成員，但在許多情況下——特別是在大公司，這位設計師往往變成旁觀的顧問。
毫無疑問，如果說設計文件是項目的父母，那麼它對項目的成長影響當然最大。即使作為設計師的你兼任項目經理，你也不能欺騙自己：你確實不能全盤兼顧。複雜的項目需要許多有才能的人共同完成。有技術的程序師和美工往往有自己的一套心思。當你打算做一匹馬，美工畫出的可能是只獨角獸，而程序師想到則是吃苦耐勞的駱駝。好的設計文件可以確保大夥想法一致、感覺一致。這好比一支大樂隊的爵士樂總樂譜，儘管仍然有大量即興表演的餘地，但在總樂譜統領作用下，大家的心思都被放在一處。
設計文件是想法與現實之間的橋樑。它能確保承載想法的野馬不會脫韁跑出現實所能駕馭的範圍，同時又保證最後抵達的終點正是最初創意的指向。
最後，記住這句久經玩家證實的格言：「偉大的藝術來自細節」。光彩奪目的細節自然而然地從遊戲中流露出來，就好像它們當初從第一道靈感中閃現光芒一樣。但是，一旦你進入實際的執行階段，細節的火花往往容易熄滅。
挑戰
給項目製做局部原型當然是個好主意——儘可能畫出所有草圖。但此外，那些細節才是最重要的。你的想像能承載的細節越多，你的作品就會越出色。
根據文件工作也有消極面。刺激的遊戲的開發過程本身就必須刺激。例如，有許多項目的閃光點往往是到了令人恐慌的截止期時才被發現。誠然，時間和成本預算的壓力不允許概念的不斷重複，但你只是不希望做出一款乾巴巴、沒驚喜的遊戲。製作設計文件的挑戰在於，能夠忍受你的項目發生意料之外的調整，但又不迷失原創意的整體方向和視野。
成功的設計文件十個要點
1、除了形體，還要描述靈魂。 如果遊戲開發只是自動輸入/輸出的問題（就像編寫代碼和預測過程）——那麼你只需要一份乾巴巴、描述性的文件就行了。但事實是，開發是人做的， 這些人是有創意的人、有獨立想法的人、想在所有自己做的工作上蓋個戳的人。
再繼續說你想要的那匹馬的故事：你把說明書交給美工，然後和他們討論要做什麼。之後你給程序師看了下說明書。兩邊都對你所說的話點頭稱是。
當天晚上，大約凌晨2點，正當C++的群星閃爍在西天，處於中年危機的程序師開始胡思亂想：「什麼，我的下半輩子就是一個程序獃子？我媽對我的指望就這樣？為什麼，我也可以像其他人一樣設計遊戲！「然後繼續埋頭輸代碼。
大約與此同時，美工等著他那台陷入死機的電腦完成複雜的3D渲染，等著等著就睡著了，這會兒剛醒過來。他不確定也不關心他是不是在做夢，或者從這些工作中取得報酬，只是沉浸在藝術天才的狂想世界裡，在不可思議的幻想和現實的融合作用下，神獸誕生了——當然不是你文件所描述的那匹馬。
第二天一大早，你的馬，當然沒來，來的是長著兩個駝峰的獨角獸。對於這些創意星人，光給指示行不通，啟發才是硬道理。
在你的設計文件中，別滿足於對各個物品和細微差別的細節性描述。花時間形容一下遊戲應該有的感覺、各個元素潛在的目的、玩家應該有的體驗和你可以想到的、能夠形容的遊戲靈魂的方方面面。
例如，你在設計一款射擊遊戲。你的目標是通過遊戲訓練玩家如何應對現實中遇到的某些挑戰，所以一開始設定的難度不高。你得向團隊的所有成員解釋你的用意，這樣他們才會理解為什麼某些東西要放在這，為什麼要這樣做。即使你的團隊不太認真地對待或胡亂刪改你的創意，你仍然可以抱著希望，即結果達到或接近整體效果。或者可能還更好。
2、易讀性。給團隊成員一份每頁標明10個要點、無襯線字體印刷、80個字元一行的文本，並且要求每個人都要閱讀。你可能得在每件份文件里準備一捆止痛藥了——這是為那些確實要忍痛遵守指令的人準備的。
以下是我遵循的頁面布局原則：
大片空白
文本主體以襯線字體（遊戲邦註：指西文中有襯線的字體，與漢字字體中的黑體相對應）印刷粗體字標題
段與段之間有空隙
文本句子簡短
引導視線直指重點內容
分層次，大綱視圖
用表格、圖表、圖片等說明例子。把圖表、表格、圖片等製作得醒目一些。
3、區分優先次序。既然你意識到你是和頭腦清楚、有自我的人一起工作，就有必要讓這些人意識到某些加標記的遊戲元素的神聖性。我確實不敢打包票，但如果你能好好利用標記，你想強調的地方大概還是能得到一點尊重吧。這還沒完，既然打了標記，當然還要區分不同的標記含義——有些是你計劃要做的，有些是時間、預算和技術允許就做的。
然後垃圾來了——那些聽起來很棒，實際上完全有理由當成垃圾的東西。你需要明確地指出來並解釋需對其警惕的原因。如果你不這麼做，我敢說這些垃圾還是會再跑出來。以下是標記列表：
不可缺少
重要
如果可能
否絕
你可能希望用上一些視覺符號來代替標記。但不要依賴顏色，因為文件不一定總是彩色印刷。
4、深入細節。沒有細節的文件毫無用處。大家可以隨意地理解大綱。「Thou Shalt Not Kill」（不可殺生） 這句話對摩西來說是一個意思，對西班牙征服者來說是另一個意思。詳細地說明哪些角色不能殺、為什麼不能殺、還有什麼用途。設計文件也是一樣：一旦你描述了一些實用的細節並給出相應的例子，你的想法就具體化了——不會被輕易地曬在一邊。
例如，不要只說：「銅鳥是無敵的。」明確地描述這傢伙被攻擊時會發生什麼情況及之後如何恢復。確實，如果動畫師有脾氣又有藝術家的尊嚴，你可以肯定他不會聽從你的指示。但至少他會另想出一個更清楚的、又不違背你的主意，且他的修改不會嚴重地改變相關的部分。
別只說：「此時，用戶會按下帶箭頭的跳躍鍵爬上牆。」而是詳盡描述如果玩家不那麼做會發生什麼情況。解釋為什麼你認為用戶能夠想到你所提供的操作組合。解釋環境暗示玩家爬牆的可能性。
另外，美工也會冒出其他想法，可能比你最初的設想更適合。如果是那樣，那就真是太好了，因為成品可能甚至比你的紙上描述更接近你最初的靈感。但除非你一開始就清楚地描述了你的概念，不然這種事不可能發生。
別只說：「Bongo Man 比Bongo Boy更強大，但Bongo Boy的反應更快。」請用表格來表現角色的動作速度值、角色可擁有的攻擊點數、角色的攻擊傷害點數、發動攻擊需要的能量等等。這種表格在Q/A和製作階段是非常有價值的。
別只說：「大多數人會在幾天內想通整個遊戲。」製作表格，用於預測不同用戶持有的產品的壽命；表明你希望各種功能特徵被發現的時間點。之後的用戶測試會為下一款遊戲的設計提供有價值的反饋。
5、演示某些東西。有時候，幾張草稿就夠了，但如果這個創意對你的概念和項目確實重要，你可能得親自製作粗略的動畫。當元素的活動太過複雜和模糊，難以用文字表達，你就得製做原型。原型的好處之一是，通過實踐往往可以催生更簡單更高明的解決方案。
除了提供動畫和原型，你還是需要提供概念的文字描述。動畫確實比十億位元組的文字更有價值，可是文字也有動畫無法達到的交流效果。看動畫時可能會遺忘了某些重要的差別，而文字可以清晰地描述出細微之處。
6、別只說「什麼」而不說「如何」。在現實世界，「如何」決定了「什麼」。例如，假設你已經選擇了粘土動畫，那麼就要制定出捕捉畫面的方法，然後在文件中描述這個過程。背景應該用什麼材料和什麼顏色？應該用什麼攝像技術和為什麼用這種攝相技術？塑造框架的步驟是什麼？等等等。如果你嘗試過，你會知道這些因素中的任意一個對結果都有重大影響。
或假設你在製作一款摩托車競賽遊戲。你表示摩托車必須在優勢和弱點之間達到平衡，所以你要在文件中提供實現平衡的表格，並註明調整是必要的，還要說明你打算如何實現調整——過程是什麼？假設遊戲的主要角色是歌劇幽靈。描述玩家的鍵盤如何映射管風琴鍵。提供一張各個鍵的映射圖。列舉發聲的可用渠道的數量。和你的程序師討論一下怎麼實現各個細節，再用文件記錄下來。兩個不同的「如何」可能會產生非常不同的結果。
7、提供替代性選擇。項目經理耗費大把時間在製作甘特圖和PERT項目評估上。個人認為，我真的不敢說這種東西對遊戲開發是有效的——很大程度上是因為未知的東西太多了。你的遊戲技術越激進越新，開發過程中可預測的情況就越少。要保證你的團隊達到日程表上的階段時間點，你能做的不過就是提供另一條通路。（遊戲邦註：甘特圖：美國工商業管理專家甘特設計的，是一種用平行線表示一定時間內生產的計劃數字和實際完成數字的圖表；PERT項目評估：在一個給定的項目中對潛在任務進行分析的一種方法。）
我們返回鍵盤映射管風琴鍵這個例子。你的程序師向你描述實現最佳效果的最終方法，此法需要50人/小時來執行。因為我們已經討論過其他事了，所以你已經記下所有東西。
你不能止步於此。你得問：「如果我們只需要一個切邊、8槽的管風琴，要費多少人力時間？如果是絕對最小值呢？如是要我們只有幾個助理能做這個怎麼辦？」然後你照舊記下一切。當最後面臨抉擇之時，你只需要脫口而出：「好吧，計劃C。」
在文件設計方面，我犯下的最大的錯誤就是問程序師：「這辦得到嗎？」除非你問的是一流的程序師，否則這個問題根本就是白問。更具體地說，回答可以分成以下三種：
（差勁的程序師）：「當然，沒問題。」
（一般的程序師）：「不，不能。」
（一流的程序師）：「我這樣做要花兩周的時間。或者我可以小調整一下，只要五小時。」
總是不忘問另種方法和所需時間。然後表明你的傾向——如果有時間就這樣做，否則就做罷。
8、允許修改。靈感和創意往往與興奮和樂趣同在，我已經警告你要防止悶死這種靈感和自然的創意。你得允許設計文件被你自己或其他人（但願是有才能的人）修改。
我在British Columbia大學主修音樂作曲時第一次吸取了這個教訓。千辛萬苦，我終於寫好了一個新文藝復興的銅管五重奏，我真是相當自豪。我的導師也很喜歡。當我們把樂曲拿給學院的銅管樂隊演練，然而，在十秒鐘的時間內，我的情緒就經歷了幾個階段的起伏：驚駭、懷疑、憤怒和沮喪。樂隊開始演奏了，一個大號手停下來向其他樂手示意，接著他取出筆開始修改幾個音節，然後所有人又繼續演奏。這種情況發生了不止一次。
我的導師，注意到我的臉色突然蒼白了，轉過身來對我說：「別擔心，他們對莫扎特的曲子也這樣。他們通常是對的。」
真相是，無論在紙上看起來有多好的東西，被置於現實世界的客觀解讀之下，最棒的專家仍然會修改它。雖然如此，你不想目睹自己的設計和夢想被無情地篡改。你希望自己的靈感以一種自然的姿態成長——永遠是那顆你播下的種子，它的成長不經過外來根枝的嫁接。
以下技巧可以幫助你製作出一份可接受修改，又不會中斷原始想法或扼殺開發進程的文件：
如果某方面是遊戲概念的重點，確保大家牢記於心。
確保所有人領會遊戲的靈魂及各個細節的用意。
如果有信息重複，必須互相參照。否則，如有改變，就會產生矛盾指示。
以下是實際執行階段的技巧：
當有人提出改變時，回頭檢查你的設計文件，看看它是否和遊戲的「靈魂」一致。
檢查這是否是獨立的改變，或它是否產生系統性影響（牽一髮而動全身）。如果是後者，就在下一份計劃中拯救它吧。
及時更正設計文件，包括修改的原因。或如果你不想修改，明確指出並解釋原因。
修改、刪除和否絕想法應該保留在主控文件中，以免重複討論相同的事。
所有人都必須以相同的版本作為工作對象。過去的版本應該銷毀。
重要的、關鍵的和緊急的一點：設計文件必須置於一人且僅有一人的監管之下。
9、應提供必要的參照和指示內容。我曾見過有些人的文件甚至連頁碼都沒有，結果卻抱怨成員沒有遵循文件指示。優秀的文字處理器會自動計算頁數並且印刷每一頁的日期和頁眉或頁角。有些甚至允許你在新章節里改變頁眉。用黑體字印刷重要的內容。你可以隨意在不同的部分重申你自己的想法，前提是你把重申的部分相互參照了，這樣你就可以一次性更新所有內容。製作一個周全的內容表格。
你可能希望用HTML寫下你的文件和運用超鏈接。有些高級的文字處理器不需HTML也能使用超鏈接。但記著，人們往往更喜歡看著死複印件文本（因為有了實實在在的文件在手，那麼在系統崩潰後重新啟動的一個小時內，就還有點東西可以讀）。
10、好文件也要好包裝。最後，你需要做的就是使文件便於閱讀和使用。沒有願意閱讀一疊紙——因為看起來也不重要。只有帶硬封面的東西看起來才重要。
製作一份應持有複印件人員的名冊並進行保存。列印出所有東西，且每一頁都要帶眉頭和日期。接著在每一頁上打洞做成活頁。最後在每一份活頁本的書脊和封面上貼標籤。更新時，人手一份校訂頁。有時，你可能需要提拱新活頁本，丟掉舊活頁本。
總結
電影製作人使用步驟原稿。建築師使用藍圖。音樂家使用樂譜。根據古代的傳說，甚至是宇宙造物主也製作了設計文件，在最初的文明之光普照大地之前，他讓一小撮先知瞄了一眼——所以有了這個古代傳說。既然神都是這麼做的，那麼遊戲開發者就以之為榜樣吧。
遊戲邦註：原文發表於1997年9月22日，所涉數據及事件均以此為準。
另外可以參照的一些內容：
設計教程：如何撰寫遊戲的特徵概要
遊戲設計文件撰寫原則之理念大綱和項目提案
http://gamerboom.com/archives/49779
闡述遊戲設計文件撰寫原則之技術規格書
http://gamerboom.com/archives/56005
闡述遊戲設計文件製作步驟及注意要點
Creating A Great Design Document
by Tzvi Freeman
I』ve got to get product out. In the panic and dizziness, my head smashes against the CRT and next thing I know this genie whiffs up out of a virtual bronze-texture-mapped lamp and offers me three wishes. Without missing a beat, I answer, 「I need…
A great team of talented, skilled, and dedicated engineers and artists (including a very understanding wife) with strong interpersonal skills.
Enough time and money to allow for a mess-up or two.
A first class design document.
Once upon a time, when coding a game involved one programmer (and maybe an artist) with a take-it-as-you-go budget and a loose deadline, documentation didn』t need to be taken so seriously. You knew what you wanted to make and you made it. If there were a few major changes along the way, the only one to complain was you. Nowadays, a thorough and readable document can mean the difference between a swift descent to budgetless Hell and a smooth ride to shrinked-wrapped Nirvana.
How the System Works
Most games go through three development stages, from concept to design to production. Think of them as 「flash,」 「paper,」 and 「grind.」
In the first stage, the concept paper acts both as a letter to yourself – setting out your goals clearly so you won』t lose sight of them – and as a sales tool for whomever takes the product to market down the road. Sometimes, this stage involves a working mini-prototype as well, which gives you a chance to experiment and revise your ideas.
The intermediate stage of design involves a lot of discussions with artists, animators, musicians, and engineers – trying things out, and finding ways to organize and set down your ideas.
In the final stage, production management is often left up to some expert in moving trains and tracks without major collisions. The original designer may be an integral part of the team, but in many cases – especially in large companies – the designer ends up as a kind of outside consultant.
Without question, the design document is where the original parent of the project exercises the most influence on how this little baby is going to grow up. Even if you, the designer, have decided to double as project manager, don』t delude yourself into thinking that you hold all the reins. A complex project involves many talented people. Skilled programmers and artists tend to have minds of their own. While you intend to create a horse, the artist may be envisioning a unicorn and the programmer a highly efficient camel. A good document ensures that you are all planning to make the same thing. A great document ensures you all have the same feel for the inner soul of this thing. Think of it as a big band jazz score – it puts everybody』s mind in the same place, even when there』s still plenty of room for the stars to improvise.
Your document is a sort of intermediary between your mind and the real world. It ensures that what you have in mind is something that the real world is able to handle, and that what you end up with will be what you originally had in mind.
Finally, remember the adage to which any salty gamer will attest: 「Great art is in the details.」 Brilliant details flow naturally from the general gestalt as though they were present in that first flash of inspiration. But once you get into the hands-on implementation, it』s easy to lose that spark.
The Challenge
Prototyping parts of the project yourself is definitely a good idea – make whatever rough sketches you can. But again, it』s those details that count. The more details your imagination can hold, the greater a masterpiece your work will be.
Working from a document has a flip side, as well. Developing an exciting game has to be exciting. Some of the best parts of many projects were discovered in the heat of last-minute deadline panic. True, the pressures of time and cost budgeting don』t allow for perpetual reiteration of concept, but you simply cannot expect a killer game to come out of dry, predictable work. The challenge is to create a design document that will allow your project to tolerate surprise adaptations without losing the integrity of its original direction and scope.
Table 1. The three stages of documentation.
Contents Purpose
1. Concept Paper Genre; target audience; description; most compelling features; market information; cost and time to develop. It defines the concept, scope, worthiness and feasibility; sells the idea to your client, publisher, employer, and venture capitalist.
2. Design Document Description of the body and soul of the entire project, with all the details, and the method by which each element will be implemented. It ensures that what is produced is what you want to produce.
3. Production Documents Time-management charts (Gantt, PERT, and so on); task database; budget spreadsheet; technical specifications; Q/A database. It implements the design document on time and within budget.
Ten Points for a Successful Design Document
1. DESCRIBE NOT JUST THE BODY, BUT THE SOUL. If game development was just an automated input/output issue – something like writing code and being able to predict how it』s going to work – you could get by with a dry, descriptive document. The reality is that development is done by people, many of them creative people, who have their own minds; most will want to leave a stamp of that mind on everything they do.
It works like this: You provide specs to the artists and discuss with them what to do. You then visit the programmers and go over their specs. Both groups nod to everything you say.
That night, around 2AM, just as the constellation of C++ is rising in the west, the programmer reaches a mid-life crisis and begins to think, 「What, a geek programmer the rest of my life? Is this what my mother expected from me? Why, I can design a game just as well as anybody else!」 And the hands keep typing code.
Around the same time, the artist has just woken up before his machine, having fallen into a deep stupor while waiting for a complex 3D rendering to finish. Unsure and not really caring whether he』s dreaming or is actually getting paid for all this, immersed in that wild world of artistic genius where fantasy and reality blend as one, the phosphors come together in ways previously unimagined – certainly not by you.
By the next morning, your horse has become a unicorn with two humps. With creative people, instructing is not good enough. You need to inspire.
In your design document, don』t satisfy yourself with a detailed description of every article and nuance. Take time to describe the feel that the game should have, the purpose behind each element, the experience each user will have, and any other aspects of the game』s soul you can envision and describe.
For example, say you』re designing a shooter. You want to train your players to deal with certain challenges before they actually meet them, so you place less lethal mini-challenges a few steps in advance. You』re going to have to explain that to everybody on the development team, so they』ll understand why certain things are where they are and why they work the way they do. That way, even if (read: when) your team toys with and mangles your ideas as they exist on paper, you can still harbor hopes that the outcome will have the same or similar overall effect. Or maybe even better.
2. MAKE IT READABLE. Go ahead, provide your people with full pages of 10-point, sans serif, 80-characters-per-line text, and demand that they read it. You may want to bundle Advil in the package – for those who actually take the pains to obey orders.
I try to follow at least some of the guidelines of good page layout.
Plenty of white space
Serif font for body text
Bold headers
Spaces between paragraphs
Short lines of text
Direct the eye towards important material
Use a hierarchical, 「2D」 format (see what I wrote about outliners in the 「Design Documentation Tools」 sidebar)
Many instances call for a table, spreadsheet, or chart. Use them and make them sensibly attractive.
3. PRIORITIZE. Now that you realize that you』re working with other conscious egos, you』ll appreciate the urgency of tagging certain game elements as sacred. True, there are no guarantees, but if you use the tag sparsely enough, it may get some respect. But don』t stop there. As long as you』re tagging ideas, you』ll also want to distinguish between things that you intend to do and things that you』d like to do if time, budget, skill sets, and technicalities permit.
Then there』s the trash bin – things that sounded great, but were trashed for good reason. Refer to them explicitly and explain the reason that they were trashed. If you don』t, I can almost guarantee that they will be resurrected. Here』s your list of tags:
Indispensable
Important
If Possible
Rejected
You may wish to use visual symbols to represent these. Don』t rely on color, since documents aren』t always printed in color.
4. GET INTO THE DETAILS. A document without details is useless. Generalities can be interpreted by anybody in any way that they like. 「Thou Shalt Not Kill」 meant one thing to Moses and another to a Spanish conquistador. Detailing whom you shouldn』t kill and under which circumstances would have been more helpful. The same holds true for your document: Once you』ve described some practical details and given some examples, your idea becomes more concrete – and harder to shove around.
For example, don』t just say, 「Bronze bird is invincible.」 Describe exactly what happens to this creature in each possible instance of its being hit, and how it recovers afterward. True, if the animator has any spunk and artistic dignity, you can rest assured that he won』t follow your specifications. But at least he』ll have a clear idea of what you want to achieve, and his modifications won』t seriously alter the related portions of the game.
Don』t just say, 「At this point, users will have to press the jump key with the arrow key to climb the wall.」 Describe what will happen if a player tries anything else. Explain why you think users will be able to figure out the combination that you』ve provided. Explain what about the environment suggests that it』s possible to climb this wall.
Again, your artist will come up with something else, perhaps something even more suitable than what you originally conceived. That』s real success: When your developers』 results come out even closer to your original flash of conception than what you were able to describe on paper. But this won』t happen unless you first lucidly describe your concept.
Don』t just say, 「Bongo Man is stronger than Bongo Boy, but Boy has faster reflexes.」 Use tables, spreadsheets, and charts to assign real values to the character』s speed of movement, how many hits the character can take, how much damage the character』s hits do, how many cels it takes to animate a hit, and so on. This sort of spreadsheet is invaluable in the Q/A and tweaking stages of production.
Don』t just say, 「Most people will figure out the whole game in a few days.」 Make a chart of predicted product life in different households, indicating at which points in time you expect various features to be discovered. User testing will later provide valuable feedback for designing your next game.
5. SOME THINGS MUST BE DEMONSTRATED. Sometimes a few rough sketches are enough, but if the idea is truly important to your concept of the project, you may want to make a rough animation yourself. When behaviors of elements become too complex and ambiguous to describe on paper, you』ll want to make a prototype. A side benefit of prototyping is that this practice often leads to a simpler, more elegant solution.
Even when you provide animations and prototypes, put the concept in words as well. True, an animation is worth a gigabyte of words, but words can communicate in ways that animations can』t. Words also clearly spell out the vital nuances that may be missed when watching the animation.
6. NOT JUST 「WHAT」 BUT 「HOW.」 In the real world, the 「how」 determines the 「what.」 For example, suppose you』ve opted for claymation. Work out the process of how the images will be captured and document everything. What material and what color should the backdrop be? What camera should be used and why? What are the steps for processing the captured frames? And on and on. If you』ve tried it, you』ll know that any one of these factors can have a serious impact on the end result.
Or suppose you』re working on a motorcycle racing game. You state that the motorbikes must be balanced by their differing pros and cons. You even provide a chart that shows how balanced they are. Then you state that tweaking will be necessary. State how you plan to tweak – what is the process? Suppose the main character in your game is the Phantom of the Opera. Describe how the player』s keyboard is mapped as a pipe organ. Provide a map of each key. Specify how many channels of sound will be available. Talk it over with your programmer and work out every detail of how. Then document it. Two different 「hows」 can mean two very different results.
7. PROVIDE ALTERNATIVES. Project managers spend a lot of time with their Gantts and PERTs. Personally, I can』t really say that this stuff is effective for game development – principally because there are just so many unknowables. The more radical and pioneering your game technology, the less predictable the development stream is going to be. The best thing you can do to ensure that your team reaches your milestones on schedule is to provide more than one way of doing things.
Lets go back to the keyboard as pipe organ example. Your engineer describes to you the ultimate method of getting awesome and funky results with tremendous power and depth to the user – at a cost of about 50 person-hours to implement. As with everything else we』ve discussed, you document the whole thing.
You can』t stop there. You』ve got to ask, 「What would it take if we just wanted a trimmed-down, eight-channel pipe-organ? And what will we need to achieve the bare minimum? And what if we just had some assistant doing this?」 And then you document all that as well. When the FedEx truck is on its way over for the final daily pickup, you』ll be able to save your skin with a simple, 「OK, do Plan C.」
One of the biggest mistakes I』ve made in product design is asking engineers, 「Can it be done?」 Unless you』re asking a first-class programmer, the question is useless. More specifically, responses fall into one of three categories:
(Lousy programmer) 「Sure, that』s no problem.」
(Mediocre programmer) 「Nope. Can』t be done.」
(First-class programmer) 「I could do it like this and it』ll take two weeks. Or I could make a slight modification like this and it』ll take five hours.」
Always ask for more than one alternative and an estimate of how long each will take. Then indicate your preference – do this is if we have time, or this if we don』t.
8. GIVE IT A LIFE. I』ve already warned you against strangling the inspiration and spontaneous creativity that comes with the excitement and fun of seeing ideas become living objects in your hands. You』ve got to allow your document to tolerate change – by you or by (hopefully intelligent) others.
I first learned this lesson as a music composition major at the University of British Columbia. With much toil, I had written a neo-renaissance brass quintet of which I was quite proud. My professor liked it, too. When we brought it to the college』s star brass quintet for rehearsal, however, I passed through several stages of horror, disbelief, indignation, and clinical depression within ten seconds. The quintet began to play, then stopped on signal from the tuba player. The fellow took out his pencil and began to change a few notes, and then everyone continued. It happened more than once.
My professor, noting my sudden faint state of health, turned to me and commented, 「Don』t worry, they did that to Mozart as well. And they』re usually right.」
The fact is, no matter how good something looks on paper, the greatest expert still modifies things when it enters the concrete world of objective perception. Nevertheless, you don』t want to witness the ruthless rape of your design and dreams. Rather, you』re hoping for a kind of organic growth – ideas growing naturally out of the seeds you』ve planted without needing foreign limbs and bodies grafted onto them.
Here are some tips for creating a document that can tolerate change without corrupting the original idea or sabotaging the development process:
Make certain to engrave in stone those aspects that are so essential to the game concept that they must not be changed.
Make certain everybody understands the feel that the game is supposed to have and the purpose of each of its details.
If information is repeated, it must be cross-referenced. Otherwise, if there are changes, you can end up with contradictory instructions.
And here are some tips for the actual implementation stage:
When a change is suggested, check back in your design document and see if it is in concordance with the 「soul」 of your game.
Check whether this is just an isolated change, or it』s of major global ecological impact (see 「The Ecology of Improvement」). If it』s the latter, save it for your next project.
Update the design document and include the reasons for the change. Or if you didn』t make the change, say so and explain why it was rejected.
Changes, deletions, and rejected ideas should be retained in a master document to avoid discussing the same thing twice.
Everyone must be working from the same version. Past versions should be destroyed.
Crucial, Vital, and Urgent: The design document must be maintained under one person』s supervision only.
9. NOBODY SHOULD BE ABLE TO SAY, 「I DID IT THAT WAY BECAUSE I COULDN』T FIND ANY REFERENCE TO IT IN THE DOCUMENT.」 I』ve seen documents that didn』t even have the pages numbered. And then they complain that people didn』t follow instructions. Every good word processor will auto-number pages and print the date and title in the header or footer of every page. Some will even allow you to change the header at new chapters. Use bold text to direct attention to important material. Repeat yourself in different parts of the document as much as you like, as long as you cross-reference so you can update everything together as well. Make a thorough Table of Contents.
You may wish to write your document using HTML and provide hot links. Some progressive word processors provide hot link capabilities without HTML. But remember that more often than not, people prefer to work from a hard copy. (That way there』s something to read while rebooting after the hourly system crash.)
10. DELIVER IT IN GOOD CONDITION. After all this, you need to do whatever you can to facilitate everyone actually reading and using the thing. A pile of papers doesn』t get read – it doesn』t look important enough. Only things with hard covers look important.
Create a list of everyone who is supposed to have a copy. Keep the list. Print out the whole thing with the date in the header of each page. Have holes made and put it in binders. Label the spine and cover of each binder. When there are updates, provide everyone with the revised pages. At some points, you may need to provide new books and throw out the old ones.
In Sum Check…
Movie makers use move scripts. Architects use blueprints. Musicians use a score. According to ancient hearsay evidence, even the Cosmic Creator created a design document – which He later let a few prophets take a peek at – before the primal 「Let there be light!」 So game developers, following their Supernal Role Model, can certainly do the same. Do it right and it』s smooth sailing the rest of the way.
Tzvi Freeman teaches Game Design and Documentation at Digipen School of Computer Gaming in Vancouver, British Columbia, Canada. He has designed several commercial games and has acted as a consultant on many others. He can be reached at TzviF@aol.com. （source:gamasutra）
這是唯獨一個雖然我沒什麼好想法但有發言權的問題。
首先我有收集癖，之前收集了近百個項目的文檔，可惜後來硬碟壞了，有微博為證：
其次，因為盛大的關係，看過早期街霸的設計文檔、魔界村的設定文檔、FF的系統文檔；多虧中國人遍布世界，讓我見過NCsoft、Rovio等公司的設計文檔；又因為偉大的黑客，讓我目睹wow的技能文檔、hellgate的數值文檔和一眾韓國網遊的全部文檔；感謝國內的外企，讓我見識了EA、UBI、Gameloft等公司的遊戲設計案。
我用人格擔保，根本沒有規範。幾乎每家公司在初期人少時，文檔都寫的很簡略，而到人多之後開始做大作，文檔都浩浩蕩蕩圖文並茂。而且個人特色極為鮮明，早期街霸的設計文檔，分明就是一些草圖漫畫……而有的程序員做策劃，寫的文檔幾乎就是流程圖、狀態機和表格的混合體……做UI則有用word、excel、powerpoint、visio、axure、畫圖、ps、flash、cd甚至autocad的……至於國內策劃寫的策劃案，完全不合格的除外，常見的問題反而是廢話太多，因為缺乏足夠的功力讓程序迅速理解。
說到底，策劃案寫得好不好真是要看閱讀者。比如下圖，不懂的只以為是犯罪現場取證，但是張亮看到了就能接收到完整的信息。
關於如何寫好策劃案，我在07年GDC上看過Bioware Austin的Damion Schubert做過的一個報告，至今我認為沒有出現更加實用的，因為裡面的內容足夠了。下載地址是：
http://twvideo01.ubm-us.net/o1/vault/gdc07/slides/S3782i1.ppt最後給大家看下GTA一代的策劃案，根本沒什麼稀奇：
能明白張亮同學在這方面的困惑，但簡單地說，最好的策劃案是不存在的。不過，能不能這麼理解，這個問題的實質是：如何量化地評估一份策劃案？如何通過文本信息評估一個策劃？
這是可以做到的。
（先蹲著佔個坑，下班了再寫吧）初級策劃成長中..就我個人現階段的理解，策劃案是給人看的，好的策劃案就是能讓人看得懂的策劃案。一個策劃案，從構思出來的框架案，到最後給相應執行人開發的執行案，我認為在這期間應該至少有3個版本。第一個版本是構思的框架案，框架案主要作用是討論玩法的可行性。是寫給主策，或者說策劃內部討論用的。在這個階段，主要應該闡明的是，這個玩法的設計目的，核心玩法。也就是這個案子是為了解決什麼需求，怎樣去解決這個需求。抓住設計目的，才能在構思的時候不會腦洞打開跑火車跑的不著邊際。第二個版本是有基本內容的草案。草案的作用（我這邊）是召集前後端美術QA進行討論。主要在於玩法的可實施性。對於現有系統暫不支持的新的需求，在實現上是否有困難。是否有更好更合適的方案來滿足設計目的。以及功能基本工作量的計算。在這個階段，主要應該闡明的是，案子對於各部門的需求。這需要對各部門的工作內容有一定程度的了解，主要是程序的實現方面。懂一些代碼，才不會被程序忽悠這不能做那不能做嘛。第三個版本是具體需求細化的執行案。在玩法都討論結束，確定方案可執行以後，就需要細化草案，完成一個可執行的執行案。執行案的作用，顧名思義，是開發人員開發過程中具體的執行文檔。需求是儘可能的細化你的需求。力求做到開發人員在開發過程中碰到的每個疑點都可以在案子中找到答案，例如這個按鈕的tips是什麼？點擊後是否置灰？主要集中在前端的表現上。如果執行案足夠詳細，那麼開發者在開發過程中可以一氣呵成，也不會不停的問策劃這裡要怎麼表現，那裡要怎麼表現。提高開發效率，策劃也可以有更整塊的時間去構思新的案子。總而言之，好的策劃案，應該針對不同的「讀者」，都讓他們看到他們想看的東西。而其中最重要的，還是設計目的吧。手裡的項目有的功能開發出來，反思一下都不明白為何要開發這個功能。。我覺得這就是挺失敗的案子。至於模板，還沒有覺得非常好的（這邊根本沒幾個模板。。），希望大家有好的模板不吝分享呀！
格式和敘述方式當然其實並不怎樣重要
不過我還是習慣要求我帶的人寫清楚設計目的，並從數據表結構到服務端邏輯、客戶端邏輯、美術需求等幾個基本點寫起
並不只是因為研發的分工，針對不同介面做切合的表達。更重要我希望他們能夠儘快弄懂這些內容間的I／O概念
資料庫與服務端，服務端與客戶端，客戶端與美術資源
最後進而要求
數據表的建立在能用後還需考慮擴展性，盡量減少數據關聯以及考慮排序遍歷的效率服務端能想到數據存儲的時機和方式，模塊能夠細分到內部無耦合邏輯，判定能夠清楚不同順序的不同結果，與客戶端通信需考慮網延並盡量保證信息發送的單向性客戶端能想到減少惡意和不必要的封包發送，不同表現對於美術資源不同的要求美術資源能夠在發出需求前明確包裝核心，在不同情景下需要突出什麼需要弱化什麼，還有盡量詳細的原型描述，草圖以及示意效果好了，這就是一個初級策劃的及格標準了。
至於更為關鍵的：我需要一個什麼樣的原始需求？需求由哪些功能系統可以很好實現？這些功能系統和現在以及將來可能添加的那些關係應該如何？
可以在你打基礎時自行體悟，或者先由你直屬上級幫你拿主意這部分說起來比較大，多種多樣的情況就不展開了。
最後，千萬記得：不要好高騖遠，真覺得案子怎麼寫都行，只要＂好玩＂；也不要被案子、程序實現、美術表現限制住自己。極端大部是給天才和失敗者用的因為策劃文檔主要在內部流通，所以不必像PPT一樣為了展示而展示，各個策劃風格分明，不過大體模塊分為分為系統流程（內在邏輯），功能詳解，還有美術需求三部分。
以下是個人認為比較優秀的一份策劃文檔
！！！奇怪，為何有張圖總是上傳失敗？先佔坑，有空再填
我也拋磚引玉說說自己的看法吧
我個人習慣把寫策劃案分為2步：1.前期對「設計目的」的思考2.新建文檔，寫具體「實現方式」一、設計目的
——————你設計這個系統的目的是什麼？設計目的一般經過2個步驟而形成：發現需求、分析及確定需求1.1 發現需求：
幾種常見情況：
①玩家驅動
I. 玩家在論壇/貼吧/QQ群討論：「別的遊戲都有翅膀，你們沒有翅膀！」——外觀需求「天天殺那幫菜鳥我都膩了，我要跟高手過招！」——Pvp需求「我掛機時被人殺了，裝備爆了七八件，魂蛋我要報仇！」——被殺記錄的需求II. 客服反饋運營反饋「chuck！玩家對xx系統意見很大！我這邊壓力山大你快幫忙解決一下！」②自己驅動
I. 觀察別的遊戲：比如你發現其他遊戲的玩家，很喜歡買月卡，你一分析，發現人家月卡做得確實好，環環相扣方便體貼還有促銷大優惠買到賺到。或者你發現別人核心玩法引導融合在新手流程中，自然流暢結合劇情易懂又好玩還有爆裝備搶美女的噱頭。II. 觀察後台數據（我後來才知道很多公司是不開放後台數據的）：比如：xx級玩家活躍度不高、在線時間不長、充值不高、等等③老闆驅動
例：老闆說：「chuck！我們的次日留存要達到xx%，七日留存要達到xx%，七日arup要達到xxx！you can you up，you can"t you get out！」1.2 分析產生需求的原因，以及如何滿足需求。
好，現在你眼前有了一堆需求要解決。但我們要如何去滿足呢？別急，先分析一下需求出現的原因。
假設我們觀察後台數據，發現：xx級玩家活躍度不高、在線時間不長、充值不高。那就讓我們來分析原因，為什麼會出現這種情況？玩家在線時間不長，是我們玩法不夠多？還是其他玩法沒有吸引力？如果優化現有玩法會有什麼效果？充值不夠高，是我們充值壓力沒給到位？是充值性價比不高？還是我們遊戲的目標群體不願意花錢？假設一番思考後，我們確認了如何滿足需求：增加一個新玩法、產出新的增加能力道具（消費坑）。註：實際情況當然會複雜很多，以上只是簡單舉例。另外一般來說需求應該由策劃發現並提出，等到老闆或其他人來提需求，可能意味著策劃的失察。
二、實現方式
2.1核心玩法設計
這個主要靠積累和想像力，一般來說就是腦袋裡閃過無數種玩法模型、想像各種組合。如果你是山寨，那還要考驗一個觀察力。在此就不細說了。（山寨也看功力，像老美把刀塔傳奇這種牛逼產品山寨得更牛逼在美國市場大紅大紫，我也不得不翹一個大拇指）2.2列舉功能
核心玩法出來了，那麼為了讓這個玩法變得豐滿起來、為了方便玩家使用，還需要哪些功能呢？我習慣的做法是：先做加法，再做減法。即：先把所有有益的功能列出來，再砍瓜切菜刪去絕大多數性價比不高或和遊戲架構不符合的。2.3界面設計
設計一個「目標明確、操作習慣、包裝精美」①目標明確：I. 重要信息：用簡潔美觀的方式，把用戶最需要的信息列出來。II. 重要功能：把功能重要程度排一排次序，越重要的功能放在越突出的位置。②操作習慣：I. 一看就懂。讓玩家不需思考和閱讀說明，憑直覺就能操作。II. 操作輕鬆不累。在腦袋裡模擬各種使用情景，做到玩家多次重複操作也不累。③包裝精美：I. 氣氛：一般來說，主題上符合遊戲背景故事。畫面上圍繞玩法主題來搞一搞氣氛。這個蠻考功力的，我也希望有前輩來指點一下。II. 界面美觀：簡單來說，你草圖和原型靠譜、參考圖給到位；主美嚴格把關；你個人和美術同事關係好點，多讓他幫忙優化一下，盡量做到你們團隊的極限水準就好。2.4具體規則
如果說，核心玩法是靈魂、界面是外表、那麼具體規則就是支撐這一切的骨骼了。把整個系統拆解成一個個組件，來講解吧。窮舉各種可能發生的情況，保證整個系統能按照你的希望來運轉，在極端情況下也不會失控。也注意小的操作體驗和外觀瑕疵，這些會影響玩家對系統品質的評價。主要就是一個「細」字。寫完了多檢查，一切要素你都寫下來了？美術和程序實現了這些要素，組合起來後，它就是一個完整的系統嗎？2.5優化排版策劃案存在的主要目的就是：把你的意圖清楚、全面地傳達給其他同事。好的策劃案，一般看得輕鬆，容易理解。最好是掃一眼看到所有關鍵點，有印象。I. 多用圖片。一般來說，人比較容易記住圖片，也更願意看圖片。II. 段落清楚分明III.多用加粗、字色。關鍵點很容易在一大排文字中被忽略掉。把它們標出來。註：最好還是畫一張流程圖，熟練後不會花多長時間，效果非常好。第一坨是總綱，遊戲的目標是什麼，fun是什麼，目標玩家群是什麼，核心玩法是什麼，etc.
第二坨是各大玩法的系統的描述，包括詳盡的規則、程序需求、美術資源等的需求簡表。第三坨是基於系統的引擎需求描述，這個要跟主程序商量著來。第四大坨是工具的需求描述，也是和程序LD商量著來第五坨是content list，包含遊戲所有內容的需求第六坨是各種PPT，對以上各種文檔的可視化概覽，用來給針對不同團隊講（程序，美術，PM，投資人，等）第七坨是和PM、主程序、主美術一起做的task細分列表，然後交給PM做成plan追蹤進度最後是change list，對以上各個文檔的維護歷史。我經手的幾個項目，只是頁游，word文檔和各種excel就上G了。遊戲策劃案的目的是讓程序、美術、測試和策劃一起完成功能或者系統的製作。
策劃案的開頭：1.闡述功能或者系統的目的2.闡述要製作的東西如何能達到文檔的設計目的3.關於策劃案的風險或者後續拓展點的思考，為後續決策做參考。4.如果涉及到一些晦澀的名詞，在這裡也可以醒目標記下，方便閱讀者理解。策劃案正文：1.一般看具體文檔的製作內容，按照邏輯進行拆分。比如任務文檔，則可拆分為接任務、完成任務和交任務三個部分，分別寫對應的文字包裝和判斷邏輯等；比如戰場玩法，則可拆分為進入條件、戰鬥規則、勝利條件、收尾處理等，分別寫對應的包裝和邏輯。2.系統的設計完成後，需要補充數值的設計，比如怪物的設定、技能的設定、涉及到的道具的屬性設定等。做到清晰，閱讀者能夠理解。策劃案結尾：1. 最後需要補充涉及到的美術資源的要求，比如圖標大小，圖標樣式；場景的大小，場景的規劃圖（這裡是再次總結，在系統涉及部分就應該標明），場景風格。2. 因為所有的涉及都存在涉及風險，如同策劃案開頭所說，需要對於功能的相關日誌進行記錄，以便於後期優化和調整。具體記錄的內容取決於風險點的類型，比如任務日誌，一般需要記錄接任務日誌，交任務日誌，日誌內又需要記錄玩家的等級、門派等情況。最最重要的是，以上所說的是整體的策劃案框架，好的策劃案的根本目的是讓別人明白你要做什麼，如何去做。那麼，對某個項目而言，檢驗你策劃案是否好，最簡單的方式就是讓一個完全不知道你要設計什麼的人去讀你的策劃案，他提出的疑問即是你的問題所在。真是悲哀，策劃寫策劃案難道目的就是讓執行同事能看懂即可？？？寫出能看懂的是最基本要求吧，格式什麼的有那麼重要？不同程序美術解讀文檔的能力肯定也不同好么。
我覺得要寫好一份策劃案，首先要明確你的設計目的，明確你的設計方式，明確遊戲用戶的行為習慣。策劃案最怕就是目的和設計方式不匹配導致返工，最怕無視現有設計方式進行「重新設計輪子」。
個人見解:
1 你的這個設計目的別的遊戲有嗎，他們怎麼設計的，能不能照抄，要修改如何改，會不會引發新問題
2 最重要的，好玩嗎，這樣做好玩嗎，玩點在哪裡？
3 ui設計是否符合現有習慣
我感覺完成以上3點再開始做案子比較好。
從業多年，寫過的文檔加起來也有好幾個g了，但我現在認為最好的辦法就是不要用所謂的策劃文檔，當然，必要的資料庫，數據表格，流程圖，示意圖還是非常重要的，這和所謂的策劃文檔不是一碼事。
我是個不寫文檔派，原因有幾點：1，文檔，寫著浪費時間，看著更費盡。很多程序員都不愛看文檔，直接當面說清楚，大家都方便。2，文檔其實是一種非常低效的交流方式，在寫和看的過程中非常容易丟失信息。舉個簡單例子，但策劃和程序員當面溝通的時候，可以通過表情、肢體動作來強調哪些東西是重要的，哪些是次要的，而文檔就沒這種功能。3，文檔並不能像一些人想像的那樣明確需求，劃清責任，相反的，對同一句文檔的不同理解會造成更大的矛盾和溝通障礙，為了解決這些矛盾，又必須進一步的指定規範來明確文檔的標準和寫法，這就陷入惡性循環，最後大家都疲憊而無所得。有效的當面溝通、即時的跟進，項目同伴之間的互相信任，這些才是問題的解決之道。如果一定要寫文檔，我的建議是把程序員和美術當成是用戶那樣來看待，多舉例，多配圖，盡量生動，少文字，沒有哪個用戶願意在使用產品前讀大段大段的說明書的，而策劃的產品就是設計，用戶就是程序員和美術。感覺上面很多答案，說的都太面兒上了……
目前國內的策劃，很多還到不了去照著上面一條條做的地步，
因為他們完全沒有做到
在 內 心 里 已 經 想 清 楚 整 個 游 戲 流 程 和 細 節
這個才是對策劃來講最重要的
很久很久以前，一個程序跟我說，遊戲策劃案其實就像 用中文寫程序一樣。
問這個問題的時候首先想想，遊戲策劃案是幹什麼的？是將你腦子裡想的東西寫出來，對吧？想的東西包括什麼呢？想法，安排如何體現你的想法和安排呢？就像一個導演一樣需要掌握遊戲中的一切，什麼時間，什麼地點，有什麼人（限制條件），發生什麼事（結果），如何發生（規則）。誰來實現你的想法呢？程序，美術那麼程序，美術需要知道什麼呢？先說美術許多美術上的東西很多策劃都不懂（像我這樣懂3DMAX，photoshop和素描的策劃很少，哇哈哈哈~）你可以和美術商量，在你需要效果和硬體技能以及公司技術的前提下制定，模型面數數量，主角在屏幕中所佔的比例，以及UI的排布，風格等等。如果是製作人的話，就需要制定整體遊戲的色彩風格，造型風格，動畫風格等等內容。再說程序程序是製作遊戲中的最後一環，所有的東西都需要到程序這裡「跑」，才能進行綜合調整，比對。這也就意味著程序需要遊戲中的所有東西（資源，規則，流程，數據，演算法等等）。所以如果你是新手策劃，而且當你周圍沒有比你靠譜的策劃指導你的時候，你的遊戲策劃案老師就是程序。但是程序需要什麼呢？（很少有我這種又懂美術又懂程序的策劃，哇卡卡卡~）前面已經提到了。但是有一些冗餘內容在裡面。資源，是美術最關心的。程序只是需要用到資源（什麼樣的資源一般情況下，策劃和美術商定好了，特殊資源，程序也需要根據需求增加對該資源的要求）。演算法，程序確實很關心，但是跟策劃沒有關係（我雖然懂程序，但是演算法上我也幫不了。術業有專攻嘛）剩下的就是策劃案中程序最關心的內容。規則，流程，數據規則包含什麼？例：裝備升級：裝備升級有什麼限制？需要什麼道具？需要多少花費？升級成功率公式是什麼？升級成功之後那些數據有增長？佩戴條件會不會改變？失敗之後有沒有降級？那些數據有變化？）流程是什麼？流程跟程序關係相當密切，如果流程圖你不會畫的話，你確實需要學習一下了。系統如何開始，如何進行，中間發生任何情況，發生之後會有什麼處理方式，需要詳詳細細的寫出來。（就像用圖表和中文，用面向過程的程序方法寫一個系統）。數據是什麼？數據包含數據類型，數據名稱，數據的作用，甚至需要和程序商討數據結構。舉個栗子：裝備升級具體有那些限制？（裝備等級int，裝備品質int，玩家等級int，完成任務int/string，在這裡你就要填上具體的限制，多少等級的玩家，多少品質的裝備才可以繼續升級，）int，string這兩個是你的數據類型，不懂得可以問程序。這裡面有些數據目前可能會用不到，例如完成那個任務，但是你要告訴程序，以後遊戲內容擴展時可能會需要更多的限制所以我先預留在這裡。知道了這些，你就用一個容易讓人看懂的方式將你的遊戲想法和安排寫出來。畢竟你的策劃案是公司內部給 美術和程序看的「腳本」 看得人理解力不一樣，你的方式就可能在細微處有差別。
-------------------------------------------------------------------------------------------------------------------------------------------給美術看的文檔，以圖為主，文字為輔。給程序看的文檔，以流程圖和數據為主，文字規則說明為輔。PS：切記！！！遊戲策劃案不是，也不可能是一蹴而就的，都是在不斷地溝通和反饋中完成的。——寫給老闆：這個功能能賺錢、這個功能能增加玩家在線量、這個功能能粘住用戶…………
——寫給程序：這是所有功能模塊，1,2,3,4……，第一個模塊有這幾個部分：1，2，3，4……——寫給美術：這是美術圖量表和效果表現表，一共有8張圖22個特效。第一張圖有3張圖片、4個按鈕…………每個部門需求不一樣，他們所要求的策劃文檔也不一樣。你只能盡量在你寫的文檔中滿足這些要求。當然，這個文檔要有一條十分重要的屬性：「易讀性」——條理分明、層級清晰、主次明確。有時候，並不是寫的越詳細就越好。
我個人經驗，供參考：1、首先你要能畫原型，這邊我建議使用axure。能非常好的把你所想要表達的功能流程展現出來，省了你很多時間。2、其次你要去網路找到一些參考圖，找出兩三份比較GUI表現較好的。這個主要給美術，也是axure元件庫的主要來源（如果沒有可下載的元件庫，那麼你只能自已做，現在網上有一個小樓元件庫是開放下載的。你也可以加一些axure群去群文件里找有沒有這方面的元件庫。當然axure本身也有自已的元件庫）3、接著用PS修改這些參考圖，將大體的功能模塊以及位置給定下來。然後使用axure將這些功能模塊鏈接在一起。（axure特效不多，但基本夠用。比如淡入淡出、滑動、切換、燈箱等）4、當低保真原型做好後，就可以考慮立項了。一步步的正常往下走，結構框架圖（用思維導圖或者viso把流程圖以及相互關聯性畫出來）——表格形式的美術圖量表、特效效果表——功能模塊具體設計（功能設計、相互之間關聯性、所引入的資源以及特效編號、各種注意事項，比如斷線重連、一機多號或者一號多機、AI設計、後台LOG統計等等）最後我個人建議：在做版本計劃時，最好把測試這一環節的時間放長，千萬別為了趕工期而急著上版本。然後在做甘蔗圖時要注意一個道理：「策劃文檔先行、程序美工齊頭並進」策劃案的目的是為了什麼？個人覺得策劃案就是讓美術、程序、測試、策劃拿到案子以後都知道這玩意，說的是什麼？然後，清晰的知道自己在做這個案子的時候需要做到哪些事情。達到這一點足以，至於什麼格式的都是浮雲！
我來談談我的觀點吧，與伊力其、戴鑫一樣，我日常寫的文檔就是詳細的將我心目中的遊戲描述出來，得虧我以前寫過代碼，所以寫的時候也會考慮他們如何實現，有時候也會順帶的寫一點進去。
但是，
1，你總會發現你有一些沒有想到或者你默認這個東西大家都這麼想的功能模塊流程，程序或者美術那兒沒想到。好一點的他們會來問你，不好的自己就想當然的做。譬如：大家可以看看＜放開那三國＞手游的登陸流程，一個流程是確認帳戶信息，一個流程是確認登陸伺服器信息，當玩家第一次打開這個遊戲的時候，如果沒聯網，伺服器信息是不會顯示的，如果你這一點沒想到，你家程序也許會給你默認顯示。然後是當你註冊帳戶點擊確認後，直接進入了推薦伺服器進行遊戲。如果當時你沒有考慮註冊帳戶後是返回主登陸界面繼續選擇伺服器還是直接就讓玩家隨便進入推薦伺服器玩。程序也許會默認給你一個驚喜。
以上的例子基本上無傷大雅，因為傷大雅的不能說。
2，你將一個策劃們討論好的東西扔給程序美術做，他們就會認為他們只是一個執行者不是參與者，事無巨細的都會來問你，你擔責任卻沒有工作量，他們擔著工作量卻沒有責任，最終會導致很多做一做交差的情況出現。朝九晚五領工資跟工廠上班一樣，這樣子很難做出好遊戲，當然，如果有一個非常有領導能力的人也許會帶得動這些人，但是這種人第一難找第二難留第三難養。
3，開發過程中有太多太頻繁的迭代了，有時候一個策劃案會改特別多版本，改到最後你都可以放到github里做血淚史了。當然也會有懶得改的飄逸型策劃，負手而立，站在程序美術後面指點江山，策劃案只有初版。然後呢？他效率高，跳槽或者高升了以後，你跑過來一接手，哇靠，確定這是同一個遊戲？
在非工作中，我也會想一些點子，整理成我自己風格的策劃案。策劃案中沒有具體的實現，只有願景和開發塊面框架。
比如我想做一個沙灘排球的手游，這個手游的核心塊面排球應該怎麼打應該怎麼做，我有有一個底稿，會以一個附錄或者舉例的形式描述出來，然後我會想和大家討論，這個怎麼做會比較好，怎麼做會有什麼風險怎麼做會很好操作。讓所有人都參與進來，大家都是設計者，最後可能會有一個初步的方案出來，然後迅速開發一版核心模塊的demo,然後大家一起來看，什麼地方好，什麼地方有需要改進的地方。不停的迭代，當這個塊面大體滿意時，進入下一個塊面，沙灘排球的賽程怎麼確定，等等。
這種模式就和以前的小手工作坊一樣，沒有了明顯的職業劃分，避免了在某一開發階段，某一類特殊工種無事可干但是其他工種忙得跟狗一樣的情況，最後項目中總是缺人，卻總是有人沒事做，不停加人最後會傳染成大家互相推脫的情況。
當然這種模式非常非常非常依賴人，只要團隊中有一人離開，這個項目就很可能擱置很久。
偏題這麼久，其實我認為的好的策劃案是說出了我想做成什麼東西，而不是事無巨細的寫出我要讓你怎麼做這個東西。
這樣只寫出框架會讓團隊里每個人都知道團隊的目標是什麼，怎麼做就是團隊能力的事了。長篇大論，一拉到底，如何寫好？請參考各大電器說明書。
您好，您好，藍港有款秒掛的遊戲，，那個策劃案，現在還保留著么
推薦閱讀：
※推薦100款遊戲策劃最應該玩的遊戲？
※如何在遊戲中設計出「快速移動的速度感」？
※影響技術對抗類遊戲勝負的因素都有哪些？
※為什麼有些遊戲會採用自動戰鬥系統？
※從事遊戲策劃工作，如何制定職業規劃？