游戏引擎相关，godot现在能用了吗
想自己搞个不大不小的2d项目玩玩，选引擎方面虚幻的2d拉胯就先不谈，听人说godot做2d游戏吊打unity，于是就边试边学。然后在泥潭搜godot看到一年前有帖子讨论过
https://bbs.saraba1st.com/2b/thread-2117754-1-1.html
结论是godot目前很不完善，gdscript坑很多，不知道现在godot4.2什么情况，有完善吗 我也在学，才过完官方教程，插个眼看看有没有大牛传授下经验 不存在什么吊打，但已经是production ready，可以参考https://steamdb.info/tech/
b站上也有好几个好的教程系列
https://p.sda1.dev/17/e15cf8c92b602862eaf2be478e84281b/CMP_20240426193915212.jpg
—— 来自 nubia NX712J, Android 13上的 S1Next-鹅版 v2.5.4 土豆兄弟就是godot写的
—— 来自 Xiaomi 23049RAD8C, Android 13上的 S1Next-鹅版 v2.5.4 2d的话问题不大可以用
嫌gdscript别扭可以用c#
— from Google Pixel 3, Android 12 of S1 Next Goose v2.5.2-play 好用不好用不知道，不过值得庆幸的是最近两年终于有产出了，土豆兄弟和杀戮尖塔2都是godot开发的 如果只是爱好的话(仅限2D),喜欢哪个选哪个
—— 来自 Xiaomi 23127PN0CC, Android 14上的 S1Next-鹅版 v2.5.2 godot我是比较嫌弃图文教程少，都是视频比较多，但我很不喜欢看视频，进度慢又难查阅 本帖最后由 Tring 于 2024-4-26 21:46 编辑
就GDSCRIPT版本来说，4.0后改进了不少东西，不过我也只用到4.0，再后面的不太清楚。每个小版本号特性更新也挺多的。
比如以前提到的，内部节点内部方法的继承处理方式和别的不同的问题也改掉了，异步逻辑也修改了（虽然还是有点怪）。
就我用到的那个版本，对于GDSCRIPT的特性还有2个最不满的地方：
变量是nullable的，但是没有nullable的类型声明，导致很多接口不容易封装。
写在脚本内的类静态变量（主要是属性编辑器里那些属性的初始值），不能在子类里重写。这导致很多想要在代码里配置的初始值无法配置，必须一个一个在属性编辑器里修改，很麻烦。
最近倒是也很少用，所以仅提点回忆里的碎片吧。 看到推荐说youtube的Unity教程大佬 Brackeys 重出江湖要出Godot教程了
https://www.youtube.com/watch?v=EYt6uDr-PHQ 取决于你想实现的是否复杂，如果你想做些很普遍的类型，比如马里奥、魂斗罗、铁板阵这种，肯定没啥问题
如果你需要实现一些不太常见的特性，那是可能会有bug或者性能问题的，这个真不好说
我感觉godot在寻路和碰撞这方面不太给力，所以如果用它做RTS这种单位众多而且需要频繁更新地图碰撞情况和单位寻路AI的类型，可能会有性能问题？我没有严格求证过
只是你一个人做的话，如果喜欢godot那种轻便感和开源，那也没必要太顾虑引擎支持问题，反正自己做，引擎不给力可以考虑换种好实现的方式 本帖最后由 PigMourne 于 2024-4-27 00:19 编辑
godot比unity最大的优势就是轻量阿，容量小启动快跑得快，想起来了打开写两行，当作个人业余爱好不比unity和虚幻这种大部头轻松多了。GDScript也更适合我这种天天鼓捣python和matlab的假程序员，学下教程搞清楚思路就能开写，C#确实门槛高不少
就我自己的需求来说，教程和轮子不比unity少，但大部分都是英语圈视频。对于rpg或者爬塔这种纯2D且几乎不考虑物理的类型，基本上所有问题都能找到解决方案。 afer 发表于 2024-4-27 03:42
人间真实，现在的视频教程真的烦……
所以我几次想上手学godot没一会儿就放弃了（ 汪达 发表于 2024-4-26 23:11
取决于你想实现的是否复杂，如果你想做些很普遍的类型，比如马里奥、魂斗罗、铁板阵这种，肯定没啥问题
如 ...
果然同屏多对象的优化肯定会有问题，可惜了 seedees3 发表于 2024-4-27 09:10
果然同屏多对象的优化肯定会有问题，可惜了
单纯同屏单位多但不涉及复杂寻路的话（比如满屏子弹的弹幕游戏，或者满屏糊脸杂兵的类幸存者）godot的2d性能可能比unity还要好一些
如果需要很复杂的寻路，godot引擎内置的功能是不给力的，就得看看有没有符合你想法的高级教程，或者去翻经典编程书里的案例再自己琢磨怎么在godot里实现了，说实话如果只是业余爱好的话感觉也没必要一开始就搞这么有挑战性的项目 汪达 发表于 2024-4-27 10:12
单纯同屏单位多但不涉及复杂寻路的话（比如满屏子弹的弹幕游戏，或者满屏糊脸杂兵的类幸存者）godot的2d ...
嗯，就是满屏单位多，不像RTS那样寻路这么复杂，但也不是完全没寻路
另外请教下关于游戏相关的编程书有什么推荐的吗 seedees3 发表于 2024-4-27 13:09
嗯，就是满屏单位多，不像RTS那样寻路这么复杂，但也不是完全没寻路
另外请教下关于游戏相关的编程书有什 ...
如果你的场景碰撞区域是固定死的，不是动态变化的，那我觉得godot的内置的寻路功能应该可以直接用，不会花费太多精力在重新写寻路AI上
当然建议先用简单的demo来跑一下看看多少是极限，能不能满足你的要求
跟着godot教程入门后，希望代码可以更美观，更高效，可以进行一些结构上的优化，可以参考这个：
《游戏编程模式》中译版在线 https://gpp.tkchu.me/acknowledgements.html
如果游戏引擎内置的寻路功能没法满足你，需要自己动手，可以参考这个：
《游戏人工智能编程案例精粹》 汪达 发表于 2024-4-27 14:03
如果你的场景碰撞区域是固定死的，不是动态变化的，那我觉得godot的内置的寻路功能应该可以直接用，不会 ...
多谢，因为是类似全战那样的战斗系统，但无法操控+自动战斗，我估计内置的寻路应该不行，还是要自己研究重写 seedees3 发表于 2024-4-27 14:49
多谢，因为是类似全战那样的战斗系统，但无法操控+自动战斗，我估计内置的寻路应该不行，还是要自己研究 ...
官方手册里有导航优化的注意事项，注意这些事项应该够用
https://docs.godotengine.org/en/stable/tutorials/navigation/navigation_optimizing_performance.html
读过这些注意事项也能明白为啥我一直问地形是不是动态变化的，如果要实现上千个同屏单位那种效果，地形也不该做成变化的，地形一变化，导航网格就要更新，那上千个单位也都需要更新，就容易出现性能问题 汪达 发表于 2024-4-27 16:15
官方手册里有导航优化的注意事项，注意这些事项应该够用
https://docs.godotengine.org/en/stable/tutori ...
地形可能会有变化但不会多，先试试等做不下去了再改，不过同屏这么多单位出现性能问题还是很正常的，像UE的话这方面问题应该会更严重 seedees3 发表于 2024-4-27 14:49
多谢，因为是类似全战那样的战斗系统，但无法操控+自动战斗，我估计内置的寻路应该不行，还是要自己研究 ...
集群寻路和引擎一般内置的那种单体寻路是两码事...
— from Google Pixel 3, Android 12 of S1 Next Goose v2.5.2-play
页:
[1]