用 Playmaker 這款 Unity 插件能做成怎樣規模的遊戲？靠譜嗎？

01-06

本人是一名策劃，接觸過U3D，也用U3D做過一些簡單的單機DEMO，一直想做一款獨立遊戲，但是苦於腳本的問題沒有成功，無意中了解了playmaker這款插件能不使用腳本用拖拽邏輯模塊的方式實現功能，請問這個插件的實用性到底有多強？做獨立遊戲靠譜不？它適合做怎樣多大規模的遊戲？

我看過兩個月的 PlayMaker，也嘗試用來寫一個項目。

優點不多說了，可視化編程，狀態機控制等。

就說一下缺點：

缺乏對數據操作的直接支持。數組，List，Dictionary 操作等等，稍微複雜一點的數據存取，PlayMaker 根本應付不過來。
缺乏對枚舉的支持。官方的教程里建議用 string 來代替枚舉，我就呵呵了。一般來講一個遊戲項目里光枚舉enum 就得要十幾個。你說完全不用枚舉行不行？當然行，但代碼規範性會差很多。
可視化編程無法跟 Git，SVN等版本工具結合使用。大項目協作無法進行。
代碼重用非常困難。Unity 的設計思想是代碼作為一種資源，可以隨意綁定到 GameObject 上讓它發揮作用。用狀態機代替代碼，完全跟這一思想跑偏了。
程序員接手別人的代碼已經夠頭疼了，但至少還可以逐步閱讀代碼塊理清思路。但是閱讀別人寫的的狀態機，將是什麼樣的噩夢？這個比電路板還要錯綜複雜得多。
狀態機只是編程的一部分子集，不能等同於編程的全部。高級的編程思想，譬如23種設計模式，大部分無法通過狀態機來實現。
大家覺得 PlayMaker 方便，其原因是它自己帶了一大堆現成的 Action 庫，加上簡單的圖形化界面。反過來想想，如果自己在項目過程中有目的地積累自己的函數庫、代碼庫，到新項目里用起來更加得心應手。效率會比 PlayMaker 只快不慢。

綜上所述，PlayMaker 真的只是玩具。適合程序需求不大，短平快類的小項目。譬如簡單的3D演示系統，小遊戲等等。如果真的想在遊戲編程領域走得更深更遠，還是認認真真地寫代碼最有效。

對於靠譜的程序員來說，C# 或 Java 這樣的語言其實已經很好用了，並不奢求圖形節點編程，而且一旦私有的圖形節點編程的語言功能不如 C# 或 Java，就會覺得不爽。

=================

使用適合的 paradigm 來做事情。

圖形節點方式適用於粒子系統、材質（即便材質都是高級 shading language 那種更適合，如 Unity 那種自定義的 effect framework + GLSL/HLSL/Cg，很容易映射成平台 shader）、圖像/視頻合成、不要太複雜的 gameplay/演算法等。

Gamplay 編程系統要既 powerful 又 productive，C++ powerful 但不夠 productive，圖形節點編程 productive 但一般不夠 powerful。

缺點：

1. 編譯器把代碼（例如一段四則運算表達式）轉換成 abstract syntax tree。圖形節點方式編程等於是自己人肉連 AST。

2. 向量分解/合併尤其蛋疼。

3. 一屏可以顯示的代碼量遠超節點量。

4. 有時候為了簡化 graph，不得不增加個 script 節點，在裡邊寫比較多的腳本。

5. 代碼是一行行的線性結構。Graph 是個二維結構，navigation 比較容易暈。當然，圖的執行可以是水平的線性結構，但水平方向容易很長，滑鼠滾輪完全排不上用場。

6. 不容易 merge 或 diff。

7. 自定義的圖形化編程，其語言功能不太會趕得上通用的標準的化代碼語言。

8. 庫支持不太會如標準化的代碼語言。

Visual programming and why it sucks

flowcharts are a very poor abstraction of software structure

work fine for simple, trivial programs

電路是天生的圖表示，但工程師還是認為用硬體描述語言更易理解：

HDL simulation enabled engineers to work at a higher level of abstraction than simulation at the schematic level, and thus increased design capacity from hundreds of transistors to thousands.

The FPGA configuration is generally specified using a hardware description language (HDL), similar to that used for an application-specific integrated circuit (ASIC) (circuit diagrams were previously used to specify the configuration, as they were for ASICs, but this is increasingly rare).

===========================

https://docs.unrealengine.com/latest/INT/Engine/Blueprints/TechnicalGuide/Guidelines/index.html

"A good practice to follow would be to use Blueprints extensively, and then push things into C++ as they reach a complexity where that would enable a more concise expression of the functionality (or it becomes too complex for a non-programmer), or speed of execution dictates a move to C++."（這段不敢苟同）

"Operating on large sets of data, doing string manipulation, complex math over large data sets, etc. are all very complex, and aren"t easy to follow in a visual system. Those things are better kept in C++ than in Blueprints, just because they"re easier to look at and figure out what"s going on."

"If you have many more artists than programmers, you"ll probably have significantly more Blueprints than C++ code. In contrast, if you have a lot of programmers, they"re probably keen to keep things in C++."

謝謝邀請

我沒有用過Playmaker，不過看過它的介紹和教程，算是知道大概。

Playmaker本質上是一個State Machine編輯器，利用可視化的操作，讓開發者輕易地將一個個State鏈接在一起，設置它們的轉換條件。

我的理解是，State是遊戲功能真正實現的地方，而Playmaker提供了大量的可重用的State。所以如果需求不是太過獨特，Playmaker自帶的功能應該可以讓開發者快速地開發出想要的設計。

而對於某一些高端的需求，開發者可以在按照Playmaker的標準寫相應的State來實現。

當然，這一切都可以用代碼來實現，而且有的開發者更喜歡用代碼控制一切。

不過總的來說，我也想試試...

謝邀，常年混playmaker,做過大量項目，我不認為playmaker不能做大項目，毫無疑問比起普通的編程來說playmaker也許在優化上面沒有任何優勢，但是在開發效率上playmaker有著令人艷羨的快捷和直觀。

如果橫向比較，拿playmaker和gamemaker或者construct這類的引擎對比，我覺得playmaker要強大的多，樓上的黃峻就拿playmaker開發了不少遊戲，我由於做新媒體和現場遊戲，所做的更多，在線也不少，保密原因就不貼遊戲了，我得說playmaker還是一個工具，一個非常方便的工具，我們沒指望它解決所有問題，我建議利用它的方式如下。

一。有什麼功能做什麼遊戲，playmaker做個賭博，貪吃蛇，鐵板陣，超級瑪麗或者跑酷的綽綽有餘（48jam什麼的我不說，我很多商業遊戲四個小時做完你造么）

二，playmaker不夠找程序寫新的action,或者將插件和playmaker聯合起來用。什麼資料庫，什麼微信，什麼多點觸摸，什麼kinect,Oculus rift,video project,新媒體,ar ,語音識別... 都做過。

我遇到很多非常優秀的程序員，他們是沒有自己一人完成過遊戲的，因為術業有專攻，他們的精力投在專業領域的程序開發，但是unity的本質是為了讓開發者開發想要的東西，程序的優化，遊戲包的大小不是第一位，做出遊戲來才是首要目的，從這個角度來說，對與沒有太多程序基礎的人來說,playmaker是非常好的選擇（不用說什麼你應該學習一門語言什麼的，你能基本看懂程序寫的是什麼，然後購買插件稍作修改讓你的遊戲跑起來是更實惠的做法），題主是策劃，那我還是強烈推薦使用playmaker的。

發現有點偏題，說一下playmaker時候做多大規模的遊戲，說我認為比較不適合的，就是對完全針對本遊戲的代碼量越高，越不能被重複利用的，往往越不適合，賽車，mmo,fps等等的在我看來就不適合（反正我也不想做這種），三消，俄羅斯方塊，泡泡龍，卡牌，橫版格鬥什麼的倒是都不錯，（夾帶點私貨，我以為大家應該借著unity東風多做小遊戲，重新學習遊戲，而不是抄襲著幾款流行遊戲的數值猛做千篇一律的換皮貨，趁著unity崛起的時間窗口期我們可以重新學習一次遊戲開發，過了這個階段，就沒機會了。）

Ps: 給盛大網路做講座的時候，他們為了省錢掉了兩天課程，其中有playmaker, 我深深表示惋惜，，友情提示:如果其他單位請我講座的話....算了反正總是要省的，你們領導怎麼說就是了

再ps..發現第一名的答案應該是autodesk上海的遊戲部門主管吧。。額那我假裝委婉的反對一下好了（反正你們把softimage幹掉我已經心死了 T T)

補一句，前日受朋友所託，說一個虛擬駕駛項目爛尾了，找我去補救一下（力反饋沒有，駕駛震動沒出來，ui有問題，光照效果差，碰撞也不不對，）總之就是麻煩一堆。

貌似找了靈禪出來的幾個人組的小團隊，做了三個月，打開一看代碼慘不忍睹，於是幫忙改三天，一天美術，一天改ui，一天搞定所有程序（由於原來寫的實在太混亂，於是playmaker下面完全重構了一遍）。

遊戲規模不算太小，不放截屏了，放個場景截圖你感受一下...

半吊子的程序比playmaker好手弱多了（如果按照日期算就是弱30倍）:D

你好，pm的能力遠超你的想像，利用這個東西製作的遊戲，上架的很多，公開表明的，你可以去pm的官網看，有些遊戲沒說，也用到了。例如爐石傳說，也用到了pm。除了pm以外，還有uscript，vizio這些類似的更先進的插件。如果你要學習pm，你可以去搜索aboutcg unity3d 301，內容就是pm的入門視頻教學。雖然盜版滿天飛，但是希望對你的學習有幫助，錢不重要。我就是這個教學的作者。。。。。

美工一名。幾乎沒有程序經驗，之前看了黃駿老師的pm教學。pm能快速實現demo，而不用學習任何一種程序語言。而在做demo的時候，也是在學習邏輯實現和unity 的api。

用下來感覺這個東西是策劃的福音，或者用來打策劃臉的東西。國內很多策劃都是嘴炮流，吹得天花亂墜，真正做起來啥也不會。有了pm，可以很方便地自己做出demo。對於策劃，可以更好的和程序和美術溝通。對於美術來說，特別是動作和特效，需要跑遊戲才能看出來的東西。可以自己測試一下，不用被不懂裝懂的策劃牽著鼻子走。

但是，個人用下來的感覺，pm用來做比較複雜的開發可能會有點混亂，因為都是狀態機的圖表，別人很難維護。pm本身的action是很不錯。不過這也有問題，action不提供的功能，要用pm的其它action來實現比較啰嗦。比如，默認的pm數學的action是沒有除余（mod）的，當然，也有可能有另外的實現的action。不過pm可以拓展action，一定程度上解決了這個問題。

學pm的初衷是想「不編程，做遊戲」後來發現最後還是繞不開編程。老老實實學c#吧。

事實證明任何想不寫代碼就想做出高大上遊戲的行為都是耍流氓

PM小玩怡情大玩傷身

我覺得做什麼產品第一要看團隊的成員是個什麼結構，例如如果你的團隊都是美術轉程序員的，那就用playmaker吧，如果你的團隊有專業的程序員，還是老老實實寫代碼的吧。寫代碼可控性會強很多。第二我覺得要看項目的粗細度，如果項目有什麼很奇葩的需求，那麼還是寫代碼容易搞定。這個問題我覺得沒有絕對的答案，只有看項目的特性來決定了。

用過一段時間，但是問題是git怎麼同步，多人操作無法同步，之前是這樣，現在不知道怎麼樣

盡量僅將PM用於高層次的狀態機，盡量避免太過細粒度的Action互動，如果需要什麼比較複雜的功能建議自己封裝Action，不要放任狀態爆炸。

否則就算你能把功能實現出來，做出來的圖在可維護性上就是一個災難。（我還是見過這樣的恐怖例子的）

總而言之，Playmaker是一個很好的編輯器擴展，可以很靈活的處理一些需要狀態機的邏輯組織。

但我個人不認為任何工具能夠讓一個沒有技術思維的人開發遊戲。編程的關鍵並不是會不會一個特定語言，而是是否能夠（從符號體系、機器功能的角度）理解你要實現的功能；而通過一個特定編程語言來描述這些功能，則是相對很容易學會的。

我覺得我要是再不出來幫pm說幾句話前幾名回答就要把pm罵死了

pm在插件里算是比較靠前但不夠說服所有人的那種，而且官方的教程也是著重講pm如何方便而輕慢了與代碼結合的部分，最終結果是很多人對pm的使用方式產生了分歧

pm使用方式主要有三種：pm為主，代碼為輔；代碼為主pm為輔；只用pm不寫代碼。這三種方式直接導致了試用體驗的嚴重分歧：

只用pm不寫代碼：作死行為，搞開發怎麼能不寫代碼，pm用過幾下就知道多麻煩了，官方宣傳「敲代碼十幾分鐘用pm一分鐘就能解決」，但我的實際使用經歷告訴我至少一半的情況下代碼都比pm好用，真的這麼用最後肯定會罵娘的

pm為主代碼為輔：本末倒置，代碼為輔還要什麼程序員，pm就是一輔助工具，它不能挑戰代碼的主導地位，如果pm為主很快就會發現「艾我草怎麼這個功能實現不出來」，然後罵娘

代碼為主pm為輔：這才是程序員應該使用的方式，既然是輔助工具就放到輔助的位置，該代碼的事還是要代碼解決，pm的核心叫「狀態機」怎麼去實現「狀態」還是代碼實現最靠譜

pm這個插件想做大規模的遊戲是沒問題的，問題在於怎麼去用，有句話說得好「語言是不會錯的，錯的肯定是寫代碼的人」，pm當然好用，但並不是怎麼用都好用

————————————————沒人看真尷尬————————————————

好的我現在想要修改一下我的評價，pm真的比官網宣傳的爛多了，狀態機之間的切換很有問題，狀態機內部更是幾何級的凌亂，狀態越來越多，每個狀態機內部幾乎平方速度變亂。你要是問我這插件咋樣，我只能說：除非你要做的是一個超多判斷超多狀態的東西，比如AI之類的玩意，要是拿來做別的，勸你省省錢，當然錢太多圖個方便買了用也可以

沒有用過playmaker，但是看了幾個答案之後，覺得如果題主是想要圖形界面編程，可以試試Unreal Engine 4的blueprint模式寫（拖拽）出遊戲，使用得當其足以應對幾十人團隊規模的遊戲。

他吃內存很厲害，如果是是公開發售的還請不要用這個

Inside 就是用Playmaker做的

我覺得這個東西可以做架構，對程序員而言。可以把MVC模式下，臃腫的Controller在PM的圖形化下分析的很清晰。對於大量界面和3D場景而言，狀態是個好東西