问游戏公司如何处理DLL资源？

EN

在第一部分中，很多现代游戏都是用C++编写的，它支持名称空间。命名空间允许将相关代码的集合分组在一个整体的一部分中。因此，您可以拥有一个名称空间集合，如'Render‘、'Input’、'AIProcessor‘等(注意:我正在编造这些)。

将这些子项目构建到主项目中，所有这些子项目都可以在不忘记在安装程序中包含DLL的情况下交付(想象一下，如果开发人员在发布时忘记在安装程序中包含一个子项目DLL --在开发人员发布包含缺失DLL的修补程序之前，游戏不会为最终用户工作！)

现在，我只和一个羽翼未丰的独立工作室合作，但我们的游戏中有“RenderEngines”、“SystemEngines”、“Interfaces”等名称空间。将它们作为名称空间包含起来要容易得多，而不是将它们导出到它们自己的DLL中，特别是当我将下一个构建交付给团队时--我经常会遇到丢失内容文件的问题。

至于DirectX，通常在安装(从观看安装程序开始)时，他们会问您是否希望安装游戏所用的特定版本的DirectX。这将被安装到计算机上的一个预定义位置，游戏在运行它时加载DirectX DLL。

即使您没有安装特定版本，DirectX安装也足够聪明，可以引用另一个版本并使用该版本。在需要一组非常具体的DirectX版本才能正常工作之前，我曾经遇到过一个游戏的问题，否则如果我开始摆弄图形设置，它就会崩溃。

DirectX是一个windows，在C:\windows目录中有一个相应的DLL，类似于opengl32.dll。去问问依赖步行器，你不相信我。

其余部分可能是通过脚本处理的，这些脚本不必是DLL，只驻留在其余的资产中。

在共享库中封装游戏模块可以减少开发期间的编译时间。如果模块之间的API是精心设计的，它不会经常更改。这允许您只重新编译您正在处理的模块。

共享库还允许多个应用程序共享，从而节省磁盘空间(并且在一定程度上也节省了由多个应用程序加载时的内存)。它们也可以独立于使用它们的应用程序分发。

但是，将游戏模块打包到共享库中也会产生倒退。在我看来，游戏的主要原因是:表现。调用共享库函数涉及到调用普通函数的轻微开销(在函数地址表中进行额外查找)。动态链接也会阻止全局优化。如果您设置您的构建，以便编译器看到所有源文件，那么它可以更积极地执行优化。这需要静态链接。

有更多的参数赞成/反对共享库，其中一些已经在其他答案中提到。但在我看来，这是主要的问题。