Godot Engine(godotengine / godot在GitHub上)是一个开源的,主要基于C ++的游戏引擎。 它同时支持2D和3D。 作为一名参加网络科学课程的C ++程序员,我决定生成#include“…”的依赖图,并尝试确定图中最重要的文件。
这样,我希望发现哪些文件对于想要为Godot做出贡献的初学者来说很重要。

我使用了基于Python的脚本cinclude2dot2,直接从GitHub存储库中的Godot源文件中解析C / C ++源文件,并检测包含文件的行。 手动清除了数据并删除了其目录路径,仅保留了文件名。 这意味着具有重复名称的文件将合并到图中的一个节点中。 这是不希望的。
我使用Gephi来执行可视化和所有度量标准计算,并在图形上使用各种设置运行OpenOrd和ForceAtlas2。
首先,让我们介绍一些概念。
- 程度是一个文件被其他文件包含多少次。
- Out-Degree是一个文件包含其他文件的次数。
- 学位是学位内和学位外的总和
- PageRank是著名的Googley网页排名算法,但通常它也可以应用于图形! 在这里,我们使用它来对依赖图中的文件进行排名。
程度内

首先,根据排名,我们可以看到配置和访问设置文件config.h和project_settings.h非常流行。 不幸的是, config.h目前是5个不同文件的混合物,但是所有文件都位于thirdparty /目录中:
./thirdparty/squish/config.h
./thirdparty/pcre2/src/config.h
./thirdparty/opus/config.h
./thirdparty/mbedtls/include/mbedtls/config.h
./thirdparty/libvpx/vpx_ports/config.h
因此,我们可以得出结论,Godot(或者Godot使用的代码)相当关注这些库。 没什么大不了的,但是如果我们想仔细看的话,也许我们以后可能会想分解。
os.h是一个非常重要的文件,因为它是处理更改视频模式,查询操作系统的内存使用情况等的类。
奇怪的是,像Object这样的重要类没有在这里显示! 对于图形中重要的节点,In-Degree是非常幼稚的度量-稍后您会看到更好的度量。
超越学位

如果我们假设必须理解来自其引用的标头的内容,则可以将出学位解释为“要理解的最复杂的文件”。 因此,将Godot编辑器和场景管理器显示在此列表中是合适的。 但是,如果我们认为register_types.cpp实际上是30多个不同文件的名称,那么大量数字就会变得不那么令人恐惧了……
您可能已经注意到某些带有“ bt”前缀的文件不断出现。 这是什么? 这是Bullet物理引擎,已在许多开源项目以及商业项目(甚至是电影!)中使用了Bullet物理引擎。有意义的是Bullet文件在此处的显示非常高,因为物理和碰撞不是一件容易完成的任务并了解。
网页排名

PageRank是一种算法,该算法根据其他节点的权重得出节点的权重,从而支持直接指向该节点而不是远离该节点的连接。 因此,PageRank不仅创建了一个更“全局”的指标,而且还偏向于依赖引用接收方的节点。
我们可以看到与其他指标相比有很大的变化。 我们可以在typedef.h中看到更重要的文件,例如Godot重新实现的vector,“将在各处使用的基本函数和定义”以及Godot的String类。
因此,也许当人们经过Godot时,留意其中的一些会有所帮助! 奇怪的是,您将在此列表中遇到头文件,而大多数其他人也会看到。
中间性

中心度度量标准非常适合于确定图的“核心/中心点”上的节点。 在这里,我们最终可以看到Object(几乎是所有东西的基类)在排行榜中名列前茅-即使官方文档也认为它很重要! 变体“引擎中最重要的类”也出现在第二名。 没有在文档中为其提供自定义指南的文档中没有很好记录的结果是针对GUI的类Control — control.h受大量代码库的影响,并且会影响大量代码库,如果我们认为Godot,这是合适的引擎的编辑器构建在其自己的GUI框架中。
- 旁注:我个人认为Godot将自己的编辑器作为Godot游戏打造的壮举是一件很酷且独特的事情! 我认为这值得更多的曝光。
editor_node.h和node.h似乎分别构成了编辑器和场景引擎的骨干-可能是他们深入了解Godot的主要研究对象。
这里的许多类都暗示了基本系统,例如映像,主机循环或编辑器本身。
重要集群/模块
在Gephi中,我运行了模块化检测功能,试图将Godot代码库分为不同的群集,但这次,我决定基于中间性来加权节点大小,因为它倾向于与官方文档在Variant和对象 。 以下是新图片,仅对7个最大的簇进行了着色:

类别1:核心和编辑者(26%)

群集2:主要,配置和库(14.53%)

类别3:物件,变体(14.11%)

类别4:项目符号库(9.2%)

群集5:libvpx(6.75%)

结论
我们发现有关Godot的一件有趣的事情是,它的大量代码库甚至都不是Godot本身的一部分。 可以预期存储库中至少有10–15%的Godot引擎代码是相当孤立的,但仍然被其他库大量引用-也许开始遇到这些高影响力文件的工作人员可能会发现自己必须学习这些库将他们的发展推向新的高度。
我们发现,Godot中的大多数代码受core /目录下的许多文件的影响是正确的,并且已经确定了一些可能适合进一步文档编制的重要候选文件。 这种分析证实了Variant和Object是Godot引擎中两个非常重要的类的观点,尽管还有许多其他重要类也极大地影响了它们在代码库中的作用。
档案
以下zip文件中包含许多但不是全部的图片和数据:
godot-all-graph-analysis.zip