GamePlay Programmer(遊戲邏輯程序員)會不會漸漸消失?

01-13

這是我最近學習Unity3D的一個感受,那就是現在的遊戲引擎實在是太好用了,各種組件都封裝的非常好,包括腳本的編寫也比較傻瓜化,有一種回到以前使用RPGMaker的感覺.
包括狀態機,行為樹和AI都可以非常直觀的去調用,實際上策劃也可以獨立完成一款不錯遊戲的構建了.那麼,GamePlay Programmer會不會越來越少,或者與遊戲策劃合併成為同一種職位呢?

謝邀。一個事實來說明，unity3d當初開始流行的時候，圈內流行的是「這玩意簡直就是美術就可以做遊戲了，程序以後吃什麼飯？」。結果是幾年發展下來，程序開始轉了不少到unity3d上來，美術依舊還是美術。大家還是一樣的合作。不會預測，只說一個事實。

謝邀，我認為不會。理由如下：

1，遊戲引擎化開發是遊戲工業化發展的表現，是進步，但並不一定所有商業遊戲都要走引擎化這條道路。引擎可以越來越強大，但終究不是萬能的，因為遊戲的的表現形式無時無刻不在創新，但引擎一般是基於現有遊戲表現形式開發出來的，它的泛用性會受到限制。

2，掏錢買引擎，拿錢換的是時間，但技術門檻肯定還是要有。至少國內即便是大公司策劃，你讓他學U3D，他也得學相當一段時間。另，專職的遊戲軟體工程師（聽好了是軟體工程師，你們一不是程序員二不是碼農，從來不是），真正的優勢在於軟工思想而非編碼技術。說白了，你給一個文案策劃講什麼叫高內聚低耦合他多長時間能聽懂並應用在項目中呢……

3，分工方面的東西我和 @安震意見一致。從社會分工理論和CMMI（軟體能力成熟度集成模型）的評判角度來說，分工的目的是為了提高生產效率。編碼工程設計和編碼本身的工作量即便用引擎也是相當大的，沒有專業遊戲軟體工程師別想完成，完成了穩定性也達不到要求。所以為了生產效率這個人力肯定是不會省的。

PS：你可以找一個策劃，找男的對程序和遊戲都感興趣的，掰著手教他U3D，試試一年內他能出師不……題主這是「達克效應」認為U3D太簡單了是個人都玩得來，其實真不是……

謝邀，我認為不會。

我是不咋會寫程序的策劃,會點lua,也看過U3D的書。

我覺得大概從2個角度來看問題吧

1）從獨立遊戲製作角度，這是好事，代碼門檻降低，更多想做獨立遊戲的人可以做，不過在獨立遊戲的製作里，這個本來就構不成什麼實質性的問題，只是說U3D強化了這個概念。

2）從商業遊戲角度，其實早年的策劃大部分都是會寫腳本，會架單服甚至對前後端的概念和具體工作方式非常了解，以現在的觀點看現在的一小部分不合格的程序猿可能對於遊戲架構的理解都不如那批人，可以隨便找幾家大公司看看現在當工作室老大的人，基本上都是半程序半策劃的早年間圈內大神。

我認為分工其實是進步，如果回到什麼都做的年代，反而是一種退步，策劃做遊戲我真的認為不是堆砌邏輯和數值的過程。

堆砌邏輯和數值只是表象，越做深了越發現經驗+用戶心理感受+打折促銷（俗稱運營思維）有很多東西要考慮和沉澱，說白了都是得學的。

對於商業遊戲公司來講，要一個懂U3D 也懂玩法但是不懂心理數值系統的策劃，和一個一行代碼都不會寫，但是非常了解人心理數值系統的策劃，傻子都知道哪個好（當然現在很多公司要前者...這是因為便宜）

分工導致專註，專註提升生產力，策劃這行業我感覺還處在一招鮮吃遍天的家傳武學時代，很多理論和知識只停留在口口相傳上，與其專註於把自己變成一個蹩腳的程序員，還不如做好策劃的本分，做精策劃。

專業的人做專業的事情，相信隊友...

不會。

至少目前虛幻這種端游主要用的引擎，非程序員無法駕馭。

反倒是不會寫代碼的策劃會逐漸消失。國內的遊戲策劃會更接近傳統意義上的遊戲設計師。

update：

樓上兩位都是策劃朋友回答，我作為程序回答一下。

原文手機打的，沒有表達清楚，重新表達下。

gameplay程序員不會消失，但是跟toolset程序員的界限會越來越模糊。

國內有一定發展年限的PC端遊戲公司，不僅限於網遊，程序員大部分都是前後通吃，順手還能winform寫點工具出來。只是前幾年頁游發展太快，這幾年手游又發展太快，出現了海量的要麼是沒學過圖形的手游端程序，要麼是只寫過lua、python就招進來開始幹活的所謂「邏輯程序員」。

gameplay部分會越來越多由策劃完成。

配表是策劃想法落地的一種工具，連圖也是，同理，寫文檔、畫流程圖都是。「策劃需要寫代碼」，不是說真要策劃吭哧吭哧硬編碼寫c或者c++。腳本一直都是想法落地的最重要的一種表達方式，沒理由國外的分工更成熟的console工作室的designer會而國內的策劃同行不會。

順便，當gameplay程序員側重點更偏向toolset和engine的時候，不少沒寫過腳本的策劃一直說的「門外漢寫亂腳本」的擔憂基本不存在。

碰巧看到一篇博客，引用如下：

我們有許多製作流程的方式，最土鱉的方法是程序根據策劃的需要不斷開開心心地硬編碼啊硬編碼，我想時至今日除非畢業生否則不會有人再喜歡這麼做了吧？稍微好一點的就是設計一個可以讀取配置文件的系統，策劃通過配置文件來自定義一些流程。這個是某英雄項目的做法，也是我過來後重點在推倒的東西。再往後，就是程序只寫核心、只搭框架，要什麼菜？自己通過腳本和工具往裡面裝。如果你在業內做過10年以上，你應該會回想起來這就是我們開發模式一直以來的變化。
如果不能把策劃調動起來，在這個遊戲內容爆炸、遊戲革新速度加快的時代，遲早會被淘汰。

配表為什麼不靠譜？
為什麼反感配表、配配置文件呢？這個方法一是太老舊了，二是它實際上並未能完成調動策劃的使命。
老舊就不用說了，02、03年剛開始學遊戲開發的時候，這種配表的方法就是初級讀本中也會收錄的基本技能。
未能完成調動策劃的使命是怎麼回事呢？但凡使用配表的工作組，往往只有兩種對配表的組織方式：
一種是程序提供核心流程後，「給，配吧」，交給策劃。
一種是策劃想好自己的需求後，告訴程序，我要這樣一個流程，然後這些地方開給我配置。
從擴展性上來說：
前者的問題是，做這個功能的程序實際上決定了整個系統的擴展能力。
而後者的問題是，雖然表面看起來策劃擁有對這個系統的控制權，但是實際上，做這個功能的程序實際上決定了整個系統的擴展能力。
無論哪種情況下，策劃由於並不是實際的實現者，因此再強勢，其實也只是紙老虎。真正把控系統命脈的，仍然是製作這個系統的程序。如果這個程序是個沒有擴展性思想的程序的話，策劃需求的完成時間就會隨著開發時間變得越來越高。如果這個程序是個有擴展性思想的程序的話，他一定會拋棄配表這種做法。
從配表本身的特點來說：

配表本身其實並不是為了解決流程概念的。它只是為了能讓一些數據性的工作能交出去，不要佔據程序寶貴的編程心力。用來描述已經既定的、簡單的邏輯也是能夠勝任的。比如，當條件A成立時做行為A，條件B成立時做行為B這種還是能夠手到擒來的。
問題在於，項目開發期，特別是端游，很多方案最終的樣子跟最初的樣子能夠差得很遠很遠。我們的策劃一開始也認為技能判傷害，最多只要做父子關係就行了。實際的結果呢？判傷害這塊兒根據需求的變化已經調整了好幾版了。如果我們程序是按照配表的方式做的話，單讀表、分析表的地方都要改好幾次。
雖然這種工作對程序而言是小Case，但是同樣也是沒營養的工作，我相信就算是再喜歡寫程序的，隔三岔五讓你改個讀表、改個流程，你也會心懷憤懣的。
簡而言之：配表無法自我進化。
再怎麼說，配表只是流程的附庸，先有了流程，才能決定配表是怎麼個東西，如果流程在變，配表自然無法自我圓滿。
所以，拿配表來做流程的想法典型的就是土鱉想法——沒有見過更好的方式，所以只能寄希望於他們唯一明白的方式——配表、配表、再配表。
我認為，程序有責任告訴他們，你們有更好的方式來完成你們的目的。
腳本是專業的流程工具
人們設計語言和腳本，就是因為他們能夠在我們和計算機之間建立起溝通的橋樑。人們因此可以讓計算機去做我們想要他們做的事情。
剛剛說的那個問題，腳本化之後根本就不是問題：
之前的一次技能一次傷害判定不夠了？腳本里這塊兒之前是做了一次，你自己再加幾次。

哦，對了，相應的數據可以自己從配表裡面讀喔，不想讀的直接寫死在腳本里也行。
後面，如果有需要的話，這裡你改成讀表就行。
什麼？你改了表結構？那腳本這裡讀表的地方你自己改一下就好啦。
……
除此之外還能完成很多你之前不敢想的東西：
什麼？Boss戰的整個流程完全要跟角色技能不一樣？
沒關係，為Boss這個技能單做一組腳本……中間還可以穿插場景交互喔~~
過去程序釘死那就是死了，現在？自己發揮去吧。
此外，腳本化後顯而易見的我們獲得了下面的優勢：

減少溝通成本，增加效率
……
程序的設計被倒逼框架化、模塊化、單元化。
……
程序概念更清晰
……
更早地發現設計問題，更靈活地完成目標
……

引用自：終於小鬆一口氣，上來冒個泡

我覺得不會，比如遊戲引擎不會有點擊npc然後彈開對話框這種東西的，如果有個引擎有這個功能，那麼我用這個引擎去做fps遊戲怎麼辦呢，當然你可以說這個引擎非常強大，連做打槍遊戲的功能也有，那麼我要去做個賽車遊戲呢，或者簡單點，做個連連看，俄羅斯方塊呢？...策劃們的需求是多變的，今天按鈕點下去是彈這個窗，明天又改成彈那個窗了，後天或許又把這功能幹掉了（當然彈什麼窗這個功能可以丟給配置表，這裡只是舉個栗子），所以連高端的引擎工程師也搞不清楚策劃們在想什麼，以至於引擎解只提供了遊戲開發的一些「共性」功能（幾乎所有遊戲都有的功能），比如把圖形顯示出來、模型導入進來給美術看效果，把遊戲物件對象介面提供給程序員操作等這樣的功能，不能解決遊戲玩法和功能層的問題，因為功能層需求千變萬化，比如美術畫的圖拖拖拽拽就能出來，不用管圖形底層介面了，但至於這個圖出來以後怎麼辦，會發生什麼，怎麼體現出策劃的想法，還得靠邏輯程序員，沒有哪個引擎能適應所有遊戲，搞定所有功能。至於rpgmaker不用寫代碼就能搞定一個遊戲，那用rpgmaker肯定做不出使命召喚，也做不出極品飛車，就算做個rpg遊戲rpgmaker很多創新玩法都做不出，把rpgmaker做的東西搞成網遊就很麻煩，別說再搞搞動態事件什麼的了。

我經歷過很多個手游項目，都是我做主策劃並同時做邏輯程序，負責伺服器、客戶端的邏輯代碼coding，我的目標就是讓自己有一天不再coding，讓其他策劃直接coding就好，因此我當時就設計了幾個努力方向：

1，設計邏輯機制，讓遊戲設計規範化，讓策劃思路規範化。

2，設計的dsl更自然語言化，讓策劃能像寫文章一樣自然地coding。

但是能力有限，至今未能實現，也無心繼續實現這塊，因為去做別的事情了，當然我想說的是，好的程序員的努力方向就是讓自己「失業」（基本不用做什麼事情）。

我們項目就是策劃自己寫邏輯……全是寫LUA的……

最近下載了鵝廠的《天涯明月刀》畫面超贊。但是game play做的慘不忍睹。各種動作銜接不好，尋路各種撞牆。所以在我看來國內非常之缺少優秀的gameplay程序員，相比之下優秀的圖形學程序員還更多一些。

我覺得不會消失。

說說我們的情況，我們之前是三個程序，一個策劃，在做技能系統時，策劃的想法是非常的豐富，隨時都可能加入一些很酷的技能，但是我們不可能他想一個我們做一個，於是我們有了技能組合單元，把他要的技能功能寫成一個一個的buff,比如:中毒，破防，麻痹，分身，Hp+ %，全屏傷害等等，buff單元寫好後讓策劃填表，他可以很自由的組合他想要的技能。當然策劃填表也需要一定的邏輯，但和程序上的邏輯有分別。策劃想要什麼樣的技能，引擎不可能直接提供給他，需要程序去提供給他。

我倒是希望啥都不懂的策劃趕快消失。你也別趕什麼工具潮流了。

額，我想說，身為程序，我們的最終目標其實是讓工具最簡單易用，讓baby們也能夠通過簡易的界面來使用複雜的系統。

也許有一天，當全世界的程序平台介面都被統一和簡化並且全面而又穩定的那一天，程序這種職業也許會真的消失。

可以說程序猿們一直致力於做這種讓自己失業的工作呢。

所以程序猿是為了世界進步而做出悲壯努力的偉大一族。

我來說一個觀點。gameplay的複雜度因遊戲而異。一個國內腦殘mmo就是數值+界面，尚且沒有辦法完全讓策劃(大部分差他們的英文名稱太遠)完成，像使命召喚這樣的遊戲gameplay有多複雜想過嗎，不是一個數量級的。當問題複雜度增加一倍，開發的難度可能就是十倍。本質上工具進步了，需求也在進步。不要只著眼於三個人三個月的手游，這是另外一個話題，不展開。

不會的啦，遊戲公司必備技術，遊戲在。

沒明白題主的邏輯，按照題主的描述，現有的引擎比如Unity這麼好用，應該漸漸消失的難道不是我們Engine Programmer？

拿引擎提供的工具寫遊戲不正是Gameplay Programmer做的嗎？

另外不要高估策劃使用工具的能力，大多數策劃的想像力太豐富而動手能力太弱

如果真的遊戲邏輯程序員都不需要了，我就不幹這一行了。