1
\$\begingroup\$

I'm undecided on a design decision. Now for my game I was thinking on splitting components into separate dlls. This would allow for a more modular approach, especially when in need of updates. On launch it [the game] could swap out newer versions of the dll coming from a centralized server. This would allow us to provide updates to each component separately and also allow us to quickly swap dll's for different implementation.

Now is this design used, and how effective is it?

I started implementing it, and loading a dll through run-time ads a lot of complexity (unless i'm doing it wrong). Another problem that could arise is some components are optional. So it would ad additional complexity.

So what i'm trying to get to is: Is splitting separate components and subsystems in dll's?

This would allow the exe to be a lot smaller, and possibly make the whole system a little more organized.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Instead of doing all the run-time loading, why not just use dll's and provide an updater that will replace the required dlls when an update is available? \$\endgroup\$ Commented Jul 13, 2012 at 11:32
  • \$\begingroup\$ Generally its a good idea to seperate stuff and put them into different libraries. However, DLLs can be a real pain when it comes to static template member variables and resource managing. For instance, you will not be able to write to a file using a FILE* pointer that was created in the DLL and used in the client-exe or another DLL. The same is true for instance for memory allocations, you cannot allocate in one DLL and free it in the exe or another DLL. I'd go for static libs. \$\endgroup\$ Commented Jul 13, 2012 at 15:28
  • \$\begingroup\$ @cli_hlt Yes that was also the plan. When the game first loads we would make a simple tcp connection to the server and check an xml file to see if any dll's require updating. Maik Semder Ahhh. With that statement I think i'll choose a different option rather than dlls. Maybe put your response as an answer so I can accept it? \$\endgroup\$ Commented Jul 13, 2012 at 22:45

1 Answer 1

Reset to default
2
\$\begingroup\$

It is not used by any game engine I've ever heard of, and I would strongly recommend against it.

All of the theoretical advantages of the model are red herrings. Smaller executables don't matter, the whole size of the loaded game matters, and an exe+dlls is larger than the same code all compiled into the same exe.

Libraries dont organize code. Your file structure (naming, folders, namespaces, etc) organizes your code. Use libraries for technical purposes, not to get around a lack of knowledge on how to use Visual Studio filters properly. One good reason to use separate static libs in Visual Studio is to use different sets of precomputed headers, for instance.

Updating via DLLs is also not a good use of time. The DLLs are going to be tightly tied to the specific version of the EXE being run an probably to the other DLLs as well (components have dependencies on othe components).

Reloading DLLs is not a good idea, either, for similar reasons to the previous point. Plus, reloading the DLL means you have tO unload all data it's using, serialize it somehow, reload the DLL, then unserialize the old data.

As others pointed out, there are many complexities and limitations of using separate DLLs. Given all those costs and a complete lack of any real benefit, there's just no reason to go that route.

As a final note, remember that the compiler can't optimize across DLL boundaries. Your game will be much slower than if you compile everything into a single EXE with link-time code generation turned on.

\$\endgroup\$
1
  • \$\begingroup\$ That makes a lot of sense. Even starting to split into dlls was starting to add a huge level of complexity. So I think i'll stick to regular folders, namespaces, etc... Thanks. \$\endgroup\$ Commented Jul 13, 2012 at 22:52

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.