Godot: C# 作为脚本语言

在我看来，向 GDscript 添加更多功能将是处理脚本的更好方法

对我来说，选择 Godot 而不是其他游戏引擎的主要原因是简化的脚本方案。 Godot 不提供学习新的编程语言。 它提供学习 Godot 及其脚本语言作为游戏开发的组合工具。 与让新手学习 C++ 或任何其他脚本编程语言相比，这是一种不那么令人生畏的方法。

感谢您打开这个问题，我认为这是一个在合理的最佳选择和大多数人的要求之间存在很大差异的话题。

存在多个引擎的最重要原因是，除了通用任务的性能或接口的可访问性等一维因素外，还有特定情况下的性能等多维因素（如果比较引擎，则没有明显的赢家3d 游戏优化和 2d 游戏优化）或特定用户组的可用性（初学者友好的界面通常必须隐藏高级功能）。
因此，为了在其他引擎中找到一席之地，引擎必须选择一种“哲学”。

现在脚本语言是引擎的一个组成部分，所以语言的哲学应该符合引擎的哲学，或者至少不应该与之相矛盾。

那么戈多的哲学是什么？ 让我们看一些事实：

• 与 Godot 相比，其他所有主要引擎都臃肿。
  Godot 的下载小于 20MB，整个“安装”是一个小于 50MB 的可执行文件。 另一方面，Lumberyard 的初始下载大小约为 5.5GB，目前我的安装文件夹为 15.3GB。 主要原因是亚马逊关于依赖的哲学。 初始下载包含 10.5GB 的 42 个依赖项的构建映像，如果您在知道 AWS 开发工具包在这方面没有什么不同之前使用过 Amazon Web 服务，那么这不是必要性或能力的问题，而是问题选择。 例如，虽然 Lumberyard 包含 boost 和 Lua，但 Godot 包含其自己版本的最重要的 STL 容器并使用 GDScript 而不是 lua，这样可以减小大小、消除依赖关系并使代码更具可读性和可访问性。
• Godot 的源代码非常易于访问。
  首先是选择使用 python 作为构建语言的构建系统 (SCons)。 大多数其他项目使用具有专有构建语言的现有构建系统或编写自己的专有构建系统，这两者都会对构建代码的可读性产生负面影响。
  源代码本身在这方面也高于平均水平。 我花了大约相同的时间来了解如何用 C++ 编写单个 Unreal Blueprint 节点，因为我花了我为 Godot 的第一个拉取请求编写代码的时间。 这并不是说 Unreal 的 C++ 代码不可读，它根本不如 Godot 的干净，因为它使用了更多的宏，并且要求用户比 Godot 了解更多的 Unreal 默认项目代码。
• Godot 提倡 KISS 和 OO 原则。
  为了说明这一点，让我们看一下 Unity 中的一些简单对象。 您在 Unity 中遇到的第一个概念是带有附加组件的游戏对象。 “组合优于继承”，因为它通常被称为（我更喜欢 Michael J. Dickheiser 的“游戏开发者的 C++”中的表述“包含与继承”，这听起来不像是战争的呐喊，而是促进对该主题的反思）是一个成功的模式由于它提供的灵活性。 不过，这种灵活性是有代价的。 如果你的游戏中的所有东西都是一个 GameObject，那么你就无法真正获得对“玩家”的引用，因为没有玩家，只有一个 GameObject 可能附加也可能没有附加玩家组件（或者更确切地说是那些使播放器）。
  Unity 开发人员看到了同样的问题，有时您只想创建一个 Button，而不是带有 Button 组件的 GameObject。 所以他们所做的是：他们允许您通过编辑器界面创建“按钮”，该界面实际上创建了一个附加了按钮组件的游戏对象。 除此之外，他们通过每个组件路由 GameObject 的最重要成员，因此现在您可以使用对 Button 的引用，就像使用对 GameObject 的引用一样。 您可以向 Button 询问它的位置，也可以向它询问其组件的列表——即使 Button 实际上是一个组件，而不是它所附加的对象。
  所以现在我们混合了两种最流行的方式来描述游戏世界——基于组合和普通对象。 但是，当您查看初学者的项目（甚至是一些高级项目）时，您会发现 Unity 还促进了解释游戏世界的第三种方式：过程编程。
  在 Unity 中，每个对象始终是“场景”的一部分。 与 Godot 不同，该术语描述了游戏的顶级部分（免责声明：现在 Unity 有一个位于场景顶部的 SceneManager，但我的观点仍然有效），这意味着如果敌人想要向玩家射击，它可以在当前场景中搜索玩家并与之交互。 这就是过程编程的核心思想——你有一系列的命令可以改变环境的状态而不考虑所有权。 当然，从技术上讲，它仍然是面向对象的编程，但是由于每个对象都可以期望成为同一场景的一部分，因此您可以编写行为类似于全局代码的代码。 例如，如果您想实例化一个对象，您所要做的就是调用“Instantiate(templateObject)”，然后模板对象的副本将被实例化并添加到场景中。 无需询问将对象添加到哪个场景，因为始终存在一个场景，所有内容当前都是其中的一部分。
  因此，Unity 提倡组合、面向对象的思维和过程编程的混合。

另一方面，Godot 提倡面向对象的思维，例如，游戏中的每个对象都可以构建为自己的场景。 这些场景可以自行启动，允许您对其进行测试、自行更改等。这反过来又要求您以不需要访问环境的方式构建这些场景。 例如，如果敌人想要与玩家交互，则使用信号来告诉底层场景请求交互或简单地要求场景为敌人提供对玩家的引用更为可行。 您仍然可以在游戏场景中搜索玩家，但如果您这样做，敌人场景将无法自行运行，因此该设计根本不适合工具。

那么这对脚本语言的选择有何影响呢？
C# 之于语言就像 Unity 之于引擎。 C# 的理念一直是，如果将某些功能添加到语言中会很好。 只需查看每个版本添加的功能列表： https ://en.wikipedia.org/wiki/C_Sharp_ (programming_language)#Features_added_in_versions
现在你可能会争辩说拥有一个特性并不是什么坏事，对吧？ 你不必使用它，如果你不喜欢它就离开它。 不幸的是，对于一种语言来说，情况并非如此。 随着当今互联网的重要性，语言不再是工具，它们是文化。 迟早你将不得不在谷歌上寻求帮助，你将使用其他人构建的模块或对象，你将使用社区构建到引擎中的新功能，迟早会要求你使用你从未想过的语言功能使用。
此外，如果您在一个团队中工作，您将学会欣赏使用一种促进通用编码风格并且不会为您提供数十种编写相同代码的方法的语言。

现在您可能想知道我是否是说功能较少的语言总是比功能较多的语言更好。 当然不是这样的。 让我们比较一下Java是如何解决这个问题的。
C# 允许您编写非托管代码。 只需使用适当的关键字，您就可以在同一个文件中使用它。 它还允许您使用 LINQ 编写函数式代码，其读取方式类似于 SQL 代码，行为方式类似于函数式代码。 为了完全理解一个文件的作用，您可能需要对编程范式有很多了解。
如果您正在编写 Java，您也可以使用函数式编程，您只需将其写入一个单独的文件，使用不同的编译器并将其称为“编程 Clojure”。 如果您更喜欢结合面向对象和函数式编程，您可以将其称为“编程 Scala”。 重要的是，您仍在为 JVM 编写代码，可以轻松地与其他 JVM 语言的代码交互。
.NET 语言具有相同的功能，只是没有在 C# 哲学中使用。 他们也可以决定在 C# 中坚持一两个编程范式并创建一种新语言来添加新范式，但他们却选择了“一种语言来征服它们”——这很好，很高兴拥有像这样的语言。 您应该只了解这种理念以及作为程序员的选择。

长话短说：在我们拥有的所有语言中，我认为 C# 最适合 Godot。 它很适合 Unity，但是如果您有所有这些选项，那么为什么要选择一种在引擎中促进范式混合和匹配的语言，该引擎促进干净的 OO 原则和 KISS 编程的每个其他部分？

因此，如果您认为 C# 将是 Godot 的一个很好的补充，那么我并不反对您 - 我只是说存在更好的替代方案，应该首先对其进行评估，一旦 C# 实施就会立即被遗忘。

@hubbyist

在我看来，向 GDscript 添加更多功能将是处理脚本的更好方法

这肯定会发生，我不认为它与其他提案不相容。

对我来说，选择 Godot 而不是其他游戏引擎的主要原因是简化的脚本方案。 Godot 不提供学习新的编程语言。 它提供学习 Godot 及其脚本语言作为游戏开发的组合工具。 与让新手学习 C++ 或任何其他脚本编程语言相比，这是一种不那么令人生畏的方法。

但是 Godot 已经可以在 C++ 中使用，所以什么都不会真正改变（只要保留 GDScript），除了那些想要这样做的人更容易用 C++ 编码（目前编写模块需要编译所有 Godot，并且它没有集成进入工作流程）。

@Warlaan很好的分析。 如果您阅读了我的帖子，我也不同意 C# 是 Godot 的好选择，这就是为什么我建议扩展现有的 C++ 功能以使其可以用作脚本语言，而 GDScript 仍然是大多数用户的默认语言。

用户应该可以用 GDScript 编写很多东西，但是认为大型游戏会用 GDScript 编写是不合理的。 在我看来，除了 GDScript 性能之外，没有什么能阻止 Godot 适合大型游戏，因为引擎设计得非常好，性能已经相当不错（Vulkan 可能会做得更好）。

在我看来，性能对大多数 Godot 用户没有吸引力，但它可以为 Godot 带来更多的专业人士，这意味着更多的贡献，这意味着对每个人来说都有一个更好的 Godot。

@paper-pauper 我知道我们站在同一边。 当我写“如果你认为 C# 会是一个不错的补充”时，我是在写“你，匿名读者”，而不是你个人。 ;-)
是的，任何新的脚本语言都会吸引 GDScript 的注意力。 我怀疑社区是否会处理不止一种语言，迟早某些功能将不可用或从其中任何一种中破坏，甚至可能会导致其中一种语言被删除。

我也同意这里唯一真正的问题是 C++ 的编译时间和 GDScript 的性能。
人们已经知道 C# 的论点是完全错误的恕我直言。 我从事 C# 专业工作大约 4 年了（主要是使用 C++ 和 SQL），在那段时间里我学到的一件事是，我很可能永远无法说我真的懂那种语言。 毕竟对于 C# 6 和 7 的提议，功能的数量仍在增长。
因此，当我们谈论“了解 C#”时，我们实际上可以指的是了解最基本的语法，即使是最差的初学者也应该能够在几天内重新学习。 我最近为一群以前专门使用 Unity 的游戏设计师举办了一场关于不同游戏引擎的讲座，他们中没有一个人对 GDScript 的语法发表过不好的评论，而事实上，一些已经放弃编程的人现在又有了动力。

所以，是的，加速 GDScript 并使 C++ 编译和使用不那么繁琐的解决方案也是我最喜欢的。

许多“了解” C# 的人并没有使用它的许多特性，这使得它与 Java 不同。 只需看看无数的 Unity 脚本，它们的作用并不比子类多。

仅出于这个原因，我对 C# 所带来的实际优势持高度怀疑态度。 它们在许多情况下都很好，但不是游戏开发。 此外，C++1x 已经提供了许多这些东西（包括类型推断、迭代器和一些基本的功能工具），而且没有任何开销。

此外，CLR（甚至 JVM）带来的开销可能会使 Godot 执行_更差_，尽管我看到使用 JVM 的垃圾收集器有一些优势（有人知道更多关于 Godot 的内存管理）吗？

我在论坛上读到关于因为 GDScript 而不使用 Godot 的人。 我认为这是狭隘的，因为它没有任何问题，只是它的库选择很差，我试图在另一张票#3943 中通过提出一个零开销和跨平台的解决方案来解决这个问题支持。

无需通过 LLVM 实现 C++ JIT，有一个解决方案可以在本机代码上运行，并且不需要对 Godot 的源代码进行任何摆弄：动态链接。

第一个将允许本机代码，而无需从头开始重新编译 Godot：您只需将其编译为 .so 文件，然后将其添加到加载路径，然后从 GDScript 使用它而无需开销（因为它都是函数调用）。

这应该很容易做到（通过 libdl？），但据我了解，由于跨平台问题，它没有完成。

此外，还有将 GDScript 编译为 C++ 的想法，就像ENIGMA对其语言所做的那样。 这并不容易，但显然提供了最佳性能。

有人更了解 Godot 的内存管理吗？

从文档：

如果一个类继承自 Reference，那么实例将在不再使用时被释放。 不存在垃圾收集器，只是简单的引用计数。 默认情况下，所有未定义继承的类都会扩展 Reference。 如果不希望这样做，那么类必须手动继承 Object 并且必须调用 instance.free()。 为了避免无法释放的引用循环，提供了一个weakref函数来创建弱引用。

只是要注意...

GDscript 的一个主要优点是它是一种完全受 Reduz 和其他开发人员控制的语言，它对 Godot 开发人员的工作方式不依赖于外部团队，因此它可以以特定于引擎的设计并满足用户的要求。

另一件事是，虽然 GDscript 目前还不是真正的高性能语言，但可能有很多领域可以在保持其简单性和动态类型特性的同时大大提高性能。

还有一个事实是，GDscript 不需要任何编译知识，而且您不需要 Godot 内置编辑器之外的任何东西（这使得工作流程变得漂亮和整洁，更不用说简单和快速）。

只是一个问题，GDscript 解释器如何在内部工作？ 像旧的基本语言一样在运行时解析每一行，还是将整个脚本转换为字节码表然后运行字节码？

@RebelliousX

https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_compiler.cpp
https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_parser.cpp

我不认为有任何像 BASIC 一样的严肃语言了！ :)

你好！
以下是 GDScript 的历史：
///////////////////////
历史
最初，Godot 旨在支持多种脚本语言（这种能力今天仍然存在）。 但是，目前只有 GDScript 正在使用。 这背后有一点历史。

早期，引擎使用 Lua 脚本语言。 Lua 速度很快，但创建与面向对象系统的绑定（通过使用回退）既复杂又缓慢，并且需要大量代码。 在对 Python 进行了一些实验后，它也被证明难以嵌入。

最后一个用于发布游戏的第三方脚本语言是 Squirrel，但它也被删除了。 在那一点上，很明显 Godot 可以通过使用内置脚本语言更优化地工作，因为遇到了以下障碍：

• Godot 在节点中嵌入脚本，大多数语言在设计时都没有考虑到这一点。
• Godot 为 2D 和 3D 数学使用了几种内置数据类型，脚本语言不提供这一点，并且绑定它们效率低下。
• Godot 大量使用线程来从网络或磁盘中提取和初始化数据，通用语言的脚本解释器对此并不友好。
• Godot 已经有一个资源的内存管理模型，大多数脚本语言都提供了自己的，这导致了重复的工作和错误。
• 绑定代码总是很混乱，会导致多个故障点、意外错误和普遍的不可维护性。

最后，GDScript 被编写为自定义解决方案。 它的语言和解释器最终比 Lua 和 Squirrel 的绑定代码本身更小，并且功能相同。 随着时间的推移，拥有内置语言已被证明是一个巨大的优势
//////////////////////

在我看来，c++ 可能是最好的。 有一些解决方案，例如：
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
甚至 Angel 脚本通常也可以像编译的运行时一样。
在脚本方面，我喜欢 python，因为我一直喜欢混合游戏和科学模拟的解决方案（python 有许多科学库）。 所以我抱怨！ 在另一个问题中，为什么 godot 拥有自己的物理库： https ://github.com/godotengine/godot/issues/4217
关于 C# 等语言存在一些问题： https ://github.com/godotengine/godot/issues/2790

很好的发现， @ alabd14313 - 这将解决几乎大多数问题，同时不理会 GDScript。

关于RCCCPP，这是一个非常好的主意。 我认为如果 Godot 在编辑器模式下支持它，然后在构建中禁用它，将会有最大的性能并且迭代时间会非常快。 我听说像虚幻引擎这样的其他引擎用 C++ 做类似的事情，我认为如果 Godot 允许无缝的类似脚本的 C++ 编码，那将会非常简洁。

似乎作者知道他们的东西，因为在此页面中，他们列出了他们方法的大多数替代方案（包括我提到的 LLVM JIT）。

我认为这种方法是最有意义的，因为 Godot 是用 C++ 编写的（而且我认为这不会改变，考虑到 C++ 几年后会更好），它已经有一个可用的 C++ API 和 C++在零开销的情况下几乎具有最大的理想性能，并且不会有额外的运行时或内存管理器。 我希望开发者能看看它。

我有点惊讶地发现，这个由 afaik 发起的线程是对将 C# 添加为脚本语言的提议的反应，即使在六个人表达了他们的意见之后，它还没有包含一个针对 C# 的参数。
也许添加 C# 的决定并不像我从听到的谣言中假设的那样有预谋。

@Warlaan如果将此 URL 发布到 facebook 群组会发生什么？ :)

请将标题更改为“C++ 作为脚本语言”之类的内容。
C++17 有更多的特性：
http://blog.mattnewport.com/why-c17-is-the-new-programming-language-for-games-i-want/
我很佩服 Godot 开发者，并感谢他们的工作。 但我反对 Box2D/LiquidFun/Bullet 库。 通过这种方式，开发人员可以专注于管道，而不是像物理这样的组件。 使用 C++，他们可以专注于性能，而不是维护和更新 gdscript。 理论上 RCCPP 可以更好地实现工具模式等一些新功能。 也许...

@reduz几个月前提到他想实现可视化脚本，比如虚幻蓝图。 使用 RCCPP，C++（针对程序员）和 Visualscripting（针对关卡设计师和美术师）之间的工作流程可以实现如下：
UE4 中的 C++ 编程简介
C++ 和蓝图
因此，在一个小组中，程序员可以为艺术家开发新的蓝图类，而艺术家使用这些而不是直接编码。

@Warlaan恕我直言，这是因为很多 C# 谈话都是由希望 Godot 成为 Unity 盗版者的人推动的，但幸运的是，这里的许多人意识到 Godot 是它自己的东西，并且在许多方面已经领先于 Unity，这不公平让它受到同样问题的影响。

@ alabd14313我会更改标题，但也许最好创建一个单独的问题并保留它以供后代使用，以便在有人提出 C# 时可以链接它（通常是这种情况）。

老实说，我对可视化脚本犹豫不决，但如果它可以作为模块实现，那为什么不呢？ 当然，我认为拥有可视化脚本（设计师和新手）、GDScript（会编程或愿意学习的人）和 C++（程序员）将使 Godot 成为适合所有技能水平的相当平衡的程序，但会使 C++ 编码更少笨重且允许更容易与第三方库交互应该具有更高的优先级，恕我直言，因为它可以带来很多专业用户（以及因此，贡献者）。

恕我直言，可视化脚本还远远不够完善以使其有意义。 它非常适合营销和谈论初学者编程，但根据我的经验，初学者更喜欢流程图的学习阶段非常短。
除了最基本的调用序列之外，我所知道的系统（Unreal、Cryengine、Fungus、Stingray）根本没有帮助。 我的意思是这个截图例如来自 Stingray 引擎的官方广告视频。 这就是我所说的意大利面条代码。 Cry 引擎中的官方示例看起来也好不到哪里去，尽管您可以从评论元素的数量中看出，为了使图形可读，或者更确切地说是试图做到这一点，我们付出了很多努力。
如果您认为这还不错，让我提醒您，如果您在基于文本的语言中看到该代码，那么从屏幕外开始的每条连接线都将是一个具有（希望）有意义的名称的变量。

当涉及到着色器/材质时，流程图有些帮助，因为可以显示中间结果，但即使在那里，系统也会受到以下事实的严重影响：
浮点 x = (ab)*(a+b)/(1-(a+b))
当它以图形的形式完成时，很容易填满整个屏幕，因为每个乘法、求和或差值都是一个具有两个输入和一个输出的节点。 以上公式至少有 10 个节点，如果您不想造成连接混乱，则必须复制 a 和 b 节点。

我们今天拥有的流程图系统（至少我知道的那些）取消了为值赋予有意义的名称的选项，因为您无需将结果放入中间命名变量中，您只需将其连接到下一个节点。 这使得自记录代码几乎不可能，并且需要您在文档中投入更多精力。
这些系统添加的是将节点放置在您想要的任何位置的选项，根据我的经验，这会导致代码的可读性降低，而不是更容易阅读。

并且请不要谈论流程图，就好像它们不是在编码一样。 它们与任何其他编程语言一样多的编码。 他们不打字，仅此而已。

可视化脚本是供设计师和艺术家在无需学习如何编码的情况下进行更改的。 一些艺术家还可以用它制作简单的互动游戏。 它有它绝对有用的目标，它只是不适合程序员。

@Warlaan好吧，这取决于您如何定义“编程”。 当然，可视化脚本类似于定义算法，因此它离编程不远，但编程还涉及其他事情。

不过，有一些很好的可视化编程实现。 PureData 是其中之一，还有GDevelop ，一个相当不错的 FLOSS 游戏制作程序（遗憾的是它不是更受欢迎）。 简而言之，尽管我个人并不喜欢它（出于您提到的某些原因），但我们都可以编程也是事实，因此对我们而言，可视化编程是一种缓慢而繁琐的实现相对较差的结果。

不过，我同意@reduz的观点，有些人认为它具有吸引力。 他们不是那些会在这样的话题上闲逛的人，但他们也制作游戏。 我认为他们可以为戈多带来一些东西。

流程图适用于着色器编辑的原因是它非常直观（您有允许您加载图像、选择颜色等的节点......无需手动输入文件路径和值）。 您也完全不用担心确保语法正确并且函数拼写正确。 也无需弄清楚如何使用矩阵等复杂任务（这一切都是为您计算的）。

Godot 的着色器编辑方法最终成为一种很好的方法，因为它干净地分离了顶点、片段和灯光组件，并且还为您正在使用的数据类型提供了清晰的指导（无论是普通信息还是相机信息）。

现在有了可视化脚本，如果节点在游戏机制方面处于足够高的水平（它们做更复杂的事情并有多个输入）并且如果有节点允许您运行脚本或创建表达式/等式（进而可用于以复杂的方式操作值）。 我在这种类型的其他可视节点系统中看到的问题是它们试图尽可能接近文字编程（即，将一堆低级函数作为节点，而不是更像是Blender 的逻辑积木或 GameMaker 的拖放）。

当然，它仍然不允许像纯脚本那样精细和高级，但它仍然可以用于游戏中的简单对象类型（不需要非常复杂的逻辑） ) 或者如果你需要快速敲出一些东西。

我同意有些人从中看到了吸引力，我也同意它不适合程序员（只是我们对“程序员”的定义不同;-)），所以我建议我们把讨论留在那个地方，因为它有点离题。

C++ 的另一个有用特性是它的静态类型。 “auto”和“decltype”工具可以检测对象的类型。 编辑器和代码完成可以更容易。 我们可以使用另一个外部 IDE，而不是专注于内部代码编辑器。 目前我认为 codelite 和 qtcreator 在代码完成方面有更好的地位。 代码块在 c++11 关键字方面存在一些问题。 eclipse-cdt 也有很好的代码完成功能。 qtcreator 插件是个好主意（如 unreal-visual studio 和 Unity-Monodevelop）。 外部IDE可以通过godot设置中的系统路径识别（如/use/bin/qtcreator），不需要godot编译打包（不像Unity包内置monodevelop）。
qtcreator 中还有其他一些工具，例如 cppcheck 和 valgrind，它们都有插件。
如果您想预览一下什么是 RCCPP：
演示

我很想看到一个基于 C++ 的 Godot 脚本语言，但是实现所有 C++ 功能会很麻烦，比如模板编程。 这种脚本语言 (STL) 必须有一些限制，并且不应使用模板。 RTTI 也可能导致性能问题。

我喜欢 GDscript，我唯一的抱怨是变量命名空间的污染，在处理大型脚本时，ready() 之前的变量定义会变得非常混乱，并且由于在同一脚本文件的函数之间共享变量而容易出现代码错误.

我的 3 美分。 （呃......它结束了20，但让它成为......）

就像前面提到的@alabd14313一样，“它就在它所在的位置”，因为多年来的演变导致 godot 形成了今天的样子。
无论大自然这样做还是我们人类这样做，在创造之时纠正事物似乎是最好的发展方式，我必须承认，多亏了这一点，我非常喜欢戈多，因为它是进化带来的。

它有所有需要的部分。

节点可以组合成更复杂的对象，保存为场景，然后在另一个场景中再次作为“简单”对象重复使用，这是一个很棒且超级灵活的功能，实际上，仅受用户自己的想象力和创造力边界的限制。

GDScript 易于使用和学习，功能强大，足以以我们​​编码人员习惯的方式控制所有节点 - 通过键入代码行。
除了以快速简单的方式（代码完成/内置文档/有用的工具提示）而不需要编译之外，只需键入、尝试、调整，然后再次将其打磨至完美。

真正一键部署到多个平台（更不用说这些通过 wifi/adb 部署到 android，生活编辑，调试等只是艺术杰作，不......它更多，它的魔力！）

此外，所有这些对常用工具（如搅拌机等）的熟悉程度。
（导入东西，它开箱即用，一切都在哪里以及应该如何）

最后，我承认有时即使是超级创造力也可能不足以在循环中完成数百万次并适合 1 帧。 这就是 C 东西的用武之地。如果你知道 C，需要它，没有什么能阻止你创建插件、自己的自定义节点等，这正是你想要的。

它几乎拥有一切，而且我相信迟早会拥有一切。
（意思是，今天的事情“还没有实现”，必须“以某种方式”或“徒手”去做（阅读：使用外部工具）例如，以一种简单的方式调整 3D 装配的东西（必须使用搅拌机)

戈多是一个了不起的神奇事物，在它所走的道路上完美无缺。需要调整并在这里和那里添加东西，但就是这样。

可视化脚本？
呃。 它可能会迫使我们编码人员以一种不寻常的方式“稍微”改变思维方式，而且我不相信它可以像普通代码那样灵活和可读。
想象一下你在编码并且有这样简单的一行（ abc / def ）* ghi
然后是快速的方法，像往常一样（？）保存打字，你标记某物的一部分，粘贴到这里，剪切到那里，再次粘贴，然后在 5 秒内并按下按键，最终得到“简单”（因为你知道它的作用）一个像 ((((abc/def+((abc/def)_ghi^4))_ghi)+(abc/def_(100))_ghi)+abc)
它很常见，也许我们中的许多人以超快的方式这样做。
现在想象一下视觉方式......
它可能需要整个屏幕，大量的鼠标工作，而且看起来不那么可读。
（当然，一年后这样的衬里看起来也不容易，但这就是评论的目的）

如果有人有 100 条这样的线，一个接一个怎么办？
视觉上他可以得到一个足球场来展示它。 怎么分析它，改变它，那是一团糟，而且很头疼。
程序员当然可以这样做，因为它不是使用的语言，使某人成为程序员，而是特定的思维方式，创建算法，将数据作为一个小部分和一个整体进行操作。
无论是 C、Python、PHP、Java 还是 Visual 脚本，这门语言都只是写下想法的工具。
在这里，恕我直言，用键盘正常打字是写下来最快和最易读的形式。
另一方面，如果有人不会编码，你是否希望他突然展现算法天才和洞察力，不会迷失在自己的想法和视觉表现中，考虑到当我们思考游戏时 - 我们谈论的事情比两个球扑打更复杂彼此与物理。

那么真正适合谁的可视化脚本呢？
让程序员的生活更加艰难，或者将 godot 限制为针对初学者的“简单游戏”的关卡引擎？

各位，#1220 中对可视化脚本进行了长时间的讨论。 让我们不要在这里再次讨论相同的话题。

各位，#1220 中对可视化脚本进行了长时间的讨论。 让我们不要在这里再次讨论相同的话题。

这里的大多数帖子都很长，也许让我在阅读时迷失了自己。
对不起：放松：

@RebelliousX即使使用 RTTI，C++ 的性能仍然比 GDScript 好得多。 尽管模板确实可能是一个问题。

@reduz在#3936 中提出的解决方案已经使 C++ 中的编码变得相当简单——您只需使用您选择的编辑器和编译器并链接到 Godot 的 API 即可。 如果实现了这一点，即使用 C++ 编写脚本会很好，就性能而言，它与用 C++ 编写代码然后从 GDScript 调用它并没有太大区别。 简而言之，我认为专注于#3936（这是一个简单的解决方案）会大大改善：

• 性能（因为用 C++ 编写部件非常容易）
• 第三方库的可用性（因为包装器可以更容易地分发，但不像 #3943 那样容易）
• 用户群和贡献者（许多 C++ 程序员会采用 Godot）

然后可以专注于 GDScript 中的静态类型和优化解释器（通过 JIT 或通过将 GDScript 编译为 C++），但如果编写模块更容易，这可能会在以后出现。

我只想提几个已经潜入讨论但尚未解决的观点：

• 我们中的一些人正在谈论通过促进 C++ 开发和提高 GDScript 性能来改进现有系统（GDScript 作为脚本语言，C++ 作为后端语言）。 其他人则在谈论使用 C++（或 Java / C# / ...）作为脚本语言。 启用快速 C++ 开发和使其成为脚本语言之间似乎没有真正的区别，但我很乐意解释我是如何体验和观察到强大的脚本语言对游戏设计质量的负面影响的。 除非这成为讨论的主题，否则我很乐意在论坛或其他不会劫持此线程的地方这样做。
• @RebelliousX ：当您谈论“变量命名空间”、“大型脚本”和“函数之间共享变量”时，听起来很像您还没有完全理解 GDScript 的面向对象性质（无意冒犯）。 每个 GDScript 文件都是一个类，因此（成员）变量之间的名称冲突应该像在任何其他面向对象语言中一样经常发生。 您不是在脚本之间共享变量，而是在编写几个可以访问包含对象状态的函数。

@Warlaan关于第一点，我认为您可以在此处发布，因为它与主题相关。

@Warlaan没有冒犯。 我知道 GDscript 是它自己的一个类，并且我知道变量就像 C++ 类中的普通成员变量，但你似乎完全错过了我的观点。 当你有一个超过 1000 行代码的脚本时，你就会理解它。 我想要的是引用或指针，而不是创建无数的成员变量，只需在成员函数之间传递它们。 这样更安全。

我喜欢 C#，但我看到了优点和缺点。

优点：

• 良好的工具支持（让我们面对现实吧，你会在没有 Visual Studio 或 MonoDevelop 的情况下用 C# 编写代码吗？）
• 适合大型项目
• 广泛使用和成熟，互联网上有大量的支持线程。
• 良好的性能，C++ 和脚本语言之间的权衡，同时是跨平台的
• 相对容易绑定到 C++

缺点：

• 垃圾收集：大型游戏项目也需要执行分配策略，以防止 GC kicks 发生过于频繁，这可能很讨厌
• 不如 GDScript 集成（节点路径完成？节点上的脚本成员变量？内存分配模型？）
• 运行时很重，.NET 框架甚至更多。 与 Unity 一样，标准库应该重新映射到 Godot 的。
• 不是最适合实际的脚本，在某种意义上让事情完成得又快又脏。 C# 比 GDScript 更冗长和限制性更强。
• 目前还没有关于 Godot 开发的指导方针。 该语言是通用的，可以做很多事情，正如 Warlaan 所说，开发人员有不同的文化（你可以让 WPF 编码员尝试 Godot 并想知道为什么没有 MVVM 方法来创建 GUI：p）

其中大部分也适用于 Java。
也许我忘记了其他事情，因为这里已经很晚了。

好的，这是我对功能丰富的脚本语言的经验。 根据您对“脚本语言”的定义，完全缺乏脚本语言。 我会尽量保持简短。 ;-)

几年来，我一直在德国柏林的 School4Games 担任工程系主任。 在那所学校，我们没有教授“纯”游戏设计的教师，但我们的游戏设计课程被称为“游戏开发”，其中包含足够多的编程课程来教游戏设计师如何开发自己的原型并了解可能性和限制硬件和通用软件架构。
所以我教的学生是那些有时对编程有浓厚兴趣但没有一个人申请成为程序员的人。
每个学期他们都必须组建团队并开发一款游戏。 由于我们学生的几乎所有潜在的未来雇主都使用 Unity，因此前两个学期必须使用该引擎。

现在让我们谈谈脚本语言的影响：
这些学生分成两组。 一种要么试图避免编程，要么已经失去希望（这意味着他们将参加编程课程，但如果遇到麻烦不会寻求帮助，而是默默地放弃），另一种是深入编程以至于他们直接跳到那些通常您在编写游戏原型时不会担心。 例如，我第一学期的一个学生最近发布了一篇关于如何使用泛型在 C# 中编写单例的教程，以便您可以通过从教程中的泛型类继承将 Unity 组件类转换为单例。 有趣的不是他能写出那篇文章，毕竟他当然得到了老师的帮助，而且网上有很多关于这个话题的资源。 有趣的一点是，申请一门主要关注游戏设计而不是编程的课程的学生会对这样一个特定的编程主题感兴趣。 该教程中的代码永远不会因为游戏设计的变化而改变，它是一个纯粹的编程结构。
类似的事情发生在另一个学生身上，他使用类似的课程将信息从一个游戏场景传输到另一个游戏场景。 当我向他展示他可以用一个公共静态成员做同样的事情时，他非常惊讶，这表明他在完全理解其中的所有基本元素之前正在寻找完整、复杂的解决方案。

因此，如果您跳过前面的内容，那么总结一下到目前为止的文本：虽然可以用功能丰富的语言编写简单的代码，但我多次观察到人们可能会忽略存在复杂替代方案的简单解决方案。

这不仅仅是由于偏见。 当然，这可能是一个因素。 如果您发现项目中的教程、示例或其他类中的代码看起来很复杂，您可能会得出结论，您的代码也应该看起来很复杂。 但我认为真正的原因是在编程中尝试创建防错代码是有意义的。 编写在不同地方使用或收到不同输入时不会中断的代码是一种自然的愿望。 这需要您找出可能需要准备的选项。
我认为这种必须检查每一种可能性的感觉将我的学生分成了那些淹没在 C# 的大量功能中的学生和那些直接进入并失去对语言的关注的学生。

Zylann提到了“又快又脏”这个词。 我们经常将这两个术语用作一个短语，但是当您考虑它时，它们实际上是两个不同的因素。 是否可以快速编码是可以衡量的。 另一方面，生成的代码是否脏取决于很多因素，最重要的是所使用的语言具有的功能数量。
例如，创建一个顶级节点并将其用作 Godot 中的单例完全没问题，因为 GDScript 不提供以与 C# 等语言相同的方式实现模式所需的功能。 当然，使用自动加载功能会更好，因为这是其他开发人员首先会寻找单例的地方（并且它使语法更好一点），但是如果一个团队决定以这种方式实现它，我怀疑会有很多争论。 另一方面，想象一下有人在 Unity 中实现了一个单例，只需向一个类添加一个公共静态成员。 它同样快，在某种程度上它甚至是同一件事（两者都是最公共场所的类实例），但由于 C# 确实提供了使构造函数私有的选项，因此可以通过延迟初始化等属性访问单例。期望你这样做，否则如果没有破坏，代码将被视为非常肮脏。

现在，游戏设计专业的学生深入研究此类主题这一事实可能模糊地暗示了我的观点，但我认为我可以通过谈论我在一家大型 F2P MMO 开发商的第一份工作时的情况来更好地说明这一点。 我加入的团队是德国最有经验的游戏开发者之一。 自 1995 年以来，他们的开发主管一直在创建自己的内部引擎，尽管他们刚刚被另一家公司收购，但他们仍然是当时最成功的开发商之一。
当我加入团队时，他们正在使用内部引擎的第三版，它没有脚本语言。 他们之前已经实现了一个，但在那个版本的引擎中，由于游戏设计师提供的代码质量存在问题，他们恢复为没有任何脚本语言。 换句话说，由于脚本语言过于强大，因此决定将程序员和游戏设计师之间的障碍转移到游戏设计师只编辑关卡和更改配置表中的设置而程序员完成所有编程的地步——回想起来，我注意到这与我的学生最终遇到的情况几乎相同（似乎许多使用 Unity 的专业工作室最终都遇到了这种情况）。
现在我为什么要关心？ 如果这种情况一次又一次地发生，那不就证明这是一种成功的工作方式吗？ 我的回答是否定的，因为在技术和游戏设计方面都存在问题，这很容易解释为程序员和游戏设计师之间的沟通被简化为一个方向的编写任务和另一个方向的设置。 从游戏设计师的角度来看，这些功能变成了可以启用和禁用的黑匣子，但在团队的那一边，没有人可以讨论甚至原型替代方案。
另一方面，程序员几乎自然而然地陷入了后端心态。 “快速而肮脏”的 KISS 心态已经消失，因为我们谁也无法预测我们构建的功能将如何使用。 我清楚地记得有一次数据库崩溃了，因为游戏设计师实施了一次复活节彩蛋活动，导致库存比以前大得多。 那是我最后一次假设一个功能的要求可能会保持不变。

这就是为什么我认为将低功能脚本语言作为游戏代码的定义区域非常重要，以及为什么我认为没有它会对游戏设计产生不良影响。

• 编写快速代码意味着忽略将其变成“快速而肮脏”的代码的功能。
• 编写干净代码的愿望将开发人员分为不编码的开发人员和花更多时间思考编码而较少时间花在游戏上的开发人员。
• 这反过来又将整个团队分成了一半在不知道代码库的情况下进行游戏设计，另一半在不知道将如何使用的情况下处理功能，没有人可以根据游戏提出引擎功能根据可以轻松实现的功能设计或建议游戏设计。

如果不使用预构建的类库，就无法想象今天的游戏开发，毕竟这就是使用 Godot、Unity、Unreal 等工具集的引擎如此成功的原因。 但所有这些引擎之间的区别在于，编程和游戏设计之间的界线在哪里，以及两者之间的差距有多大。
根据我的观察，我认为脚本语言的选择是造成或缩小这种差距的最重要因素之一。

顺便说一句，我之所以如此参与 Godot，是因为我正在努力将其确立为第一学期的强制性引擎。 只是为了让你知道，我不仅在谈论，而且还在得出我的后果。 ;-)

@RebelliousX我不得不承认我仍然不太明白你在说什么。 但是，既然您说您想要的是引用或指针，您是否可以打开一个新功能请求并在其中发布您的问题的代码示例？ 老实说，听起来您的问题仍然是代码架构之一，而不是缺少的语言功能之一。

我应该补充一点，KISS 主要对小型团队有利。 Godot 功能如此丰富，以至于一个开发人员可以制作游戏。 但是一旦一个项目有更多的开发人员，“快速和肮脏”的事情就变得不太可能，并且留给原型设计或临时修复，那么必须设置规则/指南。 所以，这真的取决于谁在使用引擎，以及为了什么。

总的来说，戈多也有比我们想象的更多的限制。 您不能制作“c-static-style”单例或全局变量是有原因的：内存泄漏和线程友好性。 GDScript 的功能不如 Python 有一个原因：专注于游戏开发任务和性能。 场景系统也是面向对象的，这是有原因的：您可以制作可以测试和重用的独立“盒子”:)

本主题是关于添加 C#（或 Java）模块支持，但我没有看到示例代码。 让我们在飞行中尝试一些东西:)

using GodotEngine;

// Inherit a node type
public class Spikeball : RigidBody2D {

    // Exported variables
    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

    // Notice the naming convention. Should Godot API follow languages or should languages follow Godot?

    void _Ready() {
        SetProcess(true);
        // Should we use the generic system?
        Connect("BodyEnter", this, "_OnBodyEnter")
        // Or use C# features?
        this.bodyEnterEvent += _OnBodyEnter;
    }

    void _Process(delta) {
        var sprite = (Sprite)GetNode("Sprite");
        sprite.SetRot(sprite.GetRot() + delta*rotationSpeed);
        // Or we can have properties
        sprite.rot = sprite.rot + delta*rotationSpeed;
    }

    public void _OnBodyEnter(PhysicsBody2D body) {
        // We cannot invent C# members on the fly, so we can do this if the other script is in C# too.
        // ScriptInstance GetScript();
        var health = body.GetScriptInstance() as IHaveHealth;
        if(health != null) {
            health.TakeDamage(damage);
        }
        // But what if the other is GDScript?

        // A generic approach would look like this, a bit like SendMessage in Unity3D
        // object Call(string funcname, object arg1, ...); // where object can be seen as Variant
        body.GetScriptInstance().Call("TakeDamage", damage);

        // Same thing if we want to get a script variable
        var category = (string)body.GetScriptInstance().Get("category")
        Console.Print(category);
    }

}

你怎么认为？
然后可以将该文件编译为 DLL 资产（或即时运行）。 但是说到这个，我们是否需要像Unity一样生成一个csproj？

@Warlaan感谢您分享您的经验。 如果我弄错了，请纠正我（这是一篇很长的帖子），但是你是说提供一种功能较少的语言对程序员来说更好，这样他们就可以专注于开发他们的游戏而不是过度编码？

如果是这样，这是一个非常微妙的观察。 我认为 Godot 开发人员必须为他们的用户群做最好的事情——他们知道什么是最好的。

今天我自己想知道这里的某些人（包括我自己）是否不只是巧妙地要求Urho3D ，而其他人则要求GDevelop 。 Godot 显然是这两者之间的中间工具（但非常适合专业人士，更像 Urho3D），我认为它应该保持不变，但 Unity 总是会在它上面投下阴影，因为这里有很多人来自它。

我认为期望 Godot 成为 Unity 盗版是不公平的 - Godot 显然有更好的设计，据我所知，更好的性能。 但是有些人认为 GDScript 不适合“严肃”的开发，并且永远不会因为它是自定义运行时，尽管 Unity 使用的旧版本 Mono 在某种程度上也是“自定义”运行时。 此外，当您在 Unity 中编写 C# 时，您编写的代码大部分只能在 Unity 中工作并遵循它们的设计模式，因此您不妨使用另一种语言。

我认为那些想要 C# 的人是错误的，但我认为一个很好的折衷方案是提供：

1) 更好的性能（静态类型，可能是 JIT）
2) 更好地支持第三方库（通过 FFI 和更简单的 C++ 集成）

对于 GDScript。 其余的可以在 C++ 中完成，包括编写实现其他脚本语言的模块（不需要是第一方 - 每个人都可以编写 C# 模块，如果他们愿意）。

@Zylann 老实说，我认为编写该代码而不是等效的 C++ 没有任何优势，而且 C++ 代码将具有更好的性能。

@paper-pauper 编写此代码的优势与 GDScript 相同：您无需为要导出到的每个平台重新编译引擎，而且......好吧，您可以选择语言（并且性能是不是唯一的一点，正如我之前提到的）。 我同意目前，GDScript 体验更胜一筹，而 C++ 是纯性能的最佳选择。 但是，有些人就是不想做 C++，不管它有多好。
我个人对 Godot+C# 不感兴趣，只是评估将它添加到 Godot 会发生什么。 这不是那么直截了当：p

在阅读了伟大的书籍 Game Scripting Mastery 之后（你找不到很多关于这个主题的书籍，除了关于编译器 Red Dragon 的非游戏书籍）。 我的结论是，GDscript 就足够了，很容易不断地向脚本语言添加功能，从而使其失去功能。 最重要的是实现一种不臃肿的脚本语言并尽可能通用，使其适用于不同的项目。 在同一本书中，它说 Unreal 正在使用 C++ 和 LLVM。

另一个可能比实现单独的运行时更轻量的想法：如何调整像 TypeScript（它与 C# 非常相似，没有运行时）这样的转译器来发出 GDScript 而不是 JavaScript？ 这不必包含在 Godot 中，实际上它可能是第三方模块。 它至少会提供静态类型（在编译时）和许多库，具有与 GDScript 相同的性能（因为它是 GDScript）。

我喜欢 TypeScript，但我不明白添加这种复杂性的意义。 如果有人这样做，他们将不得不维护它以兼容新版本的 TS。 此外，TS 是 JS 的超集，那么这是否能够将 JS 转换为 GDScript？ 然后，我们会让一些人在编译器中有错误，认为这是引擎中的错误。

我仍然认为更好的想法是拥有一个静态版本的 GDScript，它可以更轻松地使用 JIT，并且仍然与引擎和当前的 GDScript 本身密切相关。

C# 的重点是使用既定的语言，也可以在 Godot 之外使用。 TypeScript 可能适合这个，但我不相信制作 TS 转译器比嵌入 Mono 运行时更容易。

对我来说，正如我在 IRC 上所说，最好的选择是制作动态链接模块的能力。 因此，您可以更轻松地使用 C++ 工作，并且可以使用不同语言的第三方模块，例如一种用于 C#，另一种用于 C++ 作为脚本语言。 它会增加增加 Godot 资源的能力，而不必膨胀主引擎二进制文件。

@vnen

对我来说，正如我在 IRC 上所说，最好的选择是能够制作动态链接的模块。 因此，您可以更轻松地使用 C++ 工作，并且可以使用不同语言的第三方模块，例如一种用于 C#，另一种用于 C++ 作为脚本语言。 它会增加增加 Godot 资源的能力，而不必膨胀主引擎二进制文件。

哦，我 100% 同意——事实上我在 #3936 中表达了类似的观点。 我只是把它扔在那里，因为我们提到 C# 的运行时是一个缺点:)

对我来说， @Zylann的示例 C# 模块很可爱，如果可以的话，我现在会从 Unity 切换 - 这与 C++ 的更高性能或 GDScript 的“易用性”无关，而是关于舒适。

我对 Godot 还是很陌生，而且我几乎没有机会制作测试游戏，所以你们可能认为我的意见不正确，但对我来说，GDScript 是最大的障碍，而不是它应该如何与 Nodes 一起工作和场景 - 我明白这一点（而且它非常整洁！）。

但对我来说，GDScript 的语法至少可以说真的令人反感，更不用说代码编辑器严重缺乏——我很想使用 VS，因为我已经知道所有的快捷方式。
我已经掌握了多年编写 C# 的经验，老实说，我感觉自己就像一个尝试用 GDScript 编写的孩子。

允许开发人员舒适地编写会丢失什么？ 我不需要过多的 Mono 或 Linq 之类的花哨，我只想在编写代码时保持舒适。
我愿意为 GDScript 使用类似 C# 的语法，至少可以选择使用花括号、分号和显式类型——我个人无法忍受隐式类型，它们让我发疯。
我认为 GameMaker 允许使用不同的语法来适应不同的人口统计数据。

当然，这只是我与 Godot 几个小时的 2 美分 - 随意不同意（我相信你们中的大多数人都会这样）。

另外，我认为我遗漏了一些东西 - GDScript 到底是什么让每个人都如此喜爱？
我不是想冒犯，我只是还没有看到。
我对 Perl 非常熟悉，所以我知道隐式类型的力量等等，但肯定不止这些，对吧？

@皮克尔：

另外，我认为我遗漏了一些东西 - GDScript 到底是什么让每个人都如此喜爱？
我不是想冒犯，我只是还没有看到。

GDScript 的重点不在于语法（即 Pythonesque），而在于它与引擎的集成程度。 这可能听起来很迂腐，但在迁移到另一个系统时，语法是最不关心的问题。 最重要的是 API。 即使我们现在添加了 C#，您也可能会对新范例感到不舒服，因为您在 Unity 中的操作方式与在 Godot 中的操作方式不同。

抱歉，但如果我们添加语言来进入每个程序员的舒适区，我们将花费永恒的时间来做这件事。 虽然给 Unity 用户带来最小的压力可能是有意义的（现在我们正在尝试为 Unity 用户制作一个 Godot 指南），但我认为 Godot 不应该适应自己以像 Unity 一样工作。 否则我们必须对 Unreal、Urho3D、GameMaker 等的用户做同样的事情。

这并不是说 C# 没有发生（如果可行并且符合引擎的利益，可能会发生），只是这些论点也适用于许多其他语言和引擎。

@Pikl首先感谢您提供支持 C# 的第一个论点。 现在让我解释一下为什么我认为你的意见是无效的。 ;-P

让我们仔细看看 Zylann 的代码示例的开头：

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

根据经验，每个关键字和每个非关键字字符都有含义。 如果不是，它不应该在那里。
它开始于
using GodotEngine;
这意味着这段代码是指从“GodotEngine”包中导入的函数。 由于 Godot 中的每个脚本都引用了这些函数，并且没有其他包可以从中导入，因此添加该行是没有意义的，所以让我们删除它。

接下来我们有
public class Spikeball : RigidBody2D {
GDScript 中的所有内容都是公开的，为什么要提及它呢？
class Spikeball : RigidBody2D {
每个 GDScript 文件都包含一个与脚本同名的类。 这不仅仅是像其他语言那样的编码约定，它是这样定义的，那么重复类名的意义何在？
: RigidBody2D {
现在，由于 : 是这一行中唯一有意义的“关键字”，让我们用更易读的东西来替换它。
extends RigidBody2D {
任何有一点经验的编码员都会使用缩进来标记代码的不同区域。 这意味着类中的代码可以通过大括号和缩进来识别，这就是 Python 的开发人员决定强制缩进并摆脱现在多余的大括号的原因。
在我们的例子中，在类级别上甚至不需要缩进，因为每个脚本文件都被定义为一个类（除非您使用的是由缩进标记的子类）。
extends RigidBody2D

接下来我们有出口线。

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

[] 字符标记在同名类中定义的属性，这是 Godot 中不存在的机制，因此它只是使用关键字来代替。

    export public float damage = 60f;
    export public float rotationSpeed = 2f;

同样，一切都是公开的：

    export float damage = 60f;
    export float rotationSpeed = 2f;

并且您不需要指定数据类型。

    export var damage = 60f;
    export var rotationSpeed = 2f;

导出是一个例外，因为检查器需要知道要显示哪个小部件，因此类型实际上只是导出关键字的额外信息。

    export(float) var damage = 60f;
    export(float) var rotationSpeed = 2f;

所以这个C#代码之间的区别

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

和这个 GDScript 代码

extends RigidBody2D

export(float) var damage = 60f;
export(float) var rotationSpeed = 2f;

只是删除了没有描述您在 Godot 中的选项的每个字符和关键字。
我假设现在很清楚人们喜欢 GDScript 什么。 您不会被迫输入无意义或多余的内容，并且语法反映了您拥有的选项，而不是暗示 Godot 中不存在的选项或语言功能。

来自 C++/C#/TorqueScript 背景，我不得不说 Godot 的范例需要几天时间才能适应，但是一旦它的简单性“点击”，您就可以尽可能快地从想法转移到执行。

@vnen ：

只是这些论点也适用于许多其他语言和引擎

公平地说，我没有屏住呼吸，也没有期望被接纳——这不是我的领地。

现在我们正在尝试为 Unity 用户制作一个 Godot 指南

也许我可以帮忙？ 我已经使用 Unity 好几年了，与任何其他引擎相比，我对这件事非常了解——我会成为本指南的优秀实验室老鼠。

@Warlaan ：

我假设现在很清楚人们喜欢 GDScript 什么。 您不会被迫输入无意义或多余的内容，并且语法反映了您拥有的选项，而不是暗示 Godot 中不存在的选项或语言功能。

这是完全合理的——它符合 Perl 减少键入脚本所需的击键次数的思想。 但实际上，我为该示例实际键入的击键数量是相同的——我最大限度地使用 VS 的自动完成功能，并且在按空格或打开之前很少需要为任何关键字、类型或变量名称键入超过 3 个字符括号来完成它。 至于那里实际额外的“不需要”字符，我更喜欢将它们放在那里，这只是一种语法糖偏好。
Godot 具有自动完成功能，但速度很慢，它需要很长时间，以至于我经常在大部分时间出现之前输入我的整行代码。

所以人们喜欢 GDScript 的地方在于，它被精简到尽可能少，提供可供使用的确切功能，仅此而已，同时减少了击键次数。

我明白了，但这并不能帮助我再享受它——我只是不习惯输入 GDScript，但我可以很好地阅读它。 我不是在努力学习它，我只是不喜欢它，似乎。
也许再花几个小时制作一个 Space Invaders 克隆将有助于说服我——我比我更喜欢 GDScript。

事后思考：
是否可以在 Godot 中仅使用 C++？ 老实说，我认为我更愿意学习 C++ 并使用它而不是 GDScript。

也许我可以帮忙？ 我已经使用 Unity 好几年了，与任何其他引擎相比，我对这件事非常了解——我会成为本指南的优秀实验室老鼠。

@StraToN在 facebook 群组中发帖寻求这种帮助。 联系他（我不确定是否还有其他人也在做这件事）。

@neikeq谢谢，完成！

@Warlaan我了解您的代码比较，但对我而言，它主要证明 C# 具有更多功能，因此更冗长。

您需要using因为有命名空间以避免与许多类发生名称冲突（这在我自己的游戏项目中已经发生在我身上）。
您需要public因为有一个封装概念可以防止随着时间的推移出现编码错误。
您拥有[SomeClass]是因为我们可以扩展内置注释以适应不同的项目需求并改进工具。
至于大括号......我看不出有什么优势，除了定义范围。

这些功能在这里是有原因的。 其中，我会说可扩展性。 你会用 GDScript 的所有代码库开发一个巨大的跨平台 3D 游戏吗？ 嗯，你可以。 但是很多用户会更喜欢 C++、C# 或 Java，因为我列出的优点（而且我只谈论语言，而不是框架）。

但与此同时，我知道没有使用 Godot 开发的“巨大”游戏项目，所以没有那么多例子：p
另外，我在 C# 中看到了一些不好的特性（警告：个人意见）：

你可以有静态变量。 这是错误的，很多错误来自全局状态/单例。 与自动加载不同，它们不受任何场景范围的约束。
您可以在 if() 语句的 while() 末尾输入错误的分号，使其无用且难以查找。
您可以过度编码。 我同意，当使用错误的方式时，C# 代码会变得非常复杂，而另一个更简单的代码也会这样做。 但这取决于人/经验。

哦。 我没有提到preload() 。 除非您依赖编译器技巧，否则这无法实现 C#/Java：p

有人已经开始尝试 Mono 模块了吗？

作为一个 C# 开发人员，添加我最卑鄙的意见...

我认为将 C# 添加到 Godot 并没有太大价值，因为您仍然必须学习 Godot 的类才能完成任何事情，而添加 C# 真正获得的唯一好处是（对许多人来说）更熟悉的 C 风格语法和静态类型。
语法问题值得商榷，Python 以易于初学者学习而著称，而且由于 GDScript 与 Python 高度相似，我认为这同样适用。
无论如何，有一定经验的程序员在学习该语法时应该不会有任何困难，它是一致的，并且比更自由的 C 样式语法具有更少的陷阱。

另一方面，现在静态类型可以有一些价值，除了有助于提高性能外，它还可以在某些方面帮助提高开发速度。 自动完成工具只是喜欢被告知给定函数/方法期望和返回的类型，但仅类型提示就可以实现这一点。
不过，这可以添加到 GDScript 中，不需要任何其他语言。

此外，实现 C# 可能不会那么容易，并且需要花费大量时间和精力来使引擎达到当前的状态，但现在使用 C# 或代替 GDScript。

作为结束语，我知道有些人会采取错误的方式，我想说：

据我观察，一些在我们的技术中可能没有像他们应有的那样扎实的程序员倾向于坚持他们所知道的东西，并尽其所能。
在我看来，这种现象在 C# 开发社区中尤为普遍，尽管这可能只是我的偏见。
如果任何阅读本文的人认为他们可能符合该描述，我只能建议走出这个熟悉的盒子并开始学习新东西，这并不像你想象的那样艰巨，一旦你有了一个公司掌握了这个新事物，你可能也会增加对你已经知道的东西的理解。 这是值得的。

我会喜欢静态类型，但如果发生这种情况，你将如何处理泛型？ 您会在该实例中简单地使用动态类型，还是希望能够使用约束？ - 例如，只允许整数和布尔值。

命名空间将非常受欢迎，我很惊讶它们在 GDScript 中尚不存在。

使用大括号而不是冒号作为方法的选项也很可爱，我知道它们是不需要的，但我喜欢有它们 - 这就像阅读一本书没有任何句号，这很刺耳。

类型提示可以缩小阻止代码完成完全工作的差距。 我曾经做过一个使用 Lua 的项目，他们也想要这个。 研究把我带到了这里： https ://github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48
如果您在类型提示中跳得太远，这就是函数参数可能变成的样子 xD
但我认为应该有所取舍。 看看 TypeScript 或 Haxe 是如何做的（它们都允许混合变体和类型）。 此外，Godot 中已经存在类型提示。 它仅用于 export() :)

有人已经开始尝试 Mono 模块了吗？
@Zylann

查看GodotSharp 。 存储库中的当前状态尚不可用。 在我的本地 repo 中，我设法实现了足够的东西（只有 Vector2 和 Matrix32 可用作基本类型）来将 2d/平台演示转换为 C#，除了敌人和子弹实例化，它是从 GDScript 完成的，因为引用还没有工作。
这是播放器类的示例： https ://github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs

@Pikl

事后思考：
是否可以在 Godot 中仅使用 C++？ 老实说，我认为我更愿意学习 C++ 并使用它而不是 GDScript。

是的，这是可能的，但目前它不是那么容易和/或方便，你必须从头开始重新编译 Godot。 如果您对 C++ 作为一等公民感兴趣，请对#3936 表示一些支持，以便它可以与 GDScript（或独占）一起使用而无需太多工作。

@Zylann Pikl 询问将 GDScript 的语法更改为类似于 C# 的语法，以便 Unity 开发人员更容易阅读。 这就是我评论的内容。 是的，C# 确实有更多功能，这也是我删除的关键字和字符一开始就在其中的唯一原因。 这就是为什么仅仅为了让 GDScript 代码看起来像 C# 代码而添加它们不仅仅是不必要的，恕我直言，这是错误的，因为您将使用一种暗示 GDScript 没有的语言特性的语法。

@Pikl这与按键的数量

那么为什么不添加 C# 的所有功能呢？
正如 Zylann 已经提到的，将 C# 添加到 Godot 的效果并不是那么容易预测的。 如果您还没有完成，如果您阅读我在此线程中的长篇文章（https://github.com/godotengine/godot/issues/5081#issuecomment-225226235），我将不胜感激。 作为一名开发人员，我总是会要求更强大的语言。 在我的业余时间，我目前正在研究 Kotlin，因为 paper-pauper 在第一篇文章中提到了它。
但是自从我有机会了解编程语言对游戏开发者的结果和行为的影响后，我意识到选择一种合适的语言而不是一种强大的语言是多么重要。
正如我在链接帖子中解释的那样，我确信 C# 对 Unity 社区的文化产生了显着影响，将程序员视为

• 为资产商店写东西
• 写教程
• 修复错误。

根据我的经验，Unity 中没有太多的游戏编程文化。 一旦遇到任何类型的麻烦，您就会开始寻找模式或预建资产来解决它。 实际上，有相当多的人在对项目一无所知之前就选择了他们的模式，而这种心理上的僵化会影响游戏结果。

这只是我最喜欢的反驳，在第一篇文章中还有其他几个很好的反驳。 ;-)

JVM的问题是它太重了。 有人看过禽兽吗？ 它与 Java 世界的兼容性如何？

@neikeq这并不意味着它的性能更差 - AFAIK JVM 的性能比 CLR 更好，而且垃圾收集器也更适合游戏开发。 它也安装在大多数计算机上，无论它们是 Windows、Mac 还是 GNU/Linux。

它还拥有更丰富的更高质量的 FLOSS 库，并且不管某些人怎么说，更好的跨平台支持。

我想说的是，在两者之间，JVM 显然更适合游戏开发（但我会同时避免它和 CLR）。

禽兽看起来确实很有趣。 我没有这方面的经验，所以我无法回答你的问题，而且我担心它的兼容性可能会像 Unity 的 Mono 版本一样有问题，这使得使用第三方库非常尴尬，除非你碰巧找到提供的 .NET 版本之一。

但是，除了 GDScript 和 C++ 之外，还有一个轻量级的 Java 实现作为附加选项，用于需要快速周转时间并且可能牺牲代码质量的情况（如游戏卡顿或新后端想法的快速原型设计）会很好。

@neikeq Avian 旨在为 c++ 项目提供 java 脚本，因此它确实是一个很好的候选者。 它可能非常小（如果我没记错的话，大概是 100kb）。 听说过一些使用 Avian 发布 iOS 端口的 libGDX 游戏...... jMonkey 引擎也在 iOS 上使用 Avian）。 一般来说，Avian 没有像 sun/oracle 类这样的 JVM 通常附带的完整包装。 但是我不认为这是一个问题，因为“原始”Java 类根本不适合游戏，这就是为什么像 libGDX 这样的库在向量或数据结构上提供自己的实现......最后我认为我们会还需要重新实现这些类。 （然而，嵌入原始 java 类的各个部分很容易，但我们包含的越多，Avian 就会变得越大）

@paper-pauper 我的意思是体积很大，假设它会与游戏捆绑在一起。 但正如您所说，它安装在大多数计算机上，并且考虑到 libGDX 等框架的流行，它可能是最佳选择。
我用 C++ 作为 GDScript 的替代品的问题是它的语法很糟糕。 那是生产力杀手。 它可以用于引擎和模块开发，但我不会用它编写整个游戏。 话虽如此，我赞成 #3936 并拥有类似于 Unreal 所做的东西，但我不会将其视为替代的“脚本”语言。

@kubecz3k是否支持其他 JVM 语言？ 例如：科特林

@neikeq是的，据我所知，它与 java 字节码完全兼容，因此它支持任何 jvm 就绪语言（kotlin、scala、jpython 等）
我想我们可能会问一些关于鸟类谷歌组的问题： https ://groups.google.com/forum/#!forum/avian
它似乎很活跃

+1 不将 C++ 视为替代脚本语言。 正如我之前所说，Godot 拥有一种针对脚本优化的语言和一种针对后端开发的语言，而不是在这两个领域都拥有一种“meh”的语言，这是一件好事。

这并不是说动态库支持和更快的 C++ 开发不是我希望看到的。

但不要对 Avian 过于热情，这里是 libGDX 主要开发人员的博客文章，他在其中解释了为什么 libGDX 没有将 Avian 用于 ios 端口。 http://www.badlogicgames.com/wordpress/?p=3925 （向下滚动到鸟类部分）
我不是 jvm 程序员/黑客（但作者是 - 因为他也在研究 RoboVm（又一个被微软收购并关闭的 jvm））所以我不知道其中有多少会真正转变为Avian 仅用作脚本语言（不为核心引擎提供动力）的情况

你们中的大多数人可能是比我更有经验的程序员，但有我的 2 美分。 一年前，我会支持 C#。 但是我很快就学会了 GDScript 语法。 归根结底，您仍然需要学习 API，而这可能是最耗时的学习内容。 所以，是的，我不需要 C#。 @Warlaan提出了很多反对 C# 的充分理由。 实现 C# 也需要很多时间。 这也意味着更多的错误。 是的，我们有一个很棒的社区，它为代码库做出了贡献，但我们仍然只有一个@reduz我认为实现 C# 所需的时间应该投入到我们真正需要的功能上。 有多少 Godot 开发者对 GDScript 感到满意？ 是的，它可能会更快，但我没有任何其他问题。 我宁愿拥有一种很棒的脚本语言，也不愿拥有两种不太好的脚本语言。 甚至 Unity 也落后于旧的 Mono。

我想要的是 GDScript 中的静态类型。 不是 C++ 作为脚本语言，不是 C#。 让我们专注于 GDScript，让它比现在更好。

由于我在 Visual Scripting 线程中提到了我领导开发 14 年的引擎，我想我会在此处添加我的 2 美分，因为我们正在开发一个完全用我们自己的类 C# 语言编写的新引擎。

我们编写了自己的编译器（在用 C++ 引导后也用我们自己的语言编写）编译成 C++（几乎是纯 C）代码，然后输入我们支持的所有平台的编译器（XBox/PS/PC/Wii/等等）。 我们编写了自己的分代垃圾收集器，以便能够根据需要调整其性能——这样做意味着它在整个引擎中都得到了使用，这意味着它经过了良好的测试和分析。 而且由于我们交叉编译为 C++，我们可以轻松地在“本机”函数中编写 C++ 代码，这些函数可以根据需要调用系统 API 或包含平台特定操作 (SIMD)。

我真的无法想象 Unity 不得不将一堆 C++ 代码与 Mono 合并是多么令人沮丧——这可能解释了它为什么落后，正如@GlaDOSik指出的那样。 不过，这当然不是我们任何人感兴趣的事情。

我们的主要目标是将引擎、编辑器和工具以及游戏代码之间使用的语言统一为一种语言。 以前，引擎和工具完全是 C++ 并且可视化的脚本语言（至少看起来像 C 代码）被用于关卡设计师喜欢的所有游戏玩法，但惹恼了大多数编写大部分游戏的游戏程序员的代码。 它还允许我们根据游戏开发可能需要的东西（比如状态机支持）来定制语言。

_虽然你不能取悦所有人。_如果我不得不工作或尝试帮助某人调试一团令人讨厌的意大利面条蓝图/等基于节点的“代码”，我想挖出我的眼睛作为报复。 我希望一个试图阅读 C++ 代码的艺术家也能做到这一点。 你能做的就是浪费大量时间争论什么是最好的解决方案，甚至更多地试图取悦所有人。 在某些时候，您只需要专注于为合适的人制作最高效的工具 - 有时这意味着少数人可能需要学习新东西。

“如果不是 C++，它就很慢”似乎经常成为口头禅，但我想说的是，如今大多数 _shipped_ 游戏都是用 C++ 以外的东西编写的游戏代码。 我实际上还没有看到有人专门从 GDScript 发布性能问题，尽管我当然很想从他们那里听到什么是缓慢的。

就我对 GDScript 的介绍而言，它是这样的：

• 天哪，像 Python 一样！？ 这太疯狂了，空格不应该重要！
• 嗯，不喜欢“小写”风格（看你不能取悦所有人）。
• 好吧，这实际上有点酷，而且经过深思熟虑。
• 是的，它与编辑器很好地集成在一起，我当然可以看到它对于游戏代码和一些编辑器插件非常有效率！

看起来 GDScript 已经投入了很多精力和时间，而且它似乎是正确的工具。 所以我真的只想对那些努力制作它的人表示敬意！

@Ziflin嘿！ 很高兴在这里见到你，Vicious 是我们专业使用的第一批游戏引擎之一（尽管我们受雇于 @punto- 来破解它并解决它的问题，而不是实际使用它）。

可视化脚本语言确实是一场噩梦，但源代码确实做得很好，干净且有条理。 与 Torque 合作后，这是一种幸福。 使用它我学到了很多东西。 索尼在拉丁美洲销售它做得很好，因为十年前这里的每个人都在使用它。

我认为我记得使用它时最令人惊奇的时刻是不小心偶然发现了一段列出语言的代码，并且有一条评论“不支持葡萄牙语”

我们真的是在大笑和开玩笑，而游戏制作人（他在我们身后，我们没有注意到他）吓得发抖，说：“等等什么？现在剩下的就是把游戏翻译成葡萄牙语了， 这是一个玩笑，对吧？”

但是我们只是用中文的葡萄牙语，一切都很好，游戏也发货了。 很高兴知道你们仍在开发它！

（来自@Ziflin的引用）我实际上还没有看到有人专门从 GDScript 发布性能问题，尽管我当然很想知道他们的缓慢之处。

我个人在这个项目中遇到了 CPU / Gdscript 瓶颈： http ://godotdevelopers.org/index.php?topic=15519.0

我在 GDscript 中编写了一些基本的 AI 和基本的老式伪物理来控制 8 辆汽车中的每一辆。
我没有在公开场合大声谈论这个性能问题，因为还有一些优化的空间。
但是，如果我想添加更多汽车，我将被迫放弃 C++ 的 Gdscript（编辑：我想避免这种情况，因为我真的不想一次又一次地编译）。

另外，我认为去年我在另一个项目中遇到了相同的 CPU / Gdscript 瓶颈，该项目使用 GDscript 为每个错误（动物）提供基本 AI：http://ludumdare.com/compo/ludum-dare-32/ ？动作=预览&uid=50893
我添加的错误（动物）越多，性能就越低。

如果有人愿意，我可以分享我的经验。

@SuperUserNameMan请继续，但我认为我打开的另一张票 #5049（专门讨论 GDScript 性能）更适合于此。

@paper-pauper：不确定我是否可以贡献 #5049（更多的是关于添加 JIT，关于我可以添加一个大拇指的内容）。 我可以分享的经验更多是关于我遇到了什么样的瓶颈，具体症状是什么，我必须如何解决，我如何优化，以及我必须牺牲哪些“godot 的设计优势”。

@SuperUserNameMan我还没有真正考虑过通过类型推断实现 JIT，但为此 VM 必须首先支持静态类型

我最感兴趣的是听听您指的是哪种 AI 代码。
我的先入之见是，仅在 8 个实体上运行时可能导致性能问题的任何代码都可能不是真正的游戏代码，因此无论如何都应该将其放入 C++ 类中，这就是我要问的原因。

@reduz哈哈，显然这是一个小世界！ 是的，视觉脚本有点失控（它实际上只是为了处理触发器和少量事件逻辑）。 Vicious 实际上在今年早些时候关门了，但在那里工作很有趣。

@paper-pauper 我会看看你提到的另一个话题。 我并不是真的想让人们开始在这个线程中发布性能问题。

如果 GDScript 要添加静态类型，则_可能_更容易选择将其直接转换为 C++，这将避免 IL->C++ 转换的额外开销并保持运行时较小（无 JIT 编译器等）。 然后，您可以在 GDScript 中进行原型制作或使用它制作模组，但您也可以在最终构建需要时将其自动转换为 C++ 以提高速度。

这样做还可以保留人们习惯使用的现有 IDE（VC++ 等和 Godot 编辑器）。 实际上，我们只是使用 VC++ 来调试我们的语言，并且我们的编译器在 .cpp 文件中生成#LINE指令，这样您就可以轻松地单步执行原始代码并设置断点。 所以理论上你可以在编辑器中使用普通的 GDScript 进行原型设计和调试，但是在启用“GDScript->C++”的构建期间，你仍然可以使用你的 C++ IDE/调试器并在 gdscript 文件中设置断点/调试。 对我们来说，生成的 C++ 文件是临时的，只有在出现代码生成问题时才会查看它们。

无论如何，只是一个想法。 您现在拥有一门不错的脚本语言这一事实​​绝对是一个加分项，它确实使用户创建的模块、快速原型设计以及向该语言添加新功能等事情成为可能。

事实上，我不明白我也不应该将我的性能问题发布到这个线程中。 这里更合适： https ://github.com/SuperUserNameMan/kart-zero/issues/1

@Ziflin实际上，我们在其他问题中讨论的是首先，通过暴露 Godot 的整个反射 API 的最小 API 添加最小 C API 来使用普通 C 编写 godot 模块/脚本，这将解决我们在绑定分配方面遇到的常见问题到不同类型的库，而无需重新编译 Godot

这方面的例子是那些想要绑定 Steam API、ODBC、SQLite、Kinect 等的人。所有这些都需要用 C++ 编写模块。 使用 C API 执行此操作解决了与 C++ 动态链接的问题（由于每个编译器或编译器版本都有自己的 ABI，以及可能在 Godot 版本之间发生的符号大小不匹配问题，这非常有限）。 C 没有任何这些问题。

一旦成功，将 GDScript 编译成 C 并在游戏运行或导出时在运行时加载它应该很容易。

@reduz啊酷。 所以基本上你是在谈论能够编写一个“插件”DLL，它可以向 GDScript 公开它想要的东西？ （还是我误会了？）

一旦成功，将 GDScript 编译成 C 并在游戏运行或导出时在运行时加载它应该很容易。

这对想要编写一个包含几个新的 C++ 节点派生类型的 dll 的人有用吗？

令人遗憾的是，新的 C++“模块”支持似乎足以解决 DLL 的一些问题。

为什么不使用可嵌入的脚本语言，例如 lua 或 Ruby？

@jersten因为阅读了文档 - http://docs.godotengine.org/en/latest/reference/gdscript.html

@Ziflin是的，但是您必须通过反射使用 C API（尽管您可以通过反射请求函数指针，所以它应该足够快..）。 目标主要是有一种简单的方法来加载避免 ABI 问题的 DLL，以及一种将 GDScript 编译为 C 并将其加载为 .so 的简单方法。

我要在这里投入我的 2 美分，以换取物有所值。 我从来没有用 C# 编码，而只用 Java 编码。 虽然我个人更喜欢 Java，因为我使用过并喜欢它，但实际上我支持 C# 而不是 Java。 C# 是 Unity 游戏开发者所使用的，因此将其加入将使 Godot 成为 Unity 创建的独立开发生态系统的一部分。 如果您想要一种 JVM 语言，Java 也不是一个好的选择。 还有其他更好的语言可以编译到 JVM。

我认为人们无论如何都没有抓住重点。 C#/Java != 脚本语言。 GDScript 就足够了； 很容易学习，等等。

添加一种语言，如 Java（构建 JVM 用于什么目的？！语法？！需要具有特定版本的 JVM 才能运行？！？）或 C#（实现单声道并混合引擎；或构建自己的引擎？）会毒害引擎.

如果 GDScript 有问题，应该指出； 然后试图修复。

我不同意。 我觉得 C# 会吸引很多 Unity 开发人员或熟悉 C 类语言的开发人员，为像 GDScript 这样的 python 提供一个不错的替代方案。 拼图的最后一块将是视觉脚本，它将吸引不习惯编码的艺术家。 这应该涵盖几乎所有人。
此外，无论您编写什么代码，您仍然需要学习 Godot 的类和函数，这些类和函数在任何语言中都是相同的。

对于所有因为 Unity 开发人员知道 C# 而争论 C# 的人，请考虑一下：许多 Unity 开发人员不知道如何用 C# 编程。 他们所知道的是如何使用 Unity API，它恰好具有 C# 绑定。 你把他们带到 Godot，即使它是 C#，他们也不知道他们到底在做什么，并且会像为他们提供不同的编程语言一样迷失。

包括任何额外的语言只是更多的开销，并且项目必须维护它不应该的更多。

我对此思考了很多，而我对支持 C# 之类的东西的主要担忧是，大多数会使用它的人都是使用 Godot 的 Unity 用户。 显然，我们不会在官方模板中包含 C#，我非常怀疑他们会自己构建模块......
最终可能会付出很大的努力来支持一种只有少数人使用的语言。

我认为有一个误解：

• 他们看到 GDScript 并认为 GDScript 与 C# 不相上下； 错过了 C# 不是脚本语言的基本点。
• 由于上述事实，当有人说“Java 或 C#”时； 他们真正要求的是将引擎重写为 C#/Java 或添加一些绑定以支持这些语言（哈哈，不）。

因为我假设后者； 在 C#/Java 中进行调试是多平台的噩梦； 因为这两种语言都不是独立于平台的（inb4 几乎所有操作系统都有运行时）； 它变成了“一次编写，到处调试”（这就是为什么写到 Monogame 的游戏首先出现在 Windows 上；然后最终出现在 Linux/Mac 上，因为开发人员必须为这些平台进行调试）。 这就是 JVM 更新会破坏应用程序的原因。

添加对这些语言的支持不会为引擎增加任何价值。

如果参数是“moar Unity devs”； 然后应制作文档以帮助过渡 Unity 开发人员； 布局差异等。

这就是为什么我最后说不管你使用什么语言，你仍然需要学习 Godot API 类和所有东西。 不像 Unity 开发人员会成为 insta 专家，因为他们知道 C#。 如果支持 C#，我想对 Godot 来说更像是一种“善良的光环”。 人们觉得他们知道的更多，突然之间，戈多更容易接近，不再那么可怕了。 非 Godot 用户对 Godot 的第一大负面影响是它有自己的脚本语言。 作为一个 Godot 用户，知道 BS，因为 GDScript 是一种有趣且简单的语言，但对于外人来说，它可能看起来不吸引人。
我不能从开发人员的角度说话，但也许付出的努力比值得的多，除非开发人员从实现 C# 中得到一些东西然后是值得的。 最后是首席开发人员的决定，无论他们决定什么，我都会接受。 我相信这将是一个很好的决定。

我同意你关于 GDScript 有点令人反感的观点，因为它实际上是一种未知语言。 但是，在我阅读了为什么要删除 Lua 和 Python 以及添加 GDScript 的好处之后，我就不那么担心了。

另一件可能相关的事情：还有另一个 MIT 许可的引擎，它已经支持 C#，并且更类似于 Unity， Atomic Game Engine 。 我建议所有迫切需要尽可能接近 Unity 的东西的人尝试一下。

我将在这里添加我的 2 美分。 对我来说，C# 的最大优势是性能，同时仍然比 C++ 更容易使用。 GDScript 是动态类型的，编写起来非常快，但运行起来永远不会超快（尽管它可以进行很多优化，这是计划好的）。 C++ 模块非常快，但使用起来有点尴尬； C++ 并不完全是一种友好的语言，并且必须重新编译引擎才能使用它们并不是真正的最佳选择。 对我来说，C# 是一种妥协：比 GDScript 快得多，并且在适当的支持下，比 C++ 模块更容易使用。

话虽如此，它不一定是 C#。 就我而言，任何其他具有类似效果的东西都可以，无论是静态类型编译/JIT GDScript，还是其他类似 Swift 的东西。 C# 可能是“营销目的”的最佳选择； 即使没有类似的 API，来自其他引擎/框架的开发人员可能会更适应它。 修改后的 GDScript 可能更容易实现，并且可能会更好地集成。

我知道这个帖子现在很长，但请先阅读以上所有帖子，然后再自行发布内容。 C# 将吸引人们并且对 Unity 用户非常方便的论点如果被多次提及，就不再有效。

看看这里为什么恕我直言 C# 对 Unity 很好而对Godot不利从 C# 更改为 GDScript 时人们必须学习许多新事物的论点是无效的。

让我对 C# 会带来新人的论点添加评论。
为什么我们希望更多的人使用 Godot？ 我完全理解开源项目需要一个社区

• 添加功能
• 修复错误
• 创建可重复使用的资产
• 对新功能提出建议
• 发现工作流程的错误或问题
• 写教程

但以上都需要了解和欣赏引擎核心思想的人。 将不必要的功能添加到库中的人并没有帮助，而且不止一个项目受到这些功能的影响，有时甚至到项目被放弃或拆分的地步。
Unity 尤其受到那些编写教程的人的困扰，即使他们并不真正了解自己在做什么，这在很大程度上是 C# 的错。

如果人们甚至不愿意或无法学习像 GDScript 这样简单的语言，那么在开始积极为社区做出贡献之前，他们是否会花时间完全掌握 Godot 背后的设计理念，这是非常值得怀疑的。 （“积极贡献”的意思是从发送拉取请求到在 Facebook 上发布他们对 Godot 的看法。）

Godot 不是商业引擎。 Unity 有兴趣吸引尽可能多的人，因为他们都是潜在客户和引擎的广告。 拥有一个欣赏 Godot 的大型用户社区肯定会很好，但是为了迎合更大的社区而牺牲 Godot 的一些品质是没有意义的。

@Warlaan人们通常不想浪费时间，他们会在构建项目时使用他们发现的任何代码片段，尤其是在您学习的开始时。 对于初学者来说，你的观点有点相关，因为他们最终会学习他们使用的代码片段所用的任何语言。我知道这一点，因为这就是我学习查看示例的方式，我不知道 GD 脚本，但我学会了。 问题不是什么是最好的，或者这将如何影响或使教程复杂化等。问题（对我来说）是 C#，而不是任何其他语言将使 Godot 成为这个独立开发生态系统 Unity 的一部分。 这甚至不是关于 Unity，而是关于 Godot。

编辑：删除了一些不必要的苛刻语言;-)

@trollworkout 无意冒犯，但是您并没有真正理解我的观点，而且我感觉您也没有真正考虑过自己所说的话。

1. 是的，人们不想浪费时间。 GDScript 的完整规格：几个屏幕。 解释 C# 的书籍：通常至少 500 页。 我花了几天时间学习 GDScript，我很确定它没有一个我不知道的功能。 多年来，我一直在专业和业余时间使用 C#（使用 Window Forms、WPF、XNA 和 Unity），但我仍然发现使用我尚未完全理解的功能的代码片段。 因为不那么浪费时间而要求使用 C# 是没有意义的。
2. “初学者最终将学习他们使用的代码片段所用的任何语言”——参见第 1 点。您可以从代码片段中学习 C# 的想法远非事实。 您可以通过这种方式学习的东西非常基础，以至于“学习”一门不同的语言不会超过几天。 你自己说你是这样学习 GDScript 的。
3. “C# 将使 Godot 成为这个独立开发生态系统的一部分”。 那应该是什么意思？
   你能在 C#-Godot 中使用 Unity 代码片段吗？ 不。
   你能在 C#-Godot 中重用 Unity 资源吗？ 不。
   你能阅读 Unity 教程并将它们逐字应用于 C#-Godot 吗？ 不。
   那么你指的这个“独立开发生态系统”是什么？

正如paper-pauper所说，有很多引擎和库可供选择。
你想要一个像 Unity 这样的组件系统吗？ 看看原子游戏引擎。
您想在引擎中继续使用 C#，但想放弃组件系统吗？ 看看 CryEngine / Luberyard。
你想继续使用 C# 但想放弃引擎吗？ 看看MonoGame。

将 C# 添加到 Godot 帮助初学者的想法是错误的，因为您自己说您是通过查看代码片段在 Godot 中学习脚本的。 如果这就是您学习使用引擎的方式，您会不会想要一种隐含地告诉您引擎如何工作的语言，而不是一种为数千种不同用例而设计的语言？

我将在这里添加我的 2 美分。 对我来说，C# 的最大优势是性能，同时仍然比 C++ 更容易使用。 GDScript 是动态类型的，编写起来非常快，但运行起来永远不会超快（尽管它可以进行很多优化，这是计划好的）。 C++ 模块非常快，但使用起来有点尴尬； C++ 并不完全是一种友好的语言，并且必须重新编译引擎才能使用它们并不是真正的最佳选择。 对我来说，C# 是一种妥协：比 GDScript 快得多，并且在适当的支持下，比 C++ 模块更容易使用。

您提到的所有 C++ 问题都是有效的，可以通过 #3936 修复。 我们已经讨论过很多次了，但为了清楚起见，我们可以客观地认识到 GDScript 的问题：

1. 对第三方库的支持不佳
2. 表现不佳

能够用 C++ 编写部件很容易解决这两个问题。 C#（或其他语言）也可以解决这些问题，但需要额外的运行时间、更差的性能和跨平台支持以及需要大量额外工作（而 Godot 已经用 C++ 编写）。 所以理性的选择是使用已经存在的东西（C++）并让它变得更好，当然还要用 GDScript 解决这些问题。

我很快阅读了这个帖子，并看到了 GDScript to C 的设想。

如果这是选择的方式，那么考虑在编辑器中嵌入

TCC 是根据 GNU 宽通用公共许可证分发的。

（来源）

这使得它可能不适合包含在 Godot 中。 它似乎也不再维护了。

@Warlaan我不必想太多。 在这一点上，我们都已经说了大约 10 次相同的话，我想我们几乎都知道我们是否都站着。 除了我的 2 美分和一些想法之外，我没有更多可以贡献的东西，因为我不是开发人员，而且我对引擎的内部了解并不透彻。 我会让知道的人说的更好。 我只是想表达我的支持，仅此而已。
无关：
但是是的，关于第 2 点。您对必须编辑您的评论大惊小怪。 所以你是说你不能根据例子学习一门语言？ 我认为你认为人们无法学习它，除非他们阅读了 500 页的 C# 手册，因为你说理由 1 拒绝它。 好吧，我就是你错了的活生生的证据。 你认为我是如何学习 GDScript 的？ 使用 API 和演示示例并提出问题。 请注意，在我开始之前我只有 0 的 Python 知识，所以关于它的一切都非常陌生。 作为旁注，我想知道有多少人购买 libGDX 手册，而实际上有多少人在谷歌上搜索“如何在 libGDX 中做 X”，这可能是为什么资产商店在 Unity 中如此糟糕。 至此，我暂时完成了，因为我没有什么可说的了。

（ @Calinou ：Bellard 允许 TCC 的一个分支成为 BSD 或 MIT。但上次我检查时，分支的开发人员没有发布源代码。所以，也许 Bellard 会接受让 Godot 社区也重新授权 TCC？）

我不确定 TCC 是否与 GCC 或 Clang 作为编译器一样好 - 它们的大小足以支持许多架构和相当优化的代码生成（更好的性能）。

Godot 可以选择依赖 GCC 或 Clang 来编译 C 吗？ 它们安装在大多数无论如何都会构建游戏的人的机器上（因此大小并不是真正的问题），这是编译为 C 的其他语言（例如Chicken ）的方式。 它们还支持 C++，以备不时之需。

如果将它们设为可选依赖项，那么那些没有安装 GCC 或 Clang 的人（这对于应该构建游戏以进行分发的开发人员来说很奇怪，但无论如何）可以像现在一样使用 GDScript 解释器。

我建议使用 TCC 作为 GDScripts 的JIT 。 所以最重要的特性是编译速度。 而且我认为结果可能已经比当前的解决方案快得多。

大多数人希望 C / C++ 具有性能，而 Lua / Javascript 则更容易和更快地编写，那么为什么不兼得两全呢？

尼姆 - http://nim-lang.org/

像 C 一样高效，像 Python 一样富有表现力，像 Lisp 一样灵活

优点：

• 编译成 C、C++、Obj-C 或 JS ( http://nim-lang.org/docs/backends.html )
• （Python / Pascal）喜欢（https://learnxinyminutes.com/docs/nim/）
• GC 或手册 (http://nim-lang.org/docs/gc.html)
• 可以在 godot 以外的其他地方使用
• 跨平台（windows、linux、osx、mobile）
• 帮助将 C 代码转换为 Nim
• 支持 C 库
• 可调整的编译器
• 麻省理工学院许可
• 开源
• 类型安全

缺点：

• 需要开发人员计算机中的 C/C++ 编译器 -> gcc 、 vcc 、 llvm_gcc 、 icc 、 clang或ucc _（在我看来，这不是真正的骗局）_
• 小社区
• 还没有1.0

Nim 的 TODO 列表很小，接近 1.0：
https://github.com/nim-lang/Nim/blob/devel/todo.txt

正如paper-pauper所说（关于在开发人员的计算机中安装编译器）：

它们安装在大多数无论如何都会构建游戏的人的机器上
https://github.com/godotengine/godot/issues/5081#issuecomment -227706106

https://hookrace.net/blog/what-is-special-about-nim/
https://hookrace.net/blog/what-makes-nim-practical/

https://github.com/nim-lang/Nim/wiki/Nim-for-C-programmers
https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

这不是我最喜欢的解决方案，但如果你必须走这条路，我强烈建议你使用 Haxe ( haxe.org ) 而不是 Nim。

我无法评论 Haxe 的许可证（编译器本身使用“GPLv2+”，标准库使用 MIT），但所有其他因素使其成为恕我直言的上乘选择。
它是一个经过测试的平台（当前版本为 3.2.1），而 Nim 甚至还不是版本 1.0，但对我来说更重要的是语法更接近其他知名语言。 阅读 Nim 示例，在我看来，该语言背后的开发人员试图找到不寻常和/或丑陋的解决方案。

但正如我所提到的，这不是我最喜欢的解决方案，原因如下：
Nim 或 Haxe 等中间语言有许多“语义依赖”。 我的意思不是依赖于需要存在的库或可执行文件，我的意思是它们与其他语言相关。 正如我之前所说，语言不再是工具，它们是文化。 即使您只将它们视为工具，它们也有不同的核心领域。 例如，在标准输入中输入命令“echo”将文本打印到标准输出是完全有道理的。 只有在批处理脚本中使用相同的命令才有意义。 按照这个逻辑，PHP 使用相同的命令是可以理解的。 在像 Nim 这样的通用语言中使用它是没有意义的，因为基本上所有其他通用语言都有名称中带有“write”或“print”的方法。
我不知道为什么 Nim 仍会使用“echo”作为该命令的名称，但这是你可以在 Haxe 中观察到的很多事情，如果第一个版本中还没有的话，我希望 Nim 将来会出现这种情况. 例如，Haxe 的标准库包含一个 substr(int, int) 方法和一个 substring(int, int) 方法。 两者中的一个返回从第一个索引到第二个索引的子字符串，另一个返回从第一个索引到第二个参数长度的子字符串。 两者都存在的原因是，由于该语言可用于替换不同种类的语言，因此它拥有来自不同平台的用户，除非有人有很强的能力来决定哪些内容进入该开源库，哪些内容不进入该开源库你很容易就会得到这样一种编码风格的混合体。

为正确的工作选择正确的工具非常重要。 像 Haxe（或 C#）这样的语言试图为您提供一种适合所有人的语言，因此您通常最终会使用“仅一种工具”，不幸的是，它看起来像这样。

在与 Godot 合作一段时间后，我想增加我的 2 美分。
我希望看到（并且也一直在关注，但......成功有限）是 C++ 作为 Godot 中的一流语言。
用 C++ 编写计算量大的逻辑（碰撞解决、物理、转换和 AI），并使用 GDScript 编写节点脚本（触发器、条件、动画和声音）。

GDScript 很容易学习，在这方面与 Unity 相比，Godot 更接近 Gamemaker。
但是在写了 3 个小游戏并玩弄了一堆演示之后，我不得不说 GDScript 除了非常基本的游戏之外还缺乏任何东西。

代码文件太长，代码编辑器缺少其他 IDE 中的许多有用功能，例如：折叠范围、区域、跳转到当前范围的开始/结束。

GDScript 也缺少许多过程语言的基本特性，例如：正确的_for _ 循环、正确的 _do ...while _ 循环（它支持_while _ 循环）、_ switch...case _、_三元运算符_ ，_枚举_。
_没有类-场景关系意识_ 所以如果它不是预构建的，它就是一个“外部”类并且必须预加载。

此外，鉴于 GDScript 的性质，没有函数引用和模板。
这不是什么炫耀的东西，但它很烦人。

眼776; 如果您决定忽略其他功能（例如在可能的情况下使用节点和回调）而不是只坚持使用像 _get_overlapping_bodies()_ 这样的功能，GDscript 仅适用于简单游戏之外的其他功能。

原因是所述回调和节点的使用比尝试使用一个大型脚本和很少的节点来完成所有事情要快得多。 树变大了，但这对 Godot 的场景实例化系统来说不是问题。

例如，需要恒定旋转速率的对象可以只使用动画，而不是使用 GDscript 手动设置旋转，依赖时间的东西可以使用计时器节点等等。 我认为允许更快游戏的一种直接（且直接）方法是选择更多节点类型（每个节点类型都有自己的回调和连接）。

代码文件太长了

你的意思是这样的脚本吗？ https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd
你认为 C# 可以防止这种情况发生吗？ 我个人没有。 实际上，由于工具（是的，当人们指的是 C#，他们通常隐含地指 VS）和静态类型，它使得在这些长脚本中更早地重构和检测错误变得更容易，尽管节点路径错误在游戏运行之前是无法检测到的。 但除此之外，良好的节点设计和使用可以大大简化脚本。

代码编辑器缺少其他 IDE 中的许多有用功能，例如：折叠范围、区域、跳转到当前范围的开始/结束。

如果您需要，这些可以在将来添加，尽管您可以毫无问题地使用外部编辑器（https://atom.io/packages/lang-gdscript），Godot 甚至有自动完成服务。

如果你真的制作了一个巨大的游戏，那么你很可能会想要使用 C++ 扩展 Godot。
实际上，由于引擎重建过程，我目前觉得这有点令人生畏，但这是有原因的。

没有课堂场景关系意识

你是什​​么意思？ 你知道你可以把脚本放在场景的根目录上，对吧？ 此外，C# 编辑器无法猜测使用它们的场景中的内容，而 GDScript 可以。

此外，鉴于 GDScript 的性质，没有函数引用和模板。

如果您寻找类似于 lambda 和事件的东西，则有funcref和signal ，并且模板不是一个东西，因为语言是动态的。 动态语言通常更喜欢使用鸭子类型而不是接口和泛型。 此外，如果您想要可重用的东西，则组合优于继承的效果非常好。

GDScript 也缺少很多过程语言的基本特性

我有点同意。 其中一些已被请求，但我不记得这些问题，您必须搜索。 例如，我想看到一个for可以迭代整数范围和容器（浮点数？）以外的东西，所以我使用while 。 这确实有点烦人，但没什么太严重的。

你的意思是这样的脚本吗？ https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

我不得不说，即使文件很长，我也看到了更糟糕的情况，尽管代码相当程序化，但它仍然非常可读。 现在我终于明白为什么简单的语法更适合 GDScript：它最适合一般游戏逻辑，主要是if和函数调用。

我希望看到有人争辩说，用 C# 编写的同一个文件更容易阅读或编写，或者提供除性能之外的任何实际优势（无论如何都比 C++ 差）。 我认为 C# 对于这种脚本来说会是一种过度杀伤力，这比一些专业 2D 游戏中的脚本更复杂。

我有点同意。 其中一些已被请求，但我不记得这些问题，您必须搜索。 例如，我希望看到一个 for 可以迭代整数范围和容器（浮点数？）以外的东西，所以我使用 while。 这确实有点烦人，但没什么太严重的。

您能否更深入地了解for部分以及您在伪 GDScript 中所指的一些示例？

@paper-pauper GDScript 缺少的东西与 C# 无关，但例如for i in range(-PI, PI)和for i=0, i < size and stuff, ++i在 GDScript 中不起作用。 我也想写三进制而不是写三行如果。 但正如我所说，跟踪器中已经存在问题，它不会阻止我使用 GDScript：p

但是，即使你所有的脚本最多 200 行并且设计得比较好，如果你的游戏中有成千上万的脚本，你也会很难维护和重构代码库：这并不是因为语言，而是因为工具：C# 受欢迎的很大一部分是因为 Visual Studio 对它来说是一个非常好的 IDE。 我很确定如果 Godot 集成了合适的工具（goto 定义、可靠的类/函数/成员重命名、查找所有引用等），那么在庞大的 GDScript 代码库上工作将会变得容易得多。 更一般地说，这是我希望在 Godot 中看到的，它如何能够很好地扩展到 BIG 游戏，因为到目前为止我还没有看到任何东西（包括我自己的项目）。

for i in range(-PI, PI)

这让我的头在它的轴上旋转，直到它被零除并开始破坏熵。 我希望没有一种语言可以实现这种不可预测的陈述。 它有什么作用？ 迭代 -PI 和 PI 之间的整数（即 -3、-2、...、2、3），或 PI 的倍数（即 -PI 和 0）之间的整数，还是迭代浮点数，比如一些巫毒教默认步骤某些语言程序员认为最合适的 0.176 或ln(2) ？

@akien-mga 抱歉。 我应该确实添加了一个 step 参数，但它仍然不起作用。 这是我为它制作的问题https://github.com/godotengine/godot/issues/4164

我同意 Godot 错过的是工具。 主要问题是 GDScript 的鸭式类型，这使得更难知道什么是什么，因此很难执行一些操作，例如“查找引用”或“转到定义”。

计划向 GDScript 添加类型提示，但由于这是可选的，我不确定可以改进多少。 它肯定会对代码完成有很大的帮助，并且可以简化更好的工具的工作。

@vnen在我的书中，（M）ELPA 中 GDScript 的 EMACS 模式已经是朝着正确方向迈出的一步了 :)

哦，是的，几乎忘记了这两个问题，这很有趣，实际上在实践中减慢了我的速度：

• 参数不是函数签名的一部分。 这意味着您不能覆盖函数。
  实际上，在同一个类中有function doFoo(a,b,c,d)和function doFoo(a,b)将导致编译失败。 我最终将它们重命名为doFoo4(a,b,c,d)和doFoo2(a,b)并重构了一堆脚本文件。
• 由于不支持枚举，所有标志和返回码必然是整数，所以你必须猜测它们，而且许多现在仍然没有记录。

PS：显然这些函数并没有按字面意思命名为doFoo 。 ;)

编辑：@Ace-Dragon：其他引擎教会了我复杂的内置节点/组件/等。 可以而且将会改变，在这个过程中打破游戏。 这就是为什么除了基本的触发回调（碰撞、值、计时器）之外，我更愿意避免过度依赖它们。
我也不是信号槽范式的忠实拥护者，因此如果可能，我倾向于避免使用它。 再说一次，我也更喜欢线程而不是协程，称我为 luddite :)

@Zylann ：~1200 LOC？... pffft 不，我说的是真正的交易...每个文件 20k+ LOC。 一个使用 Unity 的 RPG 开发人员，应该保持未命名（不，我不为他们工作），通常有 25k+ loc 的类。 然后他们再次将所有函数设为静态并像使用 C 一样使用 C#。:fearful:

抱歉跑题了。

@eye776我想不出任何允许覆盖的动态语言（在某些情况下可以用默认参数伪造），但在 GDScript 中使用它是个好主意。

并且可以在像 Godot 这样的自由程序中轻松检测和还原引擎的破坏性更改，因此不必担心。

@eye776我也从未见过具有函数覆盖的动态语言。 GDScript 具有默认参数，因此可以使用它来代替。

另外，谁是在一个文件中做 20K+ LOC 的疯狂人？ 这里的问题不在于工具……在整个 Godot 源代码中，我找不到一个带有 10K LOC 的文件。

我同意的是给 C++ 更多的爱。 但对于你之前提到的用途，我只同意人工智能。 还有程序生成，再举一个。 现在，如果您正在重新制作引擎物理、渲染等，那么我说您甚至不再使用 Godot，您只是做了一个 fork。 如果你不能依赖内置类型，你需要引擎做什么？

当然，GDScript 并不完美（没有语言是完美的）。 它也不是刻在石头上的。 枚举、switch/case 和三元运算是未来可能添加的一些内容（关于这些已经存在未解决的问题）。 仅仅因为它现在没有东西，并不意味着它永远不会有。

最后，“怀疑”并没有真正的帮助。 我们需要的是基准和用例。 已经有相当复杂的游戏用 GDScript 编写，所以我看不出真正缺少什么。

@vnen只是为了好玩： godot/drivers/gles2/rasterizer_gles2.cpp是 11K LOC :p （这是我发现的最大的，但这是一个罕见的例外）。

@vnen

如果你不能依赖内置类型，你需要引擎做什么？
好吧，作为初学者的高质量跨平台上下文。 但这并不意味着我会编写自己的精灵或模型类。

Godot 确实在三月份烧了我一次（v 2.0.1）。 我在玩第三人称相机和角色，并尝试使用 Godot 自己的物理运动（阻力和力）并让它发挥作用。
下一个次要版本（v 2.0.2）更新基本上打破了角色的速度（快了 2-3 倍）以获得完全相同的值。
发现最好只保留它运动学并做我自己的“物理”。

此外，与 Godot 无关，我多次依赖 XCode 的故事板之类的自动化工具而被烧毁。
我有点不再被闪亮的东西所吸引，并祈祷我背后的 IDE 自动生成的任何代码都不会惹恼我。

无论如何，我真的，真的很抱歉让线程脱轨。

@eye776您是否检查了从 2.0.1 到 2.0.2 的提交差异，看看是什么破坏了您的游戏？ 这可能是一个错误，报告它可以使整个社区受益。

单声道还是 CoreCLR？ 为什么？

单核细胞增多症：

• 麻省理工学院许可
• 稳定的
• 被抛弃的可能性
• 好的文档

核心CLR：

• 麻省理工学院许可
• 仍然不是 1.0（目前是 RC2）
• 小的
• 糟糕的文档

我们使用 Mono 是因为它部署到移动设备和网络。 我想这里是
它被放弃的可能性为零，因为它更便携。 我的预感
是两个代码库最终都会合并。

2016 年 8 月 4 日星期四下午 1:45，Hubert Jarosz [email protected]
写道：

单声道还是 CoreCLR？ 为什么？

单核细胞增多症：

• 麻省理工学院许可
• 稳定的
• 被抛弃的可能性
• 好的文档

核心CLR：

• 麻省理工学院许可
• 仍然不是 1.0（目前是 RC2）
• 小的
• 糟糕的文档

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/godotengine/godot/issues/5081#issuecomment -237611905，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AF-Z2zRjC8u_owFzCCyeqIhF8W5XqCtLks5qchchgaJpZM4Ivn7R
.

除了上面提到的@reduz之外，API 是封装的，因此如果需要，以后更改为 CoreCLR 并不难。

CoreCLR：仍然不是 1.0（目前是 RC2）

它在 6 月 14 日达到 1.0 稳定。

单声道：被抛弃的可能性

根据什么？

Mono：好的文档

啊啊啊

根据什么？

为什么微软会开发三个.NET 堆栈？ 这在资源方面不是很好。 （.NET 框架、Mono、.NET 核心）

啊啊啊

我已经检查了关于 C++/C# 互操作的两个文档（我们需要 godot），并且在 Mono 中记录的很好。 在 coreCLR 中，我不得不挖掘他们的一些代码并向开发人员寻求帮助以使我的应用程序正常工作。

参考指南有太多未记录的功能，断开的链接......

理论上我在这里有偏见......但我希望我的论点是客观的......

• 我没有看到 Mono 开发的任何下降： https ://github.com/mono/mono/graphs/contributors
• Windows 上的 Mono 开发从未像今天这样强大（有点证明（没有链接大量提交）https://github.com/mono/mono/pull/3231 米格尔说“因为我们现在有真正的维护者”）前一点更清楚
• 在 Mono 中嵌入 API 已经过实战考验（不仅仅是 Unity，还有许多其他私人用户）
• Mono TODAY可在 PS4、Android、Windows、iOS BITCODE （为此投入了多年的工作）、AppleTV 和更多平台上运行……

所以恕我直言，如果你想在不久的将来（不到 3 年）和大多数游戏平台上实现这一点......选择 Mono。

你好，

一些评论：

• 除了 David Karlas 列出的平台之外，我们还添加了 WebAssembly、XboxOne、UWP 和 Win64 原生支持。
• 共享的示例也可以使用虚拟方法（更快的分派）或 C# 事件来完成。
• C# 在历史上一直处于许多语言创新的前沿，可以从任何地方汲取好主意。 它已经普及并为大众市场带来了许多来自语言研究的想法，我们现在认为这些想法是理所当然的，比如迭代器、非擦除泛型、lambdas、异步编程、属性、平台调用，但它是目前流行的语言之一最积极地在公共场合发展。 例如，即将发布的版本添加了一系列新功能，包括我最喜欢的模式匹配。
• 一般来说，Unity 不会展示现代 C#，因为它们使用的是较旧的运行时。 这有望很快改变。 也就是说，当前的 Mono 支持所有新的 C# 功能，其中包括非常适合游戏代码的“异步”编程，因为您可以线性编写它，并且编译器会自动将您的代码重写为状态机——如协程或高级Unity 中使用的“yield”版本。
• 同步上下文意味着您可以编写在特定上下文中执行的异步代码。 例如，您可能有游戏绑定执行，或 IO 绑定执行，或主与后台线程绑定执行，它们都是系统的一部分。
• 部署时，您可以选择 JIT 编译，或带或不带 LLVM 的静态编译 (AOT)，因此您几乎可以像 C++ 一样快，以 C# 执行数组边界检查的事实为模（也就是说，如果您使用本机缓冲，你会以牺牲安全为代价来恢复你的表现）
• 在过去几年中，鉴于 Mono 对移动设备的高度关注，Mono 的 GC 不是针对服务器进行调整，而是针对交互式工作负载进行调整。 我们的新 GC 是分代的，带有可以非常快速地收集并且不需要扫描整个堆的小型 Nurseries。

至于为什么微软要开发多个 CLR（我们有三个：CoreCLR 用于 JIT 工作负载；CoreRT 系列，用于 UWP 中的静态编译；Mono 用于移动工作负载），这是因为它们的服务用途略有不同。 内部正在尽可能地融合，例如，Mono 现在已经用直接与 .NET 的其余部分共享的代码替换了大约 60% 的核心代码。 只需找出哪种工作负载更适合您。

您可以从今天的一台 VM 开始，并在未来切换到另一台。 目前，Mono 具有更大的 API 界面，适用于移动设备，已针对交互式工作负载进行了优化，并支持更多架构（如 ARM64）。

好消息是，将一个虚拟机换成另一个虚拟机，或者同时支持这两个虚拟机需要几天的工作，因此您不会将自己锁定在一个特定的实现中。

@migueldeicaza欢迎！ 太棒了，您决定参加我们的讨论并且您对 Godot 感兴趣：+1：希望您能和我们一起待一段时间 :)

感谢@migueldeicaza 的精彩细分！ 我有两个简单的问题要问您或其他 Mono 开发人员。

1) 使用 Visual Studio 在 Windows 上调试嵌入式 Mono 的当前设置是什么？ Unity 有他们的插件，但除了连接到 Linux/OSX 机器的插件之外，我什么也找不到。

2) 处理运行时重新编译的推荐方法是什么（编译、卸载和重新加载，比如编辑器中的游戏或工具插件程序集）？ 不幸的是，C#（非常）没有公开 Assembly.Unload() 方法，并且在这种情况下处理 AppDomains 和跨 AppDomain 问题似乎过于烦人。

作为参考，Unity 不仅使用 Mono - https://github.com/xamarin/urho（Urho3D引擎的 C#/Mono 绑定） - 使用 MIT 许可证，因此我们可以轻松查找他们的解决方案。

我的两分钱：

C# 在游戏编程方面远优于其他类似级别的语言，因为它支持自定义值类型。 这是一个非常重要的性能特性，Java（和一般的 JVM）实际上有_no_ 替代它。

你得到：

• 堆栈分配的数学类型，支持数学运算和临时对象，无需任何堆分配。
• 优化的、缓存友好的连续集合。
• 使用值类型的泛型（包括原始类型）

最重要的是，C# 还具有使您的生活更轻松的其他功能。 当 C# 在 _game_ 编程中几乎所有重要的事情上都击败了 Java 时，我认为使用 Java 代替 C# 没有任何好处。

大家好，
我还没有阅读以上所有内容（只是太多了:)）
但是我有一些假期，所以我为 godot 制作了一个原型模块，充当 msDotNetHost，所以我可以提供一些我经历过的发现，也许它们会有所帮助。 可悲的是，我的假期结束了，我再次为钱编码:)，但这很/很有趣 :)

当前状态是：
o) 模块扩展节点类以将节点事件暴露给 netCode
(init, tree_entered, ready, process, fixedprocess....)),
o) “网络主机/包装模块”完成（使用 Microsoft dotNet 主机机制）
它封装在一个动态库中，所以以后切换到 Mono 应该很容易
o) dotNet 方法被绑定和调用（init、tree_entered、ready、process、fixedprocess....）
o) 节点类被包装并绑定到 netAssembly（用于原型设计的手动编写代码）
o) 对 godot 的调用（来自 netCode）正在通过自写的绑定机制工作
（从 dll 到 godot-exe ）所以 exe 不需要导出函数。
o) 由于使用 msDotNet，它在不久的将来会绑定到 windows..

我包含 .Net 的路线图是：

1. 使用 microsoft .Net 托管机制的 Godot 模块（完成）
2. 包装godotClasses
   （我目前的状态：编写一个包装器生成器，解析 godot c++ 代码，
   解析完成，生成正在进行）
3. 让项目脱离原型状态（完成边缘，测试它......）
4. 编写 Mono 托管机制，以摆脱 windows 绑定
5. 以某种方式使 Visual Studio 能够调试单声道，以摆脱 xamarin/monodev（如 unity vs-plugin）
6. 玩得开心数百个新的 godot .net 开发人员 :)

一些问题：

1. 我想知道我是否可以重用用于 gdscript 的绑定机制。 但是我没有时间评估所有这些，对我来说有一些好的 tut 或一些 highlvl 提示吗？

2.
目前我生成了一个包装器，将所有 godot 方法包装到函数中，以便可以通过 dll 边界和 c++/netCode 边界轻松调用它们。 （netCode的自写绑定机制）
我不想更改 godot 代码（除了我的模块代码）以保持兼容。
静态，非静态，虚拟非虚拟也让我哭了，这就是我选择这种方式的原因。
有什么更好的解决方案吗？

一些额外的想法：

Microsoft .Net 与 Mono：

我认为你使用 mono 或 msDotNet 并不重要，因为在大多数情况下，dotNet 代码在两者上都运行不变。 支持两者的唯一努力是为每个 em 编写一个“主机”（它是“GodotDotNet”的最小部分）。 我选择 msDotNet 进行原型设计。
好吧，mono 只支持许多平台 msDotNet 窗口，那么为什么要支持/使用 msDotNet？
答案：生产力、调试

msDotNet：
特别是在编写/原型化 DotNetModule 时，我需要/想要快速编译和调试，这意味着您的调试器应该从 c++ 跳转到 netCode，反之亦然。
我选择 VisualStudio，因为它可以调试两者。 但仅当您使用 msDotNet 时。
这样做你改变了一段网络代码，点击运行并在 1sek 中！ 它编译并运行！！！ 包括调试到 godot 的可能性。 （如果你没有在 godot 中改变一些东西，那么你必须等待通常 30 秒到 1 分钟......该死的你慢 scons！:)）

单核细胞增多症：
Mono 必须是最终目标，对此没有讨论（平台独立性），但是：
如果有人使用单声道，那么我在调试时会遇到一个大问题：单声道有自己的调试机制！
对我来说，这对生产力来说是一个很大的打击，因为除非你为visualstudio编写一个monodebug插件（unity这样做）你不能在visual studio中调试单声道托管的网络代码并调试成c++代码（有hack解决方案但是......）。
我尝试设置一个基于 Mono 的解决方案，但我最终并行使用 VisualStudio（用于 c++）和 xamarin/monodev（网络代码）。

结论：
原型状态：msDotNet
lateron：单声道，供不感兴趣的用户调试 godot/c++ 和平台独立性
之后：创建一个 vs-plugin 来调试单声道

c#与java：
答案很明确 c#！ java适用于脚本儿童！ （哦，c++ 编码器对 c# 开发人员有什么看法 :)）
不，这是个玩笑:)
我不明白讨论...当实现.net 系统时，您可以使用支持 dotNet 的每种语言，包括两种语言以及更多。
如果支持 java 系统，则不是这种情况...

@Ziflin ：
问题1：
也进行了搜索...只有 monoRemotedebugger 是（不是）解决方案 atm :(
如上所述，我的建议是：使用 microsofts dotNet hosting 进行原型设计
然后在稍后切换到单声道。
选择：
以黑客模式启动xamarin，让它监听本地主机，设置断点，然后在vs中启动你的项目。我测试了它，它可以工作，但是......
对我来说它没有解决方案！ 我想要一个“在 1 秒内运行和调试”- 机制和这个只需点击一下！
我在业余时间没有太多时间，所以生产力是我的主要目标。

问题2：
还不太了解单声道，但我认为你必须在 C++ 中做到这一点，实现单声道托管，从 C++ 中的“外部”管理它。

@CharlesWoodhill官方 C# https://github.com/neikeq/GodotSharp/

酷 tnx，然后我知道我如何度过下一个假期；）

嗨，我刚刚遇到了 godotSharp，但它掉线了。

这是它的下降。

我在 IRC 上听到的官方版本是这样的：

@neikeq不喜欢推送未完成的代码，所以他在本地分支工作

好吧，很高兴知道，我正准备做我自己的模块，但我想我也可以为 Godot 2.2 或 3.0

不会有 2.2 版本，Godot 开发人员将所有 2.2 功能移至 3.0。

这是我第一次发表评论。 我从 Unity 过来，迁移到 GDscript 一直是我的梦想。 不到一天，我就学会了这门语言。 我喜欢该语言在引擎中的实施效果，而且我的工作效率也大大提高了。

我主要担心的是，在增加了 C# 支持后，GDscript 将被抛在后面，或者在大量 Unity 开发人员之后看到更少的开发。 C# 是一门很好的语言，但不是我个人的最爱

此外，我担心看到 Godot 试图更像另一个引擎，而不是独立存在。 Unity 是一个神话般的成功故事，但不是我用过的最好的引擎。 它臃肿而且有缺陷。 一旦它在没有确认的情况下删除了我的整个项目。 处理错误和无法正常工作的事情是一场持续的斗争。 我数不清有多少次我不得不完全重建我正在制作的场景，因为事情不正常。 我曾经将一个旧的越野车场景中的所有内容复制并粘贴到一个新场景中，尽管两个场景相同，但它突然可以工作了。 我花了数周时间寻找会神奇地出现和神奇地消失的物理错误。

我真的很喜欢 Godot 简洁易懂。 与 Godot 合作就像使用调音良好的乐器一样。 经过近一年的工作，我只知道如何做我需要做的任何事情，即使我以前没有做过。 我只是希望 Unity 用户的涌入不会将引擎的方向转向 Unity。 如果我想要 Unity，那么我会使用 Unity。

@zaywolfe其他用户已经多次表达了您的担忧。 你没有什么可担心的。 GDScript 将继续成为 Godot 的主要语言。

我不喜欢 GDScript 。 我知道那是仿照 Python 建模的，但我觉得很微不足道。 在我看来，包括 C++ 或 Java（开箱即用）将是一个好主意。 我个人对在开发中使用 GDScript 感到厌恶，以至于质疑是否要离开 Godot 并在实现新（或替代）语言时再次回来。 对不起，但如果你想从程序员那里得到确凿的事实，你得到了它们。

另外，我想提一下，有时我什至使用 Godot 进行一些简单的软件原型设计。 因此，深度集成的编程语言可能会为引擎内的软件开发打开大门。 那将是真正的 Unity 杀手。 （当然，如果选择了 Java 或 C++）

感谢忠实的开发者的辛勤工作，我向你们所有人致敬，我期待着未来的更新版本！

@VenHayz我不知道你是否阅读过Godot文档，但你已经可以用C++编写你的游戏了，因为Godot的第一个版本- http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

使用 microsoft .net 内核怎么样？ 它是跨平台和注重性能的，也是开源的并且正在积极开发

你好只是一个随机路过的人

我想让你知道我没有使用 Godot，因为我不喜欢你使用的脚本语言

如果您添加 Java 或 C#，那么我将在您发布消息后立即安装和使用 godot :)

@RUSshy那么再见，这是你的损失，godot 很棒，GDScript 很棒，如果你是一个真正的程序员，你需要两个小时才能知道足以开始任何项目。 真正的程序员必须掌握多种语言，你可以坚持你的java/C#，做一个永远作为业余爱好者路过的“随机”人。 我不是要粗鲁，只是陈述事实。 如果你不喜欢这个引擎的某些地方，那么可以贡献一些代码，它不像大多数其他引擎那样是免费的。

营销之神偏爱 C#。 ：笑：

@RebelliousX选择 Java 或 C# 意味着您将拥有可供使用的库

将自己限制在自制脚本语言是没有用的，您的新知识将无法在其他地方应用，您将无法找到大量的库，或者无法重用您的知识或现有的学习资源

现在的选择很疯狂，不要心胸狭窄

@RUSshy你在开玩笑吗？ 我（和其他几个人）写了几页关于 GDscript 相对于 C# 的好处的解释，你认为你可以用一个简短的段落来解决讨论，而无需阅读之前所说的任何内容？

“不要心胸狭窄” - 好主意，您从对 GDscript 保持开放的态度开始怎么样？
“你的新知识将不适用于其他地方”——这完全是错误的。 您将无法通过复制粘贴您不理解的代码来弥补知识的不足。
“你将无法找到大量的库”——了解脚本语言和后端语言之间的区别。 或者 - 疯狂的想法 - 阅读我写的关于它的内容。

说真的，有些人的胆子...

在不同的地方已经多次提到 C# 集成模块正在开发中。 它的速度与人们必须这样做的时间一样快。 使其更快的唯一方法是为这种集成做出贡献:)

@Warlaan关于第二点：如果您之前在 C# 中编写了大量代码，则除非您将其全部移植，否则您将无法重用它。 您也无需了解库的代码即可使用它。 关键是，如果您需要以前在 C# 中的东西（单个文件或一组库，可能是封闭源代码），您需要移植所有内容、嵌入 C# 运行时或找到 C 实现。 这并非不可能，但很耗时。
这并不意味着 Godot 不能使用大量现有的库……C/C++ 也有很多。

这有可能成为一场火焰战。
日志很长，以至于人们会重复相同的问题或主题而不是阅读它。
也没有太多技术性的东西可以讨论。

Godot 在脚本方面的未来已经非常明确：

• GDScript 将继续作为主要语言，并且有优化它的计划或想法（但这里不适合讨论）。
• 从 3.0 开始，将支持 C# 作为脚本替代方案。 我们将提供单独的二进制文件，以避免将单声道运行时导致的额外大小强加给不会使用它的人。
• DLScript 也在工作中。 它将允许人们使用共享库来编写脚本。 这些库可以用任何支持 c 链接和共享库的语言编写（除了 Rust 和 D 等语言）。 目前尚不清楚它是否会为 3.0 做好准备（除非我已经过时了）。
• 不要忘记 3.0 中也会有可视化脚本！

如果有人打算贡献其他东西，这里也不适合讨论这个问题。

我认为这个问题可以而且应该关闭。

同意。

能否提供 C# 集成源代码的链接？

https://github.com/neikeq/GodotSharp

GodotSharp 功能如何集成？ 准备好用于测试了吗？
可以与 godot master 的源代码构建一起使用吗？

@nictaylr目前没有与 master 一起构建。 如果你想测试它，你需要使用 2.2-legacy。 它与那个版本配合得很好

我正在努力让它为 4 月的 3.0 alpha 做好准备。

随机的想法，但在与 Godot 深入思考 C++ 之后，我想到了可能更好的东西。 D语言。 它属于可以说是“低级”语言配额，具有与 C和（某些）C++ 支持的接口。 它有课程，非常现代。 虽然听起来很吓人，但它看起来很像 GDScript ，我可以看到它被用于支持非常大的项目。 它的功能强大到足以通过称为 GDC 的编译器与 C 和 C++ (gcc/g++) 竞争。 （DMC也可以用来编译，但是GDC直接编译成gcc）在这里查看更多关于GDC

无论如何，只是一个快速的建议或想法。

@VenHayz我正在开发一个模块，该模块允许将共享库用于脚本。 我已经付出了一些努力来使 C++ 更易于使用。 您也可以使用 D 创建这些库。 如果您对制作 D 绑定感兴趣，请在 IRC 或 Discord 上联系我。

@karroffel这真的很酷。 我没有编写库和 API 的经验（参考您提到的“绑定”），但我可能只需要研究一天就可以了； 我自豪地是一个快速的学习者。 如果您不介意，我想在 Discord 上与您联系？ 我的不和谐：_hasCat#3941

@VenHayz我不能加你，你不允许其他人加你。 Karroffel#8409 或加入Godot 服务器

@neikeq您的 GodotSharp 存储库是用于支持 Godot 3.0 中的 C# 的代码库吗？ 只是问，因为我想大致了解哪些功能可用，如果可用，我会围绕该代码库进行探索。 谢谢！

我看起来很锋利，过时了吗？ 新功能 ？ 还是准备在开发构建中使用？

我怎样才能为我从源代码编译 Godosarp？

@nictaylr您需要使用 2.2-legacy 分支作为开发版本。

我想我读了足够多的书来弄清楚是否有人提到了这一点。

我个人只是不想学习另一种我无法在其他任何地方使用的语言。 我不打算做很多 3D 编程，只是在这里和那里做一些事情。

是的，有很多反对意见，但是……这是一个开源项目。 没有必要讨厌有人贡献一种新的编程语言。

想象一下把啤酒带到孩子们的聚会上。 你会说“没有必要讨厌有人提供新饮料”吗？ 添加 C# 很有可能会损害 GDscript 的开发。 我知道每个人都决心将 GDscript 保留为 Godot 的主要语言，但是当我多次解释为什么添加新功能有缺点并且人们仍然在问“有什么害处？”时，我仍然感到恼火。

还要求使用 C# 而不是 GDscript，因为“你不想学习”是一个非常愚蠢的论点。 在我所知道的游戏开发语言中，GDscript 的功能最少，而 C# 的功能最多。 如果你不想学习，你应该感谢 GDscript。

我真的不想一次又一次地热身这个讨论，所以如果有人想对此线程发表评论，请从顶部阅读。

还要求使用 C# 而不是 GDscript，因为“你不想学习”是一个非常愚蠢的论点。

我不介意学习 C#，因为我可能可以在其他地方使用它。

锁定线程，它变得越来越卑鄙。

确实，这个线程已经达到了它的目的，让我们锁定它。