作為一名遊戲策劃竟然還會編程是一種怎樣的體驗？

01-03

遊戲策劃編程

懂程序思維應該是作為策劃的基礎執行能力之一。

從執行層面來看，懂程序的策劃更加能清楚描述出自己的需求，更加清楚其可行性。在整體的執行過程中掌握主動，而不是被程序牽著鼻子走。這對策劃方案實現的完備有重要價值。

另外，策劃團隊中應該要有一名具備系統架構能力的策劃，因為如果程序的一些邏輯底層你讓程序那邊一個人做，很可能在具體執行上程序提供的框架並不能讓策劃滿意。因為很簡單，程序是程序思維，他們一般想著就是如何把它做出來，且最好能適應大多數情況。但對於策劃來說，可能用到的只有20%,其餘80%用不上;但20%卻又做不到位。做個比喻就是程序一般傾向做把瑞士軍刀，但策劃團隊想要的卻是一把鋒利易揮舞的刀。因此策劃這邊需要有個人，和程序同學描繪清楚策劃實現的邊界，並與程序同學構建一個完備且必要的的邏輯底層架構。

這一點在一些基礎功能上尤為明顯，例如掉落配置，Ai技能，關卡編輯，劇情任務編輯等方面。我當前接受項目就是這樣，由於之前的掉落的底層邏輯不科學，導致策劃團隊花費大量精力去做掉落的配置。現在通過架構優化後，現在只需要一張總表，一個人，通過各種掉落模板和邏輯配置，實現各種掉落配置。

事實上是，策劃不是真的要懂得寫程序，而是需要在程序層面上把需求描述清楚的能力。其實程序無非是一種邏輯化和結構化的語言，這一點上，與策劃本身的要求並無差異。

但是要強調的是，策劃對項目最核心的價值還是在設計層面，對一般策劃的要求，無非是」想清楚，說清楚」，想清楚對項目尤為重要，因為就算程序把你要的東西百分百實現了，想錯了也是白搭。因此我覺得，程序思維是一種基礎能力，它對你具體執行很有好處，但它對策劃本身價值影響並沒那麼大。

其實，實際上並沒有想的那麼美好。 @黎健松的答案其實很接近實際情況。下面是些個人看法：

1、懂程序其實更多在「落地方法」（需求描述、跟進執行）層面有所幫助，但設計最重要的永遠是「設計方向」的選擇與取捨，懂程序在這方面起到的幫助有限。不過，對於從引擎更本質的角度思考問題、寫需求提前砍掉難以實現的、策劃案的易懂程度與執行效率、最終結果與設計差異度等等方面，的確還是有幫助的。

2、排除自己獨立做遊戲的，大型項目里一個人其實很難兼任程序、策劃兩方面工作，兩個領域其實對專業性、工作量要求都不低，而且思維方式、評價標準差異非常大。同一時間，一般會有一個精通，另一個只能做到很淺的層次。如果感覺不到這點，可能真的還沒遇到在兩個領域做到頂尖的人，或者真的是天才。現實中，有所選擇，往往本身也意味著有所捨棄。

3、並不是每個自己評估後認為可執行的需求，都推的下去執行。每個程序技術風格與能力強項完全不同，最後給你做的程序或許不願做。強推需求正面剛程序只能得罪人，你後面的需求會更難做，現實最後往往是各方面角力妥協的結果。

以上。

//4.18補充換色細節的說明

瀉藥，我本身是hardcore programmer啊，由於也做過一些項目管理的工作，也算搭上邊，說兩句。

一種非常棒的體驗，就是以一種非常不同的方式來看待和解決問題，新的體位，新的快樂。

常規情況下，是策劃根據設計意圖和現有已知的做法提一些需求，然後程序來實現。

筆者一大快事就是從項目中炸出新的創意，更高的效率，所以做日常工作的時候會去和策劃做一些討論，然後去深入理解策劃設計背後的意圖，然後從程序功能的可能性上，提出更新更棒的一些主意。

新的做法

比如天刀中的「萬色隨心」的做法

萬色隨心《天涯明月刀》染色系統獨家揭秘

【一染春風萬色隨心】天刀重新定義染色玩法

/*4.18日補充修改：

比較多的人質疑換色不過是一個老的套路

我們之前有考察過傳統換色，基本上是貼圖一部分使用固定灰度色，然後有一個mask，再使用玩家定製的顏色乘上去，這個做法主要是會限制和破壞美術的設計，所以第一時間就否了，而且這個否定是「我們不再考慮換色」的這種。

然後這背後的思路是這樣的，通過和策劃美術以及自己玩遊戲，知道如果有一種換色可以維持美術的品質和設計，那麼這個是非常牛逼的。

雖然現有的常規做法有問題，但是這是一個值得探索的方向。

然後繼續去探索，也和美術經過幾輪的開發，中間有了結果也是存在哪裡，在上線之後作為一個階段的版本特性再來發

這個背後的技術核心代碼就是幾行shader，但是關鍵的工作就是和策劃以及美術了解當前玩家的關注點，玩家如何在遊戲中去各種打扮自己如何的個性化，我們那些外裝受到玩家的喜歡。

所以當一些設計精良的外裝，可以在維持原有設計品質的前提下，任意定義出新的顏色，這個背後的對於策劃和美術的設計來說是一個有極大意義的加強，但是當時項目組的策劃和美術都不知道可以這樣做（可以維持美術所有設計品質的情況下去換其他顏色），程序同學因為這個沒啥意思，也不太會想。

這裡核心點在於作為程序，知道常規做法的局限，但是從產品角度來看知道這個事情的意義，所以會投入更多的精力去尋求突破。

時裝才是黑科技聽風透明衣料幕後揭秘

另外一個案例是透明布料，我們都知道OIT（order indepent transparency)是有那麼幾種做法，但是效率都沒法在《天涯明月刀》這種支持超大地圖和超大規模pk的遊戲中搞定，但是從產品角度看，這個對於設計對於國風來講，有透明高品質的布料有多麼重要，所以我們會經過3輪的失敗嘗試之後，還會做第四輪的嘗試，最後呈現出比較好的結果。

再回來還有很多大家看不到的，就是團隊里有很多有想法，也想突破OIT限制的同學，但是產品意義沒那麼大，就及時叫停了，也是讓我們能夠更加聚焦吧

這個地方就是一個跨領域的意義所在。

新的效率和質量

當然大部分時候，不會碰上這些特別有意思的事，更多的時候是對需求的時候，開發效率的極大提升，當場就可以挑戰程序同學的方案和估時，有的說不能做或者要做很久的，當場就實現方案開擼，相當多的東西從不能做變成能做了，從2個月變成2個禮拜了，

還有就是策劃同學的案子非常有可能修改，就把東西進一步抽象出來，程序同學去實現一個擴展性更強的框架型的東西出來，做完了策劃悶頭自己配就好了。

這種常規性武器的升級雖然不起眼，但是其實是對項目更有意義的一點，項目其實也是過日子一樣了，財米油鹽才是真實情況。

總之程序也好，策劃也罷，把知識結構擴展過去，換一個視角看問題，就是不一樣的感覺！

看到這個題目，不免有點想回答了。我是程序出身（當年以為做遊戲就要從程序做起），從工作到現在寫了8年代碼，雖然中途也兼過項目經理，助理製作人，包括後來做獨立遊戲，也都是以主程的工作為主，這段時間無法完全專註於設計工作，主要還是在思考如何去落地實現這塊的事情，所以感受並沒有太深。近期轉型為製作人，同時負責一些策劃的事情，coding的事情做的比較少了，專註點更多的在設計上，現在再來回頭看，主要有以下幾個感受：

1. 為什麼這麼簡單的邏輯，他們（多半是新人策劃）會半天繞不清楚。（編程會訓練人的邏輯思維）

2. 為什麼明明可以劃分的很清楚的事務，他們總是攪成一團。（模塊架構設計長期訓練的結果）

3. 當程序跟你說這個有技術問題時，你可以直接給他們提供解決方案，或者與他們探討可行性方案，只要你能hold的住，以後再遇到類似事情就好辦多了。

4. 當程序因為不想做給你找理由時，你可以很輕鬆的識破。

5. 可以自己寫工具，寫腳本，提高做事效率。

6. 也是最重要的一點，在你設計遊戲功能的時候可以充分考慮可行性。反之也可以在已有的技術限制下設計出最貼合技術特點的功能。

先發個前陣子剛剛經歷的會議的出席人員圖……會議內容是一干技術部大佬審核我（策劃）寫的工程框架，評估其是否可以被拿來作為未來項目開發的基礎

作為唯一列席的策劃，感受一下這壓迫感：

（瑟瑟發抖）

作為一個對編程從近乎0基礎發展到這般慘境的策劃，這題目應該挺適合我答的233333

好了，言歸正題。首先我覺得需要釐清的概念是：「會編程」

會編程是個很寬泛的說法，因為從實習程序員到架構師，都可以說他們「會編程」，所以這概念可以說並沒有什麼卵用。從我的個人成長經歷來說，策劃的編程技能可以分為幾個不同的階段，而每個階段都會顯著影響其工作能力：

了解程序基本概念（變數/選擇/循環/數據類型/基本演算法名詞概念）
不需要接觸了解任何工具/開發環境API的情境下，有能力編寫簡短的程序邏輯
開始接觸開發工具/環境的API，有能力編寫特定的小型功能模塊
了解開發工具/環境API，開始有能力編寫幾乎任意功能模塊
開始有能力進行複雜的架構設計

然後簡單說說各個階段的體驗~

了解程序基本概念

這個應該屬於策劃的入行門檻要求，在職策劃如果連這級別都不具備在我看來都屬於不合格策劃。

只有明白基本概念才可能與程序員進行基本正常交流，寫策劃案時才能寫出諸如「遍歷玩家附近的所有怪物，攻擊其中生命值最低的三個單位」這樣的句子，稍微好一點的還能畫出流程圖來（雖然絕大部分情況下這些流程圖並不能直接轉化成實際演算法）

達不到這要求的策劃，幾乎肯定會被程序嫌棄

不接觸外界API，有能力編寫簡短的程序邏輯

不接觸外界API直接寫邏輯的，通常就是程序開放給策劃的腳本環境。比如開放一些lua腳本，約定好一些策劃可以訪問的數據，然後由策划去寫一些函數定義或者極微小的功能模塊。如果把程序員面對的實際開發環境比作汪洋大海，那麼這個受控的開發環境基本就相當於室內泳池；而且有的項目對策劃不放心，還自帶各種保護糾錯機制，相當於自帶若干救生員的室內兒童泳池。達到這個編程級別的策劃就可以勝任這種程度的工作了。

然而，這個階段的策劃，程序員很容易又愛又恨。

愛的是，這策劃跟他們溝通的時候，不需要在基礎概念上糾結，而且還能分點活兒出去讓他干，挺好；比不會程序的策劃好用多了。

恨的是，這個級別的策劃對於編程其實只是入門級別而已，但是有時候他們在這個小泳池裡游舒坦了，會覺得程序開發也不過爾爾，於是有時候案子能硬寫到演算法層上去，洋洋洒洒一大段，然而程序根本不能用。要是碰到自負一點的，這交流起來還能分分鐘把程序氣炸（「哎呀這功能有什麼難的啊？你看只要這樣這樣那樣那樣不就出來了嗎？」）~所謂的半瓶醋咣當響。

所以你問我什麼體驗？我曾經差點把合作的程序氣哭過呢好嗎，這體驗真是剛剛的。

開始接觸外界API，有能力編寫小型功能模塊

這個階段的策劃剛剛一隻腳踏出程序員們給他們圈好的安全泳池，走進了海邊的淺灘；他開始查看開發工具的API文檔，查看他能使用的功能，並且可以在沒有程序員保駕護航的情況下在VBA/Unity之類的平台上獨立開發一些小功能了。從我的經驗上來說，一個很好的區分標誌就是看他們對於「對象」是否有概念。因為在這個階段，策劃才會真正開始接觸面向對象編程。

這裡已經相當於專業程序員的初入門階段了；從難度曲線上來說，此階段的難度是顯著高於前一個階段的，所以大部分策劃都會被擋在這個階段。

也因此，我估計大部分自稱「會編程」的策劃，其實也都在這個階段。

從體驗上來說，程序員在和這個等級的策劃溝通時已經開始趨於親切了，他們會當著你的面用些專業名詞，如果你不懂呢也會願意花很短的時間解釋一下。但是如果你還是喜歡在案子里寫演算法呢他們也依舊會感到蛋疼。基本上，程序對你的態度接近於對待一個菜鳥同行。

而對於策劃來說，達到這個階段的能力，代表著一個嶄新的天賦樹的前置條件已經滿足了——工具開發。

工具效率應該是所有策劃都頭疼過的問題，而且程序員對於策劃工具的態度一般就是「能用就行了不要在意這麼多細節」，所以策劃手上的工具往往是匱乏的甚至沒有的。達到這個技能級別的策劃如果願意花時間花精力的話，可以藉助VBA/UnityEditor等現成的開發平台製作出許多能幾何級提升工作效率的玩意，因此這個段位的策劃，只要平台工具沒選偏的話，其工作效率往往已經和之前的策劃開始有質變了。

我在這個階段乾的最成功的事就是拿Excel和VBA做了一套新的數據表查詢工具和批量內容生成工具，換算到工作效率保守估算至少提升了10倍吧……

了解外界API，有能力編寫具體功能模塊

這個階段實際上就是正常新人專業程序員的水準了；換句話說，1-2年經驗的程序員能做什麼，這個階段的策劃也應該能做什麼；這也是策劃開始有能力「打臉」程序爸爸的階段了。隨著經驗的累積，這階段的策劃開始感知到實際開發環境的複雜度和深度了，不需要程序教導自己也會開始收斂，不會再在文檔里寫些空中樓閣般的演算法了；而程序在和這級別的策劃溝通的時候卻也願意主動涉及到演算法層了，可以說雙方的交流算是正式接軌了。

到這個階段的策劃，策劃案務實，和程序溝通順暢，俗話說就是「落地能力強」；甚至程序遇到困難還會主動來找策劃商討解決方案，整個是人見人愛花見花開……在程序員眼裡，你其實已經算得上是他們的同行了，所以混的夠好的時候程序部團建都會主動叫上你哦~（能混雙份團建一直是我的夢想啊桀桀桀）

而且到了這個階段，一個新的天賦樹分支也亮起來了——獨立遊戲。如果你願意的話，其實完全可以自己做一個小遊戲了。

而獨立遊戲——恰恰是開啟下個階段的鑰匙，當策劃想做的遊戲功能複雜度超過一個閾值的時候，程序開發中那個永恆的難題就會找上門來了——架構設計。

架構設計

實際上，根據我的觀察，很多專業程序員都沒有達到過這個階段。因為通常來說只有在極小團隊里（或單人）挑戰過一個甚至多個完整項目的人才會真正感知到這項能力的價值與難度。而達到這個階段的策劃，也具有了觸碰策劃工作最核心最本質問題的能力：設計。

相信很多策劃學習遊戲設計是從魔獸爭霸的World Editor開始的，可以說，在很多年前，WE就相當於現在的U3D，是最通用的遊戲引擎。如果你也是從WE入的門，那麼不妨想一想，你過往所做過的項目，有哪一個項目開放給策劃的工具，能給予你與World Editor相同的揮灑創意的自由度？

就答主自己的個人經歷來說，一個都沒有。WE，這個將近二十歲高齡的老古董，依舊是高高在上無可逾越的標杆。想想也是挺奇怪的，明明連源代碼都有了，還有專業的程序員在你邊上搗鼓呢，怎麼反而你能做的事變少了？

答案就隱藏在架構設計里。達到這個級別的策劃能將遊戲中的抽象概念從紛繁的術語遮掩下剝離出來，有能力用自己新提煉的概念語言描述他想要的設計，而且他能核驗和確保他提煉出的抽象語言足以涵蓋他最狂野的腦洞；他理解應該如何拆解遊戲系統，如何創建高效易用的工作流，確保遊戲能支持住未來的需求；最棒的是，他甚至可以不需要寫系統設計文檔了，因為他寫下的代碼本身就最直觀地闡釋了他的設計。這個時候的策劃，才真正有能力設計出World Editor這樣的東西了。

援引一下 @猴與花果山的答案：

在遊戲領域，編程就是開發出完整的遊戲框架，並且在這個框架的基礎上，任何人根據自己的想法設計輕易地實現出遊戲的任何設計需求（因為遊戲的設計需求總是在改變的）
……
最重要的是，真正能夠理解好遊戲業務，並且將之實現好的很多時候真的只有你自己，同時如其他樓提到過的，可擴展性，也只有遊戲設計師才最了解遊戲要怎麼擴展

看，這就是達到這個級別的策劃追求的東西。幾年前，有程序員問我為什麼要學編程，當時我回答說：「學編程就是為了有一天可以不用編程就能做出任何遊戲」，這話說的太過極端，但追求的目標還是很明確的——一個具有極高拓展性的、能滿足任何策劃腦洞的開發基礎。

所以達到這個階段的策劃是什麼體驗呢？就像猴與花果山說的，是孤獨。因為到這個階段，策劃會受制於「策劃」的title，要用自己的能力推動項目前進反而有點事倍功半了：如果程序員不願意按你的思路來，自己做的反而又很挫，你作為一名「策劃」其實沒什麼能力override他們……所以講真，爬到這個階段頗有些吃力不討好的意味……

我比較幸運，因為我的工作環境很特殊，在過去的2年半里，我一直處於單人工作的狀態，所以不需要掙扎這些蛋疼問題；另外題圖的那場評審也通過了，現在已經有一組程序在我的框架上工作了，現在明顯他們把我當同行自己人了，相處得其樂融融……反倒是策劃不當我是同行了……

_(:3 」∠)_

嘛，以上就是策劃會編程的體驗了~

感覺我可以替我們組裡做過前台戰鬥架構、之後被我逼去後台打工的策劃，寫幾句。

1 這時往往需要指導相關程序進行編碼。你沒聽錯，就是指導。更具體地說就是，就是確認一個需求變動，到底該對繼承組合關係抑或是處理流程進行何種改動，才能不影響以前的設計和未來的可能新增的需求，恐怕程序是極難回答的。

為什麼會這樣？因為這套系統，能做什麼，怎麼做都是嚴格按照策劃對系統的需要開發的（當然這對策劃架構能力要求很高），程序主體框架結構的代碼也被該策劃看過，只有一些細節實現他不關心。

2 自己開始實實在在寫代碼後，以前那些停留在想法階段的蹩腳邏輯一點點被幹掉了，也學乖了，知道有些玩意不好搞或者改了會死人了。當然最重要的還有一點，就是中間無謂的文檔變少了，直接給你寫出來後台介面，中間應該做的排除、統計、合併甚至優化都會搞定。這時1個人頂3個人。

3 但畢竟呢不是專業程序，業務固然能設計對，但像對象池、並發、延遲非同步等等相對複雜的機制編寫及處理上經驗不足，而框架性問題的處理上完全無力。不然，程序真沒飯吃了=_=

有好有壞。
好處大家都說了，
壞處我說一點，有時會過於考慮實現難度而放棄遊戲表現。

比如對一個遊戲功能有兩種方案，方案一表現力強但是開發成本高，方案二表現力一般實現簡單。作為一個程序轉的策劃會本能的為程序考慮選擇方案二，從而犧牲了遊戲品質。（即使他與程序員討論，程序員也會為了減少自己工作量而選擇方案二）

更嚴重的問題，有些程序乾的比較久了，甚至限制了自己的思路，全部從實現技術角度出發。從而根本想不出體驗好的方案一。

但是作為策劃本身是應該為遊戲體驗做出最大努力的，應該在開發周期允許的情況下把遊戲表現力做到最強。

當然這種情況在小廠是利遠大於弊的，國產遊戲（特別是手游）是不太重視遊戲表現力的，所以作為遊戲玩家，無形中就成為了受害者，原本可以吃到海陸雙拼披薩，現在卻吃了連芝麻都沒有都燒餅。
所以在3A廠，這就不見得是什麼好事情了。

作為策劃，即使被程序美術動作特效按住地上摩擦一百次，也應該為玩家爭取到最優秀的遊戲體驗。這是職業精神。

你看這個問題都沒人要邀請我：體驗就是人家都以為你做技術的。這麼懂產品大概是CTO…

策劃會程序是挺不錯的，然而既做策劃又做程序，就不是什麼好事了。

圖紙自己畫，結構自己搭，水泥磚頭也自己填。藍就那麼多，不夠用，怎麼辦啊。

工頭說：「咱就這條件了，克服一下吧。實在不行？那就給你招人吧。簡歷發我，我來幫你打電話約！」

於是我在前程無憂後台扒簡歷，於是我又做上HR了。

做HR也得耗藍啊，熟手太貴工頭不可能給招啊，招個半生不熟的還得耗藍去帶啊。現在項目已經挺有規模了，得熟悉個倆月才能帶起來啊。帶起來之前，新人不但構不成戰鬥力，而且會把我自己的戰鬥力給減半啊。目前總共就兩個人力，招個人過來，反倒成了一個半的人力了，降低25%啊，疼。

雖說長痛不如短痛，然而這短痛不是讓別人砍自己，自己只需要咬牙忍忍就好。工頭說清楚了，簡歷我去找，他只管打電話約。這跟我自己招人有區別么。

我自己招人，那這所謂短痛不就是讓我自己下手砍自己么。

下不去手啊。

所以還看什麼簡歷啊，有這功夫還是多搞下項目吧。

能者多勞嘛！

就這麼苟且著吧。

活該。

順便問一下，有了解pomelo和unity的node.js程序員有興趣聊聊的嗎？

或者，有文筆好，會寫世界觀，人設，劇情線（大量）且會玩vba的數值策劃願意聊聊的嗎？

有沒有人接我點活兒啊，目前條件只夠招一個啊，有萬金油啊不，瑞士軍刀式的特種兵找工作的嗎？

在上海漕河涇。

作為一個大學四年學了半吊子編程，參加工作幹了五六年執行策劃系統策劃，現在在家裡從零開始寫遊戲的人來說，對這個問題也算是有發言權吧。

體驗分為這幾個階段：

1，什麼都不了解，空有一腔方案。

剛入行的時候，滿腦子「好玩的」「前無古人後無來者」「絕逼很叼」的遊戲方案。對於「能不能做」、「怎麼做」、「誰來做」完全沒有一個大體的概念。在那個時候，學校教的只是怎麼寫代碼，代碼的語法大致是什麼，而並沒有教怎麼用代碼去構建一個遊戲世界。（當然也有可能教了我沒學進去?(? ???ω??? ?)?）

這個時期，我大部分時間都在學習和配置遊戲運行所需要的參數（俗稱拉表）。同時也慢慢的把一個很大塊的模塊通過一套套的參數反推如何實現，將一個遊戲慢慢的拆解成很多個組成部分。我個人覺得這段時期是最有趣的時候，空下來了就翻一翻其他組拉的表，看看別人欄位怎麼填的，自己試試改一改提交是什麼效果。到後來已經達到了看到什麼表就能猜到大致是什麼功能的境界了。此時也慢慢的學會了用腳本語言去寫一些具體的業務邏輯。

2，開始能從需求入手，分解成若干個可執行的模塊。

這時已經開始著手系統策劃工作了，工作重心已經從「怎麼實現」遊戲，變成「怎麼呈現」遊戲了。大部分工作都是在做遊戲體驗相關，怎麼實現已經算是駕輕就熟，而且後期磨合完畢後都是簡單的說明自己的需求，程序問起某些關鍵點時，自己也能根據他的思路提出解決方案。

這個時期，雖然自己會根據別人暴露的介面用腳本寫一些業務邏輯，但是介面之外的一整套系統是如何運行的，只能去揣度，並沒有實際的研究過。只能算是腦補，所以偶爾會發生我覺得這個實現起來很簡單，程序覺得很複雜（但不是實現不了）的情況。

3，開始從實現入手，窺視整個遊戲架構。

從零開始的日子是最難熬的，一大堆的新事物撲面而來，什麼是場景？什麼是節點？什麼是組件？怎麼就給了這麼點介面？應該從哪開始寫起？

這個時期，每次想實現一個功能點，就會絞盡我的腦汁，好不容易實現了，等實現下一個功能點的時候發現上一個功能點可能需要重新寫。一股掀桌之氣從丹田騰地竄上腦門兒，真是分分鐘想掀了不寫。

這個時候就知道程序架構的重要性了，雖然現如今的遊戲引擎已經非常易於上手了，但是針對各個類型的遊戲，還是需要有一個針對當前遊戲類型的遊戲架構，使得策劃能夠在這個遊戲架構上編寫各種遊戲邏輯。這也應該是遊戲程序最重要的工作之一。

總結起來，遊戲分為這麼幾個部分，遊戲業務邏輯，遊戲程序架構，遊戲引擎。策劃的工作應該是能夠實現遊戲業務邏輯；程序的工作應該是能夠實現遊戲程序架構，同時根據新的業務邏輯對現有的遊戲程序架構進行重構或者擴展；引擎程序的工作應該是對遊戲的性能負責，讓遊戲能穩定的順利的運行在各個平台之上。

這麼說來，的確策劃是必須要有程序知識的，最次也需要了解怎麼去寫一個遊戲的業務邏輯，知道怎麼去實現自己心中的遊戲方案才行。

以上就是我個人的體驗，希望對大家有所幫助，也算是應自己家領導 @曹萍的邀請了了她的心愿。

剛入職各種雜活都可以自己寫代碼解決。比如美術資源重命名，自動生成配置表表項等等。工作效率要高很多。

寫策劃案的時候，對程序開發來說非常好理解。比如用一些計算機專業術語來表達：原子操作表示前後操作一致性等等，深受程序好評，得到評價比很多老策劃都高。悲劇是，主策看的不爽(￣□￣；)

同樣，跟程序員交流也很方便，平時多問問就知道遊戲實現原理，架構。同樣，程序想偷懶說實現不了的時候，也能懟回去。導致程序天天勸我來寫代碼。

熟練使用各種辦公軟體，就算之前沒用過，但程序員最不怕的就是自學和網上找教程。所以各種辦公軟體上手非常快。

寫腳本也很方便，包辦遊戲所有腳本開發。導致遊戲的新手引導和任務腳本全是我自己設計自己實現，很有成就感。順帶覺得原來腳本框架太簡單，一邊開發一邊順手把原來腳本框架給升級了一下，做了一些面向對象的封裝和加厚了控制層的邏輯。寫了一個自動化腳本生成工具，後期添加腳本也方便。可惜後來離職的時候，接手我工作的人不懂代碼，我開發的工具全都沒能繼續留下來（因為我沒做界面，只能程序員用）。

非科班出身，做了九個月策劃，成功轉型cocos2dx-c++客戶端…

都是被另一個懶惰的客戶端給逼的…

做策劃寫文檔的時候需要自己寫一些小工具用來給客戶端提供具體數據和演算法，比如捕魚遊戲里為各種花樣魚群寫了個統一的動作指令，就那種只要輸入文字(比如"蛤蛤")，然後寫一些統一的指令，大概就是直行三秒，停止一秒，右轉，直行什麼的，輸入是一個json，輸出一個由指定魚組成的"蛤蛤"文字出現，移動…我得自己實現一遍再給客戶端說演算法;

比如還準備做規避政策的類似百家樂遊戲，得有個路單吧，然後我寫路單演算法各種路，費了我一個周末…

測試的時候出現問題得自己看代碼查bug再告訴客戶端怎麼改…

最後就是想加新功能自己寫…查到bug自己改…然後慢慢就轉技術了…

我個人感覺吧，會編程會提高策劃案的可行性。

其實我不怕策劃會編程，最怕學藝不怎麼樣還裝逼，以為自己會點編程就把事情想簡單了。經常掛在嘴邊說這個很容易做的啊，其實做起來的時候就會發現坑。我曾經受過這種策劃傷可能會有點偏見。但了解多一樣東西比了解少一樣東西好。

__________________

你幹嘛不直接去當程序員。

多了解些東西對自己有好處，不過策劃一般不需要寫代碼，大體知道怎麼回事就行了。其實除了編程我他媽的還會3D建模 SHELL 自動化測試。要是哪天不做策划了當個產品經理也挺好。

剛畢業的時候就是策劃，然後對比了一下策劃和程序的薪水，就轉職了…

在double面前不要跟我談理想

在現世代，作為一名遊戲策劃不會編程很難混吧。

數值策劃不會個VBA，只能靠excel公式刷表，效率差距不談了……

level designer不會個腳本，只靠填表實現的那點觸發器、NPC交互，關卡玩法有誰要玩？你要多樣性還能每個都讓程序幫你實現？靠工具編輯，你不懂程序實現連個工具需求都提不出來信不信？

gameplay designer你確定你的道具不需要有填表之外的擴展功能，你確定你的技能邏輯都靠填表實現？不靠寫腳本能有多豐富的玩法？

哪怕是UE4的blue print也只是省了打字步驟而已，策劃所需的編程最重要的是自己邏輯清晰

更別提你以後想往主策職位製作人職位走了……

另外，編程只是一項門檻性質的技能，不需要你多精通，又不要你管理內存又不是太在乎你那點性能，會寫個if else和for循環就可以用，細心點別出那麼多bug，能獨立調試不要出了bug都找程序幫忙查，就算過了這個門檻了。

策劃的核心競爭力始終是遊戲審美和設計能力，就像遊戲2D美術的核心競爭力並不是你的畫有多好，而是美術審美和美術設計能力。

很多時候一個主程出身的主策比如我，是不能被人理解的，所以更多的體驗是一種孤獨。

程序出身的策劃，才能做到一些基本的工作，比如前面很多人說了，可以抽象一些「普通策劃」想不到的需求、提出一些可擴展的執行方式之類，這個在我看來再基礎不過了，因為一個策劃，本身的職責就是分析出用戶最真實的需求，根據這個需求去設計產品，設計產品一方面是用戶體驗，另一方面就是如何實現。

什麼叫會編程？很多時候我們理解的會編程，就是會寫一段代碼，然後實現一些小的功能，就叫做編程，這在我看來只能算是coder，如果你說這樣的人做遊戲策劃，我覺得他只要夠謙虛，培養一下能行，如果你說他作為專業程序員，對不起，在我看來只是會寫代碼的玩家而已（想一想，WoW裡面能寫個宏的是不是也就這樣了？）。所謂的編程，是分領域來定義的，在遊戲領域，編程就是開發出完整的遊戲框架，並且在這個框架的基礎上，任何人根據自己的想法設計輕易地實現出遊戲的任何設計需求（因為遊戲的設計需求總是在改變的）。簡單來說，遊戲編程，最核心的就是完成遊戲的業務，完成業務，包括了業務本身的運作（就是對玩家來說，遊戲玩起來沒問題），以及後續的可擴展性（就是對設計師來說，我要功能什麼的不是那麼的吃力，不是總在妥協的感覺），遊戲編程與眾不同的是面向了2層用戶（遊戲玩家和遊戲設計師）。當然順帶諷刺一下某些所謂的程序員——如果你整天只想著搞渲染，認為渲染=遊戲程序，那何苦做遊戲呢？哦，原來是其他行業比如影視動畫行業你已經進不去啦？所以被排泄了才來做遊戲的！嘖嘖嘖！

但是也正是因為程序出身的策劃，才會感覺現在主流的研發方式非常的彆扭：

1，為什麼要出策劃案呢？而且策劃案居然還能用中文？！在這個混沌的行業，有一套非常糟糕，但卻又成為公論的研發模式，就是策劃寫需求，程序去執行。但是，中文策劃案又確實有很多說不清楚的地方「中國隊，誰也贏不了」，同樣這幾個字，語境不同效果就很不同，放在中國乒乓隊，那是說他們無敵，放在中國足球隊，那是說他們無能。遊戲中有太多的語境，即使是策劃和策劃之間，玩家和玩家之間都能產生歧義的，一份策劃案就能說清楚了嗎？不能！換一個角度來說，我寫一份策劃案，說清楚這件事情的時候，背後實現的邏輯可能還不如策劃案這麼冗長，我直接coding是不是效果更好，而別人的理解代價更小？（事實是，專業程序員閱讀代碼的理解能力遠高於閱讀「策劃案」，只是遊戲行業渣渣太多了，既沒能力又沒耐心閱讀別人代碼的渣渣，做不了別的行業全來遊戲行業了而已）

2，遊戲是誰在設計？這個問題講道理，個個都會說「是策劃」，所以延伸出來一套說法就是「遊戲做完了，但是數據不好，那就是策劃的責任」。但是真是如此嗎？真正的問題是，你把一半的設計和全部的開發交給了程序，最後程序「設計」的遊戲當然不咋的，能成功那真是運氣了。在我看來，一個項目里，只要程序開發的東西，有過任何一絲「你策劃就（「只要」，「應該」等等辭彙）這麼用就行了」的思想，就會做出一個看似靈活實際上是牢籠的東西，最後策劃真要做什麼都做不了，也就只能、必須這麼做（妥協），最後出來的東西不是任何人想要的，能成功了不奇怪么？最簡單直白的一個問題，策劃在一個動作遊戲中設計了一個翻滾，程序實現（為什麼卻不是策劃實現，這才是行業問題的根本）的時候卻依賴於美術視覺，認為美術設計了這個動作多久翻滾多遠，那麼策劃對應填表、填寫數據就好了，很多「普通策劃」只能妥協，但是這卻是有致命問題的，首先設計遊戲的是策劃，那麼翻滾的時間和長度就應該依賴於策劃數據，而不應該美術和策划去做一個耦合（通常我們認為，你要這樣的效果么，你叫美術吧翻滾的時間做的跟你做的一樣長好了，這就是策劃依賴美術的製作，美術依賴於策劃的設計，工作耦合！），所以真正的實現方式是，翻滾的時間、距離讀取策劃的數據，翻滾的tween（好的翻滾動作不應該是勻速的）和美術資源由美術提供（沒錯，我是說如果你用Unity Root Motion，讓美術來設計這樣一個翻滾，並且依賴他，那就是錯的，你要用到的只是美術資源和Tween）。很多時候遊戲程序員在開發的都是牢籠（你要用一個功能，必須接受這個功能附帶的內容），因為遊戲程序員不像其他行業的程序員那樣會去理解自己做的行業的業務（事實上也沒法去理解遊戲業務，因為遊戲設計本身太簡單也太困難了），什麼是通用的、可擴展的？想用了拿來，不想用丟掉，不是非得妥協點什麼才能拿來用的。

3，為什麼遊戲策劃不是一個垂直職業呢？Growth Hacker = 營銷 + 程序，為什麼遊戲策劃不能 = 遊戲設計師 + 程序？為什麼很多實現要去交給別人寫？事實上在你實現和調試的過程中，難免會發現一些設計上的小問題，也會因為實現，產生一些新的靈感和用法，都是很常見的現象。當然這只是一方面，最重要的是，真正能夠理解好遊戲業務，並且將之實現好的很多時候真的只有你自己，同時如其他樓提到過的，可擴展性，也只有遊戲設計師才最了解遊戲要怎麼擴展。我們就說最常見的一個擴展點，這個帖子如何設計一個易擴展的遊戲技能系統？ - 知乎，是一個好問題，但是我們總覺得自己能硬編碼出來，可事實是什麼？很多時候策劃真的要一個技能的時候，程序員甚至說「這麼複雜，玩家能不能理解」之類，反正意思就是不樂意做的話，那麼問題來了，設計階段你不提任何問題，到了實現階段，你非但不去思考如何實現好，還一個勁的反對是什麼鬼呢？最後有趣的東西做不出來，遊戲不行了，怪策劃，全是策劃不好，鍋全都是策劃的，所以這個死了的遊戲就能成功了？所以甩鍋還是沒用，怎麼做好才是關鍵，怎麼才能做好呢？遊戲策劃（或者說現在被稱為「遊戲程序員」的），就應該是垂直領域的，遊戲設計垂直程序。

我們很多時候看到成功的項目，他們的開發模式都是程序策劃分工明確的，因此我們覺得開發就是如此，但我們卻看不到失敗的項目也是如此（倖存者偏差導致這個現象），所以動腦筋想想，成功的項目之所以能成功，離得開項目中那些遊走在程序和策劃中間的人（通常在國內是製作人或者項目經理）嗎？

所以說，你問我一個會編程的策劃是個什麼體驗？這就是我的體驗，孤獨，滿滿的負能量為主！但是也並不總是那麼無奈，遊戲行業里還是有頂尖的人的（只是大多數、應該說95%以上都是渣渣），至少還有人能懂我的好就足夠了。

原來作為策劃學編程是一件需要加上「竟然」的事情

如果不會編程就能當主催的話，我早就去輟學去開工作室了。

作為一名遊戲策劃當然應該懂編程啊