How do game companies handle DLL resources?

Question

This question is based solely on curiosity. I have played a great many games on my PC over the years, and just now realized a trend across all games(most if not all). In the resources of the game, or in other words, next to the executable that runs the game, there are never DLL(Dynamic Link Library) binaries. This means that those games are created by statically linking to source files and dumping them all into the primary executable. I am certain that most of these game projects: Call of Duty, World of Warcraft, Splinter Cell, and [Include other arbitrary examples here], are utterly massive by scale and have hundreds of smaller children projects. I would probably not be wrong, either, in assuming that those same projects(such as API's, etc) could be packaged into a DLL instead of the obvious static linking. I apologize if it seems like I am rambling, but there is a point to this; it will be coming up soon. Next, I wanted to address the use of the games graphics API. Most games use DirectX, why is not relevant to this question; instead, it is how. Would I be safe to assume that said games are also statically linking to DirectX? And more importantly, why? Is there a logistical reasoning behind this inherently-conventional trait? Do game companies statically link all of their resources? And just again, why? Why not use DLLs instead?

Hopefully someone can answer this question, having been present or currently are present, working for an actual game company. Oh and I typed this all on my phone so I apologize for any errors.

Answer 1

Well, for the first part a lot of modern games are coded in C++, which supports namespaces. Namespaces allow you to group a collection of related code within part of a whole. So you could have a collection of namespaces such as 'Render', 'Input', 'AIProcessor', etc (note: I am making these up)

Building these subprojects into the main project allows all of them to be shipped without forgetting to include a DLL in the installer (imagine the controversy if a developer forgot to include a subproject DLL in the installer upon release - the game wouldn't work for the end users until the developers released a patch with the missing DLL!)

Now, I only work with a small fledgling indie studio, but we have namespaces such as 'RenderEngines', 'SystemEngines', 'Interfaces', etc. in our game. Its far easier to include these in as namespaces instead of exporting them out to their own DLL, especially when I ship the next build to the team - I have enough problems with missing content files every now and then.

As for DirectX, often when installing (going from watching installers) they ask if you want to install the specific version of DirectX the game was built with. This gets installed to a predefined location on your computer, and the game loads the DirectX DLL's when you run it.
Even if you don't install the specific version, the DirectX install is smart enough to reference another version and use that. I have had problems previously with a game before requiring a very specific set of DirectX versions to work properly, otherwise it would crash if I started fiddling around with the graphics settings.

Answer 2

DirectX is a windows API with a corresponding DLL somewhere in your C:\windows directory, similarly with opengl32.dll. Check with dependency walker in you don't believe me.

The rest is probably handled through scripts which don't have to be DLLs and just reside in the rest of the assets.

Answer 3

Capsuling game modules in shared libraries has the benefit of reduced compile times during development. If the API between modules is carefully designed, it will not change often. This allows you to recompile only the module you are working on.

Shared libraries also allow to be shared by multiple Applications, thus saving disk space (and for a certain degree also memory when loaded by multiple application). They can also be distributed independently of the application which uses them.

But packaging your game modules in shared libraries has also draw backs. The main reason for games in my opinion: performance. Calling shared library functions involves a slight overhead to calling normal functions (a additional look up in a function address table). Linking dynamically also prevents global optimization. If you setup your build so that the compiler sees all source files it can perform optimization more aggressively. This requires static linking.

There are more arguments pro/con shared libraries, some of them have been mentioned in the other answers. But these are the main ones in my opinion.

Answer 4

Shared libraries such as DirectX have their DLLs installed under DirectX, not in the game folder.

Many game projects are divided up into multiple modules, particularly for different types of resources, but possibly also for modules or libraries. Breaking them up is useful for reducing patch sizes, for one thing. However, modules for a particular game are rarely if ever going to overlap with modules for any other game, and rarely will a game installer attempt to use the same module used by some other game installation, again unless it's a shared library such as DirectX. Otherwise there could be some dependency incompatibilities between versions - you wouldn't want updating game B to possibly mess with game A - you wouldn't want to have to even think about that possibility.

Usually DirectX is also backwards-compatible (so you can only have DirectX 10 installed and games written for DirectX 9 will work), though I think that has sometimes eroded a bit in practice.