Godot这个开源游戏引擎的能力如何，和Unity和Unreal等主流引擎对比主要有哪些不足？

lingli125

Godot这个开源游戏引擎的能力如何，和Unity和Unreal等主流引擎对比主要有哪些不足？

pic100

C#大师班:在Unity & Blender中制作Rpg和手机游戏
在Unity中制作一个Zenda角色扮演游戏和忍者手游，一个有志游戏开发者的入门课程！
C# Masterclass: Make Rpg & Mobile Games In Unity® & Blender
你会学到什么
在Unity中构建一个移动忍者生存游戏。
从头开始在Unity中构建一个3D“Zenda传奇”游戏。
C#中的代码。
在Blender中创建艺术品。
在Photoshop中制作纹理。
学习游戏设计的基础知识。
MP4 |视频:h264，1280×720 |音频:AAC，44.1 KHz
语言：英语+中英文字幕（云桥网络 平台huo取课程）|大小解压后:9 GB |时长:41小时43分钟








要求
要跟随这些教程，你需要以下程序:Blender(用于3D建模)，Photoshop或Gimp(用于2D艺术/纹理)等免费程序，以及Unity(用于编码)。
教程是在Mac上录制的，但你也可以使用PC。
描述
你曾经想要制作你自己的游戏吗？嗯，你来对地方了！购买本课程后，您将一步一步地了解实现这一目标所需的每个流程。了解如何建立一个Zenda角色扮演游戏和忍者生存手机游戏的传奇！我们的两位天才导师，凯文·廖和格劳科·皮雷斯，从基础的初级水平开始讲解一切。这意味着你不需要任何先前的编码或数字艺术经验就能在这里获得成功。Glauco Pires将带您从头开始在Unity中编写游戏代码。凯文廖将教你如何创建所有的艺术元素，你将需要完成这个游戏
。凯文将在Blender中教授这部分课程，Blender是一个非常棒的免费3D建模程序。最后一节将教你如何在Unity中将你在Blender中创建的艺术整合到游戏中。本课程包括初学者熟悉界面的材料。请注意，我们在类似的课程中重复使用这些材料，因为它们是介绍性材料。你可以在以下相关课程中找到本课程的一些素材:在GameMaker Studio中构建22个游戏， C# Unity & BlenderC# Masterclass:在Unity & BlenderC中制作RPG和移动游戏在Unity和BlenderC中制作忍者生存游戏实用Unity开发人员学院:制作全功能游戏a到Z





Unity开发:用C#编写代码并制作低多边形ArtC#和图像处理Masterclass:制作移动游戏和应用程序专业游戏开发:3D建模和Unity C #在Unity中制作19个低多边形模型和您的第一个3D RPG C #完成Unity和Android开发:构建游戏和应用程序sC# 大师班:在Unity和Blender中制作RPG和手机游戏在Unity和blender中制作“Zenda传奇”游戏在blender中制作3D Unity动作游戏和低多边形建筑28个低多边形模型和一个Unity游戏-完整的3D开发人员参加这样的在线课程的好处是可以随时重播任何讲座。
没有时间限制或最终测试。你可以按照自己的步调，用一种实用的学习方法来学习。其中一个最好的特点是，你可以以任何你想要的速度观看课程。这意味着您可以根据需要加快或减慢视频速度。本课程是基于项目的，所以你不会学到一堆无用的编码实践。在本课程结束时，你将有现实生活中的应用程序可用于你的作品集。
基于项目的培训内容是从A到b的最佳方式。参加本课程意味着您可以立即学习实用和可雇佣的技能。学习如何编码是进入一个新的职业或者提升你当前职业的好方法。编码是新的数学，学习如何编码将推动你在任何情况下前进。今天学习编码，为明天做好准备。能掌握技术的人将统治未来。你只需支付一次性费用，就可以终身学习这门课程。立即报名！

雯雯374943

随着网络技术的不断发展，越来越多的游戏采用了多人在线游戏的模式，其中最具代表性的就是MMORPG游戏。在MMORPG游戏中，玩家可以与其他玩家进行互动，这就需要游戏服务器对玩家进行管理。而AOI算法就是一种用于管理玩家的算法，它可以帮助游戏服务器快速地检测周围的玩家，并进行相应的处理。
对啦！这里有个游戏开发交流小组里面聚集了一帮热爱学习游戏的零基础小白，也有一些正在从事游戏开发的技术大佬，欢迎你来交流学习。
一、AOI算法的基本原理
AOI算法全称为Area Of Interest算法，即感兴趣区域算法。它的基本原理是将游戏场景划分成一个个的区域，每个区域里都有一定数量的玩家，当玩家移动时，只需要检测周围的区域，就可以确定周围的玩家。这样就可以减少游戏服务器的负荷，提高游戏的运行效率。
AOI算法的核心是AOI视野，它是一个圆形或矩形的范围，表示玩家可以观察到的区域。当一个玩家进入另一个玩家的AOI视野内，就会触发相应的事件，例如进入视野、离开视野等。这些事件可以用来更新游戏场景中的玩家信息，例如位置、状态等。
二、AOI算法的实现
AOI算法的实现分为两个部分：区域管理和玩家管理。区域管理负责划分游戏场景，将游戏场景划分成一个个的区域，并记录每个区域中的玩家信息。玩家管理负责检测玩家之间的关系，当玩家移动时，检测周围的区域，确定周围的玩家，并触发相应的事件。

• 区域管理
  

区域管理是AOI算法的核心，它负责划分游戏场景，并记录每个区域中的玩家信息。通常采用网格划分的方式，将游戏场景划分成一个个的网格，每个网格就是一个区域。网格划分的大小可以根据实际情况进行调整，一般情况下，网格大小为玩家的AOI视野大小的两倍。
代码实现如下：
class Grid:
    def __init__(self, x, y):
        self.x = x
        self.y = y
        self.players = []
        
class GridManager:
    def __init__(self, width, height, grid_size):
        self.width = width
        self.height = height
        self.grid_size = grid_size
        self.grid_width = int(math.ceil(width / grid_size))
        self.grid_height = int(math.ceil(height / grid_size))
        self.grids = [[Grid(x, y) for y in range(self.grid_height)] for x in range(self.grid_width)]
        
    def get_grid(self, x, y):
        return self.grids[int(x / self.grid_size)][int(y / self.grid_size)]
   
    def add_player(self, player):
        grid = self.get_grid(player.x, player.y)
        grid.players.append(player)
        
    def remove_player(self, player):
        grid = self.get_grid(player.x, player.y)
        grid.players.remove(player)
        
    def update_player(self, player, x, y):
        old_grid = self.get_grid(player.x, player.y)
        new_grid = self.get_grid(x, y)
        if old_grid != new_grid:
            old_grid.players.remove(player)
            new_grid.players.append(player)
        player.x = x
        player.y = y

• 玩家管理
  

玩家管理负责检测玩家之间的关系，当玩家移动时，检测周围的区域，确定周围的玩家，并触发相应的事件。玩家管理需要实现以下功能：

• 进入视野：当一个玩家进入另一个玩家的AOI视野内时，触发进入视野事件。
  
• 离开视野：当一个玩家离开另一个玩家的AOI视野时，触发离开视野事件。
  
• 移动：当一个玩家移动时，检测周围的区域，确定周围的玩家，并触发相应的事件。
  

代码实现如下：
class Player:
    def __init__(self, id, x, y, aoi_radius):
        Self.ID = id
        self.x = x
        self.y = y
        self.aoi_radius = aoi_radius
        self.in_aoi_players = set()
        
class PlayerManager:
    def __init__(self, grid_manager):
        self.grid_manager = grid_manager
        self.players = {}
        
    def add_player(self, player):
        self.players[player.id] = player
        self.grid_manager.add_player(player)
        self.update_aoi_players(player)
        
    def remove_player(self, player):
        for p in player.in_aoi_players:
            p.in_aoi_players.remove(player)
        player.in_aoi_players.clear()
        self.grid_manager.remove_player(player)
        del self.players[player.id]
        
    def update_player(self, player, x, y):
        self.grid_manager.update_player(player, x, y)
        self.update_aoi_players(player)
        
    def update_aoi_players(self, player):
        old_aoi_players = player.in_aoi_players.copy()
        new_aoi_players = set()
        for grid_x in range(int(player.x - player.aoi_radius), int(player.x + player.aoi_radius + 1), self.grid_manager.grid_size):
            for grid_y in range(int(player.y - player.aoi_radius), int(player.y + player.aoi_radius + 1), self.grid_manager.grid_size):
                if (grid_x - player.x) ** 2 + (grid_y - player.y) ** 2 <= player.aoi_radius ** 2:
                    grid = self.grid_manager.get_grid(grid_x, grid_y)
                    new_aoi_players.update(grid.players)
        enter_aoi_players = new_aoi_players - old_aoi_players
        leave_aoi_players = old_aoi_players - new_aoi_players
        for p in enter_aoi_players:
            p.in_aoi_players.add(player)
            player.in_aoi_players.add(p)
            self.on_enter_aoi(player, p)
        for p in leave_aoi_players:
            p.in_aoi_players.remove(player)
            player.in_aoi_players.remove(p)
            self.on_leave_aoi(player, p)
            
    def on_enter_aoi(self, player, other):
        print(f'player {player.id} enter aoi of player {other.id}')
        
    def on_leave_aoi(self, player, other):
        print(f'player {player.id} leave aoi of player {other.id}')
三、AOI算法的应用
AOI算法在多人在线游戏中有着广泛的应用，例如玩家聊天、打怪、PK等。在这些应用中，玩家需要观察周围的玩家，并进行相应的操作。AOI算法可以帮助游戏服务器快速地检测周围的玩家，并进行相应的处理，提高游戏的运行效率。
代码实现如下：
grid_manager = GridManager(1000, 1000, 100)
player_manager = PlayerManager(grid_manager)

player1 = Player(1, 100, 100, 150)
player_manager.add_player(player1)

player2 = Player(2, 300, 300, 150)
player_manager.add_player(player2)

player3 = Player(3, 500, 500, 150)
player_manager.add_player(player3)

player2.x = 200
player2.y = 200
player_manager.update_player(player2, player2.x, player2.y)

boyhxw

godot从19年开始关注，目前教程比较多，社区活跃。
但是面临大部分开源项目的问题，feature比商业引擎少，插件少，稳定性只能说可以。
建议可以在创新项目中使用，正正经经的做游戏就老老实实用unity。

cbl8410

自己的项目业余开发一年半了，在unity和godot上各跑着一份工程，近段时间也升级到了4.0beta，分享一点经验。
godot本身的扩展性和兼容性都算友好，毕竟能看源码。但这个友好是对C++熟练的资深程序来说的，属于一般不踩坑，踩坑就是深坑的那种，需要一点自学能力才能解决。
就这个月的事，godot4 beta出了。有了.net6加持，直接起飞，目前的C#支持甚至强过unity。http://System.IO的性能提升肉眼可见，而且能直装nuget，很方便，加dll扩展库也就是改个csproj的事。可以认为这个月新出的godot4，对于小团队/个人做C#开发已经是非常友好的引擎了。
至于自带的GDscript，语法类似Python，优点是易学，和引擎结合紧密，能快速出原型，但功能和性能相比背靠强大微软的C#并不占优势。
好在现在GDscript也开始渐渐支持静态类型声明，4正式版里性能应该会好很多。
学习难度上，godot的教程和资料很少，几乎只能查API。
隔壁unity虽然教程众多，但组件更新太快，比如搞个UI你能看到NGUI，UGUI，和最新的UI toolkit三套不同的教程，很混乱。
但总的来说，不是自学能力异于常人或者有C++经验能靠源码排雷的开发者，还是建议老实用unity。unity纵然有这样那样的毛病，但凭借网上海量的前人经验，你能在最短的时间内排完雷并进入实际游戏内容开发。如果你会花费很多时间去做UI，骨骼动画，碰撞之类的基础轮子，而编写实际游戏逻辑的时间很少，那unity一定有更现成的成熟解决方案等着。比如想打磨一个精细美观的UI，那还是UGUI配上各种插件好用。
但如果你要做的是抄都没地方抄的天马行空想法（比如baba is you，braid这种），反正少不了折腾，那倒是建议上godot，出原型试错迭代要快很多。
项目架构上，unity的scene和prefab，放到godot里都统一成了场景（scene），实际逻辑区别不大。比较独特的点是，godot设计了一套信号（signal）系统，相当于每个node默认带一大堆委托，在触发一些UI响应事件时比较方便。unity虽然也有类似的EventSystem，但便利性差点意思。
至于官方所说的没有全局变量，鼓励用autoload加载脚本配合单例模式……其实只是针对GDscript而言。用C#的话，static字段并不受影响。
另外，godot4现在偶尔闪退，3.5还算稳定。
总之，godot是个好引擎，而且开源免费，难能可贵，而且未来可期。
但也要稍微泼一点冷水，新入行的开发者们并不要看到油管上一些godot vs unity的视频就觉得godot比unity更方便，真正做一个完整的项目开发时，那点“方便”省不了太多时间，多踩个坑就都补回来了。
官方教程演示里一直在鼓励所见即所得的开发模式，说白了就是让所有面向对象的类都继承node做成可视化，并把这个类所有的数据和方法都写在node脚本里。这个理念导致做一个功能原型特别快，但真的把这些功能拼成一个游戏时，可能会面临着更多的bug，代码易读性降低，甚至重构。
这些演示，展示的并不是godot引擎的优点，而是设计模式的特点（当然也伴随着缺点）。这样的理念做一个横版恶魔城类，或是星露谷，火纹这类基于像素tilemap的游戏没问题，但总体来看godot适用面还是比unity略窄那么一点点。
当然不是说什么类型unity能做godot就不能做，游戏引擎说白了只是个图形/声音/输入接口，能做什么关键看人。但万一官方有什么轮子功能不全，或是bug没解决，那就麻烦很多。毕竟godot市面上的成品不够多，steam上卖得好的也就一个《文字游戏》，还没经过大量实际开发作品的验证。
当然官方轮子有欠缺可以自己搓，但要是什么都自己搓，那要游戏引擎干嘛。开发者毕竟是内容生产者，时间宝贵，没必要花太多精力搓那些玩家感受不到的，非游戏内容的东西。

至于我自己做沙盒策略的，为什么最后比较下选择了godot？因为这项目是后台演算为主，对引擎的利用也就是搓个UI，所以只要引擎别出幺蛾子用什么都行；另一方面因为开源+未来可期，以及.net6实在是太香了，对数据密集型的任务很友好。
搬个网图：


还有，unity竟然开始弹广告了。

简单总结：
2D小成本，以创意迭代和快速做完为优先，godot有优势。
中等成本的主流玩法作品，要拼作品卖相细节，用unity。
啥都不会，就想入个门体验一下，可以来玩godot3.5和GDscript。
（以上都是练习时长不到两年半的菜鸡发言，如有不妥欢迎指正。）

姓本无名

跑题回答:为了防止一家独大，培育生态多样性，可以适当给这些开源项目一些donation，给他们一些壮大的机会。但是学习和用的话还是unreal和unity吧，别整那些幺蛾子了。
blender除外，blender yyds