I'm trying to experiment with using multiple projects in visual studio one for the engine and one for the game and I'm getting confused because how on earth does the engine find the game project directory technically the game can be anywhere? I realized though that the engine probably needs to be a lib or dll that is put with the rest of the game files meaning it doesn't matter where the game is and I guess any game I make would just reuse the dll. Assuming I'm correct I have two questions about this:

A) does the lib/dll need to be in the games directory or can it be anywhere on the computer as long as the system knows where to find it?

B) say the engine has a function which gets an asset like “Engine/Assets/Textures/wood.png” well if it's a dll within the game directory I assume it would have to be "MyGame/Assets/…"

Apologies if I butchered this, but hopefully that makes sense 😅

Best practice is usually to link everything statically into a single .exe, if possible. This will give the most efficient code generation (e.g. allows for link-time code generation), and avoids the hell of using C++ across DLL boundaries. If your project is large, you can divide it into multiple static libraries and link those into your executable. I also like to statically link the C/C++ runtime as well, to avoid issues with missing redistributable DLLs that require installing runtime libraries for the right visual studio version. Static linking means that your code is less likely to break due to missing DLLs, or incompatible DLLs. DLLs are also a security risk, since the user can replace them (many mods use this technique as a backdoor to inject functionality, e.g. by reimplementing a common direct X or input DLL). Some games (e.g. steam ones) can be cracked easily by just replacing the steam DLL with a dummy one that implements the API but doesn't connect to steam servers.

The exceptions to static linking might be if you are using a closed-source 3rd party library which is precompiled as a DLL. In that case, you have no choice but to use a DLL.

There are rules for DLL lookup followed by the loader. I believe first it looks in the same directory as the .exe, and if not found there, looks in system directories. This is for automatic library loading. You can also manually load DLLs, in which case you control where to look. Many softwares with plugin architectures use this approach to load DLLs from a “plugins” directory.

I'd recommend that when you build your game's executable, you copy it automatically into where the final built assets are located, and run it from that location. Then, all paths can be relative to the executable (the executable will also need to set the current working directory to the executable directory). It doesn't make sense for the engine to be in a different location than the assets.

I hope I interpreted your question correctly. Actually the game has to find the lib, not vice versa. And that is done by installing the lib in a system directory for libs. There are more than one such system dir. And yes, it can be anywhere as long the system knows where to look.

For many of the major game engines it's actually the reverse. The engine is the main program which loads your game's module as a subset, alternatively, loads the editor and debug tools as a subset.

Using static or dynamic binding is an implementation detail, and some engines like Unreal support both. On game consoles of the past you needed a monolithic program, but these days the systems are fully modern operating systems.

ShapeSpheres said:
how on earth does the engine find the game project directory technically the game can be anywhere?

There are typical search paths, in addition to paths specified in your configuration.

Normally they're specified precisely because the program searches the configured directories and looks for libraries, then loads them with their full path to avoid ambiguity. If finds MyGame.dll or AwesomeAudioLibrary.so, it will provide the full path and attempt to load from there.

The search method if they aren't in the given directory depends on the system you're on and the library functions you use.

On Windows the library search order is quite long, not just any paths you specify but also paths set by DLL redirection, manifest redirection, registered or “known” DLL's, package dependencies specified in a manifest, the application's root directory, system folders, and even a broad search of the full path environment variables.

In Linux it searches the location in the library as a relative and absolute path, directories in the binary's configuration, the LD_LIBRARY_PATH directories, the cache path, and the default library paths for the system.

But again, usually engines are programmed defensively so they don't run the full search, they have the explicit directory location.

ShapeSpheres said:
say the engine has a function which gets an asset like “Engine/Assets/Textures/wood.png” well if it's a dll within the game directory I assume it would have to be "MyGame/Assets/…"

That's not dynamic library directories. The asset management system for the game will address those paths. Unreal uses a system similar to what you described, you can have assets in the engine directory, the project directory, and in plugin directories, and the system abstracts it all away so you just see the path “/Game/Levels/MyLevel.umap” without knowing or caring about the physical layout. By default it maps to the directory structure, but it's designed so you can manipulate the data tree, like anything else.

Aressera said:
Static linking means that your code is less likely to break due to missing DLLs, or incompatible DLLs. DLLs are also a security risk, since the user can replace them (many mods use this technique as a backdoor to inject functionality, e.g. by reimplementing a common direct X or input DLL). Some games (e.g. steam ones) can be cracked easily by just replacing the steam DLL with a dummy one that implements the API but doesn't connect to steam servers.

All true but a misplaced fear.

Statically linked programs can be cracked just as easily by skilled attackers. System libraries have well-established patterns and tools can trivially replace them even when statically linked.

For analysis tools standard libraries and common functions will still all be identified, and can still be replaced, they'll just take a few extra milliseconds for the tools to identify.

If the only protection you've got on your game is that you're relying on third-party libraries to control access, you've already lost that battle regardless of being static or dynamic linking.

On Windows the library search order is quite long, not just any paths you specify but also paths set by DLL redirection, manifest redirection, registered or “known” DLL's, package dependencies specified in a manifest, the application's root directory, system folders, and even a broad search of the full path environment variables.

In Linux it searches the location in the library as a relative and absolute path, directories in the binary's configuration, the LD_LIBRARY_PATH directories, the cache path, and the default library paths for the system.

That's what I meant.

For many of the major game engines it's actually the reverse. The engine is the main program which loads your game's module as a subset, alternatively, loads the editor and debug tools as a subset.

Ah, being an old programmer, I wasn't aware of that until now, but you are totally right. I just learned that it is true for example with Godot. But I guess Unity and Unreal work similar.

And about the original question: It depends on the engine how it is solved/implemented. You could choose the engine by the way this question is solved (for example you could use a smaller engine which is a library), but I recommend choosing the engine by what saves you some labour.

Engines are very different in conception from each other. One engine is maybe a game maker on its own, another engine is just a minimalistic rendering library with content loading abilities.

What i always do is, chdiring to the directory of running exe file at the beginning, and search for the files there (or within the data subdirectory).