遊戲策劃是否應該掌握一些腳本等編程知識? | 知乎問答精選

 

A-A+

遊戲策劃是否應該掌握一些腳本等編程知識?

2018年10月01日 知乎問答精選 暫無評論 閱讀 2 ℃ 次

【張小勇的回答(47票)】:

首先表明一下身份,我是一個會編程的遊戲策劃。但是我不同意題主在問題中的說法。

編程對策劃來說只是一個錦上添花的技能,不是必備知識。

會一些編程知識(如lua之類的腳本語言)能夠在一定程度上降低策劃與程序溝通的成本,如果學的深入一些,寫一些簡單的算法也是沒問題的。

但是,作為一個程序員,你確定要讓一個學了一兩個星期編程的人在你的代碼上動手動腳?出了bug誰負責?代碼效率低誰來改?他有些語法不會誰來教?到頭來還得你來做這些事,讓策劃寫代碼只會讓你更累。

題主想通過把簡單代碼交付給策劃的方式來解放自己的生產力,讓自己可以把精力和智慧用在底層、引擎、性能上。假設這樣做能解放你的生產力,那策劃還要不要做自己的工作?

策劃的工作絕對不是題主想像的那麼簡單,不是簡單地寫寫文檔扯扯皮。任何一個界面、任何一個玩法、任何一個角色的設定都需要經過無數次的思想鬥爭才能確定下來。作為一個策劃,我相信我們想把遊戲做的好玩的心和你們想把程序做的高效穩定的心是一樣炙熱的,所以請尊重我們的工作,不要覺得我們空閒到可以去插手別人的工作。

既做美術又寫代碼還做推廣運營的策劃不是策劃,那是獨立遊戲開發者。在一個團隊中,策劃做好方案,美術畫好模型,程序寫好代碼,這樣就是做好的配合了,互相插手,只會越搞越亂。

題主說策劃總是做出一些模糊不堪的文字、示意圖、表格表達邏輯和數據結構。我想這是你們公司策划水平的問題,我的同事,我以前的同事,包括我自己寫出來的案子邏輯都很清晰。我看著我同事的案子完全可以不和他再進行任何交流就寫出一個界面,當然作為一個策劃我沒有寫。

【牙牙的回答(3票)】:

基本上策劃的邏輯和程序的邏輯分屬於兩個不同的位面,合作很好的要麼有一個很懂程序邏輯的策劃,要麼有一個很懂策劃邏輯的程序。

不過作為一名策劃,加強自己寫案子的能力是非常有必要的,瞭解和熟悉程序的邏輯對自己的工作會大有幫助,自己寫代碼什麼還是免了。

基礎要求:文檔本身表達上要邏輯清晰,減少開發過程當中的溝通成本。

進階要求:提前考慮清楚可行性、可擴展性,基於自己對最終效果和開發代價的取捨,定好整個系統的邊界,這樣可以減少日後修改和新增功能帶來的麻煩。

不過即便如此,事先想得再周密再嚴謹,碰到設計思路上的改變也還是會有返工工作量,尤其是遊戲上線運營後,數據擺在面前不得不改。

淡定一點就好了。

——————吐個槽——————

「這樣程序員就可以從遊戲邏輯中解脫出來,有更多時間專門解決低一層級的問題,如遊戲引擎,功能組件,性能優化等,而不是把寶貴的時間和智商浪費在需求扯皮和被動當策劃的調試工具上。」——引用題主原話

對此我只能說,如果你的能力能夠勝任「引擎」、「性能優化」等工作的時候,你寶貴的時間和智商就不會再浪費在需求扯皮和被動當策劃的調試工具上了,如果團隊在更重要的地方更需要你,就算你願意浪費寶貴的生命和智商,負責分配工作的PM/主程也不會願意啊。

你的確沒碰到「好」的策劃,但你也不是一個「好」的程序員。

【梁巍的回答(14票)】:

看到這個不得不吐槽。。。

首先,我是策劃,我也是產品經理……我計算機畢業,學過編程但抱歉了我的老師。學過繪畫但抱歉了我的素描本……

在下不會編程,但也寫過lua腳本,懂些編程的邏輯和基礎。

好吧,大前提給你了你可以吐槽。

那麼我要開始吐槽了。

我是策劃,我負責設計遊戲內容,懂編程可以讓我和程序溝通,懂繪畫可以讓我和美術溝通。在團隊裡我們各自負責,私下裡我能找到很多與他們共同的語言,我們的小團隊其樂融融。

但此時此刻,我並不負責編程,我的程序大神們也不願意把這些事情讓我去折騰,因為他們看不起我這二把刀三流水平的能力,甚至他們不需要我畫流程,只要我告訴他們功能點就好了。什麼東西最後你對功能,實現沒,能用不?好了,沒問題了。

難道就因為你不願意看我畫的不符合你邏輯思維的流程圖,我沒辦法給出你的邏輯架構,不能幫你寫物理碰撞等一系列問題,然後你就可以大張旗鼓的告訴我,我在浪費你時間,我再謀殺你的生命?

職業是有分工的,我負責這塊,你負責那塊,他負責另外的。團隊是講究配合才能高效率的生產的,如果你能質疑你團隊裡的成員,那麼請先質疑你自己,你沒有做好你團隊裡的角色。

另外,如果你身邊有一個能幫你編程序的策劃,並且他寫的很完美,不需要你操心。那麼你的上司就該操心,我請你來幹嘛?我直接給他漲一些工資,然後他負責這兩塊內容不就得了。何必再多淘一個人的錢呢。

如果你說你可以去改底層,那麼你有沒想過,那些專門負責底層的人呢?再別人看來你丟下自己手中的活又伸向別人的碗裡去抓食……再說,如果全部程序都不用寫功能,要那麼多程序幹嘛?好吧,如果你說就你這麼想這麼做 ,那麼別的程序呢,他們又怎麼想?

你最後的比喻說建築師……如果將遊戲比作一個建築的話,團隊就是整個建築公司,產品經理和老闆是那個建築師,他們負責構思建築物建成什麼,其他人都是負責鋼筋、水泥、框架、物料等。你真覺得你就是那個建築設計師麼?

我只能說你不光沒看清楚你的團隊,你也沒看清楚你的職務。

【韓宇的回答(3票)】:

話說樓上有幾位明顯是在引戰,人激動時邏輯都是亂的。

題主的問題實際很簡單,我認為分兩方面足以說明:

策劃學編程的目的是什麼?——為開發節約大量成本

策劃學編程,學得究竟是什麼?——原理和方法,很多時候不用糾結具體編碼

舉例一:策劃難免會出現配表或數據處理的工作,假設這樣的工作是一天的時間,那麼策劃如果能使用VBA提高效率,兩小時就搞定,這就是值得的。

舉例二:策劃設計功能或測試功能時,如果對某方面技術實現的原理非常清晰,那麼他很容易就發現常人不易發現的極其變態的bug。(別小看這個事,真到快上線了再糾結bug就...說多了都是淚)

最後總結一下:如果文檔非要加代碼或偽代碼讓程序更好理解,大可不必,這個不是節約成本。如果要節約成本就讓技術封裝底層開發遊戲編輯器,讓策劃來做邏輯,管理遊戲開發,這樣思路清晰的策劃不用出太多文檔,也能高效做出質量高又賺錢的遊戲。

P.S. 知道的一些大公司就是策劃寫遊戲邏輯的。上述兩個舉例都有真實事例。

【canxu的回答(5票)】:

看到了很多人回答這個問題,大部分都是說策劃會編程了要程序幹嘛,我在這想澄清一個問題,編程是需要分很多部分的,而大量遊戲的業務邏輯是策劃想出來的。

作為一名遊戲程序員,在這個行業摸爬滾打了十餘年,深知國內策劃的水平參差不齊,題主想說的問題一直是我反覆思考的問題。我已轉做策劃許久,現在想和大家一起分享下我的理解,歡迎來噴。

首先我支持讓策劃來寫lua腳本的想法,再解釋下什麼情況下使用lua腳本,比如任務腳本,活動腳本傷害公式等只牽扯到遊戲具體業務邏輯的內容。因為策劃對具體方案比程序員要理解的透徹的多,策劃自己做掉這部分邏輯會比其他人做得好。有其他人要說了,策劃還要搞其他XX和XX,那麼策劃應該也是分工合作,主策劃和把握系統和數值,需要具體執行的時候一般都有執行策劃,而這些腳本讓執行策劃來做再好不過了。畢竟策劃的文檔不可能100%沒有問題,寫成腳本自己跑的時候可以看到問題,而且策劃可以提前得到遊戲反饋進行下一步的策劃。但是這樣做有一個必要條件那就是需要程序對遊戲架構組織的足夠好、以便把這些策劃外部編輯的程序有效解耦。

如果可以有效按照這種方式配合那邊效率肯定是最高的,我舉個例子,不管星際爭霸,魔獸爭霸,大菠蘿,為什麼都會有個編輯器?這不是讓策劃代替程序員,而是讓策劃快速的實現自己的系統或者遊戲模型。每次出新功能都在等程序的日子對策劃來說是多麼無奈,很多策劃把這些時間安排用來做其他的事情,但是一般人的大腦是需要連續性的,打破這個連續性都會降低效率。

最後,總結一下不是讓策劃把所有程序要做的工作都做掉,而是把和策劃內容關聯最多的那部分完成,這樣可以得到最快的反饋,指導後面的策劃,程序需要配合策劃製作相應的編輯器或培訓策劃一些api的使用。所以項目因人而異,採取何種方法還是要因地制宜避免水土不服。

【劉澤宇的回答(4票)】:

從一個小的方面說說吧。

端游時代的很多公司,腳本是必備的。以前我們發一個版本,副本、任務、怪物ai......幾乎不用程序寫啥代碼,最多加1、2個api接口,剩下的就是我一個人的活了。

但是,後來的頁游和手游公司,幾乎很少用腳本。

我思考了下,原因也許是:策劃寫的代碼,效率實在是太低了!時間和空間複雜度都很高不說,還時不時暗藏崩潰的風險,長此以往,你想優化都無從下手。

所以,結論是:術業有專攻。

【阿貓的回答(4票)】:

首先我是非常同意樓主意見的。設計師必須對自己所在的領域有足夠多的基礎知識。不知道為什麼大家普遍覺得遊戲策劃門檻較低,也許是因為人人都長了一張嘴吧。

無論是建築設計師還是一般的工業產品設計師也好,都需要經歷數年的職業教育,學習算數、力學等基礎知識。但是這並不代表工程師就需要對一切的技術細節負責,這些有具體的工程師、工匠、產品經理進行控制。也並不代表具體的土木工程師,機電工程師會因此失業。

策劃理解計算機運行原理和基本的編程概念,並不代表策劃需要實際參與到編程工作中!

下面我列舉幾點「懂程序」的優勢:

  • 遊戲策劃理解計算機基本的運行規律,才能從一百個天馬行空的創意中,有效甄別出可行的設計。

大家也許覺得這不算什麼。我有時間,我可以一個一個的嘗試,這樣才不會浪費每一個珍惜靈感。但是大型遊戲設計的複雜程度決定了它沒有辦法在短時間內完成。大部分的情況都是:

  1. 基礎玩法,有ABCD..可以選擇;
  2. 我們選擇一個基礎玩法X,在某個階段需要從處理方式A2B2C2..2中選擇一個方案;
  3. ...
  4. 2中的推導過程,也許會反覆出現上百、上千次。

這意味著,設計工作者需要討論Z^N個方案才可以獲得最優解(?)。由於計算量太大,這時極可能會出現兩種情況。

  1. 因為工期限制,策劃開始頻頻出現拍腦門子決定的情況。最後在程序部門的審閱過程中來回扯皮。
  2. 設計還很不完善,直接讓其餘開發人員(程序、美術)跟進。在開發過程中發現設計問題,導致推翻重做。

無論哪一種,除了降低工作室執行效率外,都會極大的損害設計人員的聲譽,導致後續的開發過程中衝突不斷。進而產生程序、美術,甚至是部門經理、老大直接干預設計的情況,進一步惡化開發環境。

  • 所謂的編程能力,本質上是嚴格的數學(程序)語言,對問題進行表述以及組織的能力。是語言能力以及數學能力的體現。

生活語言礙於表達情感的目的,還有豐富的文化性,實際上非常不利於有邏輯的梳理問題。在工作環境中,經常會看到口頭交代問題時,雙方理解出錯的情況。使用成熟,經過良好設計的數學(程序)語言描述問題,有利於與其他開發人員的溝通與交流。

再說數學能力。某些策劃人員極低的邏輯能力,導致其算表頻頻出錯,連使用計算機輔助進行概率運算的能力都沒有。我工作的時候,經常出現程序叫來策劃打臉的情況,因為很多很多的設計點從邏輯上根本就是自相矛盾的。

  • 更好找工作。

不否認一開始缺乏計算機知識、並且沒有受過大量專業訓練的人可以成為優秀的策劃。像徐波這種業界奇葩也不過才初中學歷。但這些早期入行的老傢伙們,都是大浪淘沙,操死成千上萬的競爭者才逐漸湧現出來的。

相比起來,懂計算機的策劃往往更容易在工作室中獲得一個受尊敬的職位。因為擁有高學歷,更豐富的領域知識(計算機、經濟、心理)的人,往往也意味著更強的執行力與學習能力。數十人裡面也許就能夠出現一名優秀的策劃。

這並不是我自己的意淫,看看各大公司的校招其實就知道了。

【楊小剛的回答(2票)】:

大多數人看問題都會把自己的問題看的高大上,別人的問題看得秒秒鐘解決。

題主開始質疑別人負責工作的正確性,對團隊其他人員沒有信心

工作中有一種說法

用程序的說法就是:這個重大問題我跟了兩天,最後改動了一行關鍵代碼將其解決。

用策劃的說法就是:這個設定我做了很久的思考,最終決定設計成這個簡單直白樣子。

用美術的說法就是:這個logo我整整思考了一個星期,最後做個這個設計。

用失去信任的看法來解釋就是:你們TMD的坐了兩天就寫這點我都會弄的東西?還不如給我XXXXXXXXXXX!

【於箏的回答(2票)】:

不知道為什麼那麼多人都把題主噴的一無是處,不要為自己的懶惰找借口,謝謝。

我覺得產品經理瞭解編程並不是錦上添花,對於編程,繪圖切圖等技能,是必須要掌握的。

為了整個工作高效地運轉,設計Photoshop,切圖,前端html,css,後台c語言或者java等等,都要有一定的涉獵,並且要有一定的手動編程的能力。

為了一個產品,流程圖,文檔寫得再好,原型做得再保真,都有可能有說不清楚的狀況,何況是水平一般般的策劃,原型流程圖看得人一頭霧水的情況也是大片大片的存在。這時候,別人因為你的原型模糊不清而一改再改,你反而指責他人說他們理解能力不行,這樣的指責根本就沒有效果,只會拉低整個產品的開發進度。

而且,瞭解編程的好處在於,你可以更加明白產品的邏輯結構,不會隨便亂提一些看起來很幼稚的需求,同時可以洞察到產品邏輯更多的細微之處,將產品原型做得

【足夠】好。

產品經理這個職位,師父告訴我說,是一個沒有權利的領導。雖然說得有點過,不過一個團隊中產品經理的位置,應該是在leader之下,普通隊友之上(不是指權利,是指應該做到的義務)的。

努力不斷提高配合的默契,努力寫出更加清楚明白的文檔和原型,同時瞭解一些編程知識,比如某些東西不用設計,用程序寫出來的某種效果其實就很漂亮了等等,可以大大節約討論時間和成本,同時也能讓自己在團隊裡更有信服力,為什麼一定要和程序員爭個一二三說明自己的職責和他們的職責區別呢?何況他們的要求並不高,只需要你懂一點基本的代碼,懂一些腳本語言而已,這個要求並不高,leader不會和程序員置氣鬧彆扭,別人有了固化的印象你也一時半會兒改變不了,學一些基本的編程常識,讓隊友更接納自己,讓團隊的運轉更好,又有什麼錯?

而且,策劃沒有得到程序員尊重肯定是有原因的,你的能力不夠,表達能力不夠,邏輯思維不夠,都有可能,說一個最簡單的,你能說出你每個安排的理由是什麼嗎?是因為大家都把這個按鍵放在這裡,還是因為你覺得用戶在這裡需要發個言互動一下了?

任何一個策劃和產品改動,請拿出足夠的數據和令人信服的理由。

當然,人和人之間有衝突很正常,保持自己的底線,工作方面如果對方不太過我一般能學的都盡量學習了,但是涉及到分工等等比較大的問題還是要有底線去理論,只是覺得事事和程序員爭論實在不是個產品經理應有的姿態,該學的還是學一下吧。

【KevinCeng的回答(2票)】:

我曾經是一名C++程序員,從事MFC開發一年多,我可以負責任地說一句:「有良好編程基礎的策劃有廣闊的發展前景」。

1)有良好的流程習慣,在從事系統設計時會事半功倍。

2)有面向對像思想(把行為與屬性分離),在撰寫文檔時,閱讀性相當高,一篇完整的文檔,包括了,關鍵數據分析、功能行為分析、流程圖、示意圖、公式與表等。例如一個公會系統,在數據結構上可以分析出:

公會

{

公會名稱,

公會等級,

成員數組[最大人數],

職位列表{會長、副會長……},

公會建築{A,B,C,D……}

公會排名

……

}

公會行為

{

公會創建,

公會解散,

修改公告,

加入成員,

驅逐成員,

……

3)在從事數值工作,經常要使用VBA來完善表格、演算結果,一般來說,數值工作包括:

a. 建立戰鬥數值、經濟數值,成長數值模型。

b. 通過歸納、曲線擬合設計公式與表。

c. 建立科學的數值策劃演算機制,並提出程序debug數值調試工具。

d. 計算掉率、數學期望等純數學應用。

所以說,懂一門語言對策劃幫助很大,有良好的晉陞空間。

【風滿樓的回答(1票)】:

按樓主這思路發散一下,如果這個世界沒有Photoshop,估計那些美術會被樓主逼著去學編程。如果這個世界沒有3Dmax,估計那些建築師會被樓主逼著去學編程。如果這個世界上沒有office,估計那些策劃不會被樓主逼著寫txt文件的,而是逼著去學寫鋼筆字……

開個玩笑,樓主會編程就已經比我強了。

但是,還請樓主先思考一下軟件在各個行業中扮演著怎樣的角色。如果可以的話,也請樓主有空操作一下戰爭機器裡自帶的虛幻引擎遊戲編輯器,然後再查閱一下編輯器的過去,思考一下編輯器的未來,還有腳本的過去和腳本的未來。思考的時候盡量跳出遊戲開發這個圈圈來看問題。

從作業分工的角度看,策劃能想明白一個遊戲怎麼好玩,怎麼黑錢是最核心的工作。其他的都是擴展內容。擴展內容怎麼歸納分解成標準的分工,由什麼人來處理更適合,是一項非常有挑戰的管理設計工作。樓主的策略是讓策劃去學編程,但是我覺得這樣的思路是和現代的工業開發思想背道而馳的。

就實踐來說,開放編程功能給策劃的項目,很多都做得……稀爛。

各種硬編碼,低效率和bug層出不窮。原因反而不是那些策劃懶惰。我見過大量新學腳本的策劃,都近乎瘋狂的在用簡單的命令去實現各種奇葩的目的。就如新學者一定會試試goto一樣,沒有工程的概念,沒有面向對象的思想,想到什麼就寫什麼。後果麼,只能呵呵了。

這個時候,我想我們其實不要去批評策劃了,而是應當反思遊戲開發這種工程應當怎麼構架和組織。

確實,就現階段的大型項目來說確實避免不了編程。因為遊戲太新興,和傳統的美術,建築行業沒法比,還沒有一種高層次的總論能劃定策劃的工作範疇和對接規範,所以也就無法出現通用的開發工具,只能說策劃多會一點總是好的。

所以,就我個人覺得,如果真要搞腳本或者策劃編程,那麼首先還是要程序自己得先開動起來,我覺得一個對應的程序設計人員應當提前思考的問題有:

1、自己團隊裡的策劃,他們各自有怎樣的編程水準,有多少空餘的時間可以用來編程。

2、開放多少腳本功能給策劃使用,策劃可以用到什麼程度。

3、建立一套怎樣的腳本編寫規範和維護方案給這些人用。

4、怎麼去指導他們在規定時間內學習編程,以什麼樣的標準驗算學習成功。

5、誰來檢查他們寫的代碼。

以上是我現階段的思維能想到的。希望能入樓主法眼。

【楊不悔的回答(1票)】:

因為是這樣子的,以前,特別是很多小公司,產品是由開發美工來完成的。

後來,就是因為覺得開發美工這票人不行,老闆們才逐漸意識到需要有一個來「策劃」功能。因為他們終於知道,並不是抄別人的東西這麼簡單,背後是需要想的。

而想這件事情又需要耗費大量的精力,所以才逐漸產生策劃的分工。

【Moore翔的回答(1票)】:

除非你是公司的CEO兼產品經理,否則就做好被研發團隊當皮球一樣踢來踢去的準備吧。

【夏天的回答(1票)】:

當你認為策劃只是隨便畫畫模糊不清的圖的時候,那幾乎已經沒法溝通了。

策劃也會認為你連邏輯都理解不了,也很難溝通。

任何一個行業,都是幾萬小時的積累來的。你非要讓一個非本行的人來幫你做一些你這行很簡單的事,這邏輯本身就有問題啊。

【知乎用戶的回答(1票)】:

需求扯皮是你們團隊沒有人對策劃的需求變更審核的原因,至於調試,那根本是測試的工作,策劃在人手不夠的時候被拖去幫程序配數據,去測試,才導致這麼多亂起八糟的事情

【張羊羊的回答(2票)】:

他會編程了,你幹什麼?

標籤:-編程 -遊戲策劃


相關資源:





給我留言