最近似乎玩了很多用GODOT引擎做的游戏：土豆兄弟....
本帖最后由 itsmyrailgun 于 2023-2-3 11:18 编辑数了数光一月(在一月玩的）就有三款：吸血鬼幸存者类的土豆兄弟，塔防类的穹顶守护者，我也不知道算什么但大抵是恐怖生存类主角只剩一只手的Endoparasitic，
这三款大抵共同点是：都是画面比较简单，但是玩法比较有特色的小制作独立游戏。
Godot是一款14年开源的免费游戏引擎，覆盖了大部分平台，他的特色是：真实2D，轻量，免费，依赖开源社区维护，目前来看这个引擎的维护社区非常活跃，真的非常活跃。
godot目前市场占有率（不清楚这个占有率是有多少人用还是有多少游戏用）大概仅仅为1/10，或许未来能看到更多用godot制作的高质量游戏，甚至不止于独立游戏？
当然想要追上Unreal和UE他还有很长的路要走，在国内我很少看到开发者用GODOT开发，但我不觉这是不正常的。Unity在国内有着丰富的教学资源，很多都是免费，也有着很多成熟的方案和工具，这都是未来GODOT可能要补全的。
初步用了一下这引擎，在2d游戏开发这块我觉得是优于Unity的，至少整合的工具比较好，3d还很远
—— 来自 Sony XQ-AS72, Android 12上的 S1Next-鹅版 v2.5.4 好像说今年Q3 godot4有机会出正式版吧，看看3d方面提升怎么样
我是很喜欢这引擎的，完美规避了我对大公司的厌恶，心血来潮写小demo很爽。3d方面我纯粹用方盒子凑合做玩法验证
—— 来自 S1Fun 对我来说 这玩意当初感觉爽在ide整合，而且特轻量15年mac跑的都飞起，不过最近发现UNITY里也有ide整合的插件瞬间感觉不香了 所以2d比起cocos如何 可能因为习惯了 UE 和 u3d 的 components based 模式，一直不太适应 godot 这套 node based 的逻辑 无聊学了这个玩，2D挺好用的，打开速度真快，非常适合老电脑。 godot在3d上实在是很微妙，相关配套可以说一改没有，4引入vulkan后希望能更好 国内用godot开发，印象中就是传奇生物 2d部分支持度很好，3d的常见需求实现起来基本也没问题。但引擎本身坑挺多的，建议只用来做小型项目
希望4的正式版能把老坑都填一下
— from Google Pixel 3, Android 12 of S1 Next Goose v2.5.2-play 前些时稍微用这引擎做了点练手的东西，当时想发个感想的，不过因为练手的东西坑了，感想也就坑了。
正好借这帖子发下算了。不过内容没整理也没写完，想到哪写到哪的，有点乱。
而且也只是当时用的时候的想法，说不定有些现在回头看感想都有点变化，但是也懒得改了。
=====
这是我第一次拿godot正经做点啥，所以顺便谈谈对这引擎的感想。
总的来说，确实是一款上手十分快的引擎，各种设计都是为了让上手更简单。
语言方面有点python基础的可以无缝直接过渡到他的gdscript上，
就算没有基础，这语言设计得也很容易上手，刻意避开了一些纠结的东西。
但是简单的，不代表就是方便的。
这个语言因为太简单，很多其他语言中很方便的特性也都被去掉了，
使得有些情况下对于熟悉其他语言的码农来说，可能还会把问题变复杂。
比如这语言没有任何pack和unpack特性，导致有些处理会写的很长;
又比如异步特性有点怪，需要花点时间适应。
除开方便方面的问题不谈，还会导致一些小细节很纠结。
比如子类重写父类的方法，节点的系统回调经常需要被重写就被交给引擎自动依次调用父类的方法；
而其他方法，则没有这个机制，如果要使用父类中的方法就必须手动调用。
这虽然对用户隐藏了重写机制，简化了不少不常需要关心的部分，可当真的需要关心的时候问题就会变复杂。
重写那种纠结还只是一点点的程度。可这语言还有个更纠结的天坑：
没有主动垃圾回收机制，却有引用计数这种被动垃圾回收，
因为细节需要扯很多，原理就不科普了，直接说结论：
引擎无法自动释放循环引用的对象，继而导致内存泄漏。
循环引用这用法其实还是非常常见的，任何双链逻辑都必然会导致循环引用。
比如对于节点树A->B->C，如果在C中使用了其父节点B的属性或方法，就会导致一个C->B->C的循环引用。
这时候问题就变纠结了：
如果你手动删除C，就能先破坏循环，继而成功释放掉C；
但如果你手动删除B，就会因为BC循环而无法成功释放掉B。
虽然我相信引擎的节点释放顺序能确保从叶到根来避免大部分循环出现，
但在引擎不维护的用户自定义对象中，就没有能确保这种顺序的机制了。
引擎中提供了一个手动避免循环引用的机制叫weakref，
对于专业的码农来说，依靠非常小心的使用这个机制，确实能够完全避免问题，
但这实际上带来的纠结程度甚至超过没有引用计数的纯手动内存管理模式。
而即使使用weakref，在跨文件时还会由于可选的类型检测不支持文件间类型的循环引用（虽然都是循环，但其实是另一个问题），
而导致静态类型检测无法通过，只能在这部分不使用类型检测来避开这个问题。
这部分问题，我觉得真的不该暴露给引擎用户。
使用一个隐式的不完全的垃圾回收机制，会让没有这方面知识的用户对其过度信任导致意料外的内存泄漏，
甚至不如干脆将所有内存管理交给用户自己进行。
虽然这样做确实简单了，而且现在的机能一般不至于被这么一点点内存泄漏干翻，即使选择完全无视也不过如此。
但对于强迫症码农来说，真的是要命。 其实就可以看作C++的shared_ptr / weak_ptr吧，知道哪个物件该有ownership就好，不过确实会需要用户对此有经验 Tring 发表于 2023-2-3 21:33
前些时稍微用这引擎做了点练手的东西，当时想发个感想的，不过因为练手的东西坑了，感想也就坑了。
正好借 ...
真有人正经用啊，难得，握手。那我再补充几点吧
多线程是天坑，3.2.x甚至没有办法检查子线程里方法的执行状态，后来好像有了个标记
子线程里的逻辑无法断点。这是个2015年就提出来的issue，而且作者曾表示可能到godot4也未必会完全解决
多线程渲染模式可能会导致不可控的渲染错误
不要用weakref，会不幸。老老实实手动管理释放，或者换c#
脚本中文件间类型的循环引用问题，可以通过在一个全局单例中将要引用的文件通过路径的方式统一声明，然后其他脚本来引用这个声名的成员来使用，不过这样弄出来的自动补全就别想了
数据(de)serialize是类似python中dictionary的结构，但会有一些其他元数据内容。而且配合写saving的时候似乎不是很稳定，偶有莫名其妙的bug
渲染管线不能自定义，导致可能需要奇淫技巧地套rt来实现某些效果
没有geometry shader和compute shader
profiler里scripting涉及_process（unity里的update）或类似步骤的开销无法被明确检出，做优化时很麻烦
没有double类型支持
对不同版本fbx的导入支持很差。模型只建议用gltf
不自带地形系统，不过有个第三方的组件还挺不错的。但官方已经确认不会直接整合到引擎中
过程生成mesh有三种模式，偏底层的那种用起来并不友好且和其他类型混用很容易抓瞎
ide里写gdscript没有find reference/find usage，需要自己ctrl-f
某些版本的引擎打包release后运行起来会直接崩，debug或编辑器直接运行时正常。据说是因为可能存在未察觉的null reference
还有好多想不起来了。反正还是我之前的观点。小项目可以用用试试，千万别上头去做有体量的。
rust支持咋样
—— 来自 OnePlus GM1910, Android 13上的 S1Next-鹅版 v2.5.4 Xerxes_2 发表于 2023-2-4 01:30
rust支持咋样
—— 来自 OnePlus GM1910, Android 13上的 S1Next-鹅版 v2.5.4
写起来比较麻烦，但能用（ 本帖最后由 mccleaner 于 2023-2-4 12:36 编辑
非c#用户，一直很好奇c#到底好在哪里，简单看过一些感觉也没啥区别啊，为啥一堆人天天传教要用c#写。然后我现在也是写js比较多，我搜索c#的好处也没给出什么令人满意的结果。
看了前面的帖子，是说轮子多？可惜我开发的游戏还有linux arm版，一直没明白mono怎么整进去。 Godot4 支持了直接export Node对我来说是在可用性方面跨出了一大步。之前要么捏着鼻子用字符串引用节点，要么每个export都要写又臭又长的workaround，不过已经是历史了就不展开讲了。
楼上习惯component不习惯node的，其实Godot的node基本上可以拿来当component用，可以参考一下这个视频。
GDscript2.0也比之前成熟了很多，lambda写起来还是挺爽的，不过现阶段重命名个变量还得自己去查找替换的，自动补全也是一坨，更别指望什么花哨的现代IDE功能了这方面只能说还是未来可期。
すぴぱら 发表于 2023-2-4 15:38
cpp/java出身的人一般都会更喜欢c#，
原因有几个：上手快，你熟悉java十分钟就能熟悉c#，语法是强类型语 ...
我不喜欢C#的原因终于找到了，原来是和我不喜欢JAVA一脉相承的。 我写cpp，公司自己的引擎，但是我讨厌c#的主要原因就是unity mccleaner 发表于 2023-2-4 12:22
非c#用户，一直很好奇c#到底好在哪里，简单看过一些感觉也没啥区别啊，为啥一堆人天天传教要用c#写。然后我 ...
C#主要是用起来没有明显的问题，不过这个要对比其他的语言才能说清楚
对比JavaScript和Python来说，就是静态类型
对比Java，就是语法更简单，有真泛型，更函数式，当然你要说Kotlin啥的那Kotlin有些地方还比C#强点
对比C++，内存管理更简单，函数式更简单，编译速度快，当然很多低级特性不支持运行速度会慢
对比Go，泛型和错误处理强太多，不过Go可以编译成不要运行时，大小还很小
缺点也很多，比如说：
冗余的分号，来自C、C++、Java的遗产
有类继承，来自C++、Java的遗产
C#里面那个非空引用，居然是个语法糖，和Kotlin有差距
资源释放依赖于using，很容易漏掉，而且系统库里面有很多类型不知道到底是不是需要调用Dispose，GC的时候调用析构函数非常容易出错
异常模型有问题，存在跳出using/try finally的时候调用Dispose里面再抛出异常的情况
环境割裂，同样的代码，在.Net Framework、Mono、.Net Core/5/6/7上有可能效果不一样，因为库里面实现细节不一致；Unity也不一样，GC过于落后，正常环境下不会产生问题的代码在Unity下可能出现各种内存碎片过多导致的内存问题
Tring 发表于 2023-2-4 15:53
我不喜欢C#的原因终于找到了，原来是和我不喜欢JAVA一脉相承的。
静态类型虽然写起来可能啰嗦一点，但是IDE补全强，还有很多运行时错误可以在编译时就能发现
C#比Java强一点就是类型推断什么的(比如var)，Java虽然也加了，但是Java泛型是假泛型，还是很多地方写起来麻烦
最近搞了个项目用的Blazor，网页前端全部用C#写，只有少量JavaScript，写起来很爽。缺点就是浏览器里面运行的东西很大，还用了wasm。但是写起来真的很爽 Tring 发表于 2023-2-4 15:53
我不喜欢C#的原因终于找到了，原来是和我不喜欢JAVA一脉相承的。
怪不得我寻思我以前搞oi的时候写最多的也是cpp来着，怎么对c#就没什么感觉呢，反而现在更喜欢上go或者rust。
原来是因为我不喜欢java。
说实话非程序员看不懂你们这些话，只是想要个rm那样不需烦恼build可运行程序，码相对简单，导入资源也大概没问题（3d模型格式会有问题，旧版本），至于面向对象还是尼玛，甚至不懂什么意思，写出来它能按预想动作就是了。 关于godot能不能做3A，官方有篇文章讲的挺好的。
https://godotengine.org/article/whats-missing-in-godot-for-aaa/
文章结尾是这么说的：
So, are we not even close?
While the goal of this article is to make clear how significant the work remaining is to make Godot an offering closer to the ones in the commercial segment, it is important to not forget one key detail:
Godot is Free and Open Source Software. And as such, it can be modified by anyone to fit any purpose.
Currently, many large studios have the ability to create their own in-house technology. Still, as hardware becomes more and more complex to develop for, they are giving up in favor of spending money on pre-existing commercial technology offerings.
Godot, on the other hand, serves as an excellent platform to build upon, as it solves the vast majority of problems already. As a result, more and more studios are using Godot as a base to derive their own technology from.
This is a win/win situation, as it allows them to keep their freedom to innovate and, at the same time, avoid paying expensive technology licensing costs.
Time will tell how Godot transitions from its current state to something more widely used by larger studios, but it will definitely need significantly more work from our side.
顺便godot的官方教程其实很全面简明，看完之后就可以开发独立游戏了。
这也是这种偏独立引擎的特点，他的教程并非面对「专科用户」——例如虚幻的官方教程——而是会讲解原理，让你了解为什么引擎要这样做。这和虚幻教程那种「你只需要先这样，再那样，就能获得某种效果」要更容易理解。
（黑一下虚幻，不同的功能模块甚至操作逻辑都是相反的。） 我对Godot是有一个疑问的，不知道有谁能解答一下。
据我所知，Godot的主要开发者是几个阿根廷人。我不太了解他们的职业生涯，但阿根廷距离传统的游戏工业发达地区好像是有点远的。
所以Godot在怎样的程度上能够及时贴近最新的游戏工业技术的发展，而不是走歪路子变成闭门造车？
对Godot2D我倒是不担心，2D独立游戏开发者太多了，有足够的社区力量。但我感觉3D越来越趋向于技术寡头争霸的形势。Godot在这方面似乎只有协议上的优势。 r_ex 发表于 2023-2-4 16:06
C#主要是用起来没有明显的问 ...
C#在游戏开发中对比其他虚拟机语言的一个重要优势是值类型与显式栈上分配：比如
Span<Vector3> vecs=stackalloc Vector3; hzhh95963 发表于 2023-2-6 17:52
我对Godot是有一个疑问的，不知道有谁能解答一下。
据我所知，Godot的主要开发者是几个阿根廷人。我不太了 ...
十几年前ios那个objc版本的cocos2d就是阿根廷人写的 内部有坑，到时候搞不下去了还得换 hzhh95963 发表于 2023-2-6 17:52
我对Godot是有一个疑问的，不知道有谁能解答一下。
据我所知，Godot的主要开发者是几个阿根廷人。我不太了 ...
互联网上没有距离
而且godot很多基础建设都没做好，还在追赶期，不用想有的没的
—— 来自 S1Fun godot 3d就是图一乐的水平。Juan自己还很有想法，要贯彻自己的图形思想。
你这给自己的project坚持自己的小众做派就算了，要是引擎想打出去这么整我是真不看好…
—— 来自 S1Fun
页:
[1]