确实比较容易上手。

Bug：
1.有时脚本编辑器里无法换行/删除。
2.频繁崩溃。


/////////////////
更新完卡在installing runtime上，挂VPN都无法解决。差评。

////////////////
刚打了差评立马更新成功了，好评。

儿子说好

总评：8/10


+++++ 优点 +++++

+ 简单高效的GML语言。

如果你有类C语言的基础，不用学GML其实就已经会了，所需要做的只是熟悉函数而已。GML远比C#简单的多。

如果你没有编程经验，只需要学习变量、函数和控制结构区区三个知识点，就可以用GML语言上手写游戏了。

GML语言的使用者99%的时间都在处理游戏逻辑，而C#语言的使用者需要花不少时间纠缠于琐碎的语言细节。

C#属于通用型语言，而GML语言专为游戏开发而设计。相对于GML在开发游戏时纯粹、直接、拳拳到肉的表现，C#总是让人觉得拖沓、婆婆妈妈，就像用大炮打苍蝇。虽然大炮很厉害，但打苍蝇这种工作，显然用苍蝇拍更有效率。毕竟大炮不是专门设计用来打苍蝇的。

+ 优雅的过程式编程

游戏程序员之神——约翰卡马克，曾经这样曰过：“有时，优雅的实现只需要一个函数。不是一个方法。不是一个类，不是一个框架。只是一个函数。”

Erlang语言之父——Joe Armstrong，曾经这样曰过：“面向对象编程语言的问题在于，它总是附带着所有它需要的隐含环境。你想要一个香蕉，但得到的却是一个大猩猩拿着香蕉，而且还有整个丛林。”

很多在GMS中只需一个函数就能优雅解决的问题，在Unity中要写一坨一坨的代码。

例如：读取CSV表格，然后基于某个列排序。在GMS中只需要两个函数就能搞定（load_csv和ds_grid_sort），而在Unity中实现相同的功能时，简直麻烦死了。

再例如：暂停游戏。在GMS中也只需要两个函数就能搞定（instance_deactivate_all和instance_activate_object，前者用于禁用所有对象，后者用于启用暂停菜单对象）。而在Unity中Time.timeScale = 0只影响FixedUpdate，不影响Update和LateUpdate，还需要在每个Update和LateUpdate的最前面敲代码：if (Time.timeScale == 0) return;。如果你的脚本数量很多，光敲这行代码所花费的时间，就够你酸爽的了。

+ 高容错的编译过程

可以这样写“if (a == 0 and b == 1)”，还可以这样写“if a == 0”，甚至句尾不用写分号。在其他语言中会编译出错的很多不规范写法，在GMS中都能正常编译通过。这帮助用户节省了大量时间。毕竟我们是开发独立游戏，而不是开发什么3A网游大作，什么银行系统，我们更看重效率，至于精确和安全，对于独立游戏来说并不重要。

+ 齐全的2D基础功能封装。

在GMS本体中拥有的很多2D基础功能。在Unity本体中根本没有，需要花银子买很多2D插件（往往其中一个插件的价格就比GMS本体还贵），但买来的往往是GMS本体中对应功能的残次品。

+ 开箱即用的数据结构封装。

DS Grids，DS Maps，DS Lists……用起来简直爽死了。至于Unity方面嘛，没有对C#数据结构进行任何简化封装，请花费更多的时间继续写一坨一坨的代码吧……

+ 支持动态变量名。

GML是弱类型语言，支持动态变量名，可以通过asset_前缀函数，方便的在变量名和资源之间建立动态联系，大大简化了重复性编程。而C#是强类型语言，不支持动态变量名，只能通过hack写法模拟，低效麻烦，又是一坨一坨的代码……

+ 独一无二的场景继承功能。

对不同场景中相同的部分，可以专门提炼为一个场景，再让其他场景继承该场景，点两下鼠标就搞定了，真是超级方便。我在其他引擎中没有发现相同的功能。Unity虽然有近似的DontDestroyOnLoad功能，但用起来又麻烦又不灵活。

+ 简单好用的路径移动功能。

如果你用过Unity中那些昂贵、复杂、难用、问题多多的路径移动插件，就知道GMS官方的路径移动功能有多么体贴用户了。

举两个最基本的路径移动功能的例子。（1）将某个路径复制并位移到某个对象处，并将第一个路点放置在对象所处的位置。相当于多个对象在各自的位置共享同一个路径。（2）延续上个例子，再基于第一个路点将路径在XY平面整体旋转一定角度。这两个很常用的路径功能，GMS本体内置支持，实现超级简单。Unity本体不但不支持，而且所有路径移动插件全跪（Unity的路径移动插件，我几乎都买过试过）。最后，我是在DOTween插件的基础上又写了一坨一坨的代码才实现的。可把我给膈应坏了。

+ 快速搭建模块化场景

聪明的开发者都会将游戏场景模块化，以便重复利用，从而节省搭建游戏场景的资源和时间。

GMS支持16和47两种自动Tile模式，设置好了就用笔刷尽情的刷地图吧。

而Unity在这方面，2D靠插件，3D是残废。烘焙光照贴图后，邻接的场景模块间可能出现难看的接缝。虽然启用Stitch Seams功能可以平滑接缝，但不支持平滑多个对象之间的接缝。若不烘焙，没有全局光照和间接光照，导致光影层次感不足。若烘焙，接缝很难看。只能把邻接的场景模块合并为一个对象，才能避免这个问题，但同时也失去了模块化的优势。

顺便说几句：Unity的光照系统有成吨的坑等着大家填，能把人恶心死。用Unity开发的仙剑6，不但画面不咋地而且帧数还卡到爆，是因为放弃了性能和画面都更好的烘焙光照，而选择了性能压力最大且画面质感较差的的实时光照。起初我不知道他们为什么会这么选择，直到我花了一个月时间，被Unity的光照系统坑的头破血流之后，我也作出了和仙剑6开发者相同的选择。看似荒唐的选择，其实是迫不得已的无奈之选。

+ 高效的实例化。

实例化很多对象时，GMS没事，Unity暴卒。Unity把实例化这种最基本的需求，搞的性能极为糟糕，我也是醉了。虽然可以通过对象池技术缓解，但解决了一个问题，又带来了更多的问题，如：增加复杂性，难调试，难维护。有关对象池技术的坑，大家可以去看Jackson Dunstan的文章《The Problems with Object Pools》。

所以想用Unity开发弹幕游戏的朋友，请慎重。
当你实例化很多子弹时——呵呵！！！
当你用对象池管理多个种类的很多子弹时——呵呵！！！

对于GMS用户来说，对象池带来的性能提升很微小，没有理由使用对象池增加复杂性，从而给自己找麻烦。对象池只是个别GMS极客用来炫技的工具。

对于Unity用户来说，是否使用对象池，则是个两难的抉择，不用很纠结，用了更纠结。

对于某些绝症，有时放弃治疗比积极治疗的结果更好。Unity的对象池就是典型的例子。

+ 低廉的硬件成本

GMS无论在开发时还是运行时，用老电脑都能跑的欢。不但有效降低开发者购置硬件的成本，而且玩家群非常大。只要有好美工，GMS的画面不会输给任何游戏引擎。Unity则不然，如果你不想游戏画面脱离时代，那么主流i3级别的CPU，主流1060和R580级别的甜点显卡，16G内存，大容量高速SSD，是开发Unity游戏最起码的硬件要求。以地形着色器插件CTS为例。若不用，硬件要求虽然低了，但地形极丑，不堪入目。若用了，对不起，请花几千块升级电脑吧。同时，能跑动你游戏的玩家，也大大减少了。

+ 低廉的同步成本

GMS项目占用的硬盘空间通常只有几十M，小项目甚至连10M都不到，高清2D游戏撑死也就几百M。使用Dropbox免费版就能轻松秒同步，家里、单位、外出……随时随地做游戏。

反观Unity项目，十几G甚至几十G都很正常，有的插件安装后竟然占了近10G！Dropbox付费版的成本 + 翻墙流量的成本 + 同步时间的成本 = 呵呵！

+ 低廉的授权成本。

GMS是最便宜的商业引擎，比‎Clickteam Fusion 2.5和Construct 2强大很多，价格却便宜很多。

Unity虽然有免费授权，但基础功能封装严重不足，如果不买插件，所有功能都从零开始造轮子，会累吐血的。可是购买插件后的花费，是GMS本体价格的数十倍。我用Unity八个月之后，买插件的花费就超过3万人民币了。拥有Unity商业授权的用户，在购买插件时往往有折扣。一旦免费用户开始买插件就会发现，买商业授权后再买插件，花的钱要少的多。因此对于用Unity做正式项目的用户来说，商业授权是必买的。Unity其实是个很昂贵的引擎，所谓的免费只是宣传的噱头。Unity在本体中遗漏了很多基础功能的封装，很可能是因为贪图插件销售的分成。

Unity插件刷好评现象很严重，就算是五星好评的插件，说句不客气的，大部分都是残次品。有些热门五星插件（点名：AQUAS Water/River Set），甚至年度最佳插件（再点名：Dungeon Architect），竟然会编译出错！根本就不能用于正式项目！而且Unity插件绝大部分都不支持退款，被坑也无法挽回。以我在Unity商店被坑的头破血流的经验，每买10个五星插件，能有3、4个好用，就谢天谢地了。

Unity插件弃用现象也很严重（高达30%），甚至有的热门插件也会出现弃用问题。套路往往是这样的：冒出个“牛人”做了个很“牛”的插件，宣传的铺天盖地，有时甚至Unity官方都上阵为其造势，什么技术多么多么先进，前景多么多么好，现在很便宜，将来功能增强后还要涨价，云云，总之不管作者有没有能力做出来，只管给用户画大饼。等大家趋之若鹜，买的不亦乐乎之后。突然有一天，插件作者宣布弃用插件，不再提供更新和维护，圈了一大笔钱带着他的小姨子逃跑了！让人措手不及啊！然后你的钱，你付出的时间和精力，统统打了水漂。仿佛有人在背后嘲笑你：呵呵！你个傻屄！

Unity插件僵尸化现象同样严重。很多插件N年不更新不维护，就像僵尸一样挂在商店。插件作者怎么也联系不上，不知是死了还是怎么了。Unity大部分插件商都是个人开发者，严重依赖个人的生老病死，插件的延续性非常脆弱。

Unity插件的价格往往堪比3A游戏，甚至更贵。但刷好评、弃用和僵尸化问题，令买插件的钱，大部分都被浪费了。

+ 低廉的学习成本

GMS的学习成本非常低，主要就是官方文档而已。这些文档不但编写的简洁、系统、全面，而且很照顾非英语母语的用户，直白易懂，几乎没有拗口的句子。用谷歌翻译的准确率都能做到八九不离十，很适合英语不好的朋友学习。

Unity的学习成本就非常高了。首先官方文档的内容不但庞杂，而且还动不动把简单的表述复杂化，不说人话。明明用几个简单句就能说清楚的问题，非要绕来绕去说一大堆，还说不清楚。学习者仅仅借助谷歌翻译是远远不够的。类比：

GMS文档：走
Unity文档：路漫漫其修远兮
我日！！！

为什么会出现这种情况呢？主要是因为Unity版本迭代过于频繁。上一版的文档还没有完善呢，下一版又出来了，我们这些用户升级时都觉的麻烦讨厌，更别提那些文档编写者了，今天这改改，明天那改改，根本没有精力斟酌推敲，能写出好文档就见鬼了！

此外，有些Unity插件的文档多达上百页，光啃文档就要花很多时间哟。我甚至见过拥有200多页文档的插件，我相信大部分国人看200多页的英文小说都会感到吃力，更别说这满篇专业词汇的英文技术文档了，还要边看边实践，搞清楚弄明白才行。想想吧，有几十个常用插件要学要用，这些额外的学习成本……再想想吧，大部分插件都是残次品，你花了很多时间，阅读了上百页英文文档，学完某插件，却发现是个残次品，不敢在正式项目中使用，浪费了大量宝贵的时间和精力，这是一种什么感觉……再再想想吧，当你付出了很多努力，终于精通了某插件时，作者突然宣布插件弃用，不再更新维护（僵尸插件也存在同样的问题），这又是一种什么感觉……至于Unity插件的文档质量嘛……老实说，绝大部分比官方文档还要糟糕的多，要么编写水平差，要么遗漏了很多重要的功能，要么很久不更新……

总之，学习Unity需要付出高昂的成本。上手Unity要比上手GMS多花上百倍的时间。

但是Unity一直宣传自己简单易学。为什么？不说简单，学的人就少了，插件卖给谁去！说Unity简单的主要有三种人：（1）Unity自家人，（2）搞Unity培训的，（3）刚入门人云亦云的菜鸟。真正用心钻研过Unity的人，没人会认为Unity简单。

精通GMS的高手，一抓一大把。但对于Unity，只能说，某人精通Unity的某些方面。

+ 成熟的中文用户群

国内民间游戏开发者接触GM的时间很早，最早可追溯到2000年左右Delphi语言在国内如日中天的时期（GM早期版本使用Delphi语言开发）。存在一批坚定的支持者所形成的高手圈。绝大多数问题都可以在贴吧、群里通过提问找到答案。

国内接触Unity的时间太短，水平有限。在各中文社区提进阶点的问题，基本十问九不知，好不容易有人回答，十有八九还是错的。


----- 缺点 -----

- 陈旧难用的GUI系统。

制作三国志这种交互式UI密集的游戏非常困难，急需类似Unity中UGUI那样的大升级。

- 插件难当大任。

GMS商店里的插件虽然比Unity商店里便宜很多，但人气严重不足，很多需求非常迫切的插件，芳踪难觅。对于非基础功能，用户不得不从零开始自己造轮子。

- Surfaces设计的拐弯抹角。

导致应用着色器这种最基本的需求，实现起来又烦琐又容易出错又难以调试。建议初学者不要轻易接触这部分内容。

- 找不到工作

学了GMS不是不好找工作，而是根本找不到工作。国内游戏公司基本不知道GMS的存在，更不知道GMS的优点，没有职位提供。所以GMS只适合独立开发者或业余爱好。


===== 公道话 =====

很多评测因为GMS登不上甚至打不开而不推荐。我觉得国内网络环境的锅，不应该让GMS来背吧。


===== 总结与建议 =====

对于刚入行基础不扎实的朋友来说，GMS是唯一（注意：是唯一，不是之一）能以低难度低成本作出像样商业作品的游戏引擎。其他的引擎一概不用看。我这只小白鼠早就帮大家踩过一遍地雷了。

GMS拥有非常完善的2D基础功能封装，开发功能不复杂的游戏时（特别是STG和ACT），得心应手，成本低廉。这时使用GMS比Unity更有优势。

但由于GUI和插件的拖累，开发功能复杂的游戏时会比Unity花更多的时间。如果GMS能解决这两个问题，那2D游戏开发领域就没Unity什么事了。

对于多数中小型独立游戏项目，如果能用GMS做出来，就不要用Unity了，否则是自找麻烦。

那么，用GMS做不出来的游戏，就适合用Unity来做了吗？

Unity最要命的问题是：基础功能封装严重不足，缺乏完整的工具链，只能通过第三方插件补完。但插件不良的品质和脆弱的延续性，导致用户摸索出一套堪用的工具链，会耗费巨大的时间成本和金钱成本。

为什么我们要在Unity插件的血海中备受煎熬，而不考虑UE4这个救生圈呢？UE4对基础功能的封装比Unity更完善，工具链很完备，几乎不用再额外购买插件，不用担心插件刷好评，也不用担心插件作者弃用跑路，更不用担心僵尸插件。UE4只在游戏发行后收取5%的分成（若收入低于3000美元，则无须支付分成），开发阶段一分钱都不用掏，而Unity用户，在游戏开发阶段掏几万块钱买插件，是很平常的事情。对于绝大多数独立游戏来说，UE4的5%分成远远低于在Unity插件上的花费。

选择UE4最大的障碍是C++。提醒C++零基础的朋友，不要低估C++的学习难度。如果你有一定C++技术底子，那么UE4是比Unity更明智的选择。

对于C++苦手，也只能选择Unity了。如果有经验丰富的Unity前辈能带着你把插件这部分捋顺：哪些插件质量好，哪些插件适合组合使用，哪些插件商技术强，哪些插件商有责任心……那么使用Unity也能达到不错的开发效率。不过这种人不容易碰到，而且人家用了那么多真金白银砸出来的经验，谁也不愿意轻易告诉别人。

我秃了，但游戏还没做出来……

本评测及说明由GameMaker开发者之家提供，如与官方说法有出入，以官方说法为准



近期官方可能会要求安装更新，因此请确保更新时能够联网进行更新。

请注意，GMS 2的更新方式是：提示你更新，GMS 2：如果你不更，我就死给你看！！(#｀皿´)，如果点击Download Now，则会启动浏览器并跳转到安装包的下载链接，然后在安装包进行安装的时候命令安装包把旧版卸掉然后再注♂入新版强行NTR。但请注意，下载安装包不需要代理！！！（此条仅对单机版用户有效，反正Steam会乖♂乖帮我们更新的╮(╯▽╰)╭）

已经在YoYo Games官方购买或升级GameMaker Studio 2的朋友可以进入YoYo Games官网并登录自己的YYA（YoYo Account）账户，在自己的GameMaker Studio 2的License状态里右侧会出现Add on Steam的按钮，因此，如果也想要Steam平台的GameMaker Studio 2不需要重复购买，点击Add on Steam进行绑定即可（请注意，绑定过程是不可逆的）。

请注意，GMS 2 on Steam使用YYG的第三方DRM，而且有激活机器数限制（3台同时登陆），这个问题已经有歪果仁吐槽过了。
http://steamcommunity.com/app/585410/discussions/0/133259227520347725/
http://steamcommunity.com/app/585410/discussions/0/133259227517627826/
大概意思三台机器的限制表现为只能同时在三台不同机器上是在线状态，而更换机器则是没有限制的。比如，我今天在机器A登录GMS 2，过几天A机器坏了我换B机器登录，再过几天可能换C、换D、换E、换F……你命里克电脑，这是允许的，并且如果你的命足够硬的话你还可以继续换G、H、I……因为你保证每次只有一台机器在登录，但是如果你同时在A、B、C上登录了，那么你将不可以在D、E、F……上继续同时登陆禁忌·N重存在。

===========================
<待补充>
如有更多疑问，请在评论区留言，并且视问题的重要程度可能会被补充到该评测中。

♥♥♥♥

每次使用都需要联网验证是基于什么逻辑？除了恶心正版用户，对防盗版有起到任何作用吗？

刚买就打折，还是这种万年不打折的，真倒霉<(‵^′)>

听说打差评可以解决卡更新的问题，来试试

Chinese Please!!!