# How do game companies handle DLL resources?

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.

• I challenge the premise. I took a look at Guild Wars 2, Starcraft 2, and most of the Steam games I have installed (Left 4 Dead, Fez, Braid, Mark of the Ninja, Pinball Arcade, Antichamber, X-Com Enemy Unknown, and all of them are full of DLLs (and not just steam_api.dll). In fact, any closed source software that uses third-party LGPL libraries must use DLLs. – jamesdlin Mar 15 '15 at 6:15
• @jamesdlin I'd expand on that with a full fledged answer, I think its the one closest to the truth. – akaltar Mar 15 '15 at 13:12

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.

• I think that the reasons you mention aren't real. If they miss a .dll, they might just miss a texture or model file, and most games crash when that happens. I would also say that most game have .dll files, just sometimes in a separate folder. – akaltar Mar 15 '15 at 13:10
• Just because it hasn't happened yet doesn't mean its not real. Well, it probably has happened, I'm just not aware of any games that have had this happen. And in terms of DLL's, I'm addressing the instance where a game developer has one (or more DLL)'s for every aspect of the engine - here's a DLL for reading XML we made, here's one that stores all the game objects, here's another with our game loop, etc. You end up with an engine that has dozens of DLL's where there should only be the exe and one or two others, excluding 3rd party DLL's. – Seta Mar 15 '15 at 18:21
• Still the reason is not "Not to forget" them, but that creating them is a additional problem, and if they won't be reused Separately Then they are unnecessary. – akaltar Mar 16 '15 at 14:08
• @akaltar Ah, ok. Do you mind if I edit that into my answer crediting you? There are a few other revisions/clarifications that I want to make as well. – Seta Mar 16 '15 at 19:44
• That's the whole point of commenting I think, so yes, sure. You could also add that game engines might use multiple dll-s so unnecessary code isn't loaded and distributed(Here the components are reused separately). Or custom-built engines might have a single dll which makes it easier to create tools for the game(The dll contains the shared code, I do it this way too) – akaltar Mar 16 '15 at 19:58

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.

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.

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.