开源游戏引擎 Godot Engine 使用体验如何？
开源游戏引擎 Godot Engine 使用体验如何？ 分享一下我们使用Godot Engine开发MINIEYE AI防碰仪的体验。先上几张图让大家直观感受一下：
AI防碰仪：左边是摄像头和主机，右边是显示屏
AI防碰仪显示屏上对路况进行的3D动画呈现
看到这个小显示屏了吗？上面是3D渲染的前方道路交通实况。
这种3D路况画面可以过滤掉不重要的道路交通信息，只呈现对司机最重要的信息，可以有效减轻司机的认知负担。
而这个3D路况就是用Godot引擎渲染出来的。
Godot游戏引擎在我们自制的嵌入式设备上运行成功了！
这个小显示屏采用了ARM CPU和GPU，操作系统是一个高度裁剪过的Android系统。在这样一个小巧的系统上，要运行Unity之类的大型3D游戏引擎是不太可能的，而自己用OpenGL ES撸一个好用的3D渲染引擎又太费时，经过充分调研和测试，我们最终选择了Godot引擎。
我们选择Godot引擎的主要理由是：
1. 宽松的开源协议。Godot引擎的源代码采用MIT协议发布，这意味着我们可以在商业项目中免费使用Godot Engine，并且可以自由地修改Godot的源代码，将其移植到我们自己的硬件平台上。这个需求用Unity之类的闭源游戏引擎肯定是不行的。
其实我们最初的原型是用Unity开发的，后来因为无法移植而放弃了Unity，所以说还是开源软件好。
2. 所见即所得的开发环境。我们也尝试过OGRE等其他3D游戏引擎，但是它们都没有Godot这样强大而好用的开发工具，你只能用代码来构造场景，这样效率就很低。而Godot提供了和Unity类似的开发体验，直接把模型、光源、摄像机拖进场景，再设置参数就可以了，随时可以看到渲染效果，搭建场景非常方便。
3. 自带的GUI控件非常好用。
Godot原本是个2D游戏引擎，所以天然地对2D渲染有着良好的支持。它自带了几十种GUI控件，直接拖到场景中去，就可以迅速构造出一个2D交互界面，对于熟悉Xcode和Qt的人来说很容易上手。
实际上Godot引擎的开发环境（Editor）就是用Godot自己的GUI控件搭起来的，这一点是非常厉害的。相比之下，Unity的GUI工具就没有这么简便了。
4. 一键导出到目标平台的能力。我们在电脑上开发3D游戏，在电脑上测试OK之后，直接一键导出project，然后把导出的文件拷贝到我们的嵌入式设备上就可以使用了，渲染效果和电脑上一模一样，省去了适配不同平台的麻烦。
但是不得不说，Godot也有一些不足：
1. 渲染性能不如Unity。
当我们的模型总面数达到30万的时候，Unity仍可以渲染60帧，而Godot只能渲染不到30帧。
经过分析，Unity主要采用Deferred rendering，并且在一次Draw Call中渲染尽可能多的物体（比如所有GUI控件可以在一个Draw Call内渲染完），以减少Draw Call。而Godot采用了不同的思路，它通过调整渲染顺序，尽可能减少shader change。两种方式各有千秋，但就目前来说，Unity的渲染性能更胜一筹，希望Godot加油啊。
2. 对嵌入式GPU的抗锯齿支持不太好。
在开发AI防碰仪的早期阶段，当时Godot的最新版本为3.1，这个版本对MSAA抗锯齿的支持非常有限。具体来说，就是不支持OpenGL ES 2.0的MSAA扩展。
而我们的Mali-400 GPU偏偏只支持OpenGL ES 2.0，这就用不了MSAA了吗？也不是，幸好Godot是一个比较活跃的开源软件，在Github上有人为Godot贡献了OpenGL ES 2.0的MSAA补丁。我们在合并这个补丁之后又做了一些修改，就可以启用MSAA了，渲染质量瞬间提升了一截。
现在Godot已经发布了3.2版本，这个版本是支持在OpenGL ES 2.0上启用MSAA的，大家可以放心使用。
关于AI防碰仪的更多信息，大家可以点击卡片了解：
<a href="http://link.zhihu.com/?target=https%3A//c.minieye.cc/%3Flocale%3Dzh-cn" data-draft-node="block" data-draft-type="link-card" class=" wrap external" target="_blank" rel="nofollow noreferrer">MINIEYE AI 防碰仪MINIEYE AI防碰仪高级智能驾驶辅助系统行车记录高清夜视ADAS前车行人防碰新手司机安全预警仪 【现货】MINIEYE AI防碰仪【图片 价格 品牌 报价】-京东 开发方式比起u3d，
godot的节点话开发，更加时候独立游戏制作
独立游戏有个特点，随时可能添加新内容
godot可以在无需考虑架构的层面上往里面添加内容
3.0新特性，内容
3.0的出现，有了vs，c#的支持
以后可以带个平板，充电宝，去附近的一家公园，躺在草地上用vs(可视化脚本)进行拖拉连线开发
不过vs逻辑太复线会很乱，所以只能用于小游戏
juan(godot始作者) 用获得的捐款雇佣了几名图形学顶级人物，其中有adobe前员工，
重写了3d渲染部分，速度更快
总结:godot更适合 独立游戏制作者，简单直接
顺便附上几张我正在开发的一款沙盒2d游戏
我准备加入电路系统，种植系统，酿酒系统，甚至可以搭建电脑
虽然还在初期阶段。。。
2018/10/7
我有开了个新坑，想用godot试试3d
是一个卡通风格，可以联机，的互相打手枪游戏
截图下面
理我想象中的游戏还差距有点远，
现在手感不大好，以及动画简陋 引擎官网：
https://godotengine.org/体验不错的。
如果一定要用一句话形容他的话，那么godot重新定义了轻量级。
市面有的，能做2d游戏的引擎，不论是国产的cocos，egret，强健如unity，庞大如ue，还是一些名不见经传的譬如love2d之类的，多多少少有点毛病。
但是godot有点例外。
这款短小精悍的游戏重新定义了轻量级。
整个引擎就一个文件，50多m。
下载，解压，开箱即用。
这款游戏引擎3d模式不谈，2d模式适合以下这几类人：
做原型，做demo，需求速度出货的即没有用过godot，也没有用过unity的自己做游戏做着玩的有一定技术实力可以搞c++的出精品2d游戏的
他有一些问题会阻碍用户用它做一个商业游戏，这些问题是可选的，可以克服的：
积累不够，和Unity之类的比还是差太多了。火爆的社区讨论对大陆用户来说，门槛还是有点高的。需要学习gdscrpit，虽然极度像python没什么门槛，但是直接用c++或者c#多好……技术支持不足，商业游戏作为一门工程，最怕途中遇到问题解决不了，godot官方不能保证独特的设计理念和工作流很适合小团队精品，但比较不适合大规模团队的工作
=========================
很多人选引擎会关心功能……
其实吧，功能都是差不多的，该有的都有，没有的黑科技也大都不是必要的。
3d游戏用黑科技多了组里人全都是猪队友，工程一定出问题。
2d游戏就更不要谈了，
除了有些连骨骼动画都没有的玩具本来就很难出现在候选者名单上以外，
功能不影响，大家都一样。 2017年了，关注这个 godot engine 很久了，很早的时候还提交过一次pr，现在发布版本是2.1.2
开发版本 3.0 更新比较大，简单说说目前2.1.2的版本的一些东西：
常规的2d，3d游戏支持，声音，动画，网络方面的支持就不说了，说点自己觉得好玩的东西
1. 有asset lib (Godot Asset Library)了，可以下载素材，模板，插件等，当然这个内容的建设需要时间。
2. 扩展模式支持 c++ module 和gdscript的扩展，很方便
3. visual script: 和 unreal 蓝图类似的 可视化脚本工具，很不错的东西
4. steam 上已经有使用它做的独立游戏了，很不错的发展
5. 支持 shader
还有很多东西，而且可以关注一下 3.0的版本（Godot 3.0 new internals, progress report #4）
godot engine 我觉得是一个很适合游戏开发入门的 引擎，编辑器设计的很简单，结合官方文档很容易理解，至少比 unity3d 更容易上手，自己尝试简单的 tilemap 的小demo，很简单。
目前，用的还不多，接下去会用它做点小东西，如果有更多体验了，来补充一下
补张图（Visual Script 编辑界面），使用的是 最新代码编译的3.0的版本，2.1.2 没有把visual script功能编译进去，因为还没有开发完整。
接触了一段时间来更新体验，上手最大的感受是：
1.引擎体积很小，下载到笔记本只有一个exe文件，50m的样子。我想更适合小团队做游戏原型用，或者独立开发者做小游戏。比起某些引擎动辄上g的体量来说，对初学者很友好。
2.开发成本低，简单易用。很适合2D小游戏的制作。编辑器简单易用，以节点为中心开发，大部分游戏可能行为都已经都封装好，通过界面绑定到节点上。这种思想很新颖，与其说是引擎倒不如说是个节点编辑器。你不需要搭建任何游戏框架，游戏内所见的一切都是节点，拖动制作即可。
3.可拓展，对c++造轮子的用户友好。个人猜测可以自己写需要的功能绑定到节点上。不管做什么游戏，用熟了节点增加游戏内容或修改更方便。
3D不熟悉，不评论。如果比成熟应该不及unity，毕竟后者已经填了这么多年的坑了。毕竟开源引擎，应该在修改底层方法有优势，可以造轮子为特定功能服务，不知是否算是优势。
最后从游戏设计角度来说，其一，在能满足功能和画面质量的前提下，游戏引擎越易用学习成本越低对小团队越友好。设计者可以把更多精力放在游戏的可玩性上。其二，好的游戏是迭代出来的，需要不断的根据测试结果调整和修改游戏的内容，node的设计原则能满足这样的需求。我们不需要懂搭建程序的框架，只需要对游戏的内容足够了解，处理好node之间的关系就好了。
—————————原答案—————————
计划今年业余时间做个2D游戏，正硬着头皮啃unity。偶然发现戈多，简直个人开发的福音。看样子是比flash还轻量级的引擎，适合做实验性质的游戏。
果断决定转坑理由：
1.轻装上阵。由于是计划一个人做2D游戏，精力和能力有限，能把主要的游戏内容表达并测试好已经不易，引擎的选择肯定越轻量越好。看介绍node为核心，曾摆弄过flash小游戏，应该类似于后者的元件。
2.语言选择。因为知道以后应该不会做unity开发的工作，对C#也没接触过。之前有一些C和C++底子，未来也是打算往这个方向走，做游戏除了乐趣，也是为了熟悉引擎各模块的功能，能用上C++自然是最好的。
3.学习成本。在保证能做出自己想要的东西的前提下，学习成本越低越好。节省出的时间可以更多放在其他方面。
先占坑，实际体验了再详答。
——————by 20190107 看下github
bug太多，1000多个，开源主要就2个人在写代码，确实忙不过来。
写个flappy bird ，马里奥是很快。但是要做个能赚钱商业化游戏，坑很多。
这也是主流开发商不用的原因。
另外圈子小，导致tutorial，demo，plugin template都不丰富。
虽然这款引擎设计的很好，但是由于上诉缺点，在实际开发中还是没有unity快。
现在能看到的一个用途就是搞什么少儿编程培训班，哄小孩子入坑。因为确实能很快做个马里奥类的游戏。孩子家长看着都很高兴。
个人愚见，不喜勿喷。 1. 新的脚本语言GDScript，语法类似Python。和Flash的IDE相似，可以将GDScript代码绑定到组件上。部分语法比较特别，例如检查某种对象类型是:
if a extends preload(res://ascript.gd): print(&#34;a 是ascript的子类&#34;)2. 编辑器不是很完善，初次使用的时候，切换脚本和显示容易混乱。经常出现点击A脚本，但是展示的是B脚本。
3. 一切基于Node，即使是Tween和Timer，也需要add_child 之后才能生效。
4. 打印输入不是很友好。会出现自动冲掉的现象。为了避免打印过多，只能通过自己的开关控制打印自己想要的东西。
5. 支持UI编辑器和动画编辑器。但是这对开发而言不是很方便，通过第三方插件将已经做好的UI或者动画导入进来，似乎不可行。
6. 中文资源较少。需要有一定英文能力看懂它的文档。
7. 也有Asset Store，但是相对Unity资源较少。
8. 提供了许多Example工程，这些看完，可以做一个简单的Demo。
9.导出各个平台的可执行文件的步骤比较麻烦，需要自己编译一次源码，生成godot_opt文件。这样才能在模拟器上运行。暂时没有找到直接在xcode中断点调试的方法，只能自己先导出pck文件，然后在xcode上运行。依靠打印找到问题的原因。
暂时想到这些。 简单的下载下来了解了一哈，如果没说到位各位轻喷，我的评价是“中等偏上”，好处呢和楼下题主们说的大同小异，就不重复了，总结一下就是确实好用（感受一个被Unity崩溃和UE编译整疯的开发者的心情），是真的好用。至于缺陷，在我看来最致命的问题还是体量问题，积累不够吧。
比方说处理重度逻辑运算，可以考虑研发一套类似Unity ECS + Job System这样的超高的性能，配合以高度解耦的框架，带来更好的版本迭代，协作开发体验，渲染方面应该提供一套Frame Graph或者Scriptable Rendering Pipeline这样的跨平台的底层API封装，这样在面对高级的渲染需求不会觉得无力。开放世界和大地形一直是近几年的热点，如果引擎在这些方面有所建树，不断积累工具链和编辑器扩展，想必能在开发类似游戏时提供不错的帮助。当然，这些比起技术更加趋近于积累和经验问题，还是希望这个引擎随着时间的积累，可以越做越好，逐渐变成强大的顶级引擎。 这个引擎圈子还没有unity大，但是引力足够
建议去godot中文社区：Godot中文社区_Godot游戏引擎官方社区_Godot交流平台_Godot教程资源_Godot教程文档_Godot源码资源
页:
[1]
2