為什麼策劃和程序之間沒有產生技術策劃（Technical Designer）這個職位？
既然已經有不少次世代、3DMMO、3A項目中出現了技術美術（Technical Artist）這個職位，就說明到一定要求時項目就會需要美術和程序之間的橋樑職位。那麼為什麼沒有聽說在某些項目里出現策劃和程序之間的橋樑職位呢？
是有的，很多國外的3A項目都是有這個職位的。我在現在的項目也在做這個職位。讓我們來看下育碧的technical designer 的要求吧： Technical Designer
Relevant experience
? Minimum 5-10+ years in technical design, scripting or level design
必須在技術設計，腳本或者關卡設計領域有5到10年的經驗? Must have shipped a minimum of 3 AAA titles
必須參與制作過至少三個已發行的3A遊戲Skills and knowledge
? Game or level design (profile: more technical than creative)
具有遊戲設計和關卡設計的相關知識? Curiosity and drive to understand how things work
對於懂得遊戲技術方面如何工作有好奇心和動手能力? Solid analytical and problem-solving skills
紮實的分析和解決問題的能力? Adaptability, autonomy, proactivity
適應能力，自治力，主動性? Structure, attention to detail, efficiency
架構能力，注重細節，有效率? Ability to clearly express ideas (spoken and written)
具有清晰表達觀點的能力? Ability to understand and communicate in technical language
有能力懂得技術辭藻並且使用它? User focus
注重用戶的感受（主要指提供給項目內的工具）? Experience with engines and/or platforms at an asset
有引擎方面的知識? Experience with 2D/3D software an asset
有2D 和 3D軟體方面的知識（其實就是photoshop, 3dsmax, maya之類的）? Programming/scripting experience an asset
懂得編程和編寫腳本? Knowledge of the Office suite
會用office
看到這裡我相信同學們對這個職位有了大致的概念。其實這個職位的主要作用是：
- 運用自己的一些技能對遊戲的模塊採取基本的實現原型
- 不斷迭代使其可以便於被所有項目的數據成員使用
- 教導並協助設計師們運用這些工具製作遊戲的內容
- 做一些艱難的技術選擇
- 和創意總監（creative director），主設計師（Lead Game designer）做一些設計上的艱難選擇。
- 修一些非常難修的bug
- 為項目發賣保駕護航
但是，這個職位不是必須的。總的來說是要看項目要做什麼，項目的規模和組織架構的。事實上遊戲製作當中的職位其實也就只是你分工的一個ID。很多遊戲甚至沒有程序，沒有策劃，沒有美術， 比如《星辰穀物語》。因為這是一個人做的，他既是美術又是策劃還是程序。所以我非常鼓勵不同工種的同學去學其它工種的工作技能，這對與提升你的整體價值是有天翻地覆的改變的。策劃不一定光去學程序，也可以去學美術啊，這樣資源就可以自己做，多好啊。所以我相信，技術策劃的確是可以給策劃同學兼顧掉的，事實上我相信大部分的策劃同學多多少少都在做一些這樣的工作。但這麼說來，這些國外的3A studio為什麼要進一部細分呢？ 原因大致有這些
- 首先是項目管理，技術質量。需要的功能繁多複雜，同時多數的內容需要很完美的調整和提升質量（polish）。在這樣的前提之下，設計師還要兼顧內容好不好玩，系統平不平衡，用戶體驗好不好。所以讓一兩個人比較有經驗的同學來把關技術實現，制定規則同時進行技術工具方面的篩選比較好，對於領導來說項目也比較容易管理。同時還可以保證項目技術質量的一致性。
- 同時是效率，工作量和生活方式，國外的設計師在工作強度上來講完全比不上國內設計師這麼努力。如果真要996的話，早就告到政府那裡去了。 同時國外的同學比較講究生活質量，每年基本兩次休假，一次至少一周。有孩子的同學每天基本5點走人去幼兒園接孩子。國外的幼兒園對於家長來接孩子比較嚴苛，比如我們這裡加拿大蒙特利爾。如果到點家長沒有來，幼兒園會按分鐘加錢收加班費，如果你遲到一個小時，有可能會交一筆昂貴的罰金。這樣的生活方式之下，3A項目主張細分工同時提高效率編程重中之重。多個項目的事實證明，有一兩個technical designer其實對於這些都是有好處的。
- 救火隊，很多時候項目在製作的同時會產生人員上的缺口。比如，「我們UI設計改了，現在要全部做成3d的」，「沒有人建模怎麼辦?" 通常這個時候technical designer會挺身而出說，」原型我來，細化再看！「。這樣technical designer 做起來原型建模的工作。
就是這麼多了吧，希望能夠讓大家對這東西有個大致的了解。：）
你說的如果是 「腳本策劃」
那一直都存在，在老式的遊戲公司里，都存在這麼一個職位。之前的東家前任上司也是以前寫過腳本的策劃。
在現有遊戲公司里，我知道的莉莉絲之前也是有在招 策劃 ，有一個職位需求是要能寫Lua腳本實現技能機制的，對代碼技術的要求並不高。
首先要搞清楚，遊戲公司招懂技術的策劃，目標不是為了「技術」」，而是為了更好的了解自身設計。
所以我的觀點是：
會做不代表專業，跨界會提高設計和執行效率，但是不利於專業化。大型遊戲中，交叉聯繫太多，除非程序提前構建好了非常良好的框架，否則讓策划去實現一些簡單的邏輯，後面很可能得跟著一個排的測試。評論一個策劃：
如果他腳本寫的很棒，但是他技能做的一塌糊塗，平庸之極另外一個策劃技能做的特徵鮮明兼顧平衡性，但是自己寫的實現非常糟糕，必須重構公司要怎麼評價這兩個策劃呢？你要哪個
你可以說我要招個兩個技能都牛逼的，請摸摸自己兜里的錢，這樣的如果這麼容易僱到，那我們這些瘸腿策劃 早就被趕出這行了結論：
腳本策劃 或者說 技術型策劃 經歷了 興起 - 逐漸式微 - 再次興起策劃的核心還是應該是遊戲設計水平，但是不會像之前一樣完全不需要有代碼或者技術實現能力，而是要求策劃本身在合作的基礎上有一定的編輯器腳本水平，能夠快速地驗證自身的一些初級想法，有效降低試錯成本。
當然我也認識幾個代碼水平和策划水平都很高的童鞋，比方說這個 @胡昆 ，一個廣告能頂掉欠你的錢嗎？胡總
在未來精品市場上，我相信獨立遊戲設計所需要的技能樹，會逐漸成為遊戲策劃的平均技能樹。有的。
目前EA主頁上開的一個缺。手機截圖，拼著看吧。
細節可以自己看。我就簡單說下TD在我之前工作室的日常工作。
當年作為Gameplay Engineer，和TD打交道非常多。許多TD的背景本來就是程序，只是因為懶得繼續寫代碼或者希望做更有創造力的事情選擇改行。然而其實我覺得他們每天要做的事比我機械多了。畢竟我覺得調數值這種事比寫代碼枯燥。
那時候策劃主要有兩種，System Designer和Tech Designer，所以很多設計SD和TD會一起摳。SD把握方向，TD研究細節實現。Engineer負責給實現搭系統框架，然後TD往框架裡面填內容。以前最終結果在engineer手中展現，有了TD之後就是engineer出原型，然後TD出成品。其中有利有弊吧，我個人覺得我被解放了不少生產力。
不懂編程的TD在食物鏈里是最底層，只能一遍一遍改平衡改觸發幾率什麼的，厲害的TD一邊可以寫策劃書一邊會直接畫behavior tree，我只要給他個邏輯框架，他自己就能把一整套行為填好了。
因為遊戲策劃本身就應該是掌握程序的，不然你如何提出需求？只有厚顏無恥的國游策會在那裡說，啊呀，我們只要想好遊戲好玩，提出需求就好了，可是你真的會提需求嗎？我相信大多國游策和程序的交流中，都存在著善意的欺騙，所以你真要成為一個好的遊戲策劃，你就應該會程序。如果你看不清下面文章的表或者圖，可以點這裡看我發的原貼：
[經驗心得]提煉出遊戲設計中真實的需求是高效開發的基礎 - GameRes遊資網
策劃的文案總是在說謊
在項目開發的時候，策劃會發現一個有趣的問題——程序做的功能總是不那麼順應自己的設計。也由此推論出了一個道理——好的程序員是懂的策劃心事的人——因為他們總是能做出看起來和策劃案需求一樣的東西。但是藏在這個問題背後的更深層次的問題是什麼？是程序的閱讀能力不行還是策劃的表達能力不足呢？事實上問題的關鍵在於——策劃寫的文案總是在撒謊。並不是策劃真心想玩弄誰，也不是因為策劃想賣弄文筆而最終表達能力不足。唯一的原因就是——文字描述的內容是表面現象，而非真實的需求。下面我們就來舉一段實際例子來深入分析這個合作中的問題，策劃設計了一個玩法（此處我們不討論以下舉例中的玩法是否OK）：
這是一個橫板的動作射擊遊戲，玩法類似於魂斗羅。遊戲中玩家可以收集4種不同的武器，每一關開始前，玩家都可以選擇攜帶2把武器進入關卡，一旦進入關卡，就只能在選擇的2把武器之間做切換，而無法選擇另2把武器。
武器
說明
弩箭
最基礎的武器，直線發出弩箭，攻擊路線上命中的第一個敵人，造成單體傷害。
投擲發射器
投出拋物線爆彈，爆彈落地後會彈跳2次，當2次彈跳結束後或者軌跡中碰到敵人時，爆彈就會爆炸，對範圍內的所有敵人造成傷害。
自跟蹤武器
可以發射出鎖定目標的子彈，自動鎖定最近的敵人，子彈一旦發出就會追蹤目標而去，直到擊中目標，對目標造成較大單體傷害。
火箭炮
重型武器，在較長的蓄力（表現為填裝炮彈並瞄準）後，發射出火箭炮，火箭炮慢速向前飛行，擊中路線上的第一個敵人或撞上障礙物後會爆炸，對大範圍內的敵人造成傷害。
分析背後真正的需求
我們可以看到，這是一個標準的國游策寫出來的策劃案，最多可能產生的不同就是「文字戲法」，但是核心內容還是如此。在這裡，我們就會簡單的分析出遊戲的玩法：
當我們列出這個腦圖的時候，我們看似已經想的非常全面了，不僅僅是對已知的需求進行了分析，還追加了可能延伸出來的其他需求。這個時候我們就會直接開始動手進入下一環工作——設計遊戲中的表格，我們的遊戲中會有一個武器表，表結構為：
表項
作用
Id
武器的id，唯一的標識。
武器名稱
武器名稱。
icon
武器圖標的資源文件。
說明
武器的說明文字。
子彈數量
武器可以裝載的最大子彈數量，-1代表子彈無限。
子彈軌跡
子彈發射出去的軌跡：0=直線，1=拋物線，2=追蹤。
子彈速度
子彈飛行的速度。
子彈參數
如果子彈是拋物線，那麼這個參數就是頂點高度；如果子彈是追蹤的，這個就是追蹤規則（blabla大段）。
傷害範圍
子彈打中敵人後的傷害範圍，0代表單體目標，&>0代表子彈的爆炸半徑。
傷害係數
子彈的殺傷力，用於帶到傷害計算公式中計算傷害。
聚氣時間
開槍時候需要預先聚氣的時間，此時角色會做出舉槍聚氣的動作，待聚氣時間結束後，子彈發射出去，玩家在聚氣時間是不能操作角色的。
冷卻時間
子彈發射出去多久以後可以再次發射。
武器圖形
武器拿在手裡的圖形。
子彈圖形
子彈的圖形。
命中圖形
子彈擊中目標時，播放的圖形效果，主要用於爆炸。
發射音效
子彈發射出來的音效。
命中音效
子彈命中目標時候的音效。
被擊表現
被子彈擊中的敵人做出的動作名。
最大等級
武器的最大等級，強化武器最終不會超過這個等級。
價格
武器賣店的價格。
稀有程度
武器的稀有程度，0=白色，1=綠色，2=藍色，3=紫色，4=橙色。
設計到這裡，我們大概可以滿意的說，武器系統已經設計完成了，程序實現了這個表以後，再把對應功能一做，遊戲中的武器系統就算完成了。我們也看到了分析這個需求的人是具有一定經驗的，能夠分析出可能擴展的玩法非常棒！雖然在設計表的時候發生了Magic Number、二義性名詞等錯誤，但是因為有了這樣一個表，策劃可以無限制的設計武器。
但是！上面的分析全都是錯的！這正是一個典型的被策劃善意欺騙的結果！
乍一看，我們要做的就是一個簡單的武器系統，武器在戰鬥中可以發射出子彈，還能強化。但事實上，這個需求真正的概念是：
所以藏在這個設計背後的，並不是簡簡單單的一個武器數據就能滿足的需求。我們深入思考幾個問題：
1， 子彈是不是必須是武器發出的？會不會地圖上某個點也發出類似的子彈？
2， 武器發出的子彈是不是一定的？我有沒有可能改裝某件武器之後，比如改裝弩箭之後，他可以發出榴彈炮來了？
3， 子彈是不是可以改造？弩箭可不可以發射出火矢、毒矢、冰矢？亦或者連續發射出不同屬性的箭矢？
4， 子彈的效果僅僅只是傷害嗎？我能不能強化之後發生變化？比如跟蹤彈在命中之後產生爆炸？或者更進一步跟蹤彈擊中目標之後散射出一排箭矢，其中一些是爆炸箭矢，命中敵人之後會產生爆炸傷害？
5， ……
當我們進一步深入思考擴展性的時候，就會發現很多有趣的設定，這些設定不僅可以讓遊戲變得更豐富，也同時可以埋下收費點。但是如果我們按照之前的那種分析，是不是我們就做不成了？當然我相信也不是，因為總有笨辦法的，比如你一種武器可以擴展出幾十種子彈，就讓策劃填寫幾十條數據……但是這樣的設計，並不是一個好的設計。
當我們通過進一步思考總結後，我們再來看上面這個腦圖的分析，事實上，我們遊戲中會有若干個數據結構：
Model與Object
在上面這個腦圖裡面，我們會看到好幾處用到了Model和Object（或者結尾Obj的）。這其實是設計的一個陷阱——我們通常把靜態數據（來自策劃填寫的）和動態數據混為一談。在這裡，Model就是靜態的數據，稱為「讀表數據」，是策劃從通過一些方式（如填表、編輯器）最後轉化出來的數據，這些數據始終就是那樣的，不會有任何變化。Object則是隨著遊戲進程變化會逐漸發生變化的數據。
Object和Model的關係是：Model是產生Object的依據，但是Model無法代表Object。
數據結構
1， 武器Model（Weapon）：這是策劃需要配置的武器數據。
數據
作用
Id
String，武器模板（或者說單種類武器）的唯一標示。
名稱
String，武器名稱。
說明
String，武器說明。
Icon
String，武器icon文件名。
造型
String，武器拿在手裡的造型文件夾名。
冷卻時間
Int，單位毫秒，武器使用的冷卻時間。
Timeline
String，使用武器（即開火）之後，角色會做出的動作，在這個動作中，會負責決策發射出的子彈等信息。
OnFire
String，武器發射後的回調函數，在武器發射開始執行Timeline的同時，會給出一個回調函數，調用策劃編寫的邏輯腳本，程序提供的回調參數：
l WeaponObj*：使用的武器。
l Character*：使用武器的人。
2， 武器Object（WeaponObj）：這是在遊戲運行中，結合當前情況產生出來的數據，玩家擁有的武器等都屬於WeaponObj，而不是Weapon。
屬性
說明
UniqueId
String，唯一id，在這個世界上，任何一把武器的實體都是唯一的，即使他們採用同一個模板生成。
Model
Weapon，非指針，而是克隆一個Model，即武器的模板信息，改裝等玩法可能改變這個武器的信息。
子彈
Hash&
等級
Int，武器當前的等級，當然還會有很多關於武器強化的屬性，這裡就列幾個說明一下問題。包括稀有程度（如果可以被提升），星級（如果可以被提升）都會放在這裡，如果不能提升的，
比如「AK47不論怎麼升級都是藍色的」，那「顏色」就應該放到Model中去。
價格
Int，當前武器的賣家，由於強化之後武器的價格會變高，因此他屬於Obj而不是Model，Model中頂多可以有一個參數用於獲取這個值。
3， 角色動作線（Timeline）：角色使用槍支、受到攻擊等，在遊戲中可以歸納一個角色任何的一個動作都是一個Timeline。Timeline有一個宿主，這個宿主就是播放這個Timeline的角色。Timeline上可能存在若干個事件點，每個點可能的事件包括：
事件類型
說明
播放動作
讓Timeline的宿主開始做一個動作1次，需要的參數：
l 動作名：播放什麼動作。
l 保持：保持某一段的動作（用於死亡動作等）。
場景特效
在場景中指定位置播放一個視覺特效，需要的參數：
l 特效名：播放什麼特效。
l 位置：在什麼位置播放。
l 循環：1次還是始終。
l 時間：如果不是1次的，那麼播放多久結束。
角色特效
在宿主身上播放一個視覺特效，需要的參數。
l 特效名：播放什麼特效。
l 綁點：角色身上某個播放這個特效的點。
l 循環：1次還是始終。
l 時間：如果不是1次的，那麼播放多久結束。
產生AoE
產生出AoEObj，即非鎖定類子彈，需要的參數：
l AoEId：要產生的AoEObj，他的Model的Id。這個會由Timeline產生的時候決策，是從某個WeaponObj的子彈Hash表中獲得，還是直接走讀取的值，這是一個有點Magic的用法。
l 位置：AoEObj初始坐標。
l 生命周期：AoEObj存在時長。
l Tween：AoEObj的運動軌跡和變化方式，不僅僅是坐標的變化，還可以設置如範圍等的變化。
產生Bullet
產生出bulletObj，即鎖定類子彈，需要的參數：
l bulletId：創建這個bulletObj所用的Model的id，和AoEId一樣有個Magic用法（我都不好意思再寫了）。
l 位置：bulletObj產生時候的位置。
l 生命周期：bulletObj最多存在多久。
l 速度：這發bulletObj的速度。
l 目標：選擇目標的規則，返回一個Character*。
開始僵直
從這個時間點開始，角色將進入僵直，所謂僵直就是不再接受操作指令，直到做其他動作（進入另一個Timeline了，比如受傷、死亡）。無參數。
結束僵直
從這個時間點開始，角色將離開僵直。無參數。
其他
以上只是一些舉例，根據實際需要，可以在Timeline中加入更多的動作類型，比如給宿主添加buff等，這個看項目的需要決定，而針對本文中的上述範例，是沒有這個需求的。
4， 非跟蹤子彈Model（AoE）：非跟蹤的子彈，實際上是通過AoE來實現的，包括子彈命中後產生的爆炸也屬於AoE。我們可以在AoE的2個回調函數中寫關於傷害等效果的邏輯。
屬性
說明
Id
String，AoE模板的id，每一個模板都是唯一的。
視覺效果
String，位於AoEObj位置上要播放的特效，可以沒有即不播放。
循環播放
Boolean，是否要反覆循環的播放這個特效，如果沒有特效這個就沒意義。
範圍
Int，AoE的初始有效範圍，實際有效範圍以AoEObj為準，由於這個遊戲的設定，因此範圍都是圓形的，這裡的數據是圓形的半徑。
碰角色結束
Enum，這個AoEObj在碰撞到任何角色時是否會結束？有幾個風格：
1， 任何碰撞角色都不會結束。
2， 碰撞到Caster同陣營角色結束。
3， 碰撞到非Caster同陣營角色結束。
4， 碰撞任何角色結束。
碰障礙結束
Boolean，這個AoEObj在碰撞任何地形的時候是否會結束。
OnEnter
String，當有角色進入AoEObj的瞬間觸發的回調，一個角色在一個AoEObj的生命周期內，只能觸發一次這個回調。需要的參數：
l AoEObj：AoEObj*，這個AoEObj。
l EnterCharacter：Character*，進入AoE範圍內的這個角色。
l CharacterInRange：Array&
l DesignParam：Array&
OnDestory
String，當AoE結束時執行的函數回調。需要的參數：
l AoEObj：AoEObj*，這個AoEObj。
l CharacterInRange：Array&
l DesignParam：Array&
5， 非跟蹤子彈Object（AoEObj）：在遊戲中的實體，根據實際狀況產生。
屬性
說明
UniqueId
String，每一個存在於世界上的子彈都是獨一無二的。
Model
AoE*，產生這個子彈的Model，由此獲取基礎信息。
釋放者
Character*，這個子彈的創建者，可能是Null，比如來自地形。
位置
Position，當前這個時間點上，這個子彈的位置，對於一個射擊遊戲而言，大多子彈的位置應該是經常變動的。
範圍
Int，子彈當前的邏輯有效範圍。
生命周期
Int，還有多久AoEObj就將結束。
其他
根據需要還可以添加一些其他的信息，包括可以給策劃一個Param來記錄一些動態的數據等。
6， 跟蹤子彈Model（Bullet）：會跟蹤的子彈，這種子彈只會追擊目標，直到命中、自身生命周期結束或者目標消失（或其他條件比如死亡）之後會結束。
屬性
說明
Id
String，子彈模板的Id，唯一的標識。
造型
String，子彈的圖形文件。
範圍
Int，子彈的初始有效範圍，同樣是一個圓形，所以這代表了半徑。
碰障礙結束
Boolean，子彈是否會因為碰撞任何障礙物而結束。
OnHit
String，當子彈命中了追蹤的目標後執行的回調函數，如造成傷害，產生爆炸等邏輯都編寫在這個腳本中。只有子彈真的命中了目標（或者碰障礙而結束的時候）才會進入這個回調，如果子彈提前消失就不會進入。需要的參數：
BulletObj：BulletObj*，這個子彈。
TargetCharacter：Character*，被擊中的角色，可能是Null，因為存在碰撞障礙物結束的可能性。
DesignParams：Array&
7， 跟蹤子彈Object（BulletObj）：跟蹤子彈在遊戲中的實體。
屬性
說明
UniqueId
String，世界上任何一個子彈都是唯一的。
Model
Bullet*，創建這個Obj的模板。
釋放者
Character*，釋放這個子彈的目標，可能是Null，比如GM指令創建的。
追蹤目標
Character*，子彈追蹤的目標，如果這個目標不存在了，子彈也就結束了
位置
Position，子彈在這一時刻所在的世界位置。
範圍
Int，子彈當前的有效範圍。
生命周期
Int，子彈剩餘的時間，如果生命周期小於等於0，那麼子彈也就銷毀了，不會進入OnHit回調。
玩法相關數據
到這裡，所有跟武器有關的基礎玩法的數據都有了。可能會有一個疑惑——那麼假如我遊戲中有合成武器的玩法，上述數據結構中並沒有任何相關的信息，是不是漏了什麼？或者說我應該把它們加在哪兒？合成這個例子是典型的、常見的。
我們可能會有這樣一個玩法需求——可以用多種材料或者武器合成一個武器。
我們直接跳過被欺騙的抽象，來看背後真實的需求：
在我們遊戲中可能會同時存在這兩種合成方式，雖然可能早期策劃並不這麼考慮，但是隨著項目的推進，運營的介入，這些都可能會成為最終的需求。因此我們要考慮到的是一個武器，可能會有多個「配方」來合成他。所以，我們需要設計的結構是：
數據
說明
id
String，每一個配方需要獨特的標識。
產出結果
Weapon，最後產出的結果的Model（但是產出的還是WeaponObj，是由這個Model為依據產生的）。
材料
Array&
資源
Array&
數據中，只有id是唯一的，意味著產出結果可以相同，因此「同一個武器會有多種合成方式」的需求是滿足的。但是這裡會延伸出一個問題——為什麼這個要獨立建一個數據？而不把它放在Weapon下，既然我是產生這個Weapon，那麼當然產生他的「零件」，也屬於他了。這裡有一個非常核心的原因——邏輯依賴性！
單向依賴圖
我們在研發遊戲的過程中，往往忽略了很多軟體工程最重要的一步——建立單向依賴圖（DAG，也稱單環依賴圖）。這往往是因為遊戲策劃或者程序員腦子裡都是漿糊，所以在設計數據和結構的時候，並沒有一個依賴關係的思路，最終導致做出來的東西是高耦合性的，至於高耦合有多危險，這個我就不多說了。
在上面這個問題中，我之所以把合成玩法的數據提出來，就是因為依賴性問題——在這個遊戲中，武器合成玩法依賴於武器，而（或者說也應該「因此」）武器不依賴於武器合成。你可以簡單的理解為：遊戲在沒有武器合成玩法的情況下並不影響有武器，但是遊戲在沒有遊戲的情況下就不可能有武器合成玩法，因此武器合成玩法依賴於武器，而武器不依賴於武器合成玩法，假如我們強行讓武器也依賴於武器合成玩法，他們互相依賴，就形成了一個耦合，這是在設計任何玩法的時候都必須避免的。
因此當我們設計玩法的時候，需要設計一個單向依賴圖（而不要去想設計一個毫無合理性可言的UML，至於具體噴UML的，這就不該是本篇的內容了），在這個遊戲系統中，單向依賴關係是：
每個玩法和元素之間的關係，都是單向依賴的，不會因為刪除或者改動上層的內容，而使得下層的內容需要作出調整，比如改變了武器合成玩法的規則，產生一些武器合成的數據要改動，我們只需要改動武器合成的數據，而不需要（也本不應該需要）改動武器數據結構。
從數據結構出發雙向發展
說到這裡，你可能覺得這樣的工作有一個問題——策劃有太多的數據表要處理。事實上，這是另外一個問題，我是這麼來歸納從策劃填寫的數據到遊戲中的數據的：
在上圖中有3個元素：
1， Input：即策劃填寫的數據表。
2， Data：即本文上述分析的一些數據結構。
3， Logic：即遊戲中使用的邏輯數據結構，其中一些恰好「長得和Data中對應部分一樣」。
我們通常的工作中，會直接把策劃填寫的數據當做最後邏輯用的數據來處理，因此建立了一張幾乎無法維護的數據表，當然這個無法維護不僅僅是因為直接使用，還因為上述分析的各種問題。這樣的工作中，我們漏掉了最終要的一環——Data的分析，也正是本篇上述範例中最大筆墨所做的內容。
為什麼我們需要一個這樣的Data？因為Data才是被研發真正依賴的東西：
我們可以看到，在這個依賴關係下，
我們只需要在系統設計的時候定出這個Data，就可以分頭開始工作了，程序根據這個Data來coding邏輯，而策劃設計一種input方式來產出這個data，程序本不應該坐等策劃先配完表（至少配一個測試數據）才能工作，程序的工作並不應該依賴於策劃的工作。
而作為策劃，我們最關注的還是input的環節，我們看到上面的實例中，有這麼多要我們去填寫的數據，我們真的需要配這麼多表嗎？回答可以是no，回到最初我們的需求，那個帶有欺騙性的需求，我們可以用最好的語法來填寫這個表，這個表只有一列：
當策劃填寫好這些數據後，通過工具轉換，就能產生出我們上述需要的Data：
至於如何將這一句話提煉分析成4個文件，這是文件轉化工具的工作，當然你別找我要這樣的工具，因為我們嘗試了5年讓人可以用自然語言編程（至少是填表），但都沒成功。也不要吐槽為什麼圖標是Delphi，這毫無意義……當然，這麼做的最重要的因素，不僅僅是整理了研發的思路，更重要的是做到了工作內容的解耦。
最後總結
有些需求，只有提出的人才會知道真正想要的是什麼，所以首先提出的人想要。最簡單的例子是，策劃的需求是一個蘋果，但是提出的是「圓圓的、酸酸的水果」，那麼橘子是不是也沒問題呢？所以無論你怎麼溝通，都不如你真的抽象好結構和實現方式來的OK，如何做到這樣，很簡單——你得會用程序員的邏輯方式來思考問題。
一般3A公司的LD都要干這事，一邊建粗模，一邊寫腳本。
粗模是給美術用，描繪功能，順便可以給點尺寸規格一類。（和AC系的3D地圖差不多，到時候美術直接換成做好模型貼圖的就行，實際會更複雜一些）。腳本就不多說了，一些基礎的執行需要策劃來做，當然這個就很多地方都有了。
一般乾的就是關卡搭建和世界細節功能設計一類的細活，這些事程序和美術其實都不沾（我記得業內只有聖莫妮卡的戰神系列是先有場景後有關卡的，其他的都是先想好再去構建世界），得策劃想好之後才去實施，然而不可能只靠文字描述去做好這一點，不現實，還得搭個有功能的粗糙玩意。個人感覺是因為,美術可以脫離技術存在,可以脫離"遊戲"存在, 美術是個獨立的個體,比如畫出來的畫,做出來的模型,靠的還是美術功底, 只不過做出來的東西被遊戲用了. 離開遊戲美術還是美術,畫出來的東西還是很好看
技術也可以脫離美術存在,可以脫離"遊戲"存在, 技術也是個獨立的個體,比如寫出來的代碼,[del]攢起來的bug[/del],靠的還是技術功底, 只不過做出來的東西被遊戲用了. 離開遊戲技術還是技術,不做遊戲跨度也沒有特別大
所以對於遊戲來說,美術和技術像是兩撥"外人", 而就技能本身而言, 從美術到技術的跨度可以說是很大的([del]圖形程序員不算[/del]), 所以有些時候需要一個技美來拉近技術和美術之間的距離.
而策劃是無法脫離遊戲存在的,至少系統策劃數值策劃這些,離開遊戲從事其他行業跨度是很大的, 策劃是遊戲的一部分, 好的策劃一定是要懂點技術的, 至少得知道自己做的案子大概會用什麼方式被實現,順帶提供給技術幾個解決方案以供參考(可能不成熟,但是一定不能原地起飛)
好的策劃可以讓技術不用想太多隻要寫代碼就可以了(有時候還要寫代碼給技術抄)早期遊戲製作中是沒有專職策劃的，基本上遊戲設計是程序員/美術同時兼任的。
隨著遊戲體量越來越大，程序/美術無法兼顧設計，所以才有現在的「策劃」崗位，而策劃本身的職責是設計遊戲規則並與程序、美術溝通，讓程序、美術還原實現這些設計。
所以策劃本身，一般來說要麼具備與程序溝通的能力（偏技術），要麼具備與美術溝通的能力（偏美術），只會純遊戲設計的話，在團隊中很難混下去吧以技術美術的標準來說的話，每一個核心的系統策劃，數值策劃都必須是「技術策劃」，否則根本混不下去。
現在倒沒有發現哪家招聘信息上有招這樣的人，但項目中或多或少，會出現這種很懂程序的策劃，或者很懂策劃的程序，在項目中扮演題主所說的這種角色。理想情況是大家都是通才，每個人，程序美術策劃都有所涉獵，然後各有專精，這就是精英團隊。招一個足夠好的專業美術、策劃、程序都得看緣了份，更不用說招一個在兩方面都能carry的角色，這種人通常招不到，招來身份很可能就變成製作人了。寫程序是一個需要全職投入的工作，遊戲程序員一般都是滿負荷運行的，能把需求做完不砍已經不錯了，有兼職干策劃的熱情也沒那個時間精力。而策劃這個工種實際上是很難做的，策劃的能力無法直觀測評，也沒有一個策劃案編譯器來約束策劃案的嚴謹性和邏輯完整性，而且遊戲的設計思維很受外部環境的影響，變化極快，導致策劃這行槽點很多。幹了這麼多年還沒有退出的話，大家應該習慣一件事情，那就是做遊戲就是這麼狗血，如果程序策劃美術都能多站在對方的角度看問題，真正重視彼此的問題，不要自己沒幹過，就下意識的就覺得對方的做的事情很簡單。就算都有這樣的專業態度，結果也不見得更好，只是合作的過程不會那麼痛苦。獨立遊戲，或者自己創業的，都是通才，至少團隊都很有經驗知道如何配合。而在公司打工，如果策劃不靠譜，那程序慢慢就懂策划了，如果程序不靠譜，策劃也就慢慢懂程序了，或者老闆等不到那天先把程序開了重招人。但要說招聘這種通才來改善現狀，抱歉了，這是你們程序和策劃自己溝通解決的事情，老闆可不會加錢招這樣的人，反正你們現在這樣不也能把遊戲做出來嘛！
我先說一句啊。
策劃確實要懂一些技術，才能夠合理地的提出需求，但是以為策劃學點程序，就能直接指導程序編程，那就大錯特錯了。
程序的水可沒有那麼淺。
懂策劃的程序才是必須的。換個說法，叫「需求分析」能力。
也就是 猴與花果山 說的那部分內容。這些內容確實是程序來做比較合適一點的。畢竟後續部分全是程序在做，你策劃程序再牛逼，能牛逼過主程么？誰牛逼，誰主事，不是起碼的事情么？
而如果你有了懂策劃的程序，貌似也不太需要懂程序的策划了，而前者目前容易達到的多（因為一般程序都比策劃腦子好使，經驗也更豐富），懂程序的策劃僅僅是為了減少懂策劃的程序的工作量而已。當然，這很有必要。
起碼，程序蒙你說這個功能無法實現，你好歹要能看出來啊？
但是這兩個職位，除非是細分細緻的大團隊都是沒有必要出現的。確切的說，這本來就該是所有成員都應該掌握的技能，因為並不難。
不會，完完全全是你自己的問題。
算了，我給大家舉幾個溝通的例子吧。
提需求的時候，不要扯什麼「隨機亂動」
而應該是「在屏幕下方1/4區域，隨機選擇一個位置，並以它作為目標以5單位/s速度運動0-0.5s（或者在到達終點後立即停止），然後循環（速度和運動最大時間可配置）」不要扯什麼「掉線後」
而應該是「連接斷開，或者長達20秒沒有獲得任何數據信息後」
（對於程序而言所謂的掉線就是系統給予的連接斷開提示，而策劃腦子裡的掉線就是角色長時間不動，你的腦子裡想的是長時間不動就不要用什麼「掉線」來概括）另外還有個最基本的，不要把「網路不穩定」，「幀數低」，「遊戲偶爾定格」，甚至是「人物動作不流暢」統稱為「卡」。
直接描述很難嗎？
而做到這點難道不應該是策劃的基本能力嗎？
而高於這部分的事情，策劃也請不要去干預。水深著呢。
-------------------
技術美術這個職位出現的原因，是因為美術，本來就包含了大量的技術部分（3D，粒子，優化，引擎和工具的使用，這些全都是技術活），需要有人去指導，負責，而不是為了和程序溝通（因為程序自己也不懂這些玩意兒），所謂的「橋樑職業」的說法只是一種望文生義的誤解。
所以，如果你說的技術策劃是：策劃里專門負責和引擎以及各種輔助工具打交道的人，如有這樣的需要，那就是需要的。常見在關卡設計上。
但是，它同樣不是什麼和程序的橋樑職業，是純粹的策劃技能分支而已。
至於溝通：說話沒有歧義，先讓自己理解，然後讓對方理解，這是基本能力，還扯不到橋樑職業這種玩意上去。不要小看職業（專家）。
而在溝通前，先自己想明白，則是更基礎一級別的事情。
---------------------
我這麼說吧，我們國內策劃溝通（以及本職工作）普遍存在問題，而他們把這種問題當成了理所應當。現在在很多策劃簡直就是在以老闆的思路做事，覺得啥事都該是別人考慮的，他只需要隨便BB一下就好了。畢竟確實不少策劃本來就是項目經理或者老闆。
讓他多考慮些東西還覺得委屈。
如果是這種狀況的話，說啥都沒用。
不會寫程序的策劃也許還能活下去。
不懂程序的策劃真是難。每次給策劃講模板和實例，看見他們理解不了的樣子都想直接幫他改策劃案。
了解面向對象很難嗎？又不要求你精通。嘛，給前東家在一個月內寫了一個小的Pascal腳本框架和幾百個腳本（其實真邏輯只寫了不到1百個，其餘都是自己又寫了一個小程序自動生成的腳本）。用代碼把各種美術資源打包整理，轉格式並導入遊戲中。基本上除了寫策劃案，其餘安排的雜活能代碼自動生成都走代碼走了。
然後遇上權利鬥爭，讓我走人了。
說好的技術策劃值錢呢？港真，U3D，Cocos代碼我也能寫。。。聽說，劍網三大部分gameplay腳本都是策劃自己編碼的。
別問為什麼，先問是不是。
在下就擔任過。
主要為策劃和程序做橋樑。
傾聽並更容易理解策劃的需求，翻譯成程序能懂的話與之討論最優方案。
！重點！並最快的速度完成這個工具，並負責該工具的教學和日後更新迭代。此外，就算脫離了程序，也會寫一些vba 甚至其他腳本來輔助一切和策劃相關的工作。就我觀察到的現象
一個能做出東西的項目組裡,要麼是有活躍的程序承擔了這部分職能,要麼是有偏技術的策劃承擔了這部分職能.在嘴炮輸出者和具體實現者之間架起橋樑.
如果一個項目組裡缺少這樣的人,那這個項目凶多吉少.
我粗略理解為腳本策劃。
在最初做端游時候，是有的，項目有2個同事一直在做這方面的。
我們做其他策劃的有時候也會參與，lua設計一些任務腳本，活動腳本。
後來我轉做頁游和手游後，這個職位基本不存在了。
你說的是小島這種王牌製作人，國內也有，少.
從軟體開發這個範疇來說，是有的。
RUP（Rational Unified Process）過程中中，使用UML實現需求分析和程序設計。題主描述的這個過程，在RUP中的定義就是一個建模和模型演進的過程：業務模型——分析模型——設計模型——實現模型。
粗略的說最初的業務模型就是對最原始需求對象的建模和描述，最後實現模型就是最終代碼介面級的設計。
而傳統的軟體開發團隊中，也有個職位來擔負這個工作：系統分析師（SA，System Analyst）。這個崗位要求對對需求和開發都很熟悉，運用專門的技能來確保挖掘出正確的需求，以及正確的演進到代碼設計。比如，RUP過程中的UML用例建模，對場景的的描述有近似八股的規範要求。例如強制使用主謂賓形式來描述交互，主語是使用者時，謂語會轉化成調用介面，賓語是會轉化成數據對象及介面參數。主語是系統時，賓語會是借口返回數據對象，如果主謂賓之外有定語狀語等修飾詞出現，則一定會轉換為業務規則（實際情況當然要複雜得多，這裡只是籠統的說明一下大概的概念）。
上面這一堆可能看起來文縐縐的太多概念，其實重點是想說，在專門的思維方式下，需求分析和技術設計是無縫的。完美的分析模型和設計模型應該是對應一致。
現在流行的敏捷過程，這方面就不強求那麼八股了，但是本質上要求描述和表達的東西，還是一樣的。
（中國）遊戲開發有自己的一套崗位稱呼，但始終還是軟體開發的範疇。所以不管title如何叫，這個工作始終都是要做的。就我的經驗來看，一般是團隊中最高技術負責人（主程）來負責這個事情。
補充：傳統軟體研發團隊中，系統分析師向上銜接的需求提供方是外部客戶；在產品（遊戲）研發團隊中，需求提供方是內部的策劃；這方面稍微有點內外之別，但本質上還是一回事。因為策劃本身就是要具備這些能力的，但是目前策劃門檻太低，入門太簡單，以至於你打雜個幾年就能混上來了。。。。舉個例子，真實的，作為一個跑腿執策，我的主策跟我說年終老闆會問你有沒有自己學代碼啊腳本啊你就隨便應付一下就好了，我們文科生怎麼學呀，我們這麼笨，公司又不開講座，我們怎麼知道啊看不懂啊balabala，我。。。？。。。？？？？？？？。。。。。。？？？？可想而知，現在的策劃是什麼水平了，別問我她是怎麼當上主策的。。。她寫的策劃案水平。。。真的是相當感人。。她會讓我先寫一遍然後把我寫的詳細的案子用萌化(沒錯，就是萌化)的語言來改成很粗略的案子，然後我說這裡會不會不準確。。。她說「沒事兒，我和程序熟」我覺得吧這可能也算得上是策劃和程序溝通的一種藝術(撒嬌？)？？？？？可能是公司小項目周期短只要有點工作經驗都能來當個主策吧。。。。
看某人的答案給我看樂了。順便想起來一件往事。
當初剛入行的時候填表寫欄位，寫了幾個英文單詞，結果搞得幾個大齡程序員很不開心，跑來教育我讓我改成拼音。後來入職的新人小弟，本來還挺膜拜我的，結果一看到看到我的策劃表頭都寫的拼音，瞬間那眼神就變了。-- -#國內技術策劃之所以沒有，只是因為國內遊戲開發的瓶頸根本就不在那。
別說策劃懂不懂程序，代碼寫的一泡污的程序國內少了？但這並不妨礙別人賺錢。多少程序走江湖靠的不是自己的實力水平，而是從前東家帶走的代碼。再說了，現在遊戲行業也發展了這麼多年，老司機多的很，很多系統的邏輯大家都輕車熟路，實現功能根本就不是門檻。不是有個調侃策劃的段子嗎？策劃寫了一堆，程序看都不看直接問「你就說是抄的哪個遊戲吧？」而且話說回來，策劃的程序水平一般也就三腳貓，剛剛夠用，哪來的自信天天教人寫程序？
話再說回來，別看有些程序員天天BB策劃不懂程序，你以為你懂程序他們就不罵了？他們才不關心你懂不懂程序，他們關心的是你會不會增加他們的工作量。而遊戲改動最多的一般也不是邏輯，而是前端界面，這可不是你會程序就不用改的。推薦閱讀：
※小公司如何運作大的系統集成項目？
※在你的項目管理活動中，Excel 起了哪些作用？
※剛剛畢業兩個月的小白如何做好項目管理？
※長期婚禮策劃工作者應選擇考取國際註冊婚禮策劃師與國際註冊項目管理師（pmp）中的哪個更有益處？