用 Playmaker 这款 Unity 插件能做成怎样规模的游戏？靠谱吗？

明绍宗朱聿键鼻 · 发表于 2020-11-30 18:35

明绍宗朱聿键鼻 · 发表于 2020-11-30 18:35

我看过两个月的 PlayMaker，也尝试用来写一个项目。
优点不多说了，可视化编程，状态机控制等。
就说一下缺点：

综上所述，PlayMaker 真的只是玩具。适合程序需求不大，短平快类的小项目。譬如简单的3D演示系统，小游戏等等。如果真的想在游戏编程领域走得更深更远，还是认认真真地写代码最有效。

明绍宗朱聿键鼻 · 发表于 2020-11-30 18:37

谢谢邀请 :)

我没有用过Playmaker，不过看过它的介绍和教程，算是知道大概。
Playmaker本质上是一个State Machine编辑器，利用可视化的操作，让开发者轻易地将一个个State链接在一起，设置它们的转换条件。

我的理解是，State是游戏功能真正实现的地方，而Playmaker提供了大量的可重用的State。所以如果需求不是太过独特，Playmaker自带的功能应该可以让开发者快速地开发出想要的设计。

而对于某一些高端的需求，开发者可以在按照Playmaker的标准写相应的State来实现。

当然，这一切都可以用代码来实现，而且有的开发者更喜欢用代码控制一切。

不过总的来说，我也想试试...

明绍宗朱聿键鼻 · 发表于 2020-11-30 18:43

事实证明任何想不写代码就想做出高大上游戏的行为都是耍流氓
PM小玩怡情大玩伤身

明绍宗朱聿键鼻 · 发表于 2020-11-30 18:52

我觉得做什么产品第一要看团队的成员是个什么结构，例如如果你的团队都是美术转程序员的，那就用playmaker吧，如果你的团队有专业的程序员，还是老老实实写代码的吧。写代码可控性会强很多。第二我觉得要看项目的粗细度，如果项目有什么很奇葩的需求，那么还是写代码容易搞定。这个问题我觉得没有绝对的答案，只有看项目的特性来决定了。

明绍宗朱聿键鼻 · 发表于 2020-11-30 18:55

你好，pm的能力远超你的想象，利用这个东西制作的游戏，上架的很多，公开表明的，你可以去pm的官网看，有些游戏没说，也用到了。例如炉石传说，也用到了pm。除了pm以外，还有uscript，vizio这些类似的更先进的插件。如果你要学习pm，你可以去搜索aboutcg unity3d 301，内容就是pm的入门视频教学。虽然盗版满天飞，但是希望对你的学习有帮助，钱不重要。我就是这个教学的作者。。。。。

明绍宗朱聿键鼻 · 发表于 2020-11-30 19:01

尽量仅将PM用于高层次的状态机，尽量避免太过细粒度的Action互动，如果需要什么比较复杂的功能建议自己封装Action，不要放任状态爆炸。
否则就算你能把功能实现出来，做出来的图在可维护性上就是一个灾难。（我还是见过这样的恐怖例子的）

总而言之，Playmaker是一个很好的编辑器扩展，可以很灵活的处理一些需要状态机的逻辑组织。

但我个人不认为任何工具能够让一个没有技术思维的人开发游戏。编程的关键并不是会不会一个特定语言，而是是否能够（从符号体系、机器功能的角度）理解你要实现的功能；而通过一个特定编程语言来描述这些功能，则是相对很容易学会的。

明绍宗朱聿键鼻 · 发表于 2020-11-30 19:08

美工一名。几乎没有程序经验，之前看了黄骏老师的pm教学。pm能快速实现demo，而不用学习任何一种程序语言。而在做demo的时候，也是在学习逻辑实现和unity 的api。
用下来感觉这个东西是策划的福音，或者用来打策划脸的东西。国内很多策划都是嘴炮流，吹得天花乱坠，真正做起来啥也不会。有了pm，可以很方便地自己做出demo。对于策划，可以更好的和程序和美术沟通。对于美术来说，特别是动作和特效，需要跑游戏才能看出来的东西。可以自己测试一下，不用被不懂装懂的策划牵着鼻子走。
但是，个人用下来的感觉，pm用来做比较复杂的开发可能会有点混乱，因为都是状态机的图表，别人很难维护。pm本身的action是很不错。不过这也有问题，action不提供的功能，要用pm的其它action来实现比较啰嗦。比如，默认的pm数学的action是没有除余（mod）的，当然，也有可能有另外的实现的action。不过pm可以拓展action，一定程度上解决了这个问题。
学pm的初衷是想“不编程，做游戏”后来发现最后还是绕不开编程。老老实实学c#吧。

明绍宗朱聿键鼻 · 发表于 2020-11-30 19:11

谢邀，常年混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

明绍宗朱聿键鼻 · 发表于 2020-11-30 19:13

对于靠谱的程序员来说，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
&#34;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++.&#34;（这段不敢苟同）
&#34;Operating on large sets of data, doing string manipulation, complex math over large data sets, etc. are all very complex, and aren&#39;t easy to follow in a visual system. Those things are better kept in C++ than in Blueprints, just because they&#39;re easier to look at and figure out what&#39;s going on.&#34;
&#34;If you have many more artists than programmers, you&#39;ll probably have significantly more Blueprints than C++ code. In contrast, if you have a lot of programmers, they&#39;re probably keen to keep things in C++.&#34;

		自动登录	找回密码
密码			立即注册

用 Playmaker 这款 Unity 插件能做成怎样规模的游戏？靠谱吗？

本帖子中包含更多资源